From dime-bounces@ietf.org Wed Mar 01 07:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQaj-0001Ef-1s; Wed, 01 Mar 2006 07:38:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQai-0001Bx-5A for dime@ietf.org; Wed, 01 Mar 2006 07:38:04 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEQag-00044m-TL for dime@ietf.org; Wed, 01 Mar 2006 07:38:04 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k21CbtVS086579; Wed, 1 Mar 2006 07:37:58 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44058911.10801@tari.toshiba.com> Date: Wed, 01 Mar 2006 06:44:17 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Kristensen Subject: Re: [Dime] answer routing References: <44036026.9090106@cisco.com> In-Reply-To: <44036026.9090106@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Anders, > RFC 3588 talks about request routing but AFAICT it doesn't really talk > about how answer messages are routed. Given that request failover is > triggered by connection failures I concluded that answers are always > sent on the transport connection that the request was received on and > if that connection has failed the server just doesn't send the answer. > It's recommended somewhere that the server hang on the answer for a > period of time in case the request is retransmitted to the same server > on a new connection but the server would not send the answer on a new > connection without first receiving a retransmission of the request on > that connection. I agree in part. The base proto is not clear about the behavior when it has to send an answer when its own link to that route has recently broken. Though, I'm not sure if storing answer messages in the base protocol is useful because there is already a request retransmission mechanism. If a retransmitted request is received by a server on a new connection, the T flag is set and the application itself can have the intelligence to respond accordingly and send an answer on that new connection. > > The other piece of supporting evidence is that answer messages do not > contain Destination-Host (3588, 6.2) which I think would be a > reasonable thing to expect if answers were routed in a way similar to > requests. I agree. hop-to-hop id is the only method. Regards, victor > > Is this the correct interpretation? Did I miss an explicit statement > to this effect anywhere in the base spec? > > Thanks, > Anders > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 07:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQcc-0004gx-P4; Wed, 01 Mar 2006 07:40:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQcb-0004gi-Bz for dime@ietf.org; Wed, 01 Mar 2006 07:40:01 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEQcX-0004A8-U8 for dime@ietf.org; Wed, 01 Mar 2006 07:40:01 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k21Cdsqs028649 for ; Wed, 1 Mar 2006 14:39:57 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 14:39:53 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 14:39:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Mar 2006 14:39:52 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869D31@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interop update (redux) Thread-Index: AcY9LTjtA8ENe/xgSrW6PvthUtktSQ== From: To: X-OriginalArrivalTime: 01 Mar 2006 12:39:53.0728 (UTC) FILETIME=[3D434800:01C63D2D] X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Dime] Interop update (redux) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Dear Diameter Interop Teams, =20 Due to a technical issue, registrations submitted for the Ulticom-sponsored Interop Testing being held April 24-28 in Mt. Laurel, NJ have been lost. Please visit http://www.ulticom.com/html/diameter-interop/registration.asp to re-register. This does not affect your hotel reservations, merely registration for the event itself. We apologize for the inconvenience. =20 Sincerely, Ulticom Events Staff _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 07:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQll-0007zb-OV; Wed, 01 Mar 2006 07:49:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQlk-0007th-9b for DiME@ietf.org; Wed, 01 Mar 2006 07:49:28 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEQlj-0004bY-1o for DiME@ietf.org; Wed, 01 Mar 2006 07:49:28 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k21CnMe6014857; Wed, 1 Mar 2006 06:49:24 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Mar 2006 13:49:21 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097219C9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: DiME@ietf.org Date: Wed, 1 Mar 2006 13:49:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Dan Romascanu \(E-mail\)" , "David Kessens \(E-mail\)" Subject: [Dime] Permanent DiME chair appointments delayed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org [bcc: to the candidates, to ensure they get this. they should be on the WG mailing list though.] DiME WG members, as you all know (or so I assume, because I posted that to this list), John Loughney is acting WG chair. We did this to ensure that we have proper preparation for the upcoming IETF meeting. One of the reasons why the ADs are still not done with selecting one or two permanent WG chairs is the fact that at least 2 (as far as we know) candidates have been nominated for TSV AD. And those 2 candidates would decline if they get appointed to be AD. You may all have seen, that the nomcom has extended their call for nominations for that AD position. It looks like the nomcom will not be able to announce the 2nd TSV AD appointment before very close to the Dallas meeting. As a result, we (ADs) intend to NOT change the acting WG chair before the upcoming IETF. The candidates will be contacted between now and Dallas for further discussion. So pls bear with us, and pls give John all the support so that we have a productive first WG session. Bert, David and Dan Romascanu (Berts successor after Dallas). _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 08:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERWW-0007HV-UO; Wed, 01 Mar 2006 08:37:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERWV-0007HQ-Bu for dime@ietf.org; Wed, 01 Mar 2006 08:37:47 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FERWV-0005uB-0C for dime@ietf.org; Wed, 01 Mar 2006 08:37:47 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k21Dbc9W086748; Wed, 1 Mar 2006 08:37:39 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4405A3A4.8010301@tari.toshiba.com> Date: Wed, 01 Mar 2006 08:37:40 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "German Blanco (E2/EEM)" Subject: Re: [Dime] Invalid AVP within a Grouped AVP References: <7457D12699374F40BD026D2B1EFFBEC60138BE66@eesmdmw020.eemea.ericsson.se> In-Reply-To: <7457D12699374F40BD026D2B1EFFBEC60138BE66@eesmdmw020.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id k21Dbc9W086748 X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, >Wouldn't it be better to give to the peer that makes the error as much i= nformation as possible? > >One way to do that would be to send the Failed-AVP with the erroneous AV= P, but inside the Grouped AVP. That is, sending a Diameter Answer with o= nly the Grouped AVP that failed, containing a Failed AVP with the AVP tha= t caused the error. > >I believe that for an application, it would be very interesting to know = which is the part of the information that was erroneous or missing in the= request. And since the Grouped AVP will contain more than one informati= on element, it would be hard to guess which is the one that caused the pr= oblem if the answer only refers to a problem in the Grouped AVP. > >You could argue that it may not be possible to include the Failed-AVP in= side the Grouped AVP, since the ABNF of the Grouped AVP could avoid this = possibility. But since this will be a revised version of Diameter, then = it could also be recommended or mandatory to allow the Failed AVP inside = Grouped AVPs. Would that be feasible? > =20 > I think it maybe better to just extend the definition of Failed-AVP to somehow provide inheritance information of each offending avp belonging to a group (which maybe deep). This is probably easier for a parser since the failed-avp occurs only at the root level as it is now (instead of deep inside a group). It also minimizes ABNF changes. Additionally, I also think reason code(s) (i.e, avp not allowed, duplicate avp etc) for the each offending AVP should be provided instead of just relying on the value of result-code avp since each offending AVPs could have different reasons for failing. Regards, victor >Thank you for bringing up this issue, I also think that it would be a go= od idea to include it in the next RFC. > >German. > > =20 > >>-----Original Message----- >>From: Anders Kristensen [mailto:andersk@cisco.com]=20 >>Sent: s=E1bado, 25 de febrero de 2006 15:45 >>To: john.loughney@nokia.com >>Cc: dime@ietf.org >>Subject: Re: [Dime] Invalid AVP within a Grouped AVP >> >>OK, makes sense. Probably should be made explicit in the next=20 >>version of the spec. >> >>Thanks, >>Anders >> >>john.loughney@nokia.com wrote: >> >> =20 >> >>>I agree with David on this. The top-level AVP would be the best to=20 >>>return the with the error. >>> >>>John >>> >>> >>> =20 >>> >>>>-----Original Message----- >>>>From: ext David Connelly [mailto:dconnelly@gmail.com] >>>>Sent: 25 February, 2006 08:16 >>>>To: Anders Kristensen >>>>Cc: dime@ietf.org >>>>Subject: Re: [Dime] Invalid AVP within a Grouped AVP >>>> >>>>I think the top level AVP is better since it is really the=20 >>>> =20 >>>> >>AVP whose=20 >> =20 >> >>>>value is incorrect. It is also less ambiguous in some=20 >>>> =20 >>>> >>situations. For=20 >> =20 >> >>>>example, if a CER message contained a=20 >>>> =20 >>>> >>Vendor-Specific-Application-Id=20 >> =20 >> >>>>with a bad Vendor-Id AVP, and we were to return that=20 >>>> =20 >>>> >>Vendor-Id AVP as=20 >> =20 >> >>>>invalid, then how would a peer know if the Failed-AVP refers to the=20 >>>>embedded Vendor-Id or the top-level Vendor-Id AVP for the=20 >>>> =20 >>>> >>CER itself? >> =20 >> >>>>- David >>>> >>>>On Feb 24, 2006, at 1:20 PM, Anders Kristensen wrote: >>>> >>>> >>>> =20 >>>> >>>>>Suppose an AVP nested within a Grouped AVP is illegal. Should the=20 >>>>>server return the "most specific" illegal child AVP or the >>>>> =20 >>>>> >>>>"top level"=20 >>>> >>>> =20 >>>> >>>>>Grouped AVP containing the offending AVP? >>>>> >>>>>Same question for a Grouped AVP with a missing mandatory child AVP. >>>>> >>>>>Thanks, >>>>>Anders >>>>> >>>>>_______________________________________________ >>>>>DiME mailing list >>>>>DiME@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/dime >>>>> =20 >>>>> >>>>_______________________________________________ >>>>DiME mailing list >>>>DiME@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> =20 >>>> >>> =20 >>> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www1.ietf.org/mailman/listinfo/dime >> >> =20 >> > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > > > =20 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 09:16:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FES7e-0003ha-1C; Wed, 01 Mar 2006 09:16:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FES7c-0003hQ-7D for dime@ietf.org; Wed, 01 Mar 2006 09:16:08 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FES7b-0007Jt-R8 for dime@ietf.org; Wed, 01 Mar 2006 09:16:08 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id DA28799451 for ; Wed, 1 Mar 2006 09:16:07 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k21EG5jq015941 for ; Wed, 1 Mar 2006 09:16:06 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] answer routing Date: Wed, 1 Mar 2006 08:56:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44058911.10801@tari.toshiba.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Comments inline.... > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, March 01, 2006 6:44 AM > To: Anders Kristensen > Cc: dime@ietf.org > Subject: Re: [Dime] answer routing > > > Hi Anders, > > > RFC 3588 talks about request routing but AFAICT it doesn't really talk > > about how answer messages are routed. Given that request failover is > > triggered by connection failures I concluded that answers are always > > sent on the transport connection that the request was received on and > > if that connection has failed the server just doesn't send the answer. > > It's recommended somewhere that the server hang on the answer for a > > period of time in case the request is retransmitted to the same server > > on a new connection but the server would not send the answer on a new > > connection without first receiving a retransmission of the request on > > that connection. > > I agree in part. The base proto is not clear about the behavior when it > has to send an answer when its own link to that route has recently > broken. Though, I'm not sure if storing answer messages in the base > protocol is useful because there is already a request retransmission > mechanism. If a retransmitted request is received by a server on a new > connection, the T flag is set and the application itself can have the > intelligence to respond accordingly and send an answer on that new > connection. [TOLGA]IMHO RFC3588 is pretty clear about how answers are to be routed -it is as explained by Anders-. If the link where corresponding request has been received is broken, answer is not sent. OTOH, I don't know the rationale behind not acknowledging answer messages. Afterall base protocol performs some transport functionality and not to have some acknowledgement mechanism for answers causes all that hassle about storing requests and checking for retransmission if T-flag is set. It seems pretty inefficient to me. To have some guideleines about how E2E-Id is incremented, e.g. sequentially and piggybacking last received answers E2E-Id in request messages and possibly introducing a new message to send answer acknowledgement if there is no requests to send could help -just as an initial idea, I didn't think much about details- not to store received requests for long time. Asking applications to take care of retransmission is also another approach and considering that they are aware of the expected message flow, they may use that extra information to decide for retransmission more efficiently for *most* of the times, but I think this may not always be true. To define a transport protocol, where requests are retransmitted by the protocol but duplicate detection for requests is performed by the user of the protocol may be considered architecturally not elegant either. In any case, AFAICS duplicate detection in RFC3588 not very efficient, but I suspect there could be some reasons which led to the current design. If somebody knows them and shares them with us, it could be great to get more insight. > > > > > The other piece of supporting evidence is that answer messages do not > > contain Destination-Host (3588, 6.2) which I think would be a > > reasonable thing to expect if answers were routed in a way similar to > > requests. > > I agree. hop-to-hop id is the only method. > > Regards, > victor > > > > > Is this the correct interpretation? Did I miss an explicit statement > > to this effect anywhere in the base spec? > > > > Thanks, > > Anders > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 09:46:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESbH-0000A1-46; Wed, 01 Mar 2006 09:46:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESbF-00009q-MF for dime@ietf.org; Wed, 01 Mar 2006 09:46:45 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESbD-0000Cb-Q4 for dime@ietf.org; Wed, 01 Mar 2006 09:46:45 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0ACD74F0002; Wed, 1 Mar 2006 15:46:43 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 15:46:42 +0100 Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 15:46:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Invalid AVP within a Grouped AVP Date: Wed, 1 Mar 2006 15:46:40 +0100 Message-ID: <7457D12699374F40BD026D2B1EFFBEC60138BE89@eesmdmw020.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Invalid AVP within a Grouped AVP Thread-Index: AcY9NVXN046Ue6iBSJiWX94goj0yMgACWCSQ From: "German Blanco \(E2/EEM\)" To: "Victor Fajardo" X-OriginalArrivalTime: 01 Mar 2006 14:46:41.0742 (UTC) FILETIME=[F3FE16E0:01C63D3E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, Your proposal of extending the definition of Failed-AVP sounds=20 good to me too. I am not that sure that it is needed to provide information=20 about all the errors in the request, since just one is enough=20 to reject the message and (hopefully :-) only a very small=20 percentage of the requests will contain more than one error. Regards, German. > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 > Sent: mi=E9rcoles, 01 de marzo de 2006 14:38 > To: German Blanco (E2/EEM) > Cc: Anders Kristensen; john.loughney@nokia.com; dime@ietf.org > Subject: Re: [Dime] Invalid AVP within a Grouped AVP >=20 > Hi, >=20 > >Wouldn't it be better to give to the peer that makes the=20 > error as much information as possible? > > > >One way to do that would be to send the Failed-AVP with the=20 > erroneous AVP, but inside the Grouped AVP. That is, sending=20 > a Diameter Answer with only the Grouped AVP that failed,=20 > containing a Failed AVP with the AVP that caused the error. > > > >I believe that for an application, it would be very=20 > interesting to know which is the part of the information that=20 > was erroneous or missing in the request. And since the=20 > Grouped AVP will contain more than one information element,=20 > it would be hard to guess which is the one that caused the=20 > problem if the answer only refers to a problem in the Grouped AVP. > > > >You could argue that it may not be possible to include the=20 > Failed-AVP inside the Grouped AVP, since the ABNF of the=20 > Grouped AVP could avoid this possibility. But since this=20 > will be a revised version of Diameter, then it could also be=20 > recommended or mandatory to allow the Failed AVP inside=20 > Grouped AVPs. Would that be feasible? > > =20 > > > I think it maybe better to just extend the definition of=20 > Failed-AVP to somehow provide inheritance information of each=20 > offending avp belonging to a group (which maybe deep). This=20 > is probably easier for a parser since the failed-avp occurs=20 > only at the root level as it is now (instead of deep inside a=20 > group). It also minimizes ABNF changes. Additionally, I also=20 > think reason code(s) (i.e, avp not allowed, duplicate avp=20 > etc) for the each offending AVP should be provided instead of=20 > just relying on the value of result-code avp since each=20 > offending AVPs could have different reasons for failing. >=20 > Regards, > victor >=20 > >Thank you for bringing up this issue, I also think that it=20 > would be a good idea to include it in the next RFC. > > > >German. >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 09:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESeX-00011E-TS; Wed, 01 Mar 2006 09:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESeW-00010h-JM for dime@ietf.org; Wed, 01 Mar 2006 09:50:08 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESeV-0000I8-7g for dime@ietf.org; Wed, 01 Mar 2006 09:50:08 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k21Eo203087000; Wed, 1 Mar 2006 09:50:03 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4405B49C.2050302@tari.toshiba.com> Date: Wed, 01 Mar 2006 09:50:04 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] answer routing References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Comments inline ... >> >> >>>RFC 3588 talks about request routing but AFAICT it doesn't really talk >>>about how answer messages are routed. Given that request failover is >>>triggered by connection failures I concluded that answers are always >>>sent on the transport connection that the request was received on and >>>if that connection has failed the server just doesn't send the answer. >>>It's recommended somewhere that the server hang on the answer for a >>>period of time in case the request is retransmitted to the same server >>>on a new connection but the server would not send the answer on a new >>>connection without first receiving a retransmission of the request on >>>that connection. >>> >>> >>I agree in part. The base proto is not clear about the behavior when it >>has to send an answer when its own link to that route has recently >>broken. Though, I'm not sure if storing answer messages in the base >>protocol is useful because there is already a request retransmission >>mechanism. If a retransmitted request is received by a server on a new >>connection, the T flag is set and the application itself can have the >>intelligence to respond accordingly and send an answer on that new >>connection. >> >> >[TOLGA]IMHO RFC3588 is pretty clear about how answers are to be routed -it >is as explained by Anders-. If the link where corresponding request has been >received is broken, answer is not sent. > > ok. >OTOH, I don't know the rationale behind not acknowledging answer messages. >Afterall base protocol performs some transport functionality and not to have >some acknowledgement mechanism for answers causes all that hassle about >storing requests and checking for retransmission if T-flag is set. It seems >pretty inefficient to me. To have some guideleines about how E2E-Id is >incremented, e.g. sequentially and piggybacking last received answers E2E-Id >in request messages and possibly introducing a new message to send answer >acknowledgement if there is no requests to send could help -just as an >initial idea, I didn't think much about details- not to store received >requests for long time. > > I see. E2E sequencing is definitely useful and maybe the only functionality required to provide message loss and answer co-relation. Though, I probably dont understand well but I'm not sure how sending an 'answer acknowledgement' is more efficient. This seems redundant since it means acknowledging an acknowledgement. >Asking applications to take care of retransmission is also another approach >and considering that they are aware of the expected message flow, they may >use that extra information to decide for retransmission more efficiently for >*most* of the times, but I think this may not always be true. To define a >transport protocol, where requests are retransmitted by the protocol but >duplicate detection for requests is performed by the user of the protocol >may be considered architecturally not elegant either. > > I dont have strong opinions on this and it maybe a matter of semantics. In general both retransmission and duplicate detection (t-flag) is done by the base protocol. how to process receipt of a duplicate request is probably an issue left up to the application. >In any case, AFAICS duplicate detection in RFC3588 not very efficient, but I >suspect there could be some reasons which led to the current design. If >somebody knows them and shares them with us, it could be great to get more >insight. > > regards, victor >>>The other piece of supporting evidence is that answer messages do not >>>contain Destination-Host (3588, 6.2) which I think would be a >>>reasonable thing to expect if answers were routed in a way similar to >>>requests. >>> >>> >>I agree. hop-to-hop id is the only method. >> >>Regards, >>victor >> >> >> >>>Is this the correct interpretation? Did I miss an explicit statement >>>to this effect anywhere in the base spec? >>> >>>Thanks, >>>Anders >>> >>>_______________________________________________ >>>DiME mailing list >>>DiME@ietf.org >>>https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >>> >> >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www1.ietf.org/mailman/listinfo/dime >> >> >> > > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 09:53:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEShX-000238-I1; Wed, 01 Mar 2006 09:53:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEShW-00022x-J8 for dime@ietf.org; Wed, 01 Mar 2006 09:53:14 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEShW-0000LI-An for dime@ietf.org; Wed, 01 Mar 2006 09:53:14 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k21Er5RU087009; Wed, 1 Mar 2006 09:53:08 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4405B552.9000205@tari.toshiba.com> Date: Wed, 01 Mar 2006 09:53:06 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "German Blanco (E2/EEM)" Subject: Re: [Dime] Invalid AVP within a Grouped AVP References: <7457D12699374F40BD026D2B1EFFBEC60138BE89@eesmdmw020.eemea.ericsson.se> In-Reply-To: <7457D12699374F40BD026D2B1EFFBEC60138BE89@eesmdmw020.eemea.ericsson.se> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id k21Er5RU087009 X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi German, >Hi Victor, > >Your proposal of extending the definition of Failed-AVP sounds=20 >good to me too. >I am not that sure that it is needed to provide information=20 >about all the errors in the request, since just one is enough=20 >to reject the message and (hopefully :-) only a very small=20 >percentage of the requests will contain more than one error. > =20 > This is probably true. I was just thinking of more enterprising=20 implementations thats able to detect multiple avp failures. regards, victor >Regards, > >German. > > =20 > >>-----Original Message----- >>From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 >>Sent: mi=E9rcoles, 01 de marzo de 2006 14:38 >>To: German Blanco (E2/EEM) >>Cc: Anders Kristensen; john.loughney@nokia.com; dime@ietf.org >>Subject: Re: [Dime] Invalid AVP within a Grouped AVP >> >>Hi, >> >> =20 >> >>>Wouldn't it be better to give to the peer that makes the=20 >>> =20 >>> >>error as much information as possible? >> =20 >> >>>One way to do that would be to send the Failed-AVP with the=20 >>> =20 >>> >>erroneous AVP, but inside the Grouped AVP. That is, sending=20 >>a Diameter Answer with only the Grouped AVP that failed,=20 >>containing a Failed AVP with the AVP that caused the error. >> =20 >> >>>I believe that for an application, it would be very=20 >>> =20 >>> >>interesting to know which is the part of the information that=20 >>was erroneous or missing in the request. And since the=20 >>Grouped AVP will contain more than one information element,=20 >>it would be hard to guess which is the one that caused the=20 >>problem if the answer only refers to a problem in the Grouped AVP. >> =20 >> >>>You could argue that it may not be possible to include the=20 >>> =20 >>> >>Failed-AVP inside the Grouped AVP, since the ABNF of the=20 >>Grouped AVP could avoid this possibility. But since this=20 >>will be a revised version of Diameter, then it could also be=20 >>recommended or mandatory to allow the Failed AVP inside=20 >>Grouped AVPs. Would that be feasible? >> =20 >> >>>=20 >>> >>> =20 >>> >>I think it maybe better to just extend the definition of=20 >>Failed-AVP to somehow provide inheritance information of each=20 >>offending avp belonging to a group (which maybe deep). This=20 >>is probably easier for a parser since the failed-avp occurs=20 >>only at the root level as it is now (instead of deep inside a=20 >>group). It also minimizes ABNF changes. Additionally, I also=20 >>think reason code(s) (i.e, avp not allowed, duplicate avp=20 >>etc) for the each offending AVP should be provided instead of=20 >>just relying on the value of result-code avp since each=20 >>offending AVPs could have different reasons for failing. >> >>Regards, >>victor >> >> =20 >> >>>Thank you for bringing up this issue, I also think that it=20 >>> =20 >>> >>would be a good idea to include it in the next RFC. >> =20 >> >>>German. >>> =20 >>> > > > > =20 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 10:04:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESsA-0000bF-TD; Wed, 01 Mar 2006 10:04:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESsA-0000Yo-El for dime@ietf.org; Wed, 01 Mar 2006 10:04:14 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESs9-0000oq-UD for dime@ietf.org; Wed, 01 Mar 2006 10:04:14 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9BB3FA948A for ; Wed, 1 Mar 2006 10:04:13 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k21F4Cdb020572 for ; Wed, 1 Mar 2006 10:04:12 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] answer routing Date: Wed, 1 Mar 2006 09:44:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <4405B49C.2050302@tari.toshiba.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, Please see for comments below. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, March 01, 2006 9:50 AM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] answer routing > > > Comments inline ... > > >> > >> > >>>RFC 3588 talks about request routing but AFAICT it doesn't really talk > >>>about how answer messages are routed. Given that request failover is > >>>triggered by connection failures I concluded that answers are always > >>>sent on the transport connection that the request was received on and > >>>if that connection has failed the server just doesn't send the answer. > >>>It's recommended somewhere that the server hang on the answer for a > >>>period of time in case the request is retransmitted to the same server > >>>on a new connection but the server would not send the answer on a new > >>>connection without first receiving a retransmission of the request on > >>>that connection. > >>> > >>> > >>I agree in part. The base proto is not clear about the behavior when it > >>has to send an answer when its own link to that route has recently > >>broken. Though, I'm not sure if storing answer messages in the base > >>protocol is useful because there is already a request retransmission > >>mechanism. If a retransmitted request is received by a server on a new > >>connection, the T flag is set and the application itself can have the > >>intelligence to respond accordingly and send an answer on that new > >>connection. > >> > >> > >[TOLGA]IMHO RFC3588 is pretty clear about how answers are to be > routed -it > >is as explained by Anders-. If the link where corresponding > request has been > >received is broken, answer is not sent. > > > > > ok. > > >OTOH, I don't know the rationale behind not acknowledging answer > messages. > >Afterall base protocol performs some transport functionality and > not to have > >some acknowledgement mechanism for answers causes all that hassle about > >storing requests and checking for retransmission if T-flag is > set. It seems > >pretty inefficient to me. To have some guideleines about how E2E-Id is > >incremented, e.g. sequentially and piggybacking last received > answers E2E-Id > >in request messages and possibly introducing a new message to send answer > >acknowledgement if there is no requests to send could help -just as an > >initial idea, I didn't think much about details- not to store received > >requests for long time. > > > > > I see. E2E sequencing is definitely useful and maybe the only > functionality required to provide message loss and answer co-relation. > Though, I probably dont understand well but I'm not sure how sending an > 'answer acknowledgement' is more efficient. This seems redundant since > it means acknowledging an acknowledgement. [TOLGA]Probably it could be a mechanism similar to what is present in other transport layer protocols: One could have sender/receiver windows which are maintained based on a sequence number, i.e. E2E-Id. AFAICS the issue is relying on the concept of request/response on transport level is not very common, everything is usually considered a message. Each side keeps a sequence number for send/receive directions. the concept of request/response seems a bit higher than the transport protocol level. Right now, responses are used to acknowledge requests but there is nothing to acknowledge responses, afterall both are messages transported by the base protocol. Acknowledging responses would allow to keep the data, which is necessary for duplicate detection/handling only till the acknowledgement for the response is received rather than an indefinete/arbitrarly choosen amount of time. > > >Asking applications to take care of retransmission is also > another approach > >and considering that they are aware of the expected message > flow, they may > >use that extra information to decide for retransmission more > efficiently for > >*most* of the times, but I think this may not always be true. To define a > >transport protocol, where requests are retransmitted by the protocol but > >duplicate detection for requests is performed by the user of the protocol > >may be considered architecturally not elegant either. > > > > > I dont have strong opinions on this and it maybe a matter of semantics. > In general both retransmission and duplicate detection (t-flag) is done > by the base protocol. how to process receipt of a duplicate request is > probably an issue left up to the application. > > >In any case, AFAICS duplicate detection in RFC3588 not very > efficient, but I > >suspect there could be some reasons which led to the current design. If > >somebody knows them and shares them with us, it could be great > to get more > >insight. > > > > > > regards, > victor > > >>>The other piece of supporting evidence is that answer messages do not > >>>contain Destination-Host (3588, 6.2) which I think would be a > >>>reasonable thing to expect if answers were routed in a way similar to > >>>requests. > >>> > >>> > >>I agree. hop-to-hop id is the only method. > >> > >>Regards, > >>victor > >> > >> > >> > >>>Is this the correct interpretation? Did I miss an explicit statement > >>>to this effect anywhere in the base spec? > >>> > >>>Thanks, > >>>Anders > >>> > >>>_______________________________________________ > >>>DiME mailing list > >>>DiME@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> > >>> > >>> > >> > >> > >>_______________________________________________ > >>DiME mailing list > >>DiME@ietf.org > >>https://www1.ietf.org/mailman/listinfo/dime > >> > >> > >> > > > > > > > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 10:16:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FET4I-0008HF-CK; Wed, 01 Mar 2006 10:16:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FET4H-0008HA-Ao for dime@ietf.org; Wed, 01 Mar 2006 10:16:45 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FET4G-0001Qt-2h for dime@ietf.org; Wed, 01 Mar 2006 10:16:45 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 Mar 2006 07:16:43 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,157,1139212800"; d="scan'208"; a="22795017:sNHT25019188" Received: from [161.44.55.246] (dhcp-161-44-55-246.cisco.com [161.44.55.246]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k21FGhjJ009796; Wed, 1 Mar 2006 10:16:43 -0500 (EST) Message-ID: <4405BADB.7080204@cisco.com> Date: Wed, 01 Mar 2006 10:16:43 -0500 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] answer routing References: <44036026.9090106@cisco.com> <44058911.10801@tari.toshiba.com> In-Reply-To: <44058911.10801@tari.toshiba.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Victor Fajardo wrote: > Hi Anders, > >> RFC 3588 talks about request routing but AFAICT it doesn't really talk >> about how answer messages are routed. Given that request failover is >> triggered by connection failures I concluded that answers are always >> sent on the transport connection that the request was received on and >> if that connection has failed the server just doesn't send the answer. >> It's recommended somewhere that the server hang on the answer for a >> period of time in case the request is retransmitted to the same server >> on a new connection but the server would not send the answer on a new >> connection without first receiving a retransmission of the request on >> that connection. > > > I agree in part. The base proto is not clear about the behavior when it > has to send an answer when its own link to that route has recently > broken. Though, I'm not sure if storing answer messages in the base > protocol is useful because there is already a request retransmission > mechanism. If a retransmitted request is received by a server on a new > connection, the T flag is set and the application itself can have the > intelligence to respond accordingly and send an answer on that new > connection. Right, I just wanted to clarify the intention of the current spec and I thought I read somewhere (can't find the reference right now) that the server should hang on to the answer for some time just in case the request is retransmitted. If the server is idempotent it could just choose to recompute the answer and no one would know the difference. Anyway, it sounds like there's agreement that answers are *always* sent on the transport connection on which the corresponding request was received. Thanks, Anders > >> >> The other piece of supporting evidence is that answer messages do not >> contain Destination-Host (3588, 6.2) which I think would be a >> reasonable thing to expect if answers were routed in a way similar to >> requests. > > > I agree. hop-to-hop id is the only method. > > Regards, > victor > >> >> Is this the correct interpretation? Did I miss an explicit statement >> to this effect anywhere in the base spec? >> >> Thanks, >> Anders >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 10:57:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEThv-0002MT-Gt; Wed, 01 Mar 2006 10:57:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETht-0002MJ-P8 for dime@ietf.org; Wed, 01 Mar 2006 10:57:41 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEThs-0003d7-ES for dime@ietf.org; Wed, 01 Mar 2006 10:57:41 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k21FvXDx087290; Wed, 1 Mar 2006 10:57:34 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4405C46E.9070505@tari.toshiba.com> Date: Wed, 01 Mar 2006 10:57:34 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] answer routing References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, >>> >>> >>> >>> >>I see. E2E sequencing is definitely useful and maybe the only >>functionality required to provide message loss and answer co-relation. >>Though, I probably dont understand well but I'm not sure how sending an >>'answer acknowledgement' is more efficient. This seems redundant since >>it means acknowledging an acknowledgement. >> >> >[TOLGA]Probably it could be a mechanism similar to what is present in other >transport layer protocols: One could have sender/receiver windows which are >maintained based on a sequence number, i.e. E2E-Id. > > I see. >AFAICS the issue is relying on the concept of request/response on transport >level is not very common, everything is usually considered a message. Each > > It not common above transport (tcp/tls/sctp) level though I can uderstand why diameter diameter does it. It is especially useful when result-code avp for each answer is relevant. As an example, in diameter-EAP the result-code may indicate one or more continued-authentication before final success or failure. >side keeps a sequence number for send/receive directions. the concept of >request/response seems a bit higher than the transport protocol level. Right >now, responses are used to acknowledge requests but there is nothing to >acknowledge responses, afterall both are messages transported by the base >protocol. Acknowledging responses would allow to keep the data, which is >necessary for duplicate detection/handling only till the acknowledgement for >the response is received rather than an indefinete/arbitrarly choosen amount >of time. > > I see. Though I'm still not sure how this can help in duplicate detection of request. Also, what happens when the 'answer acknowledgement' itself gets lost due to a failure on one of the peers along the answer path. Will we send another ack after a period of time and keep state ? How will the answer ack get routed after the path failure ? This maybe one reason why current duplicate detection is more resilient but maybe less efficient as you mentioned. I'm not really sure how the designers approach to this issue and maybe they can shed some ligth on thier decision(s). To come back to an initial conversation, I think that storing answer messages is not very useful and I dont know if its in the spec. I think sequencing and retransmission is effective. Thanks and regards, Victor >>>Asking applications to take care of retransmission is also >>> >>> >>another approach >> >> >>>and considering that they are aware of the expected message >>> >>> >>flow, they may >> >> >>>use that extra information to decide for retransmission more >>> >>> >>efficiently for >> >> >>>*most* of the times, but I think this may not always be true. To define a >>>transport protocol, where requests are retransmitted by the protocol but >>>duplicate detection for requests is performed by the user of the protocol >>>may be considered architecturally not elegant either. >>> >>> >>> >>> >>I dont have strong opinions on this and it maybe a matter of semantics. >>In general both retransmission and duplicate detection (t-flag) is done >>by the base protocol. how to process receipt of a duplicate request is >>probably an issue left up to the application. >> >> >> >>>In any case, AFAICS duplicate detection in RFC3588 not very >>> >>> >>efficient, but I >> >> >>>suspect there could be some reasons which led to the current design. If >>>somebody knows them and shares them with us, it could be great >>> >>> >>to get more >> >> >>>insight. >>> >>> >>> >>> >>regards, >>victor >> >> >> >>>>>The other piece of supporting evidence is that answer messages do not >>>>>contain Destination-Host (3588, 6.2) which I think would be a >>>>>reasonable thing to expect if answers were routed in a way similar to >>>>>requests. >>>>> >>>>> >>>>> >>>>> >>>>I agree. hop-to-hop id is the only method. >>>> >>>>Regards, >>>>victor >>>> >>>> >>>> >>>> >>>> >>>>>Is this the correct interpretation? Did I miss an explicit statement >>>>>to this effect anywhere in the base spec? >>>>> >>>>>Thanks, >>>>>Anders >>>>> >>>>>_______________________________________________ >>>>>DiME mailing list >>>>>DiME@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/dime >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>DiME mailing list >>>>DiME@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>>> >>>> >>>> >>> >>>_______________________________________________ >>>DiME mailing list >>>DiME@ietf.org >>>https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >>> >>> >>> > > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 11:00:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETkf-0003sd-CY; Wed, 01 Mar 2006 11:00:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETkd-0003sY-Ob for dime@ietf.org; Wed, 01 Mar 2006 11:00:31 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FETkc-0003jy-Gk for dime@ietf.org; Wed, 01 Mar 2006 11:00:31 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2006 11:00:31 -0500 X-IronPort-AV: i="4.02,157,1139202000"; d="scan'208"; a="83317779:sNHT32691088" Received: from [161.44.55.246] (dhcp-161-44-55-246.cisco.com [161.44.55.246]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k21G0TqM013491; Wed, 1 Mar 2006 11:00:29 -0500 (EST) Message-ID: <4405C51C.4040302@cisco.com> Date: Wed, 01 Mar 2006 11:00:28 -0500 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Victor Fajardo Subject: trailing [*fixed] section in messages [was: Re: [Dime] DiME WG meeting in Dallas] References: <1AA39B75171A7144A73216AED1D7478D01A08CED@esebe100.NOE.Nokia.com> <43EBA4EE.9040104@tari.toshiba.com> In-Reply-To: <43EBA4EE.9040104@tari.toshiba.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org (going through old email) Victor Fajardo wrote: > Hi, > > I'd like to post a question regarding the trailing [*fixed] avp set of > diameter-message ABNF in Sec 3.2 of the base proto (where: > diameter-message = header [*fixed] [*required] [*optional] [*fixed]). > I'm not familiar with the history of this layout but in which > scenario(s) are trailing fixed avps used ? So far appending of trailing > avps are most relevant to proxies and relays but route-records and > proxy-info are normally tagged as optional as they should be. And at the > moment, there does'nt seem to be any application defining a trailing > fixed avp. Maybe this format can be relaxed to help simplify parsing. I also don't know the reason this was put in but I agree that it doesn't seem very useful. Presumably the reason for the first [*fixed] section is that having certain AVPs appear early can help allow implementations that are interested only in these specific AVPs to not have to parse or skip over other AVPs. This reason cannot apply to fixed AVPs at the end of messages as one cannot parse from the end (no way of telling where the last AVP started without making one's way from the start). Anders > > Victor > >> Hi all, >> >> While our ADs are sorting out the chairing issues, I wanted to solicit >> input for the Dallas IETF meeting. I was thinking of summarizing some >> of the outstanding Diameter Base open issues (if you have any, send them >> to the mailing list!). Also, discussion of the upcoming Interop event, >> Diameter test plans, Diameter MIPv6 work, Diameter QoS working would all >> be good topics. Speak up if you have any topics you wish to discuss. >> >> John >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> >> >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 12:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVNU-0001Wy-BK; Wed, 01 Mar 2006 12:44:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVNT-0001Wd-Na for dime@ietf.org; Wed, 01 Mar 2006 12:44:43 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEVNS-0007x0-UA for dime@ietf.org; Wed, 01 Mar 2006 12:44:43 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 58DAF0B683 for ; Wed, 1 Mar 2006 12:44:41 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k21HiNgg007070 for ; Wed, 1 Mar 2006 12:44:23 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] answer routing Date: Wed, 1 Mar 2006 12:24:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <4405C46E.9070505@tari.toshiba.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, March 01, 2006 10:58 AM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] answer routing > > > Hi Tolga, > > >>> > >>> > >>> > >>> > >>I see. E2E sequencing is definitely useful and maybe the only > >>functionality required to provide message loss and answer co-relation. > >>Though, I probably dont understand well but I'm not sure how sending an > >>'answer acknowledgement' is more efficient. This seems redundant since > >>it means acknowledging an acknowledgement. > >> > >> > >[TOLGA]Probably it could be a mechanism similar to what is > present in other > >transport layer protocols: One could have sender/receiver > windows which are > >maintained based on a sequence number, i.e. E2E-Id. > > > > > I see. > > >AFAICS the issue is relying on the concept of request/response > on transport > >level is not very common, everything is usually considered a > message. Each > > > > > It not common above transport (tcp/tls/sctp) level though I can > uderstand why diameter diameter does it. It is especially useful when > result-code avp for each answer is relevant. As an example, in > diameter-EAP the result-code may indicate one or more > continued-authentication before final success or failure. [TOLGA]I believe this type of semantics fits more to application layer rather than to transport layer. IMHO, the main task of transport layer should be successful delivery of messages. > > >side keeps a sequence number for send/receive directions. the concept of > >request/response seems a bit higher than the transport protocol > level. Right > >now, responses are used to acknowledge requests but there is nothing to > >acknowledge responses, afterall both are messages transported by the base > >protocol. Acknowledging responses would allow to keep the data, which is > >necessary for duplicate detection/handling only till the > acknowledgement for > >the response is received rather than an indefinete/arbitrarly > choosen amount > >of time. > > > > > I see. Though I'm still not sure how this can help in duplicate > detection of request. Also, what happens when the 'answer > acknowledgement' itself gets lost due to a failure on one of the peers > along the answer path. Will we send another ack after a period of time > and keep state ? How will the answer ack get routed after the path > failure ? This maybe one reason why current duplicate detection is more > resilient but maybe less efficient as you mentioned. I'm not really sure > how the designers approach to this issue and maybe they can shed some > ligth on thier decision(s). [TOLGA]I think with a properly designed mechanism the problems you mentioned may be overcome. I don't have answers yet, actually let me put a draft together, it will be easier to discuss it once there is a document, which presents the idea completely. I am not suggesting that a method mimicing traditional transport layer protocols completely is the way to go-maybe it is, I don't know now-, but having some mechanism to acknowledge answers will help not to store much data to detect duplicates -for that more below-. > > To come back to an initial conversation, I think that storing answer > messages is not very useful and I dont know if its in the spec. I think > sequencing and retransmission is effective. [TOLGA]Appendix C there are some sentences hinting about it but I wouldn't think it is normative: A Diameter server MAY check the T flag of the received message to determine if the record is a possible duplicate. If the T flag is set in the request message, the server searches for a duplicate within a configurable duplication time window backward and forward. IMO, rather than what it says in Appendix C, the real issue is whehter there is some other solution -afterall duplicate detection is a local procedure-. I would like to make a distinction here between two types of servers: a)Servers which can regenerate a previous answer b)Servers, which can't regenerate a previous answer If some data bookkeeping is necessary, it probably would be limited to OriginHostAvp+E2eId for a). For b), the answer itself need to be kept as well. Why I believe that some bookkeeping is necessary -according to the current procedures defined in RFC3588- is as follows: Let's consider the follwing message flow from server's point of view: (I assume E2E-Id contains a number, which is sequentially increased by the sender and that this number is at a well-defined place in E2E-Id. This is currently not there in RFC3588, but still does not solve the problem completely) Server receives messages with sequence number 27001, 27002, 18933. Now, how can the server decide what the reason is for receiving 18933? It could be because this request has never been received at all by the server, e.g. the relay agent via which the request was to be sent was down and 27001, 27002 are sent through other relay agents, or it could be that request was received by the server and the answer was generated but the answer did not reach the client, e.g. due to relay agent crash. Based on the reason, the behavior will be different. AFAICS, the only way to figure our the real reason is to keep the history of the requests received -at least for a while-, and the current mechanism seems not very efficient to me in that regard. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 18:52:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEb7T-0006tD-Kt; Wed, 01 Mar 2006 18:52:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEb6C-0005dS-UN for dime@ietf.org; Wed, 01 Mar 2006 18:51:17 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEb6C-0005FA-I5 for dime@ietf.org; Wed, 01 Mar 2006 18:51:16 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k21Np8ID089311; Wed, 1 Mar 2006 18:51:12 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4406336D.8090905@tari.toshiba.com> Date: Wed, 01 Mar 2006 18:51:09 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] answer routing References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, >>It not common above transport (tcp/tls/sctp) level though I can >>uderstand why diameter diameter does it. It is especially useful when >>result-code avp for each answer is relevant. As an example, in >>diameter-EAP the result-code may indicate one or more >>continued-authentication before final success or failure. >> >> >[TOLGA]I believe this type of semantics fits more to application layer >rather than to transport layer. IMHO, the main task of transport layer >should be successful delivery of messages. > > I guess if tranport layer==(tpc/tls/sctp) and application layer == diameter base protocol then I agree :) >>> >>> >>> >>I see. Though I'm still not sure how this can help in duplicate >>detection of request. Also, what happens when the 'answer >>acknowledgement' itself gets lost due to a failure on one of the peers >>along the answer path. Will we send another ack after a period of time >>and keep state ? How will the answer ack get routed after the path >>failure ? This maybe one reason why current duplicate detection is more >>resilient but maybe less efficient as you mentioned. I'm not really sure >>how the designers approach to this issue and maybe they can shed some >>ligth on thier decision(s). >> >> >[TOLGA]I think with a properly designed mechanism the problems you mentioned >may be overcome. I don't have answers yet, actually let me put a draft >together, it will be easier to discuss it once there is a document, which >presents the idea completely. > > ok. >I am not suggesting that a method mimicing traditional transport layer >protocols completely is the way to go-maybe it is, I don't know now-, but >having some mechanism to acknowledge answers will help not to store much >data to detect duplicates -for that more below-. > > ok > > >>To come back to an initial conversation, I think that storing answer >>messages is not very useful and I dont know if its in the spec. I think >>sequencing and retransmission is effective. >> >> >[TOLGA]Appendix C there are some sentences hinting about it but I wouldn't >think it is normative: > A Diameter server MAY check the T flag of the received message to > determine if the record is a possible duplicate. If the T flag is > set in the request message, the server searches for a duplicate > within a configurable duplication time window backward and > forward. > >IMO, rather than what it says in Appendix C, the real issue is whehter there >is some other solution -afterall duplicate detection is a local procedure-. >I would like to make a distinction here between two types of servers: >a)Servers which can regenerate a previous answer >b)Servers, which can't regenerate a previous answer > > ... this distinction is better made by the application is'nt it ? One thing I was thinking of was that since the application already keeps state about an ongoing session, it maybe well informed about what to do with dups without needing extra info. The following snippet from sec 3 of the spec maybe provide some hint: "The End-to-End Identifier MUST NOT be modified by Diameter agents of any kind. The combination of the Origin-Host (see Section 6.3) and this field is used to detect duplicates. Duplicate requests SHOULD cause the same answer to be transmitted (modulo the hop-by-hop Identifier field and any routing AVPs that may be present), and MUST NOT affect any state that was set when the original request was processed. Duplicate answer messages that are to be locally consumed (see Section 6.2) SHOULD be silently discarded." If I interpret correctly, the application decides what to do with dups. >If some data bookkeeping is necessary, it probably would be limited to >OriginHostAvp+E2eId for a). For b), the answer itself need to be kept as >well. > >Why I believe that some bookkeeping is necessary -according to the current >procedures defined in RFC3588- is as follows: >Let's consider the follwing message flow from server's point of view: >(I assume E2E-Id contains a number, which is sequentially increased by the >sender and that this number is at a well-defined place in E2E-Id. This is >currently not there in RFC3588, but still does not solve the problem >completely) > > ok >Server receives messages with sequence number 27001, 27002, 18933. Now, how >can the server decide what the reason is for receiving 18933? It could be >because this request has never been received at all by the server, e.g. the >relay agent via which the request was to be sent was down and 27001, 27002 >are sent through other relay agents, or it could be that request was >received by the server and the answer was generated but the answer did not >reach the client, e.g. due to relay agent crash. > I see. Just to clarify, (pls let me know if i did not understand correctly) you want to make a distinction between retransmission of messages from a relay because of failover and retransmission by the originator of the message, i.e. the client, because it has not received an answer. One thing I was thinking of is that a retransmission from the originator can simply use a new e2d id to distinguish itself. I guess any message originator should use a new e2e (may already be hinted by the spec). >Based on the reason, the >behavior will be different. AFAICS, the only way to figure our the real >reason is to keep the history of the requests received -at least for a >while-, and the current mechanism seems not very efficient to me in that >regard. > > > ok. I do agree there is room for improvement. Thanks and Regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 01 22:54:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEet9-0006XH-Ne; Wed, 01 Mar 2006 22:54:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEet8-0006WM-An for dime@ietf.org; Wed, 01 Mar 2006 22:54:02 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEet8-00007k-3W for dime@ietf.org; Wed, 01 Mar 2006 22:54:02 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 01 Mar 2006 19:54:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,158,1139212800"; d="scan'208"; a="22837072:sNHT28352548" Received: from [10.86.243.62] (che-vpn-cluster-2-317.cisco.com [10.86.243.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k223s1Wc001081 for ; Wed, 1 Mar 2006 22:54:01 -0500 (EST) Message-ID: <44066C58.8090909@cisco.com> Date: Wed, 01 Mar 2006 22:54:00 -0500 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Dime] application identifiers X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org All, I have some questions on application IDs. This is all pretty fundamental stuff so hopefully I didn't get it completely wrong ;) Applications are identified by the combination of vendor ID and application ID with IETF defined apps having vendor ID 0 (3588, 2.7). My understanding is that with the exception of CER and CEA which are special the following is true for all messages: - Messages belonging to IETF defined apps will never have a Vendor-Specific-Application-Id (VSAI) AVP. - Messages belonging to IETF defined apps may have either an Auth-Application-Id or an Acct-Application-Id AVP. If it does have one of those AVPs, the value will equal that of the Application-ID field in the message header. - Messages belonging to non-IETF defined apps must have exactly one VSAI AVP. This AVP must contain either an Auth-Application-Id or an Acct-Application-Id whose value must equal that of the Application-ID field in the message header. [This is not actually what I get from reading 3588 (see below) but it's what makes sense, I think.] Are these statements correct? If they're correct it follows that a vendor specific application cannot reuse commands defined in the base spec or at least that such messages cannot contain a Vendor-Specific-Application-Id and hence must be considered part of the base app, not the vendor specific app. Some questions on specific section of 3588: Section 2.4: Each Diameter application MUST have an IANA assigned Application Identifier (see Section 11.3). The base protocol does not require an Application Identifier since its support is mandatory. All Diameter nodes have to understand CER, DWR and DPR requests but clearly not all Diameter nodes will know what to do with, say, an ACR so this seems wrong. 6.11: The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present. ... ::= < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } The sentence "Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present" seems odd. Should't it be a requirement that exactly one of the AVPs be present? As it stands a Vendor-Specific-Application-Id containing just a Vendor-Id would seem to be OK. And why are multiple Vendor-Ids allowed here? Are there any known situations where messages contain a Vendor-Specific-Application-Id with more than one Vendor-Id? Also, the text seems to rule out inclusion of both Auth-Application-Id and Acct-Application-Id but wouldn't it be possible for an app to have both an accounting and an authentication portion or is that just disallowed? (The base app has both, right?) Section 11.3: Both Application-Id and Acct-Application-Id AVPs use the same Application Identifier space. and Auth-Application-Id too, right? Comments much appreciated. Thanks, Anders _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 02 04:07:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEjmW-0000mZ-Km; Thu, 02 Mar 2006 04:07:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEjmU-0000mU-MT for dime@ietf.org; Thu, 02 Mar 2006 04:07:30 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEjmT-00049X-4s for dime@ietf.org; Thu, 02 Mar 2006 04:07:30 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k2297Ssg005140 for ; Thu, 2 Mar 2006 10:07:28 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k2297Nhb003507 for ; Thu, 2 Mar 2006 10:07:28 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 10:07:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Mar 2006 10:06:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter MIPv6 Application thread-index: AcY92KcZcob/+n5oRQqioyEdYqUm0w== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 02 Mar 2006 09:07:25.0717 (UTC) FILETIME=[B944EC50:01C63DD8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Dime] Diameter MIPv6 Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all,=20 we have compiled two Diameter documents that provide the backend solution for the split & the integrated scenario.=20 Please find the document here: Mobile IPv6 Bootstrapping using Diameter in the Split Scenario Abstract In Mobile IPv6 deployment a need for an interaction between the Home Agent, the AAA infrastructure of the Mobile Service Provider (MSP) and the Mobility Service Authorizer (MSA) has been identified. This document provides a description of the functionality that allows to meet the goals outlined in the MIPv6 AAA Goals document. http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-split-00.txt Diameter MIPv6 Application for the Integrated Scenario Abstract A Mobile IPv6 node requires a home agent address, a home address, and IPsec security association with its home agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document defines a Diameter application to facilitate Mobile IPv6 bootstrapping for the integrated scenario. http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-integrated-0 0.txt Before I started working on the latter document I contact Franck Le since he was the author/editor of the previous Diameter MIPv6 Application document. It turned out that the previously written document had a different focus than today's bootstrapping activites. Anyway, I got in touch with Franck to work on the document with him but he moved to CMU and has no time for it anymore. Maybe the other co-authors are still interested in this subject - but I haven't received a reply yet. I am still looking for some co-authors.... =20 Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 02 04:34:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkCL-0003Cb-Dg; Thu, 02 Mar 2006 04:34:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkCJ-00039D-Mk for dime@ietf.org; Thu, 02 Mar 2006 04:34:11 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEkCI-0005lS-9U for dime@ietf.org; Thu, 02 Mar 2006 04:34:11 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k229Y7qq004963 for ; Thu, 2 Mar 2006 10:34:08 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k229Y1pk030338 for ; Thu, 2 Mar 2006 10:34:07 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 10:33:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Mar 2006 10:33:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter QoS Application thread-index: AcY924uALAkCHBETRayAeauSegHe0Q== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 02 Mar 2006 09:33:21.0642 (UTC) FILETIME=[58AC3CA0:01C63DDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Dime] Diameter QoS Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all,=20 we have resubmitted our Diameter QoS application draft to the DIME working group.=20 Here is the new draft version: Diameter Quality of Service Application Abstract This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-diameter-qos-00.t xt This version of the draft is based on draft-alfano-aaa-qosprot-05.txt and contains feedback we received by John, Robert Hancock and Jerry Ash. The issue tracker of this document can be found at: http://www.tschofenig.priv.at:8080/diameter-qos/index Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 02 07:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnH5-0000gO-9J; Thu, 02 Mar 2006 07:51:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnH4-0000gI-Tm for dime@ietf.org; Thu, 02 Mar 2006 07:51:18 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEnH3-0004j9-Fc for dime@ietf.org; Thu, 02 Mar 2006 07:51:18 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 11C4080B1; Thu, 2 Mar 2006 13:51:14 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FEnDo-0008H9-GF; Thu, 02 Mar 2006 13:47:56 +0100 Date: Thu, 2 Mar 2006 13:47:56 +0100 From: Julien Bournelle To: "Tschofenig, Hannes" Subject: Re: [Dime] Diameter MIPv6 Application Message-ID: <20060302124756.GB31800@ipv6-3.int-evry.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi hannes, I took a quick look at the Integrated document and I have a comment: what happens if 802.1X or PANA is in used for network access authentication ? the NAS needs to carry EAP packets to the AAA servers and thus will used Diameter NASREQ/EAP. If you want that the NAS uses your application instead of Diameter EAP, it means that it knows that the user has mobile IPv6 which may imply some modifications to the network access authentiaction protocol. I tend to think that we should only define AVPs that could be included in Diameter NASREQ/EAP. -- Julien Bournelle On Thu, Mar 02, 2006 at 10:06:55AM +0100, Tschofenig, Hannes wrote: > Hi all, > > we have compiled two Diameter documents that provide the backend > solution for the split & the integrated scenario. > > Please find the document here: > > Mobile IPv6 Bootstrapping using Diameter in the Split Scenario > > Abstract > > In Mobile IPv6 deployment a need for an interaction between the Home > Agent, the AAA infrastructure of the Mobile Service Provider (MSP) > and the Mobility Service Authorizer (MSA) has been identified. This > document provides a description of the functionality that allows to > meet the goals outlined in the MIPv6 AAA Goals document. > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-split-00.txt > > > Diameter MIPv6 Application for the Integrated Scenario > > Abstract > > A Mobile IPv6 node requires a home agent address, a home address, and > IPsec security association with its home agent before it can start > utilizing Mobile IPv6 service. RFC 3775 requires that some or all of > these parameters are statically configured. Ongoing work aims to > make this information dynamically available to the mobile node. An > important aspect of the Mobile IPv6 bootstrapping solution is to > support interworking with existing authentication, authorization and > accounting infrastructure. This document defines a Diameter > application to facilitate Mobile IPv6 bootstrapping for the > integrated scenario. > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-integrated-0 > 0.txt > > Before I started working on the latter document I contact Franck Le > since he was the author/editor of the previous Diameter MIPv6 > Application document. It turned out that the previously written document > had a different focus than today's bootstrapping activites. Anyway, I > got in touch with Franck to work on the document with him but he moved > to CMU and has no time for it anymore. Maybe the other co-authors are > still interested in this subject - but I haven't received a reply yet. I > am still looking for some co-authors.... > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 02 10:03:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpKq-0000KM-Sw; Thu, 02 Mar 2006 10:03:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpKp-0000HR-8E for dime@ietf.org; Thu, 02 Mar 2006 10:03:19 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpKo-0001NB-Ty for dime@ietf.org; Thu, 02 Mar 2006 10:03:19 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id AFF01E4969 for ; Thu, 2 Mar 2006 10:03:18 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k22F3D8A003052 for ; Thu, 2 Mar 2006 10:03:16 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] answer routing Date: Thu, 2 Mar 2006 09:43:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <4406336D.8090905@tari.toshiba.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, [..snip..] > >[TOLGA]Appendix C there are some sentences hinting about it but > I wouldn't > >think it is normative: > > A Diameter server MAY check the T flag of the received message to > > determine if the record is a possible duplicate. If the T flag is > > set in the request message, the server searches for a duplicate > > within a configurable duplication time window backward and > > forward. > > > >IMO, rather than what it says in Appendix C, the real issue is > whehter there > >is some other solution -afterall duplicate detection is a local > procedure-. > >I would like to make a distinction here between two types of servers: > >a)Servers which can regenerate a previous answer > >b)Servers, which can't regenerate a previous answer > > > > > ... this distinction is better made by the application is'nt it ? One > thing I was thinking of was that since the application already keeps > state about an ongoing session, it maybe well informed about what to do > with dups without needing extra info. The following snippet from sec 3 > of the spec maybe provide some hint: > > "The End-to-End Identifier > MUST NOT be modified by Diameter agents of any kind. The > combination of the Origin-Host (see Section 6.3) and this field is > used to detect duplicates. Duplicate requests SHOULD cause the > same answer to be transmitted (modulo the hop-by-hop Identifier > field and any routing AVPs that may be present), and MUST NOT > affect any state that was set when the original request was > processed. Duplicate answer messages that are to be locally > consumed (see Section 6.2) SHOULD be silently discarded." > > If I interpret correctly, the application decides what to do with dups. [TOLGA]The application logic may help for certain situations but I believe there are certain cases where the service itself is stateless and probably should rely on OriginHost+E2E-Id for duplicate detection. [..snip..] > >Server receives messages with sequence number 27001, 27002, > 18933. Now, how > >can the server decide what the reason is for receiving 18933? It could be > >because this request has never been received at all by the > server, e.g. the > >relay agent via which the request was to be sent was down and > 27001, 27002 > >are sent through other relay agents, or it could be that request was > >received by the server and the answer was generated but the > answer did not > >reach the client, e.g. due to relay agent crash. > > > I see. Just to clarify, (pls let me know if i did not understand > correctly) you want to make a distinction between retransmission of > messages from a relay because of failover and retransmission by the > originator of the message, i.e. the client, because it has not received > an answer. One thing I was thinking of is that a retransmission from the > originator can simply use a new e2d id to distinguish itself. I guess > any message originator should use a new e2e (may already be hinted by > the spec). [TOLGA]The distinction is necessary between cases, where a request is retransmitted by base protocol and received by the server for the first time and the request is retransmitted by the base protocol but original transmission of the request was already received by the server and the corresponding answer was generated but the answer was lost. In any case, let me try to put some document together, then we can see whether it makes sense. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 02 10:17:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpYa-0004d2-Oh; Thu, 02 Mar 2006 10:17:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpYZ-0004ce-AA for dime@ietf.org; Thu, 02 Mar 2006 10:17:31 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpYX-0001z1-Tp for dime@ietf.org; Thu, 02 Mar 2006 10:17:31 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id C9B8BCF241 for ; Thu, 2 Mar 2006 10:17:25 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k22FHNhN004282 for ; Thu, 2 Mar 2006 10:17:24 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] application identifiers Date: Thu, 2 Mar 2006 09:57:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44066C58.8090909@cisco.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Anders, I am also confused based on seemingly confusing -at least to me- statement/procedured in RFC3588. I guess/believe/think ApplicationId is globally unique based on: a)11.3 Application Identifiers It seems like ApplicationIds for all types of applications are assigned from the same pool b)Message header has ApplicationId but no other field to further identify the application the message is belonging to. OTOH, espacially 2.7 seems to contradict the above view. If a global pool is used for ApplicationIds, I don't see the reason why vendorId is necessary to identify them uniquely. Please see for more comments/questions below. Thanks, Tolga > -----Original Message----- > From: Anders Kristensen [mailto:andersk@cisco.com] > Sent: Wednesday, March 01, 2006 10:54 PM > To: dime@ietf.org > Subject: [Dime] application identifiers > > > All, > > I have some questions on application IDs. This is all pretty fundamental > stuff so hopefully I didn't get it completely wrong ;) > > Applications are identified by the combination of vendor ID and > application ID with IETF defined apps having vendor ID 0 (3588, 2.7). My > understanding is that with the exception of CER and CEA which are > special the following is true for all messages: > > - Messages belonging to IETF defined apps will never have a > Vendor-Specific-Application-Id (VSAI) AVP. > > - Messages belonging to IETF defined apps may have either an > Auth-Application-Id or an Acct-Application-Id AVP. If it does have one > of those AVPs, the value will equal that of the Application-ID field in > the message header. [TOLGA]I am wondering, what is the use of those AVPs except when advertising support during capability exchange procedure -eem then, why do we distinguish between different types of applications, considering that ApplicationId are assigned from a global pool-? Don't we have the ApplicationId already in the message header -or am I missing something fundamental-? > > - Messages belonging to non-IETF defined apps must have exactly one > VSAI AVP. This AVP must contain either an Auth-Application-Id or an > Acct-Application-Id whose value must equal that of the Application-ID > field in the message header. [This is not actually what I get from > reading 3588 (see below) but it's what makes sense, I think.] > > Are these statements correct? > > If they're correct it follows that a vendor specific application cannot > reuse commands defined in the base spec or at least that such messages > cannot contain a Vendor-Specific-Application-Id and hence must be > considered part of the base app, not the vendor specific app. > > Some questions on specific section of 3588: > > Section 2.4: > > Each Diameter application MUST have an IANA assigned Application > Identifier (see Section 11.3). The base protocol does not require an > Application Identifier since its support is mandatory. > > All Diameter nodes have to understand CER, DWR and DPR requests but > clearly not all Diameter nodes will know what to do with, say, an ACR so > this seems wrong. > > > 6.11: > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > Grouped and is used to advertise support of a vendor-specific > Diameter Application. Exactly one of the Auth-Application-Id and > Acct-Application-Id AVPs MAY be present. > ... > ::= < AVP Header: 260 > > 1* [ Vendor-Id ] > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > > The sentence "Exactly one of the Auth-Application-Id and > Acct-Application-Id AVPs MAY be present" seems odd. Should't it be a > requirement that exactly one of the AVPs be present? As it stands a > Vendor-Specific-Application-Id containing just a Vendor-Id would seem to > be OK. [TOLGA]I think your understanding is correct. > > And why are multiple Vendor-Ids allowed here? Are there any known > situations where messages contain a Vendor-Specific-Application-Id with > more than one Vendor-Id? > > Also, the text seems to rule out inclusion of both Auth-Application-Id > and Acct-Application-Id but wouldn't it be possible for an app to have > both an accounting and an authentication portion or is that just > disallowed? (The base app has both, right?) > > > Section 11.3: > > Both Application-Id and Acct-Application-Id AVPs use the same > Application Identifier space. > > and Auth-Application-Id too, right? [TOLGA]Yes, I think so, even vendor specific application Id use the same identifier pool. > > > Comments much appreciated. > > Thanks, > Anders > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 02 10:32:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpme-0001F4-Ge; Thu, 02 Mar 2006 10:32:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpmd-0001EB-AU for dime@ietf.org; Thu, 02 Mar 2006 10:32:03 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpmc-0002Uy-25 for dime@ietf.org; Thu, 02 Mar 2006 10:32:03 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k22FVs8g091683; Thu, 2 Mar 2006 10:31:56 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44070FEB.4010602@tari.toshiba.com> Date: Thu, 02 Mar 2006 10:31:55 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] answer routing References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, [..snip..] > >[TOLGA]The application logic may help for certain situations but I believe >there are certain cases where the service itself is stateless and probably >should rely on OriginHost+E2E-Id for duplicate detection. > > ok. >>I see. Just to clarify, (pls let me know if i did not understand >>correctly) you want to make a distinction between retransmission of >>messages from a relay because of failover and retransmission by the >>originator of the message, i.e. the client, because it has not received >>an answer. One thing I was thinking of is that a retransmission from the >>originator can simply use a new e2d id to distinguish itself. I guess >>any message originator should use a new e2e (may already be hinted by >>the spec). >> >> >[TOLGA]The distinction is necessary between cases, where a request is >retransmitted by base protocol and received by the server for the first time >and the request is retransmitted by the base protocol but original >transmission of the request was already received by the server and the >corresponding answer was generated but the answer was lost. > >In any case, let me try to put some document together, then we can see >whether it makes sense. > > ok. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 02 11:16:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqU2-0001vI-57; Thu, 02 Mar 2006 11:16:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqU1-0001vD-A2 for dime@ietf.org; Thu, 02 Mar 2006 11:16:53 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqU1-0004XG-1h for dime@ietf.org; Thu, 02 Mar 2006 11:16:53 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k22GGmu3091842; Thu, 2 Mar 2006 11:16:49 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44071A72.4080903@tari.toshiba.com> Date: Thu, 02 Mar 2006 11:16:50 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] application identifiers References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, >Anders, > >I am also confused based on seemingly confusing -at least to me- >statement/procedured in RFC3588. > >I guess/believe/think ApplicationId is globally unique based on: >a)11.3 Application Identifiers >It seems like ApplicationIds for all types of applications are assigned from >the same pool > >b)Message header has ApplicationId but no other field to further identify >the application the message is belonging to. > >OTOH, espacially 2.7 seems to contradict the above view. If a global pool is >used for ApplicationIds, I don't see the reason why vendorId is necessary to >identify them uniquely. > > I think Sec 2.7 has a bug. Only application id (which is/can be a vendor id) is relevant for routing. [snipet] >> - Messages belonging to IETF defined apps may have either an >>Auth-Application-Id or an Acct-Application-Id AVP. If it does have one >>of those AVPs, the value will equal that of the Application-ID field in >>the message header. >> >> >[TOLGA]I am wondering, what is the use of those AVPs except when advertising >support during capability exchange procedure -eem then, why do we >distinguish between different types of applications, considering that >ApplicationId are assigned from a global pool-? Don't we have the >ApplicationId already in the message header -or am I missing something >fundamental-? > > We can add more to this confusion by looking at Sec 6.1 where an app id avp is mandatory for relayed messages. This implies that those avp's are used for routing instead of the id in the message header. OTOH, app-id definition in Sec 3 says that the app-id avp and the app-id in the header header must be the same but this is duplicated info as you pointed out. For routing, only the id in the header is relevant so you dont have to parse the entire message and look for an id. victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 02 17:00:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvq7-00069O-5Z; Thu, 02 Mar 2006 17:00:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvq6-00069H-Lt for dime@ietf.org; Thu, 02 Mar 2006 17:00:02 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEvq6-0007Jf-E7 for dime@ietf.org; Thu, 02 Mar 2006 17:00:02 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2006 12:44:16 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,161,1139212800"; d="scan'208"; a="22881538:sNHT30782004" Received: from [161.44.55.246] (dhcp-161-44-55-246.cisco.com [161.44.55.246]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k22KiEVU022270; Thu, 2 Mar 2006 15:44:14 -0500 (EST) Message-ID: <4407591D.7000606@cisco.com> Date: Thu, 02 Mar 2006 15:44:13 -0500 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] application identifiers References: <44071A72.4080903@tari.toshiba.com> In-Reply-To: <44071A72.4080903@tari.toshiba.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Victor Fajardo wrote: > Hi, > >> Anders, >> >> I am also confused based on seemingly confusing -at least to me- >> statement/procedured in RFC3588. >> >> I guess/believe/think ApplicationId is globally unique based on: >> a)11.3 Application Identifiers >> It seems like ApplicationIds for all types of applications are >> assigned from >> the same pool Yes, that's clearly the case. There's a single IANA registry for IDs of all types of apps. >> >> b)Message header has ApplicationId but no other field to further identify >> the application the message is belonging to. >> >> OTOH, espacially 2.7 seems to contradict the above view. If a global >> pool is >> used for ApplicationIds, I don't see the reason why vendorId is >> necessary to >> identify them uniquely. Agreed. >> >> > I think Sec 2.7 has a bug. Only application id (which is/can be a vendor > id) is relevant for routing. > > [snipet] > >>> - Messages belonging to IETF defined apps may have either an >>> Auth-Application-Id or an Acct-Application-Id AVP. If it does have one >>> of those AVPs, the value will equal that of the Application-ID field in >>> the message header. >>> >> >> [TOLGA]I am wondering, what is the use of those AVPs except when >> advertising >> support during capability exchange procedure -eem then, why do we >> distinguish between different types of applications, considering that >> ApplicationId are assigned from a global pool-? Don't we have the >> ApplicationId already in the message header -or am I missing something >> fundamental-? >> >> > We can add more to this confusion by looking at Sec 6.1 where an app id > avp is mandatory for relayed messages. This implies that those avp's are > used for routing instead of the id in the message header. OTOH, app-id > definition in Sec 3 says that the app-id avp and the app-id in the > header header must be the same Would make sense if Vendor-Id was also needed for routing but I agree that given that app IDs come out of a single flat space apps are uniquely identified by the app id alone. Anders > but this is duplicated info as you > pointed out. For routing, only the id in the header is relevant so you > dont have to parse the entire message and look for an id. > > victor > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 03 04:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6Dj-0004yx-UG; Fri, 03 Mar 2006 04:05:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6Di-0004vR-EX for dime@ietf.org; Fri, 03 Mar 2006 04:05:06 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF6Dh-0003dj-NV for dime@ietf.org; Fri, 03 Mar 2006 04:05:06 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6B552C0A; Fri, 3 Mar 2006 10:04:17 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 10:04:17 +0100 Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 10:04:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: [Dime] application identifiers Date: Fri, 3 Mar 2006 10:04:14 +0100 Message-ID: <7457D12699374F40BD026D2B1EFFBEC60138BE9D@eesmdmw020.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] application identifiers Thread-Index: AcY+RKuItQ7l7E0SQ26xZKjhWlZmMwAW8Ysw From: "German Blanco \(E2/EEM\)" To: "Anders Kristensen" , "Victor Fajardo" X-OriginalArrivalTime: 03 Mar 2006 09:04:16.0792 (UTC) FILETIME=[73130180:01C63EA1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, I agree that the Vendor-Id AVP for applications does not make=20 sense without a Vendor space for application ids. I may get some shouts for this, but ... just in case someone=20 else thinks that it would make sense to reopen the topic ... in my humble personal opinion, a vendor space for applications, and command codes makes the protocol only easier to extend. German. > -----Original Message----- > From: Anders Kristensen [mailto:andersk@cisco.com]=20 > Sent: jueves, 02 de marzo de 2006 21:44 > To: Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] application identifiers >=20 >=20 >=20 > Victor Fajardo wrote: > > Hi, > >=20 > >> Anders, > >> > >> I am also confused based on seemingly confusing -at least to me-=20 > >> statement/procedured in RFC3588. > >> > >> I guess/believe/think ApplicationId is globally unique based on: > >> a)11.3 Application Identifiers > >> It seems like ApplicationIds for all types of applications are=20 > >> assigned from the same pool >=20 > Yes, that's clearly the case. There's a single IANA registry=20 > for IDs of all types of apps. >=20 > >> > >> b)Message header has ApplicationId but no other field to further=20 > >> identify the application the message is belonging to. > >> > >> OTOH, espacially 2.7 seems to contradict the above view.=20 > If a global=20 > >> pool is used for ApplicationIds, I don't see the reason=20 > why vendorId=20 > >> is necessary to identify them uniquely. >=20 > Agreed. >=20 > >> =20 > >> > > I think Sec 2.7 has a bug. Only application id (which is/can be a=20 > > vendor > > id) is relevant for routing. > >=20 > > [snipet] > >=20 > >>> - Messages belonging to IETF defined apps may have either an=20 > >>> Auth-Application-Id or an Acct-Application-Id AVP. If it=20 > does have=20 > >>> one of those AVPs, the value will equal that of the=20 > Application-ID=20 > >>> field in the message header. > >>> =20 > >> > >> [TOLGA]I am wondering, what is the use of those AVPs except when=20 > >> advertising support during capability exchange procedure=20 > -eem then,=20 > >> why do we distinguish between different types of applications,=20 > >> considering that ApplicationId are assigned from a global pool-?=20 > >> Don't we have the ApplicationId already in the message=20 > header -or am=20 > >> I missing something fundamental-? > >> =20 > >> > > We can add more to this confusion by looking at Sec 6.1=20 > where an app=20 > > id avp is mandatory for relayed messages. This implies that those=20 > > avp's are used for routing instead of the id in the message header.=20 > > OTOH, app-id definition in Sec 3 says that the app-id avp and the=20 > > app-id in the header header must be the same >=20 > Would make sense if Vendor-Id was also needed for routing but=20 > I agree that given that app IDs come out of a single flat=20 > space apps are uniquely identified by the app id alone. >=20 > Anders >=20 > > but this is duplicated info as you > > pointed out. For routing, only the id in the header is=20 > relevant so you=20 > > dont have to parse the entire message and look for an id. > >=20 > > victor > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 03 05:45:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF7nH-0004IF-Vp; Fri, 03 Mar 2006 05:45:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF7nG-0004DE-IT for dime@ietf.org; Fri, 03 Mar 2006 05:45:54 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF7nF-0006zq-5u for dime@ietf.org; Fri, 03 Mar 2006 05:45:54 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 706E34F0074 for ; Fri, 3 Mar 2006 11:45:52 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 11:45:51 +0100 Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 11:45:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Dime] feature tag AVP Date: Fri, 3 Mar 2006 11:45:50 +0100 Message-ID: <7457D12699374F40BD026D2B1EFFBEC60138BEA1@eesmdmw020.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] feature tag AVP Thread-Index: AcY+r6Lzo965uRVVSJeJfL6HJ0Fsqw== From: "German Blanco \(E2/EEM\)" To: X-OriginalArrivalTime: 03 Mar 2006 10:45:51.0830 (UTC) FILETIME=[A3FFFF60:01C63EAF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello, as far as I know, there is no AVP defined to transport the feature tags specified in RFC 2533, or? Wouldn't it make sense to have an AVP code reserved=20 for that? Regards, German. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 03 11:07:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCoA-0003SE-Kq; Fri, 03 Mar 2006 11:07:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCo9-0003Ow-By for dime@ietf.org; Fri, 03 Mar 2006 11:07:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFCo8-0002WN-1q for dime@ietf.org; Fri, 03 Mar 2006 11:07:09 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 03 Mar 2006 08:07:08 -0800 X-IronPort-AV: i="4.02,163,1139212800"; d="scan'208"; a="259318651:sNHT29711782" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k23G777T024629; Fri, 3 Mar 2006 08:07:07 -0800 (PST) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Mar 2006 08:07:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Dime] feature tag AVP Date: Fri, 3 Mar 2006 08:04:08 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CC84@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] feature tag AVP Thread-Index: AcY+r6Lzo965uRVVSJeJfL6HJ0FsqwALGOyg From: "Glen Zorn \(gwz\)" To: "German Blanco \(E2/EEM\)" X-OriginalArrivalTime: 03 Mar 2006 16:07:07.0167 (UTC) FILETIME=[84FF02F0:01C63EDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org German Blanco (E2/EEM) supposedly = scribbled: > Hello, >=20 > as far as I know, there is no AVP defined to transport the feature > tags specified in RFC 2533, or?=20 >=20 > Wouldn't it make sense to have an AVP code reserved for that? Why? ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Mar 05 03:52:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFoyM-0004oO-3n; Sun, 05 Mar 2006 03:52:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFoyK-0004oJ-Q9 for dime@ietf.org; Sun, 05 Mar 2006 03:52:12 -0500 Received: from pproxy.gmail.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFoyI-0001Yd-BR for dime@ietf.org; Sun, 05 Mar 2006 03:52:12 -0500 Received: by pproxy.gmail.com with SMTP id n25so555193pyg for ; Sun, 05 Mar 2006 00:52:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:x-priority:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=jSSYm9POIkFga+KOTRXUkvmbC4+vC+YI2aPYdIgdEwjzmeZtoEKwn7DUMYeSdfubBTKoLHoLmJdvoOIkuyAfK90uylBe3LUxaRdFLeoLJtyjnUamuNUn0Eqr7D9eWSFIlkaHhOJ3sibKhqRqmbrGHPukxe83YxBIYH8Iyf5pPxQ= Received: by 10.35.109.2 with SMTP id l2mr1704387pym; Sun, 05 Mar 2006 00:52:09 -0800 (PST) Received: from ?192.168.1.100? ( [68.165.107.76]) by mx.gmail.com with ESMTP id n40sm371961pyg.2006.03.05.00.52.09; Sun, 05 Mar 2006 00:52:09 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <799BA04A-D8A9-4F27-BB7F-5BCB4221A636@gmail.com> Content-Transfer-Encoding: 7bit From: David Connelly Subject: Re: [Dime] application identifiers Date: Sun, 5 Mar 2006 00:52:07 -0800 To: Tolga Asveren X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org My interpretation is that the Vendor-Ids within a Vendor-Specific- Application-ID are merely used to indicate which vendor-specific AVPs are required by the application. Perhaps some implementations could use this information to determine which AVP tables to use when interpreting the message. However, looking at OpenDiameter is even more confusing as OD appears to allow routing of Diameter requests based on the VSAID vendor id(s) as well as the application id, implying that vendor id may be part of the application identity. This does not seem correct at all, but since OD is a popular implementation I wonder how many others may be based on this interpretation as well. - David On Mar 2, 2006, at 6:57 AM, Tolga Asveren wrote: > Anders, > > I am also confused based on seemingly confusing -at least to me- > statement/procedured in RFC3588. > > I guess/believe/think ApplicationId is globally unique based on: > a)11.3 Application Identifiers > It seems like ApplicationIds for all types of applications are > assigned from > the same pool > > b)Message header has ApplicationId but no other field to further > identify > the application the message is belonging to. > > OTOH, espacially 2.7 seems to contradict the above view. If a > global pool is > used for ApplicationIds, I don't see the reason why vendorId is > necessary to > identify them uniquely. > > > Please see for more comments/questions below. > > Thanks, > Tolga > >> -----Original Message----- >> From: Anders Kristensen [mailto:andersk@cisco.com] >> Sent: Wednesday, March 01, 2006 10:54 PM >> To: dime@ietf.org >> Subject: [Dime] application identifiers >> >> >> All, >> >> I have some questions on application IDs. This is all pretty >> fundamental >> stuff so hopefully I didn't get it completely wrong ;) >> >> Applications are identified by the combination of vendor ID and >> application ID with IETF defined apps having vendor ID 0 (3588, >> 2.7). My >> understanding is that with the exception of CER and CEA which are >> special the following is true for all messages: >> >> - Messages belonging to IETF defined apps will never have a >> Vendor-Specific-Application-Id (VSAI) AVP. >> >> - Messages belonging to IETF defined apps may have either an >> Auth-Application-Id or an Acct-Application-Id AVP. If it does have >> one >> of those AVPs, the value will equal that of the Application-ID >> field in >> the message header. > [TOLGA]I am wondering, what is the use of those AVPs except when > advertising > support during capability exchange procedure -eem then, why do we > distinguish between different types of applications, considering that > ApplicationId are assigned from a global pool-? Don't we have the > ApplicationId already in the message header -or am I missing something > fundamental-? >> >> - Messages belonging to non-IETF defined apps must have exactly one >> VSAI AVP. This AVP must contain either an Auth-Application-Id or an >> Acct-Application-Id whose value must equal that of the Application-ID >> field in the message header. [This is not actually what I get from >> reading 3588 (see below) but it's what makes sense, I think.] >> >> Are these statements correct? >> >> If they're correct it follows that a vendor specific application >> cannot >> reuse commands defined in the base spec or at least that such >> messages >> cannot contain a Vendor-Specific-Application-Id and hence must be >> considered part of the base app, not the vendor specific app. >> >> Some questions on specific section of 3588: >> >> Section 2.4: >> >> Each Diameter application MUST have an IANA assigned Application >> Identifier (see Section 11.3). The base protocol does not >> require an >> Application Identifier since its support is mandatory. >> >> All Diameter nodes have to understand CER, DWR and DPR requests but >> clearly not all Diameter nodes will know what to do with, say, an >> ACR so >> this seems wrong. >> >> >> 6.11: >> >> The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type >> Grouped and is used to advertise support of a vendor-specific >> Diameter Application. Exactly one of the Auth-Application-Id and >> Acct-Application-Id AVPs MAY be present. >> ... >> ::= < AVP Header: 260 > >> 1* [ Vendor-Id ] >> 0*1{ Auth-Application-Id } >> 0*1{ Acct-Application-Id } >> >> The sentence "Exactly one of the Auth-Application-Id and >> Acct-Application-Id AVPs MAY be present" seems odd. Should't it be a >> requirement that exactly one of the AVPs be present? As it stands a >> Vendor-Specific-Application-Id containing just a Vendor-Id would >> seem to >> be OK. > [TOLGA]I think your understanding is correct. >> >> And why are multiple Vendor-Ids allowed here? Are there any known >> situations where messages contain a Vendor-Specific-Application-Id >> with >> more than one Vendor-Id? >> >> Also, the text seems to rule out inclusion of both Auth- >> Application-Id >> and Acct-Application-Id but wouldn't it be possible for an app to >> have >> both an accounting and an authentication portion or is that just >> disallowed? (The base app has both, right?) >> >> >> Section 11.3: >> >> Both Application-Id and Acct-Application-Id AVPs use the same >> Application Identifier space. >> >> and Auth-Application-Id too, right? > [TOLGA]Yes, I think so, even vendor specific application Id use the > same > identifier pool. >> >> >> Comments much appreciated. >> >> Thanks, >> Anders >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Mar 05 08:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFtVt-0001US-KR; Sun, 05 Mar 2006 08:43:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFtVr-0001Pc-R6 for dime@ietf.org; Sun, 05 Mar 2006 08:43:08 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFtVo-00066c-CK for dime@ietf.org; Sun, 05 Mar 2006 08:43:07 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k25Dh0vc002014 for ; Sun, 5 Mar 2006 15:43:03 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Mar 2006 15:43:02 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Mar 2006 15:43:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 5 Mar 2006 15:43:02 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DA2@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DiME Interop & NDAs Thread-Index: AcY+8KSfWTofLDQGT+yj/ts1KQFkZQBaaAtA From: To: X-OriginalArrivalTime: 05 Mar 2006 13:43:03.0127 (UTC) FILETIME=[B992AE70:01C6405A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Dime] DiME Interop & NDAs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Some folks had questions about possible NDAs for the upcoming interop. I need to gauge what you all want. One option is no NDA.=20 There would be no identification of who has what bug is to be done. This is essentially what SIPIT does. The purpose of the interop is to a. Check the correctness of implementations b. Gauge the quality of the RFC being tested. The second one in my mind is more important and to expose the flaws in document is necessary to disclose bugs/confusions/errors after the event, without explicitly identifying the implementation affected. When a anomaly shows up in one implementation it is a bug, if it shows up in multiple implementations, frequently it is a documentation issue but sometimes it is because an implementor copies the behavior of another implementation. We encourage people to show up with pre-release code. If some external people demand to know which implementation failed what and claim it is their RIGHT to know, we tell them to get lost.=20 Choice two would be: Use the NDA that is also used by the Connectathon (). Please find it at . A problem with NDAs is that you need them in order to get industrial partners participating, but every participant wants a different NDA (at least their legal departments). The Connectathon NDA has the advantage that it already has been signed by almost every big network equipment manufacturer. Usually, this signature required a check by the company's legal department. I'd prefer option one, but would that prevent anyone from actually attending? John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 06 16:24:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNBn-0000oK-Hy; Mon, 06 Mar 2006 16:24:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMkS-00017D-2l for dime@ietf.org; Mon, 06 Mar 2006 15:56:08 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMhM-0002EL-8Q for dime@ietf.org; Mon, 06 Mar 2006 15:52:56 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 1F080CC141 for ; Mon, 6 Mar 2006 15:52:55 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k26KqsdU015438 for ; Mon, 6 Mar 2006 15:52:55 -0500 (EST) From: "Tolga Asveren" To: Date: Mon, 6 Mar 2006 15:32:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: unknown X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Dime] RFC3588 Error semantics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I am confused about error semantics defined in RFC3588 7. Error Handling AFAICS, in general one can have two different uses for reporting errors: a)Conveying result for a request, if it fails b)Reporting unexpected behavior a) seems applicable only for requests, b) for both requests and answers. I noticed that for some error codes the scope is limited to requests specifically, e.g. DIAMETER_INVALID_MESSAGE_LENGTH, DIAMETER_MISSING_AVP, whereas for some other ones the scope is mentioned as "message", e.g. DIAMETER_AVP_OCCURS_TOO_MANY_TIMES, DIAMETER_AVP_NOT_ALLOWED. What is the criteria to decide whether an error is applicable only for requests or for any message type, e.g. why is DIAMETER_MISSING_AVP only applicable to requests, whereas DIAMETER_AVP_OCCURS_TOO_MANY_TIMES is specified as applicable for a message? Secondly, how the errors for answers going to be routed anyhow? Will the 'r' bit set? If not, how can a relay agent route it, considering that it probably will try to route based on h2hId, like it is doing for other answer messages, -at the time such a message is received, there won't be a matching h2hId on the relay agent-? If the 'r' bit is set, are we expecting the relay agent to be clever enough not to store the h2hId to match for the answer routing? Or, are errors never supposed to be sent for received answers? If so, don't we miss some mechanims to convey information about malformed messages by server? Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 06 20:44:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRFC-0008Om-Vg; Mon, 06 Mar 2006 20:44:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRFB-0008NF-OA for dime@ietf.org; Mon, 06 Mar 2006 20:44:09 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRF9-0002o8-Fw for dime@ietf.org; Mon, 06 Mar 2006 20:44:09 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Mar 2006 20:44:07 -0500 X-IronPort-AV: i="4.02,169,1139202000"; d="scan'208"; a="83632461:sNHT30695084" Received: from [10.86.240.76] (che-vpn-cluster-1-76.cisco.com [10.86.240.76]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k271i6VU012755; Mon, 6 Mar 2006 20:44:06 -0500 (EST) Message-ID: <440CE564.7050801@cisco.com> Date: Mon, 06 Mar 2006 20:44:04 -0500 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] RFC3588 Error semantics References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tolga, I'm pretty sure the intention is that the Result-Code AVP is present only in answer messages and that answer messages are not sent in response to answer messages, only in response to requests. Not having a mechanism for reporting errors in response messages in not unique to Diameter (SIP and ICMP springs to mind). I don't really see that as a big problem although some guidance on how to handle various types of errors found in messages might be useful. Anders Tolga Asveren wrote: > I am confused about error semantics defined in RFC3588 7. Error Handling > > AFAICS, in general one can have two different uses for reporting errors: > a)Conveying result for a request, if it fails > b)Reporting unexpected behavior > > a) seems applicable only for requests, b) for both requests and answers. > > I noticed that for some error codes the scope is limited to requests > specifically, e.g. DIAMETER_INVALID_MESSAGE_LENGTH, DIAMETER_MISSING_AVP, > whereas for some other ones the scope is mentioned as "message", e.g. > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES, DIAMETER_AVP_NOT_ALLOWED. > > What is the criteria to decide whether an error is applicable only for > requests or for any message type, e.g. why is DIAMETER_MISSING_AVP only > applicable to requests, whereas DIAMETER_AVP_OCCURS_TOO_MANY_TIMES is > specified as applicable for a message? > > Secondly, how the errors for answers going to be routed anyhow? Will the 'r' > bit set? If not, how can a relay agent route it, considering that it > probably will try to route based on h2hId, like it is doing for other answer > messages, -at the time such a message is received, there won't be a matching > h2hId on the relay agent-? If the 'r' bit is set, are we expecting the relay > agent to be clever enough not to store the h2hId to match for the answer > routing? > > Or, are errors never supposed to be sent for received answers? If so, don't > we miss some mechanims to convey information about malformed messages by > server? > > > Thanks, > Tolga > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 07 02:39:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGWnG-0003xq-Du; Tue, 07 Mar 2006 02:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGWmz-0003eg-SZ for dime@ietf.org; Tue, 07 Mar 2006 02:39:25 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGWfu-0004mF-A7 for dime@ietf.org; Tue, 07 Mar 2006 02:32:07 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k277Vx2S026651 for ; Tue, 7 Mar 2006 09:32:05 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 09:32:00 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 09:32:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Mar 2006 09:32:00 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869E0E@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda planning Thread-Index: AcZBuTjzNwSGvzkWTfSgyHaLrnO9Nw== From: To: X-OriginalArrivalTime: 07 Mar 2006 07:32:00.0483 (UTC) FILETIME=[38D44B30:01C641B9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Dime] Agenda planning X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, The rough agenda that I have for the DiME meeting in Dallas is as follows: TUESDAY, March 21, 2006 1740-1840 Afternoon Session III WG overview - 5 minutes Interop update - 15 minutes QoS overview - 10 minutes MIP overview - 10 minutes Diameter base updating - as time permits Comments? I will try to assign names and drafts shortly. Indicate your intested in discussing the above topics. http://tools.ietf.org/wg/dime/ thanks, John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 07 03:11:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGWyS-00079y-GE; Tue, 07 Mar 2006 02:51:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGWxR-0004Tz-4a; Tue, 07 Mar 2006 02:50:13 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGWxG-0005Ik-Ct; Tue, 07 Mar 2006 02:50:13 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k277o2vP017080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Mar 2006 07:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGWxF-0002kJ-Ud; Tue, 07 Mar 2006 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 07 Mar 2006 02:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintanence and Extensions Working Group of the IETF. Title : The Diameter API Author(s) : P. Calhoun, et al. Filename : draft-ietf-dime-diameter-api-00.txt Pages : 45 Date : 2006-3-6 The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes a standardized API for the Diameter protocol. The API is defined for the C language. The intent of the API is to foster source code portability across multiple programming platforms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-diameter-api-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-diameter-api-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-6202243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-api-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-api-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6202243.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Mar 07 04:40:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYg0-0005k8-VM; Tue, 07 Mar 2006 04:40:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYfz-0005jU-RO for dime@ietf.org; Tue, 07 Mar 2006 04:40:19 -0500 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGYfx-0003CB-5T for dime@ietf.org; Tue, 07 Mar 2006 04:40:19 -0500 Received: from etri04q4sqc7zc ([129.254.12.66]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 18:42:49 +0900 From: "Junghoon Jee" To: Date: Tue, 7 Mar 2006 18:40:12 +0900 Message-ID: <013c01c641cb$21d7b8b0$420cfe81@etri04q4sqc7zc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcZByyHH44mQImz5QeOaeDBIHt7ubw== X-OriginalArrivalTime: 07 Mar 2006 09:42:49.0792 (UTC) FILETIME=[7F61CC00:01C641CB] X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: dime@ietf.org Subject: [Dime] Re: Diameter MIPv6 Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, Great works! For working on the integrated scenario, the following I-D which is also based on the Franck Le's draft would be helpful. Maybe, I hope you would get hints from the following I-D, for rationale of new Diameter Application regarding MIPv6 bootstrapping based on the feature of local or home agent assignments which is not directly related with the previous existing Diameter Application, like Diameter EAP. "Diameter Mobile IPv6 Bootstrapping Application using PANA", http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt Thanks, -Junghoon -------------------------------------------- Hi all, we have compiled two Diameter documents that provide the backend solution for the split & the integrated scenario. Please find the document here: Mobile IPv6 Bootstrapping using Diameter in the Split Scenario Abstract In Mobile IPv6 deployment a need for an interaction between the Home Agent, the AAA infrastructure of the Mobile Service Provider (MSP) and the Mobility Service Authorizer (MSA) has been identified. This document provides a description of the functionality that allows to meet the goals outlined in the MIPv6 AAA Goals document. http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-split-00.t xt Diameter MIPv6 Application for the Integrated Scenario Abstract A Mobile IPv6 node requires a home agent address, a home address, and IPsec security association with its home agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document defines a Diameter application to facilitate Mobile IPv6 bootstrapping for the integrated scenario. http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-integrated -0 0.txt Before I started working on the latter document I contact Franck Le since he was the author/editor of the previous Diameter MIPv6 Application document. It turned out that the previously written document had a different focus than today's bootstrapping activites. Anyway, I got in touch with Franck to work on the document with him but he moved to CMU and has no time for it anymore. Maybe the other co-authors are still interested in this subject - but I haven't received a reply yet. I am still looking for some co-authors.... Ciao Hannes http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 07 05:00:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYz9-00065b-42; Tue, 07 Mar 2006 05:00:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYz8-00063x-BT for dime@ietf.org; Tue, 07 Mar 2006 05:00:06 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGYz6-0004I8-Tj for dime@ietf.org; Tue, 07 Mar 2006 05:00:06 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 0F559809A; Tue, 7 Mar 2006 11:00:03 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FGYvn-0001Kw-EQ; Tue, 07 Mar 2006 10:56:39 +0100 Date: Tue, 7 Mar 2006 10:56:39 +0100 From: Julien Bournelle To: Junghoon Jee Subject: Re: [Dime] Re: Diameter MIPv6 Application Message-ID: <20060307095639.GA5134@ipv6-3.int-evry.fr> References: <013c01c641cb$21d7b8b0$420cfe81@etri04q4sqc7zc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013c01c641cb$21d7b8b0$420cfe81@etri04q4sqc7zc> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: dime@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi junghoon, On Tue, Mar 07, 2006 at 06:40:12PM +0900, Junghoon Jee wrote: > Hi Hannes, > > Great works! > > For working on the integrated scenario, > the following I-D which is also based on the Franck Le's draft would > be helpful. > > Maybe, I hope you would get hints from the following I-D, for > rationale > of new Diameter Application regarding MIPv6 bootstrapping based on > the feature of local or home agent assignments which is not directly > related with > the previous existing Diameter Application, like Diameter EAP. I don't think we have to reinvent a bootstrapping mechanism for mip6 since it was the goal of the DT. From my point of view, the document should be aligned on draft-ietf-mip6-boostrapping-integrated-dhc-00.txt. Wether we need new Diameter Messages (I don't think that's the good option based on my recent mail posted here) or just add AVPs to NASREQ/EAP may need more discussions. In both case, requesting an Application-ID seems necessary for the 'M' bit support. My 2 cents, Julien Bournelle > > "Diameter Mobile IPv6 Bootstrapping Application using PANA", > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > Thanks, > -Junghoon > > > -------------------------------------------- > Hi all, > > we have compiled two Diameter documents that provide the backend > solution for the split & the integrated scenario. > > Please find the document here: > > Mobile IPv6 Bootstrapping using Diameter in the Split Scenario > > Abstract > > In Mobile IPv6 deployment a need for an interaction between the > Home > Agent, the AAA infrastructure of the Mobile Service Provider (MSP) > and the Mobility Service Authorizer (MSA) has been identified. > This > document provides a description of the functionality that allows to > meet the goals outlined in the MIPv6 AAA Goals document. > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-split-00.t > xt > > > Diameter MIPv6 Application for the Integrated Scenario > > Abstract > > A Mobile IPv6 node requires a home agent address, a home address, > and > IPsec security association with its home agent before it can start > utilizing Mobile IPv6 service. RFC 3775 requires that some or all > of > these parameters are statically configured. Ongoing work aims to > make this information dynamically available to the mobile node. An > important aspect of the Mobile IPv6 bootstrapping solution is to > support interworking with existing authentication, authorization > and > accounting infrastructure. This document defines a Diameter > application to facilitate Mobile IPv6 bootstrapping for the > integrated scenario. > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-integrated > -0 > 0.txt > > Before I started working on the latter document I contact Franck Le > since he was the author/editor of the previous Diameter MIPv6 > Application document. It turned out that the previously written > document > had a different focus than today's bootstrapping activites. Anyway, I > got in touch with Franck to work on the document with him but he moved > to CMU and has no time for it anymore. Maybe the other co-authors are > still interested in this subject - but I haven't received a reply yet. > I > am still looking for some co-authors.... > > Ciao > Hannes > > > > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 07 05:51:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZmT-0007N6-1W; Tue, 07 Mar 2006 05:51:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZmR-0007Mq-NV for dime@ietf.org; Tue, 07 Mar 2006 05:51:03 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZmR-00065D-2t for dime@ietf.org; Tue, 07 Mar 2006 05:51:03 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27AnMiK028687; Tue, 7 Mar 2006 12:49:25 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 12:50:57 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 12:50:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RFC3588 Error semantics Date: Tue, 7 Mar 2006 12:50:52 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869E2F@esebe100.NOE.Nokia.com> In-Reply-To: <440CE564.7050801@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC3588 Error semantics Thread-Index: AcZBiKbyllekl0pcRPeJ4b84AQVXhgATEhPQ From: To: , X-OriginalArrivalTime: 07 Mar 2006 10:50:53.0258 (UTC) FILETIME=[015142A0:01C641D5] X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I'm not to sure any extra text in 3588 would really help - RFCs shouldn't specify every detail ... =20 >-----Original Message----- >From: ext Anders Kristensen [mailto:andersk@cisco.com]=20 >Sent: 07 March, 2006 03:44 >To: Tolga Asveren >Cc: dime@ietf.org >Subject: Re: [Dime] RFC3588 Error semantics > >Tolga, > >I'm pretty sure the intention is that the Result-Code AVP is=20 >present only in answer messages and that answer messages are=20 >not sent in response to answer messages, only in response to=20 >requests. Not having a mechanism for reporting errors in=20 >response messages in not unique to Diameter (SIP and ICMP=20 >springs to mind). I don't really see that as a big problem=20 >although some guidance on how to handle various types of=20 >errors found in messages might be useful. > >Anders > >Tolga Asveren wrote: > >> I am confused about error semantics defined in RFC3588 7. Error=20 >> Handling >>=20 >> AFAICS, in general one can have two different uses for=20 >reporting errors: >> a)Conveying result for a request, if it fails b)Reporting unexpected=20 >> behavior >>=20 >> a) seems applicable only for requests, b) for both requests=20 >and answers. >>=20 >> I noticed that for some error codes the scope is limited to requests=20 >> specifically, e.g. DIAMETER_INVALID_MESSAGE_LENGTH,=20 >> DIAMETER_MISSING_AVP, whereas for some other ones the scope=20 >is mentioned as "message", e.g. >> DIAMETER_AVP_OCCURS_TOO_MANY_TIMES, DIAMETER_AVP_NOT_ALLOWED. >>=20 >> What is the criteria to decide whether an error is=20 >applicable only for=20 >> requests or for any message type, e.g. why is DIAMETER_MISSING_AVP=20 >> only applicable to requests, whereas=20 >> DIAMETER_AVP_OCCURS_TOO_MANY_TIMES is specified as=20 >applicable for a message? >>=20 >> Secondly, how the errors for answers going to be routed=20 >anyhow? Will the 'r' >> bit set? If not, how can a relay agent route it, considering that it=20 >> probably will try to route based on h2hId, like it is doing=20 >for other=20 >> answer messages, -at the time such a message is received,=20 >there won't=20 >> be a matching h2hId on the relay agent-? If the 'r' bit is=20 >set, are we=20 >> expecting the relay agent to be clever enough not to store the h2hId=20 >> to match for the answer routing? >>=20 >> Or, are errors never supposed to be sent for received=20 >answers? If so,=20 >> don't we miss some mechanims to convey information about malformed=20 >> messages by server? >>=20 >>=20 >> Thanks, >> Tolga >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >>=20 > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 07 09:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdAT-0006eb-A3; Tue, 07 Mar 2006 09:28:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdAS-0006eW-I2 for dime@ietf.org; Tue, 07 Mar 2006 09:28:04 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdAS-0004bn-4B for dime@ietf.org; Tue, 07 Mar 2006 09:28:04 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9783856B4A for ; Tue, 7 Mar 2006 09:28:03 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k27ES1ex002790 for ; Tue, 7 Mar 2006 09:28:03 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] RFC3588 Error semantics Date: Tue, 7 Mar 2006 09:07:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <440CE564.7050801@cisco.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Anders, > -----Original Message----- > From: Anders Kristensen [mailto:andersk@cisco.com] > Sent: Monday, March 06, 2006 8:44 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] RFC3588 Error semantics > > > Tolga, > > I'm pretty sure the intention is that the Result-Code AVP is present > only in answer messages and that answer messages are not sent in > response to answer messages, only in response to requests. Not having a > mechanism for reporting errors in response messages in not unique to > Diameter (SIP and ICMP springs to mind). I don't really see that as a > big problem although some guidance on how to handle various types of > errors found in messages might be useful. [TOLGA]Yes, using errors only for requests is not a big issue, client can drop connection anytime if it is unhappy with responses sent by the server anyhow. For any possible text clarification, I would think using the word "request" in all of the error code descriptions could be an idea -that for certain error codes the description contains the word "message" was the starting point for my confusion-. > > Anders > > Tolga Asveren wrote: > > > I am confused about error semantics defined in RFC3588 7. Error Handling > > > > AFAICS, in general one can have two different uses for reporting errors: > > a)Conveying result for a request, if it fails > > b)Reporting unexpected behavior > > > > a) seems applicable only for requests, b) for both requests and answers. > > > > I noticed that for some error codes the scope is limited to requests > > specifically, e.g. DIAMETER_INVALID_MESSAGE_LENGTH, > DIAMETER_MISSING_AVP, > > whereas for some other ones the scope is mentioned as "message", e.g. > > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES, DIAMETER_AVP_NOT_ALLOWED. > > > > What is the criteria to decide whether an error is applicable only for > > requests or for any message type, e.g. why is DIAMETER_MISSING_AVP only > > applicable to requests, whereas DIAMETER_AVP_OCCURS_TOO_MANY_TIMES is > > specified as applicable for a message? > > > > Secondly, how the errors for answers going to be routed anyhow? > Will the 'r' > > bit set? If not, how can a relay agent route it, considering that it > > probably will try to route based on h2hId, like it is doing for > other answer > > messages, -at the time such a message is received, there won't > be a matching > > h2hId on the relay agent-? If the 'r' bit is set, are we > expecting the relay > > agent to be clever enough not to store the h2hId to match for the answer > > routing? > > > > Or, are errors never supposed to be sent for received answers? > If so, don't > > we miss some mechanims to convey information about malformed messages by > > server? > > > > > > Thanks, > > Tolga > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 07 16:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjLW-0000cE-1K; Tue, 07 Mar 2006 16:03:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjFu-0002aS-8Z for dime@ietf.org; Tue, 07 Mar 2006 15:58:06 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGjFs-0004NO-PM for dime@ietf.org; Tue, 07 Mar 2006 15:58:06 -0500 Received: (qmail invoked by alias); 07 Mar 2006 20:51:23 -0000 Received: from p54987E8F.dip.t-dialin.net (EHLO [192.168.2.101]) [84.152.126.143] by mail.gmx.net (mp019) with SMTP; 07 Mar 2006 21:51:23 +0100 X-Authenticated: #29516787 Message-ID: <440DF248.2020403@gmx.net> Date: Tue, 07 Mar 2006 21:51:20 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Junghoon Jee Subject: Re: [Dime] Re: Diameter MIPv6 Application References: <013c01c641cb$21d7b8b0$420cfe81@etri04q4sqc7zc> In-Reply-To: <013c01c641cb$21d7b8b0$420cfe81@etri04q4sqc7zc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: dime@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Junghoon, thanks for your response. We will certainly take a look at your draft as well. Ciao Hannes Junghoon Jee wrote: > Hi Hannes, > > Great works! > > For working on the integrated scenario, > the following I-D which is also based on the Franck Le's draft would > be helpful. > > Maybe, I hope you would get hints from the following I-D, for > rationale > of new Diameter Application regarding MIPv6 bootstrapping based on > the feature of local or home agent assignments which is not directly > related with > the previous existing Diameter Application, like Diameter EAP. > > "Diameter Mobile IPv6 Bootstrapping Application using PANA", > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > Thanks, > -Junghoon > > > -------------------------------------------- > Hi all, > > we have compiled two Diameter documents that provide the backend > solution for the split & the integrated scenario. > > Please find the document here: > > Mobile IPv6 Bootstrapping using Diameter in the Split Scenario > > Abstract > > In Mobile IPv6 deployment a need for an interaction between the > Home > Agent, the AAA infrastructure of the Mobile Service Provider (MSP) > and the Mobility Service Authorizer (MSA) has been identified. > This > document provides a description of the functionality that allows to > meet the goals outlined in the MIPv6 AAA Goals document. > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-split-00.t > xt > > > Diameter MIPv6 Application for the Integrated Scenario > > Abstract > > A Mobile IPv6 node requires a home agent address, a home address, > and > IPsec security association with its home agent before it can start > utilizing Mobile IPv6 service. RFC 3775 requires that some or all > of > these parameters are statically configured. Ongoing work aims to > make this information dynamically available to the mobile node. An > important aspect of the Mobile IPv6 bootstrapping solution is to > support interworking with existing authentication, authorization > and > accounting infrastructure. This document defines a Diameter > application to facilitate Mobile IPv6 bootstrapping for the > integrated scenario. > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-integrated > -0 > 0.txt > > Before I started working on the latter document I contact Franck Le > since he was the author/editor of the previous Diameter MIPv6 > Application document. It turned out that the previously written > document > had a different focus than today's bootstrapping activites. Anyway, I > got in touch with Franck to work on the document with him but he moved > to CMU and has no time for it anymore. Maybe the other co-authors are > still interested in this subject - but I haven't received a reply yet. > I > am still looking for some co-authors.... > > Ciao > Hannes > > > > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 07 16:04:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjLi-0000vx-7p; Tue, 07 Mar 2006 16:04:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjLG-0000MB-Ja for dime@ietf.org; Tue, 07 Mar 2006 16:03:39 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGjLG-000621-4V for dime@ietf.org; Tue, 07 Mar 2006 16:03:38 -0500 Received: (qmail invoked by alias); 07 Mar 2006 21:03:37 -0000 Received: from p54987E8F.dip.t-dialin.net (EHLO [192.168.2.101]) [84.152.126.143] by mail.gmx.net (mp034) with SMTP; 07 Mar 2006 22:03:37 +0100 X-Authenticated: #29516787 Message-ID: <440DF526.6050100@gmx.net> Date: Tue, 07 Mar 2006 22:03:34 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Dime] Diameter MIPv6 Application: Status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, during the last week we had a lot of discussions on how to proceed with the Diameter MIPv6 application for the integrated scenario. Julien Bournelle, Jouni Korhonen, Victor Fajardo and Charles Perkins joined the work on the draft. Two issues were discovered during our discussions: 1) A pull approach has to be used for the interaction between a Diameter entity and the Home Agent. The push approach is not supported. We clearly want to make sure that the work is closely aligned with draft-ietf-mip6-boostrapping-integrated-dhc-00.txt This requires a few modifications to the draft. 2) Do we need a new application or just a bunch of AVPs? We haven't reached consensus on this issue. Particularly regarding issue (2) we would appreciate feedback. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 07 20:20:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGnLn-0004Ko-87; Tue, 07 Mar 2006 20:20:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGnLg-0003qX-BS for dime@ietf.org; Tue, 07 Mar 2006 20:20:20 -0500 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGnAo-00067q-DN for dime@ietf.org; Tue, 07 Mar 2006 20:09:08 -0500 Received: from etri04q4sqc7zc ([129.254.12.66]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 10:11:39 +0900 From: "Junghoon Jee" To: "'Julien Bournelle'" Subject: RE: [Dime] Re: Diameter MIPv6 Application Date: Wed, 8 Mar 2006 10:09:02 +0900 Message-ID: <02f901c6424c$e36fcae0$420cfe81@etri04q4sqc7zc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060307095639.GA5134@ipv6-3.int-evry.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZBzkmRlU9C6OxCQr+CxKmGjuVvjwAe36+Q X-OriginalArrivalTime: 08 Mar 2006 01:11:39.0572 (UTC) FILETIME=[40EB5F40:01C6424D] X-Spam-Score: 0.1 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: dime@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, Please see my inline replies. > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > Sent: Tuesday, March 07, 2006 6:57 PM > To: Junghoon Jee > Cc: hannes.tschofenig@siemens.com; dime@ietf.org > Subject: Re: [Dime] Re: Diameter MIPv6 Application > > > Hi junghoon, > > On Tue, Mar 07, 2006 at 06:40:12PM +0900, Junghoon Jee wrote: > > Hi Hannes, > > > > Great works! > > > > For working on the integrated scenario, the following I-D which is > > also based on the Franck Le's draft would be helpful. > > > > Maybe, I hope you would get hints from the following I-D, for > > rationale of new Diameter Application regarding MIPv6 bootstrapping > > based on the feature of local or home agent assignments > which is not > > directly related with the previous existing Diameter > Application, like > > Diameter EAP. > > I don't think we have to reinvent a bootstrapping mechanism > for mip6 since it was the goal of the DT. From my point of > view, the document should be aligned on > draft-ietf-mip6-boostrapping-integrated-dhc-00.txt. Sure, I am not proposing any new bootstrapping mechanism here. I am talking about the rationale for a new Diameter application regarding MIP6 bootstrapping. Let me more clarify. Through the integrated scenario, AAA server assigns a home agent for a mobile node. This home agent can be located at local or home of mobile node. The decision where to locate a home agent needs to be transacted between AAAv and AAAh based on the MN's profile and request. The seed information can be conveyed as a flag type as shown below. 2 Home-Address-Allocatable-Only-in-Home-Domain flag: This flag is set to '1' when the MN requests the home address to be assigned in its home network. 4 Home-Agent-in-Visited-Domain flag: This flag is set to '1' when the AAAh allows the allocation of HA in the visited network. 8 Visited-Home-Agent-Available flag: This flag is set to '1' when the AAAv notifies to the AAAh that it can support the assignment of a HA in the visited network. I don't think that it is a right choice to transfer this kind of information through the existing Diameter messages which are not relevant to MIP6. Thanks, Junghoon > Wether we need new Diameter Messages (I don't think that's > the good option based on my recent mail posted here) or just > add AVPs to NASREQ/EAP may need more discussions. > In both case, requesting an Application-ID seems necessary > for the 'M' > bit support. > > My 2 cents, > > Julien Bournelle > > > > > "Diameter Mobile IPv6 Bootstrapping Application using PANA", > > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > > > Thanks, > > -Junghoon > > > > > > -------------------------------------------- > > Hi all, > > > > we have compiled two Diameter documents that provide the backend > > solution for the split & the integrated scenario. > > > > Please find the document here: > > > > Mobile IPv6 Bootstrapping using Diameter in the Split Scenario > > > > Abstract > > > > In Mobile IPv6 deployment a need for an interaction between the > > Home > > Agent, the AAA infrastructure of the Mobile Service > Provider (MSP) > > and the Mobility Service Authorizer (MSA) has been identified. > > This > > document provides a description of the functionality > that allows to > > meet the goals outlined in the MIPv6 AAA Goals document. > > > > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-split-00.t > > xt > > > > > > Diameter MIPv6 Application for the Integrated Scenario > > > > Abstract > > > > A Mobile IPv6 node requires a home agent address, a home > address, > > and > > IPsec security association with its home agent before it > can start > > utilizing Mobile IPv6 service. RFC 3775 requires that > some or all > > of > > these parameters are statically configured. Ongoing work aims to > > make this information dynamically available to the > mobile node. An > > important aspect of the Mobile IPv6 bootstrapping solution is to > > support interworking with existing authentication, authorization > > and > > accounting infrastructure. This document defines a Diameter > > application to facilitate Mobile IPv6 bootstrapping for the > > integrated scenario. > > > > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-integrated > > -0 > > 0.txt > > > > Before I started working on the latter document I contact Franck Le > > since he was the author/editor of the previous Diameter MIPv6 > > Application document. It turned out that the previously written > > document had a different focus than today's bootstrapping > activites. > > Anyway, I got in touch with Franck to work on the document with him > > but he moved to CMU and has no time for it anymore. Maybe the other > > co-authors are still interested in this subject - but I haven't > > received a reply yet. > > I > > am still looking for some co-authors.... > > > > Ciao > > Hannes > > > > > > > > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > -- > julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 08 03:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGu2j-0007CN-CL; Wed, 08 Mar 2006 03:29:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGu2i-0007C4-1a for dime@ietf.org; Wed, 08 Mar 2006 03:29:12 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGsiv-0000GZ-1H for dime@ietf.org; Wed, 08 Mar 2006 02:04:41 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGsTz-0006mx-Pr for dime@ietf.org; Wed, 08 Mar 2006 01:49:17 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k286nAXL006790 for ; Wed, 8 Mar 2006 08:49:14 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 08:49:11 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 08:49:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Mar 2006 08:49:11 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869E4F@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Thread-Index: AcZB+K+H/bPtHKKIQgausGeQUwe9SQAgzepg From: To: X-OriginalArrivalTime: 08 Mar 2006 06:49:11.0910 (UTC) FILETIME=[6840E860:01C6427C] X-Spam-Score: -2.6 (--) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, I'd like to start a WG last call on the Diameter API. The API is in use in the OpenDiameter project,=20 and changes they have made for their implementation have been reflected in the API. =20 WGLC ends on Friday March 24th.=20 Please review the document, send issues in the form of> Description of issue Submitter name: Your_Name_Here Submitter email address: Your_Email_Address_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail describing problem, if available Document: Document Requiring change [Diameter API] Comment type: ['T'echnical | 'E'ditorial] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposed changes to the document. Please be specific about what text you want=20 to change, add or delete. Issues cannot be considered until specific text is provided. If you have read the document & think it is good to go, please send a mail to that respect. thanks, John >>From: ext dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>Sent: 07 March, 2006 09:50 >>To: i-d-announce@ietf.org >>Cc: dime@ietf.org >>Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-00.txt >> >>A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >>This draft is a work item of the Diameter Maintanence and Extensions=20 >>Working Group of the IETF. >> >> Title : The Diameter API >> Author(s) : P. Calhoun, et al. >> Filename : draft-ietf-dime-diameter-api-00.txt >> Pages : 45 >> Date : 2006-3-6 >>=09 >> The Diameter authentication, authorization, and accounting (AAA) =20 >> protocol provides support for peering AAA transactions across the =20 >> Internet. This document describes a standardized API for the =20 >> Diameter protocol. The API is defined for the C language. The =20 >> intent of the API is to foster source code portability across =20 >> multiple programming platforms. >> >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.tx >>t >> >>To remove yourself from the I-D Announcement list, send a message to=20 >>i-d-announce-request@ietf.org with the word unsubscribe in the body of >>the message. >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the=20 >>username "anonymous" and a password of your e-mail address. After=20 >>logging in, type "cd internet-drafts" and then >> "get draft-ietf-dime-diameter-api-00.txt". >> >>A list of Internet-Drafts directories can be found in=20 >>http://www.ietf.org/shadow.html or=20 >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-dime-diameter-api-00.txt". >>=09 >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> =09 >> =09 >>Below is the data which will enable a MIME compliant mail reader=20 >>implementation to automatically retrieve the ASCII version of the=20 >>Internet-Draft. >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 08 04:04:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuaW-0007Aw-HV; Wed, 08 Mar 2006 04:04:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuaU-00074d-Ic for dime@ietf.org; Wed, 08 Mar 2006 04:04:06 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGuaT-0008Re-0N for dime@ietf.org; Wed, 08 Mar 2006 04:04:06 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 60487801B; Wed, 8 Mar 2006 10:04:02 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FGuX7-0001ft-J1; Wed, 08 Mar 2006 10:00:37 +0100 Date: Wed, 8 Mar 2006 10:00:37 +0100 From: Julien Bournelle To: Junghoon Jee Subject: Re: [Dime] Re: Diameter MIPv6 Application Message-ID: <20060308090037.GE6356@ipv6-3.int-evry.fr> References: <20060307095639.GA5134@ipv6-3.int-evry.fr> <02f901c6424c$e36fcae0$420cfe81@etri04q4sqc7zc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02f901c6424c$e36fcae0$420cfe81@etri04q4sqc7zc> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: dime@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi junghoon, On Wed, Mar 08, 2006 at 10:09:02AM +0900, Junghoon Jee wrote: > Hi Julien, > Please see my inline replies. > > > -----Original Message----- > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > Sent: Tuesday, March 07, 2006 6:57 PM > > To: Junghoon Jee > > Cc: hannes.tschofenig@siemens.com; dime@ietf.org > > Subject: Re: [Dime] Re: Diameter MIPv6 Application > > > > > > Hi junghoon, > > > > On Tue, Mar 07, 2006 at 06:40:12PM +0900, Junghoon Jee wrote: > > > Hi Hannes, > > > > > > Great works! > > > > > > For working on the integrated scenario, the following I-D which is > > > > also based on the Franck Le's draft would be helpful. > > > > > > Maybe, I hope you would get hints from the following I-D, for > > > rationale of new Diameter Application regarding MIPv6 > bootstrapping > > > based on the feature of local or home agent assignments > > which is not > > > directly related with the previous existing Diameter > > Application, like > > > Diameter EAP. > > > > I don't think we have to reinvent a bootstrapping mechanism > > for mip6 since it was the goal of the DT. From my point of > > view, the document should be aligned on > > draft-ietf-mip6-boostrapping-integrated-dhc-00.txt. > > Sure, I am not proposing any new bootstrapping mechanism here. Let's say new features. > I am talking about the rationale for a new Diameter application > regarding MIP6 bootstrapping. > > Let me more clarify. > Through the integrated scenario, AAA server assigns a home agent for a > mobile node. > This home agent can be located at local or home of mobile node. > The decision where to locate a home agent needs to be transacted > between AAAv and AAAh > based on the MN's profile and request. In the Integrated scenario, this decision is made by the MN in his DHCP request. This is not based on its profile. At least that's what I understood. The AAAH always sends a HA address in the (visited NAS). > The seed information can be conveyed as a flag type as shown below. > > 2 Home-Address-Allocatable-Only-in-Home-Domain flag: This flag > is > set to '1' when the MN requests the home address to be assigned in > its home network. > > 4 Home-Agent-in-Visited-Domain flag: This flag is set to '1' > when > the AAAh allows the allocation of HA in the visited network. > > 8 Visited-Home-Agent-Available flag: This flag is set to '1' > when > the AAAv notifies to the AAAh that it can support the assignment of > a > HA in the visited network. > > > I don't think that it is a right choice to transfer this kind of > information through the existing Diameter messages > which are not relevant to MIP6. but how do the NAS know which Diameter application to use with the AAA server ? If you want a specific Diameter Application (I mean new messages), this imply to modify all Client - NAS protocol. Am I missing something ? Thanks, Julien > > Thanks, > Junghoon > > > Wether we need new Diameter Messages (I don't think that's > > the good option based on my recent mail posted here) or just > > add AVPs to NASREQ/EAP may need more discussions. > > > In both case, requesting an Application-ID seems necessary > > for the 'M' > > bit support. > > > > My 2 cents, > > > > Julien Bournelle > > > > > > > > "Diameter Mobile IPv6 Bootstrapping Application using PANA", > > > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > > > > > Thanks, > > > -Junghoon > > > > > > > > > -------------------------------------------- > > > Hi all, > > > > > > we have compiled two Diameter documents that provide the backend > > > solution for the split & the integrated scenario. > > > > > > Please find the document here: > > > > > > Mobile IPv6 Bootstrapping using Diameter in the Split Scenario > > > > > > Abstract > > > > > > In Mobile IPv6 deployment a need for an interaction between the > > > > Home > > > Agent, the AAA infrastructure of the Mobile Service > > Provider (MSP) > > > and the Mobility Service Authorizer (MSA) has been identified. > > > This > > > document provides a description of the functionality > > that allows to > > > meet the goals outlined in the MIPv6 AAA Goals document. > > > > > > > > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-split-00.t > > > xt > > > > > > > > > Diameter MIPv6 Application for the Integrated Scenario > > > > > > Abstract > > > > > > A Mobile IPv6 node requires a home agent address, a home > > address, > > > and > > > IPsec security association with its home agent before it > > can start > > > utilizing Mobile IPv6 service. RFC 3775 requires that > > some or all > > > of > > > these parameters are statically configured. Ongoing work aims > to > > > make this information dynamically available to the > > mobile node. An > > > important aspect of the Mobile IPv6 bootstrapping solution is > to > > > support interworking with existing authentication, > authorization > > > and > > > accounting infrastructure. This document defines a Diameter > > > application to facilitate Mobile IPv6 bootstrapping for the > > > integrated scenario. > > > > > > > > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-integrated > > > -0 > > > 0.txt > > > > > > Before I started working on the latter document I contact Franck > Le > > > since he was the author/editor of the previous Diameter MIPv6 > > > Application document. It turned out that the previously written > > > document had a different focus than today's bootstrapping > > activites. > > > Anyway, I got in touch with Franck to work on the document with > him > > > but he moved to CMU and has no time for it anymore. Maybe the > other > > > co-authors are still interested in this subject - but I haven't > > > received a reply yet. > > > I > > > am still looking for some co-authors.... > > > > > > Ciao > > > Hannes > > > > > > > > > > > > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > -- > > julien.bournelle at int-evry.fr > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 08 04:53:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGvLp-00005Q-LI; Wed, 08 Mar 2006 04:53:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGvLn-0008Ti-Bm for dime@ietf.org; Wed, 08 Mar 2006 04:52:59 -0500 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGvLl-0002EF-CU for dime@ietf.org; Wed, 08 Mar 2006 04:52:59 -0500 Received: from etri04q4sqc7zc ([129.254.12.66]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 18:55:30 +0900 From: "Junghoon Jee" To: "'Julien Bournelle'" Subject: RE: [Dime] Re: Diameter MIPv6 Application Date: Wed, 8 Mar 2006 18:52:54 +0900 Message-ID: <047b01c64296$124dbd10$420cfe81@etri04q4sqc7zc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060308090037.GE6356@ipv6-3.int-evry.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZCj52wy7BO6Y9lT/G02GkUafayvAAAnCGQ X-OriginalArrivalTime: 08 Mar 2006 09:55:30.0291 (UTC) FILETIME=[6F167C30:01C64296] X-Spam-Score: 0.1 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: dime@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Julien, please see my inline replies. > > I am talking about the rationale for a new Diameter application > > regarding MIP6 bootstrapping. > > > > Let me more clarify. > > Through the integrated scenario, AAA server assigns a home > agent for a > > mobile node. > > This home agent can be located at local or home of mobile node. > > The decision where to locate a home agent needs to be transacted > > between AAAv and AAAh based on the MN's profile and request. > > In the Integrated scenario, this decision is made by the MN > in his DHCP request. This is not based on its profile. At > least that's what I understood. Yes, this is a point that needs to be amended from the existing DHCP based integrated scenario. Why AAAh needs to allocate a home agent in case AAAv can/needs to allocate a home agent in the local domain? If AAAh always allocates a home agent then when that kind of information will be cleaned up in case that home agent is not used? IMO, AAAh needs to know that AAAv can allocate a home agent for the mobile node and then needs to decide where to locate home agent for a mobile node. In case the mobile node requests the allocation of home agent in the visited domain and the kind of feature is possible depending on the profile of the mobile node then, AAAv finally allocates the local home agent following the confirmation from AAAh. > The AAAH always sends a HA address in the (visited NAS). > > > The seed information can be conveyed as a flag type as shown below. > > > > 2 Home-Address-Allocatable-Only-in-Home-Domain flag: This flag > > is > > set to '1' when the MN requests the home address to be > assigned in > > its home network. > > > > 4 Home-Agent-in-Visited-Domain flag: This flag is set to '1' > > when > > the AAAh allows the allocation of HA in the visited network. > > > > 8 Visited-Home-Agent-Available flag: This flag is set to '1' > > when > > the AAAv notifies to the AAAh that it can support the > assignment of > > a > > HA in the visited network. > > > > > > I don't think that it is a right choice to transfer this kind of > > information through the existing Diameter messages which are not > > relevant to MIP6. > > but how do the NAS know which Diameter application to use > with the AAA server ? According to the DHCPv6 options, I think. DHCP server parses these DHCP options which are configured by a mobile node, then it can notify NAS of the fact that a mobile node is requesting the assignment of home agent. Thus, NAS can invoke a new Diameter MIP6 bootstrapping application. If the DHCP relay which can be collocated with NAS can parse these options, then it can be more simpler. Thanks, -Junghoon If you want a specific Diameter > Application (I mean new messages), this imply to modify all > Client - NAS protocol. > > Am I missing something ? > Thanks, > > Julien > > > > > Thanks, > > Junghoon > > > > > Wether we need new Diameter Messages (I don't think > that's the good > > > option based on my recent mail posted here) or just add AVPs to > > > NASREQ/EAP may need more discussions. > > > > > In both case, requesting an Application-ID seems > necessary for the > > > 'M' > > > bit support. > > > > > > My 2 cents, > > > > > > Julien Bournelle > > > > > > > > > > > "Diameter Mobile IPv6 Bootstrapping Application using PANA", > > > > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > > > > > > > Thanks, > > > > -Junghoon > > > > > > > > > > > > -------------------------------------------- > > > > Hi all, > > > > > > > > we have compiled two Diameter documents that provide > the backend > > > > solution for the split & the integrated scenario. > > > > > > > > Please find the document here: > > > > > > > > Mobile IPv6 Bootstrapping using Diameter in the Split Scenario > > > > > > > > Abstract > > > > > > > > In Mobile IPv6 deployment a need for an interaction > between the > > > > > > Home > > > > Agent, the AAA infrastructure of the Mobile Service > > > Provider (MSP) > > > > and the Mobility Service Authorizer (MSA) has been > identified. > > > > This > > > > document provides a description of the functionality > > > that allows to > > > > meet the goals outlined in the MIPv6 AAA Goals document. > > > > > > > > > > > > > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-split-00.t > > > > xt > > > > > > > > > > > > Diameter MIPv6 Application for the Integrated Scenario > > > > > > > > Abstract > > > > > > > > A Mobile IPv6 node requires a home agent address, a home > > > address, > > > > and > > > > IPsec security association with its home agent before it > > > can start > > > > utilizing Mobile IPv6 service. RFC 3775 requires that > > > some or all > > > > of > > > > these parameters are statically configured. Ongoing > work aims > > to > > > > make this information dynamically available to the > > > mobile node. An > > > > important aspect of the Mobile IPv6 bootstrapping solution is > > to > > > > support interworking with existing authentication, > > authorization > > > > and > > > > accounting infrastructure. This document defines a Diameter > > > > application to facilitate Mobile IPv6 bootstrapping for the > > > > integrated scenario. > > > > > > > > > > > > > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-integrated > > > > -0 > > > > 0.txt > > > > > > > > Before I started working on the latter document I contact Franck > > Le > > > > since he was the author/editor of the previous Diameter MIPv6 > > > > Application document. It turned out that the previously written > > > > document had a different focus than today's bootstrapping > > > activites. > > > > Anyway, I got in touch with Franck to work on the document with > > him > > > > but he moved to CMU and has no time for it anymore. Maybe the > > other > > > > co-authors are still interested in this subject - but I haven't > > > > received a reply yet. > > > > I > > > > am still looking for some co-authors.... > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > > > > > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > -- > > > julien.bournelle at int-evry.fr > > > > -- > julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 08 06:49:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGxA8-0007JB-Ah; Wed, 08 Mar 2006 06:49:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGxA7-0007IG-QD for dime@ietf.org; Wed, 08 Mar 2006 06:49:03 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGxA6-00066h-4S for dime@ietf.org; Wed, 08 Mar 2006 06:49:03 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8DB1A68D; Wed, 8 Mar 2006 12:49:01 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 12:49:01 +0100 Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 12:49:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: [Dime] feature tag AVP Date: Wed, 8 Mar 2006 12:48:41 +0100 Message-ID: <7457D12699374F40BD026D2B1EFFBEC60138BEAF@eesmdmw020.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] feature tag AVP Thread-Index: AcY+r6Lzo965uRVVSJeJfL6HJ0FsqwALGOygAPHcd9A= From: "German Blanco \(E2/EEM\)" To: "Glen Zorn \(gwz\)" X-OriginalArrivalTime: 08 Mar 2006 11:49:01.0224 (UTC) FILETIME=[4AB86280:01C642A6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org If I understand it correctly, these feature tags are used to identify the content and format of the communication. They are intended for=20 the negotiation of the characteristics of the communication. If it were possible to have restrictions on the kind of communication that=20 a certain user is authorized to establish, then it would make sense to me to perform the authorization to establish this communication=20 with Diameter and to transport these feature tags in a Diameter AVP. Should I continue? Or is there already a wrong assumption in that? /German. > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 > Sent: viernes, 03 de marzo de 2006 17:04 > To: German Blanco (E2/EEM) > Cc: dime@ietf.org > Subject: RE: [Dime] feature tag AVP >=20 > German Blanco (E2/EEM) =20 > supposedly scribbled: >=20 > > Hello, > >=20 > > as far as I know, there is no AVP defined to transport the feature=20 > > tags specified in RFC 2533, or? > >=20 > > Wouldn't it make sense to have an AVP code reserved for that? >=20 > Why? >=20 > ~gwz >=20 > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 08 08:23:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGyd5-0004UD-RF; Wed, 08 Mar 2006 08:23:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGyd4-0004U4-Ne for dime@ietf.org; Wed, 08 Mar 2006 08:23:02 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGyd4-0000lF-G4 for dime@ietf.org; Wed, 08 Mar 2006 08:23:02 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k28DMuJJ013772; Wed, 8 Mar 2006 08:22:57 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <440EDAB2.1030407@tari.toshiba.com> Date: Wed, 08 Mar 2006 08:22:58 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "German Blanco (E2/EEM)" Subject: Re: [Dime] feature tag AVP References: <7457D12699374F40BD026D2B1EFFBEC60138BEAF@eesmdmw020.eemea.ericsson.se> In-Reply-To: <7457D12699374F40BD026D2B1EFFBEC60138BEAF@eesmdmw020.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dime@ietf.org, "Glen Zorn \(gwz\)" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi German, >If I understand it correctly, these feature tags are used to identify >the content and format of the communication. They are intended for >the negotiation of the characteristics of the communication. If it >were possible to have restrictions on the kind of communication that >a certain user is authorized to establish, then it would make sense >to me to perform the authorization to establish this communication >with Diameter and to transport these feature tags in a Diameter AVP. > >Should I continue? Or is there already a wrong assumption in that? > > Are you proposing that a feature tag avp definition should be present the base proto ? I think it has no use in there. victor >/German. > > > >>-----Original Message----- >>From: Glen Zorn (gwz) [mailto:gwz@cisco.com] >>Sent: viernes, 03 de marzo de 2006 17:04 >>To: German Blanco (E2/EEM) >>Cc: dime@ietf.org >>Subject: RE: [Dime] feature tag AVP >> >>German Blanco (E2/EEM) >>supposedly scribbled: >> >> >> >>>Hello, >>> >>>as far as I know, there is no AVP defined to transport the feature >>>tags specified in RFC 2533, or? >>> >>>Wouldn't it make sense to have an AVP code reserved for that? >>> >>> >>Why? >> >>~gwz >> >>Why is it that most of the world's problems can't be solved by simply >> listening to John Coltrane? -- Henry Gabriel >> >> >> > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 08 08:25:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGyfr-0005pt-Ux; Wed, 08 Mar 2006 08:25:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGyfp-0005pP-OI for dime@ietf.org; Wed, 08 Mar 2006 08:25:54 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGyfp-0000oD-Cr for dime@ietf.org; Wed, 08 Mar 2006 08:25:53 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k28DPo0h013788; Wed, 8 Mar 2006 08:25:51 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <440EDB60.1040702@tari.toshiba.com> Date: Wed, 08 Mar 2006 08:25:52 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt References: <1AA39B75171A7144A73216AED1D7478D01869E4F@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869E4F@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi John, >I'd like to start a WG last call on the Diameter API. The API is in use >in the OpenDiameter project, >and changes they have made for their implementation have been reflected >in the API. > > We've significantly branched away from this API since our model evolved differently but I'll review the document regards, victor >WGLC ends on Friday March 24th. > >Please review the document, send issues in the form of> > > Description of issue > Submitter name: Your_Name_Here > Submitter email address: Your_Email_Address_Here > Date first submitted: Insert_Date_Here > Reference: URL to e-mail describing problem, if available > Document: Document Requiring change [Diameter API] > Comment type: ['T'echnical | 'E'ditorial] > Priority: ['S' Must fix | '1' Should fix | '2' May fix ] > Section: Insert_Section_Number_Here > Rationale/Explanation of issue: > Length description of problem > > Requested change: > Proposed changes to the document. Please be specific about what text >you want > to change, add or delete. Issues cannot be considered until specific >text is provided. > >If you have read the document & think it is good to go, please send a >mail to that >respect. > >thanks, >John > > > >>>From: ext dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>>Sent: 07 March, 2006 09:50 >>>To: i-d-announce@ietf.org >>>Cc: dime@ietf.org >>>Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-00.txt >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>>This draft is a work item of the Diameter Maintanence and Extensions >>>Working Group of the IETF. >>> >>> Title : The Diameter API >>> Author(s) : P. Calhoun, et al. >>> Filename : draft-ietf-dime-diameter-api-00.txt >>> Pages : 45 >>> Date : 2006-3-6 >>> >>> The Diameter authentication, authorization, and accounting (AAA) >>>protocol provides support for peering AAA transactions across the >>>Internet. This document describes a standardized API for the >>>Diameter protocol. The API is defined for the C language. The >>>intent of the API is to foster source code portability across >>>multiple programming platforms. >>> >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.tx >>>t >>> >>>To remove yourself from the I-D Announcement list, send a message to >>>i-d-announce-request@ietf.org with the word unsubscribe in the body of >>> >>> > > > >>>the message. >>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>to change your subscription settings. >>> >>> >>>Internet-Drafts are also available by anonymous FTP. Login with the >>>username "anonymous" and a password of your e-mail address. After >>>logging in, type "cd internet-drafts" and then >>> "get draft-ietf-dime-diameter-api-00.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html or >>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE /internet-drafts/draft-ietf-dime-diameter-api-00.txt". >>> >>>NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail >>> >>> >readers > > >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. >>> >>> >>> > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 08 08:35:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGyov-0004UU-2C; Wed, 08 Mar 2006 08:35:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGyou-0004UP-Kf for dime@ietf.org; Wed, 08 Mar 2006 08:35:16 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGyot-00015q-VR for dime@ietf.org; Wed, 08 Mar 2006 08:35:16 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 92FC3E59; Wed, 8 Mar 2006 14:35:14 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 14:35:14 +0100 Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 14:35:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] feature tag AVP Date: Wed, 8 Mar 2006 14:35:11 +0100 Message-ID: <7457D12699374F40BD026D2B1EFFBEC60138BEB0@eesmdmw020.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] feature tag AVP Thread-Index: AcZCs29cgcRX+kciSyOo+lJSY7B17wAAOUkA From: "German Blanco \(E2/EEM\)" To: "Victor Fajardo" X-OriginalArrivalTime: 08 Mar 2006 13:35:14.0376 (UTC) FILETIME=[216A3480:01C642B5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: dime@ietf.org, "Glen Zorn \(gwz\)" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, No, that was not my idea. But I think the AVP could be useful for many cases. Since there is no Diameter application that needs this in the list of mandatory AVPs, how about a short document describing how it could be used and with the allocation of the code? If that makes sense, I could start writing a draft. It may take some time for me, but I don't think there is a hurry. /German. > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 > Sent: mi=E9rcoles, 08 de marzo de 2006 14:23 > To: German Blanco (E2/EEM) > Cc: Glen Zorn (gwz); dime@ietf.org > Subject: Re: [Dime] feature tag AVP >=20 > Hi German, >=20 > >If I understand it correctly, these feature tags are used to=20 > identify=20 > >the content and format of the communication. They are=20 > intended for the=20 > >negotiation of the characteristics of the communication. If it were=20 > >possible to have restrictions on the kind of communication that a=20 > >certain user is authorized to establish, then it would make=20 > sense to me=20 > >to perform the authorization to establish this communication with=20 > >Diameter and to transport these feature tags in a Diameter AVP. > > > >Should I continue? Or is there already a wrong assumption in that? > > =20 > > > Are you proposing that a feature tag avp definition should be=20 > present the base proto ? I think it has no use in there. >=20 > victor >=20 > >/German. > > > > =20 > > > >>-----Original Message----- > >>From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > >>Sent: viernes, 03 de marzo de 2006 17:04 > >>To: German Blanco (E2/EEM) > >>Cc: dime@ietf.org > >>Subject: RE: [Dime] feature tag AVP > >> > >>German Blanco (E2/EEM) > >>supposedly scribbled: > >> > >> =20 > >> > >>>Hello, > >>> > >>>as far as I know, there is no AVP defined to transport the feature=20 > >>>tags specified in RFC 2533, or? > >>> > >>>Wouldn't it make sense to have an AVP code reserved for that? > >>> =20 > >>> > >>Why? > >> > >>~gwz > >> > >>Why is it that most of the world's problems can't be solved=20 > by simply > >> listening to John Coltrane? -- Henry Gabriel > >> > >> =20 > >> > > > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > =20 > > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 08 13:24:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3Kz-0007HK-7L; Wed, 08 Mar 2006 13:24:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3Kx-0007HF-Ne for dime@ietf.org; Wed, 08 Mar 2006 13:24:39 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3Kw-0003DQ-F9 for dime@ietf.org; Wed, 08 Mar 2006 13:24:39 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id C81CB79485 for ; Wed, 8 Mar 2006 13:24:38 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k28IOYJe010417 for ; Wed, 8 Mar 2006 13:24:37 -0500 (EST) From: "Tolga Asveren" To: Date: Wed, 8 Mar 2006 13:04:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Dime] Classification of Erorr Codes in RFC3588 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org What is the rationale behind classifying DIAMETER_COMMAND_UNSUPPORTED and DIAMETER_INVALID_AVP_BITS as protocol errors? They seem to be end-to-end issues fitting more to Permanent Failures category. Considering Protocol Errors SHOULD be treated on a per-hop bases, are we expecting a relay agent to be aware of every supported command by each peer/application to be able to generate DIAMETER_COMMAND_UNSUPPORTED? Or, are we expecting all intermediares to look to all AVPs in a message and check the validity of AVP header bits for DIAMETER_INVALID_AVP_BITS case? Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 08 20:59:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHARW-0003FI-0x; Wed, 08 Mar 2006 20:59:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHARV-0003CY-Ah for dime@ietf.org; Wed, 08 Mar 2006 20:59:53 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHARU-0006H5-0r for dime@ietf.org; Wed, 08 Mar 2006 20:59:53 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Mar 2006 17:59:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="23249409:sNHT24637740" Received: from [10.86.241.11] (che-vpn-cluster-1-266.cisco.com [10.86.241.11]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k291xoWc006954; Wed, 8 Mar 2006 20:59:51 -0500 (EST) Message-ID: <440F8C16.5010306@cisco.com> Date: Wed, 08 Mar 2006 20:59:50 -0500 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt References: <1AA39B75171A7144A73216AED1D7478D01869E4F@esebe100.NOE.Nokia.com> <440EDB60.1040702@tari.toshiba.com> In-Reply-To: <440EDB60.1040702@tari.toshiba.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org So we're standardizing an API that hasn't been implemented? That seems a bit dubious. Anders Victor Fajardo wrote: > Hi John, > >> I'd like to start a WG last call on the Diameter API. The API is in use >> in the OpenDiameter project, and changes they have made for their >> implementation have been reflected >> in the API. >> > We've significantly branched away from this API since our model evolved > differently but I'll review the document > regards, > victor > >> WGLC ends on Friday March 24th. >> Please review the document, send issues in the form of> >> >> Description of issue >> Submitter name: Your_Name_Here >> Submitter email address: Your_Email_Address_Here >> Date first submitted: Insert_Date_Here >> Reference: URL to e-mail describing problem, if available >> Document: Document Requiring change [Diameter API] >> Comment type: ['T'echnical | 'E'ditorial] >> Priority: ['S' Must fix | '1' Should fix | '2' May fix ] >> Section: Insert_Section_Number_Here >> Rationale/Explanation of issue: >> Length description of problem >> >> Requested change: >> Proposed changes to the document. Please be specific about what text >> you want to change, add or delete. Issues cannot be considered until >> specific >> text is provided. >> >> If you have read the document & think it is good to go, please send a >> mail to that >> respect. >> >> thanks, >> John >> >> >> >>>> From: ext dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>>> Sent: 07 March, 2006 09:50 >>>> To: i-d-announce@ietf.org >>>> Cc: dime@ietf.org >>>> Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-00.txt >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Diameter Maintanence and Extensions >>>> Working Group of the IETF. >>>> >>>> Title : The Diameter API >>>> Author(s) : P. Calhoun, et al. >>>> Filename : draft-ietf-dime-diameter-api-00.txt >>>> Pages : 45 >>>> Date : 2006-3-6 >>>> >>>> The Diameter authentication, authorization, and accounting (AAA) >>>> protocol provides support for peering AAA transactions across the >>>> Internet. This document describes a standardized API for the >>>> Diameter protocol. The API is defined for the C language. The >>>> intent of the API is to foster source code portability across >>>> multiple programming platforms. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.tx >>>> t >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the body of >>>> >> >> >> >> >>>> the message. >>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>> to change your subscription settings. >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username "anonymous" and a password of your e-mail address. After >>>> logging in, type "cd internet-drafts" and then >>>> "get draft-ietf-dime-diameter-api-00.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE /internet-drafts/draft-ietf-dime-diameter-api-00.txt". >>>> >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant mail >>>> >> >> readers >> >> >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> >> >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 08 23:28:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHCll-0005fG-Ij; Wed, 08 Mar 2006 23:28:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHClk-0005f8-QN for dime@ietf.org; Wed, 08 Mar 2006 23:28:56 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHClk-0002HB-8V for dime@ietf.org; Wed, 08 Mar 2006 23:28:56 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k294Sn0p019616; Thu, 9 Mar 2006 06:28:51 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 06:28:40 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 06:28:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Thu, 9 Mar 2006 06:28:35 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869E9B@esebe100.NOE.Nokia.com> In-Reply-To: <440F8C16.5010306@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Thread-Index: AcZDHS5azuQKV7m6Twanp/OekOpevgAFKlFA From: To: , X-OriginalArrivalTime: 09 Mar 2006 04:28:39.0335 (UTC) FILETIME=[F075D370:01C64331] X-Spam-Score: 0.2 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Well, review the document and let us know if the API defined is good or bad, or any recommendations and we'll take it from there. john=20 >-----Original Message----- >From: ext Anders Kristensen [mailto:andersk@cisco.com]=20 >Sent: 09 March, 2006 04:00 >To: Victor Fajardo >Cc: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org >Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > >So we're standardizing an API that hasn't been implemented?=20 >That seems a bit dubious. > >Anders > >Victor Fajardo wrote: > >> Hi John, >>=20 >>> I'd like to start a WG last call on the Diameter API. The=20 >API is in=20 >>> use in the OpenDiameter project, and changes they have made=20 >for their=20 >>> implementation have been reflected >>> in the API. =20 >>> >> We've significantly branched away from this API since our model=20 >> evolved differently but I'll review the document regards, victor >>=20 >>> WGLC ends on Friday March 24th. >>> Please review the document, send issues in the form of> >>> >>> Description of issue >>> Submitter name: Your_Name_Here >>> Submitter email address: Your_Email_Address_Here Date first=20 >>> submitted: Insert_Date_Here >>> Reference: URL to e-mail describing problem, if available >>> Document: Document Requiring change [Diameter API] Comment type:=20 >>> ['T'echnical | 'E'ditorial] >>> Priority: ['S' Must fix | '1' Should fix | '2' May fix ] >>> Section: Insert_Section_Number_Here >>> Rationale/Explanation of issue: >>> Length description of problem >>> >>> Requested change: >>> Proposed changes to the document. Please be specific about=20 >what text=20 >>> you want to change, add or delete. Issues cannot be=20 >considered until=20 >>> specific text is provided. >>> >>> If you have read the document & think it is good to go,=20 >please send a=20 >>> mail to that respect. >>> >>> thanks, >>> John >>> >>> =20 >>> >>>>> From: ext dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>>>> Sent: 07 March, 2006 09:50 >>>>> To: i-d-announce@ietf.org >>>>> Cc: dime@ietf.org >>>>> Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-00.txt >>>>> >>>>> A New Internet-Draft is available from the on-line=20 >Internet-Drafts=20 >>>>> directories. >>>>> This draft is a work item of the Diameter Maintanence and=20 >>>>> Extensions Working Group of the IETF. >>>>> >>>>> Title : The Diameter API >>>>> Author(s) : P. Calhoun, et al. >>>>> Filename : draft-ietf-dime-diameter-api-00.txt >>>>> Pages : 45 >>>>> Date : 2006-3-6 >>>>> =20 >>>>> The Diameter authentication, authorization, and accounting (AAA)=20 >>>>> protocol provides support for peering AAA transactions across the=20 >>>>> Internet. This document describes a standardized API for the=20 >>>>> Diameter protocol. The API is defined for the C language. The=20 >>>>> intent of the API is to foster source code portability across=20 >>>>> multiple programming platforms. >>>>> >>>>> >>>>> A URL for this Internet-Draft is: >>>>>=20 >http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.tx >>>>> t >>>>> >>>>> To remove yourself from the I-D Announcement list, send a=20 >message to=20 >>>>> i-d-announce-request@ietf.org with the word unsubscribe=20 >in the body of >>>>> =20 >>> >>> >>> =20 >>> >>>>> the message. >>>>> You can also visit=20 >https://www1.ietf.org/mailman/listinfo/I-D-announce >>>>> to change your subscription settings. >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP.=20 >Login with the=20 >>>>> username "anonymous" and a password of your e-mail address. After=20 >>>>> logging in, type "cd internet-drafts" and then >>>>> "get draft-ietf-dime-diameter-api-00.txt". >>>>> >>>>> A list of Internet-Drafts directories can be found in=20 >>>>> http://www.ietf.org/shadow.html or=20 >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> >>>>> Internet-Drafts can also be obtained by e-mail. >>>>> >>>>> Send a message to: >>>>> mailserv@ietf.org. >>>>> In the body type: >>>>> "FILE /internet-drafts/draft-ietf-dime-diameter-api-00.txt". >>>>> =20 >>>>> NOTE: The mail server at ietf.org can return the document in >>>>> MIME-encoded form by using the "mpack" utility. To use this >>>>> feature, insert the command "ENCODING mime" before the "FILE" >>>>> command. To decode the response(s), you will need=20 >"munpack" or >>>>> a MIME-compliant mail reader. Different MIME-compliant mail >>>>> =20 >>> >>> readers >>> =20 >>> >>>>> exhibit different behavior, especially when dealing with >>>>> "multipart" MIME messages (i.e. documents which have=20 >been split >>>>> up into multiple messages), so check your local=20 >documentation on >>>>> how to manipulate these messages. >>>>> =20 >>>>> =20 >>>>> Below is the data which will enable a MIME compliant mail reader=20 >>>>> implementation to automatically retrieve the ASCII version of the=20 >>>>> Internet-Draft. >>>>> >>>>> =20 >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >>> =20 >>> >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >>=20 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 02:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHFZF-0001o7-Ga; Thu, 09 Mar 2006 02:28:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHFZE-0001o2-Ql for dime@ietf.org; Thu, 09 Mar 2006 02:28:12 -0500 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHFZB-00070M-8Z for dime@ietf.org; Thu, 09 Mar 2006 02:28:12 -0500 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id EF5AC1CCC0D4 for ; Wed, 8 Mar 2006 23:28:07 -0800 (PST) Received: from [192.168.2.166] (unknown [12.178.55.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id EFB591CCC0D0 for ; Wed, 8 Mar 2006 23:28:05 -0800 (PST) Message-ID: <440FD8AE.9090901@frascone.com> Date: Thu, 09 Mar 2006 01:26:38 -0600 From: David Frascone User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt References: <1AA39B75171A7144A73216AED1D7478D01869E9B@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869E9B@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org The API was used in sun's reference implementation. Opendiameter moved away from it, since they're in c++. I think there is one other implementation. The author has promised to review and post ocmments to this list. john.loughney@nokia.com wrote: > Well, review the document and let us know if the API defined is good > or bad, or any recommendations and we'll take it from there. > > john > > >>-----Original Message----- >>From: ext Anders Kristensen [mailto:andersk@cisco.com] >>Sent: 09 March, 2006 04:00 >>To: Victor Fajardo >>Cc: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org >>Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt >> >>So we're standardizing an API that hasn't been implemented? >>That seems a bit dubious. >> >>Anders >> >>Victor Fajardo wrote: >> >> >>>Hi John, >>> >>> >>>>I'd like to start a WG last call on the Diameter API. The >> >>API is in >> >>>>use in the OpenDiameter project, and changes they have made >> >>for their >> >>>>implementation have been reflected >>>>in the API. >>>> >>> >>>We've significantly branched away from this API since our model >>>evolved differently but I'll review the document regards, victor >>> >>> >>>>WGLC ends on Friday March 24th. >>>>Please review the document, send issues in the form of> >>>> >>>>Description of issue >>>>Submitter name: Your_Name_Here >>>>Submitter email address: Your_Email_Address_Here Date first >>>>submitted: Insert_Date_Here >>>>Reference: URL to e-mail describing problem, if available >>>>Document: Document Requiring change [Diameter API] Comment type: >>>>['T'echnical | 'E'ditorial] >>>>Priority: ['S' Must fix | '1' Should fix | '2' May fix ] >>>>Section: Insert_Section_Number_Here >>>>Rationale/Explanation of issue: >>>>Length description of problem >>>> >>>>Requested change: >>>>Proposed changes to the document. Please be specific about >> >>what text >> >>>>you want to change, add or delete. Issues cannot be >> >>considered until >> >>>>specific text is provided. >>>> >>>>If you have read the document & think it is good to go, >> >>please send a >> >>>>mail to that respect. >>>> >>>>thanks, >>>>John >>>> >>>> >>>> >>>> >>>>>>From: ext dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>>>>>Sent: 07 March, 2006 09:50 >>>>>>To: i-d-announce@ietf.org >>>>>>Cc: dime@ietf.org >>>>>>Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-00.txt >>>>>> >>>>>>A New Internet-Draft is available from the on-line >> >>Internet-Drafts >> >>>>>>directories. >>>>>>This draft is a work item of the Diameter Maintanence and >>>>>>Extensions Working Group of the IETF. >>>>>> >>>>>> Title : The Diameter API >>>>>> Author(s) : P. Calhoun, et al. >>>>>> Filename : draft-ietf-dime-diameter-api-00.txt >>>>>> Pages : 45 >>>>>> Date : 2006-3-6 >>>>>> >>>>>>The Diameter authentication, authorization, and accounting (AAA) >>>>>>protocol provides support for peering AAA transactions across the >>>>>>Internet. This document describes a standardized API for the >>>>>>Diameter protocol. The API is defined for the C language. The >>>>>>intent of the API is to foster source code portability across >>>>>>multiple programming platforms. >>>>>> >>>>>> >>>>>>A URL for this Internet-Draft is: >>>>>> >> >>http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.tx >> >>>>>>t >>>>>> >>>>>>To remove yourself from the I-D Announcement list, send a >> >>message to >> >>>>>>i-d-announce-request@ietf.org with the word unsubscribe >> >>in the body of >> >>>>>> >>>> >>>> >>>> >>>> >>>> >>>>>>the message. >>>>>>You can also visit >> >>https://www1.ietf.org/mailman/listinfo/I-D-announce >> >>>>>>to change your subscription settings. >>>>>> >>>>>> >>>>>>Internet-Drafts are also available by anonymous FTP. >> >>Login with the >> >>>>>>username "anonymous" and a password of your e-mail address. After >>>>>>logging in, type "cd internet-drafts" and then >>>>>> "get draft-ietf-dime-diameter-api-00.txt". >>>>>> >>>>>>A list of Internet-Drafts directories can be found in >>>>>>http://www.ietf.org/shadow.html or >>>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> >>>>>>Internet-Drafts can also be obtained by e-mail. >>>>>> >>>>>>Send a message to: >>>>>> mailserv@ietf.org. >>>>>>In the body type: >>>>>> "FILE /internet-drafts/draft-ietf-dime-diameter-api-00.txt". >>>>>> >>>>>>NOTE: The mail server at ietf.org can return the document in >>>>>> MIME-encoded form by using the "mpack" utility. To use this >>>>>> feature, insert the command "ENCODING mime" before the "FILE" >>>>>> command. To decode the response(s), you will need >> >>"munpack" or >> >>>>>> a MIME-compliant mail reader. Different MIME-compliant mail >>>>>> >>>> >>>>readers >>>> >>>> >>>> >>>>>> exhibit different behavior, especially when dealing with >>>>>> "multipart" MIME messages (i.e. documents which have >> >>been split >> >>>>>> up into multiple messages), so check your local >> >>documentation on >> >>>>>> how to manipulate these messages. >>>>>> >>>>>> >>>>>>Below is the data which will enable a MIME compliant mail reader >>>>>>implementation to automatically retrieve the ASCII version of the >>>>>>Internet-Draft. >>>>>> >>>>>> >>>> >>>> >>>>_______________________________________________ >>>>DiME mailing list >>>>DiME@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>>> >>>> >>>> >>> >>> >>>_______________________________________________ >>>DiME mailing list >>>DiME@ietf.org >>>https://www1.ietf.org/mailman/listinfo/dime >>> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 05:40:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHIZN-00073g-Jp; Thu, 09 Mar 2006 05:40:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHIZM-00073b-7R for dime@ietf.org; Thu, 09 Mar 2006 05:40:32 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHIZK-00054I-JQ for dime@ietf.org; Thu, 09 Mar 2006 05:40:32 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id B8E5180F3; Thu, 9 Mar 2006 11:40:27 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FHIVx-00025e-JK; Thu, 09 Mar 2006 11:37:01 +0100 Date: Thu, 9 Mar 2006 11:37:01 +0100 From: Julien Bournelle To: Junghoon Jee Subject: Re: [Dime] Re: Diameter MIPv6 Application Message-ID: <20060309103701.GA8026@ipv6-3.int-evry.fr> References: <20060308090037.GE6356@ipv6-3.int-evry.fr> <047b01c64296$124dbd10$420cfe81@etri04q4sqc7zc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <047b01c64296$124dbd10$420cfe81@etri04q4sqc7zc> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: dime@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org hi junghoon, On Wed, Mar 08, 2006 at 06:52:54PM +0900, Junghoon Jee wrote: > > > > I am talking about the rationale for a new Diameter application > > > regarding MIP6 bootstrapping. > > > > > > Let me more clarify. > > > Through the integrated scenario, AAA server assigns a home > > agent for a > > > mobile node. > > > This home agent can be located at local or home of mobile node. > > > The decision where to locate a home agent needs to be transacted > > > between AAAv and AAAh based on the MN's profile and request. > > > > In the Integrated scenario, this decision is made by the MN > > in his DHCP request. This is not based on its profile. At > > least that's what I understood. > > Yes, this is a point that needs to be amended from the existing DHCP > based integrated scenario. > Why AAAh needs to allocate a home agent in case AAAv can/needs to > allocate a home agent in the local domain? > If AAAh always allocates a home agent then when that kind of > information will be cleaned up in case that home agent is not used? > IMO, AAAh needs to know that AAAv can allocate a home agent for the > mobile node and then needs to decide where to locate home agent > for a mobile node. > In case the mobile node requests the allocation of home agent in the > visited domain and the kind of feature is possible depending > on the profile of the mobile node then, AAAv finally allocates the > local home agent following the confirmation from AAAh. I agree that it's a good feature to have. > > The AAAH always sends a HA address in the (visited NAS). > > > > > The seed information can be conveyed as a flag type as shown > below. > > > > > > 2 Home-Address-Allocatable-Only-in-Home-Domain flag: This > flag > > > is > > > set to '1' when the MN requests the home address to be > > assigned in > > > its home network. > > > > > > 4 Home-Agent-in-Visited-Domain flag: This flag is set to '1' > > > when > > > the AAAh allows the allocation of HA in the visited network. > > > > > > 8 Visited-Home-Agent-Available flag: This flag is set to '1' > > > when > > > the AAAv notifies to the AAAh that it can support the > > assignment of > > > a > > > HA in the visited network. > > > > > > > > > I don't think that it is a right choice to transfer this kind of > > > information through the existing Diameter messages which are not > > > relevant to MIP6. > > > > but how do the NAS know which Diameter application to use > > with the AAA server ? > > According to the DHCPv6 options, I think. > DHCP server parses these DHCP options which are configured by a mobile > node, > then it can notify NAS of the fact that a mobile node is requesting > the assignment of home agent. > Thus, NAS can invoke a new Diameter MIP6 bootstrapping application. > If the DHCP relay which can be collocated with NAS can parse these > options, then it can be more simpler. hmmm, so you want: - DHCPV6 request by the MN before any network access authentication protocol - the NAS learns that MN wants DHCPv6 (how ?) - if the MN require also an address in the network, how is it managed ? - network access authentication protocol (with no modifications) + Diameter MIP6 specific Application (this application would still need to be compatible with the network access authentication protocol e.g. EAP) - the AAAH or AAAV allocate the HA and sends it to the NAS and then to DHCP. - DHCPV6 Request (from the MN) or directly DHCPV6 Response containing the HA ? Julien > > > Thanks, > -Junghoon > > If you want a specific Diameter > > Application (I mean new messages), this imply to modify all > > Client - NAS protocol. > > > > Am I missing something ? > > > > > > Thanks, > > > > Julien > > > > > > > > Thanks, > > > Junghoon > > > > > > > Wether we need new Diameter Messages (I don't think > > that's the good > > > > option based on my recent mail posted here) or just add AVPs to > > > > > NASREQ/EAP may need more discussions. > > > > > > > In both case, requesting an Application-ID seems > > necessary for the > > > > 'M' > > > > bit support. > > > > > > > > My 2 cents, > > > > > > > > Julien Bournelle > > > > > > > > > > > > > > "Diameter Mobile IPv6 Bootstrapping Application using PANA", > > > > > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > > > > > > > > > Thanks, > > > > > -Junghoon > > > > > > > > > > > > > > > -------------------------------------------- > > > > > Hi all, > > > > > > > > > > we have compiled two Diameter documents that provide > > the backend > > > > > solution for the split & the integrated scenario. > > > > > > > > > > Please find the document here: > > > > > > > > > > Mobile IPv6 Bootstrapping using Diameter in the Split Scenario > > > > > > > > > > Abstract > > > > > > > > > > In Mobile IPv6 deployment a need for an interaction > > between the > > > > > > > > Home > > > > > Agent, the AAA infrastructure of the Mobile Service > > > > Provider (MSP) > > > > > and the Mobility Service Authorizer (MSA) has been > > identified. > > > > > This > > > > > document provides a description of the functionality > > > > that allows to > > > > > meet the goals outlined in the MIPv6 AAA Goals document. > > > > > > > > > > > > > > > > > > > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-split-00.t > > > > > xt > > > > > > > > > > > > > > > Diameter MIPv6 Application for the Integrated Scenario > > > > > > > > > > Abstract > > > > > > > > > > A Mobile IPv6 node requires a home agent address, a home > > > > address, > > > > > and > > > > > IPsec security association with its home agent before it > > > > can start > > > > > utilizing Mobile IPv6 service. RFC 3775 requires that > > > > some or all > > > > > of > > > > > these parameters are statically configured. Ongoing > > work aims > > > to > > > > > make this information dynamically available to the > > > > mobile node. An > > > > > important aspect of the Mobile IPv6 bootstrapping solution > is > > > to > > > > > support interworking with existing authentication, > > > authorization > > > > > and > > > > > accounting infrastructure. This document defines a > Diameter > > > > > application to facilitate Mobile IPv6 bootstrapping for the > > > > > integrated scenario. > > > > > > > > > > > > > > > > > > > > http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-mip6-integrated > > > > > -0 > > > > > 0.txt > > > > > > > > > > Before I started working on the latter document I contact > Franck > > > Le > > > > > since he was the author/editor of the previous Diameter MIPv6 > > > > > Application document. It turned out that the previously > written > > > > > document had a different focus than today's bootstrapping > > > > activites. > > > > > Anyway, I got in touch with Franck to work on the document > with > > > him > > > > > but he moved to CMU and has no time for it anymore. Maybe the > > > other > > > > > co-authors are still interested in this subject - but I > haven't > > > > > received a reply yet. > > > > > I > > > > > am still looking for some co-authors.... > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > > > > > > > > > > > http://jhjee.vsix.net/draft-jee-mip6-bootstrap-pana-01.txt > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > -- > > > > julien.bournelle at int-evry.fr > > > > > > > -- > > julien.bournelle at int-evry.fr > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 05:47:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHIgB-0006hb-A0; Thu, 09 Mar 2006 05:47:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHIg9-0006ea-Le for dime@ietf.org; Thu, 09 Mar 2006 05:47:33 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHIg9-000591-8i for dime@ietf.org; Thu, 09 Mar 2006 05:47:33 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k29AlPGf030194; Thu, 9 Mar 2006 12:47:26 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 12:47:02 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 12:47:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: Diameter MIPv6 Application Date: Thu, 9 Mar 2006 12:47:02 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869ED6@esebe100.NOE.Nokia.com> In-Reply-To: <20060307095639.GA5134@ipv6-3.int-evry.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: Diameter MIPv6 Application Thread-Index: AcZBzlbkXSttXrUkSCiZwO3vTjE3OQBmGnBg From: To: , X-OriginalArrivalTime: 09 Mar 2006 10:47:02.0342 (UTC) FILETIME=[CC81C660:01C64366] X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dime@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org =20 >> Maybe, I hope you would get hints from the following I-D, for=20 >> rationale of new Diameter Application regarding MIPv6 bootstrapping=20 >> based on the feature of local or home agent assignments which is not=20 >> directly related with the previous existing Diameter=20 >> Application, like=20 >> Diameter EAP. > > I don't think we have to reinvent a bootstrapping mechanism=20 >for mip6 since it was the goal of the DT. From my point of=20 >view, the document should be aligned on =20 >draft-ietf-mip6-boostrapping-integrated-dhc-00.txt. I agree with this assement, at a highlevel. John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 05:48:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHIhX-0001Ro-Ni; Thu, 09 Mar 2006 05:48:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHIhW-0001Rj-BO for dime@ietf.org; Thu, 09 Mar 2006 05:48:58 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHIhV-0005Ap-T0 for dime@ietf.org; Thu, 09 Mar 2006 05:48:58 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k29AmoQ3032406; Thu, 9 Mar 2006 12:48:55 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 12:48:51 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 12:48:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Dime] Invalid AVP within a Grouped AVP Date: Thu, 9 Mar 2006 12:48:50 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869ED7@esebe100.NOE.Nokia.com> In-Reply-To: <7457D12699374F40BD026D2B1EFFBEC60138BE89@eesmdmw020.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Invalid AVP within a Grouped AVP Thread-Index: AcY9NVXN046Ue6iBSJiWX94goj0yMgACWCSQAYoQ5EA= From: To: , X-OriginalArrivalTime: 09 Mar 2006 10:48:50.0918 (UTC) FILETIME=[0D392860:01C64367] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, Feel free to draft text. I think we should collect text and produce a = Diameter-bis document after the Dallas meeting. John=20 >-----Original Message----- >From: ext German Blanco (E2/EEM) [mailto:german.blanco@ericsson.com]=20 >Sent: 01 March, 2006 16:47 >To: Victor Fajardo >Cc: Anders Kristensen; Loughney John (Nokia-NRC/Helsinki);=20 >dime@ietf.org >Subject: RE: [Dime] Invalid AVP within a Grouped AVP > > >Hi Victor, > >Your proposal of extending the definition of Failed-AVP sounds=20 >good to me too. >I am not that sure that it is needed to provide information=20 >about all the errors in the request, since just one is enough=20 >to reject the message and (hopefully :-) only a very small=20 >percentage of the requests will contain more than one error. > >Regards, > >German. > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: mi=E9rcoles, 01 de marzo de 2006 14:38 >> To: German Blanco (E2/EEM) >> Cc: Anders Kristensen; john.loughney@nokia.com; dime@ietf.org >> Subject: Re: [Dime] Invalid AVP within a Grouped AVP >>=20 >> Hi, >>=20 >> >Wouldn't it be better to give to the peer that makes the >> error as much information as possible? >> > >> >One way to do that would be to send the Failed-AVP with the >> erroneous AVP, but inside the Grouped AVP. That is, sending a=20 >> Diameter Answer with only the Grouped AVP that failed, containing a=20 >> Failed AVP with the AVP that caused the error. >> > >> >I believe that for an application, it would be very >> interesting to know which is the part of the information that was=20 >> erroneous or missing in the request. And since the Grouped AVP will=20 >> contain more than one information element, it would be hard to guess=20 >> which is the one that caused the problem if the answer only=20 >refers to=20 >> a problem in the Grouped AVP. >> > >> >You could argue that it may not be possible to include the >> Failed-AVP inside the Grouped AVP, since the ABNF of the Grouped AVP=20 >> could avoid this possibility. But since this will be a revised=20 >> version of Diameter, then it could also be recommended or=20 >mandatory to=20 >> allow the Failed AVP inside Grouped AVPs. Would that be feasible? >> > =20 >> > >> I think it maybe better to just extend the definition of=20 >Failed-AVP to=20 >> somehow provide inheritance information of each offending avp=20 >> belonging to a group (which maybe deep). This is probably=20 >easier for a=20 >> parser since the failed-avp occurs only at the root level as=20 >it is now=20 >> (instead of deep inside a group). It also minimizes ABNF changes.=20 >> Additionally, I also think reason code(s) (i.e, avp not allowed,=20 >> duplicate avp >> etc) for the each offending AVP should be provided instead of just=20 >> relying on the value of result-code avp since each offending AVPs=20 >> could have different reasons for failing. >>=20 >> Regards, >> victor >>=20 >> >Thank you for bringing up this issue, I also think that it >> would be a good idea to include it in the next RFC. >> > >> >German. >>=20 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 08:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLEh-0006UJ-0a; Thu, 09 Mar 2006 08:31:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLEf-0006UA-Mb for dime@ietf.org; Thu, 09 Mar 2006 08:31:21 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHLEf-0001kP-7m for dime@ietf.org; Thu, 09 Mar 2006 08:31:21 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 7093CDE36A for ; Thu, 9 Mar 2006 08:31:20 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k29DVFbK029623 for ; Thu, 9 Mar 2006 08:31:17 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Thu, 9 Mar 2006 08:11:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <440FD8AE.9090901@frascone.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org What makes it better/more usefull than the practically endless other API possibilities so that IETF endorses it? Actually why does IETF endorses an API at all? Thanks, Tolga > -----Original Message----- > From: David Frascone [mailto:dave@frascone.com] > Sent: Thursday, March 09, 2006 2:27 AM > To: dime@ietf.org > Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > > > > The API was used in sun's reference implementation. Opendiameter moved > away from it, since they're in c++. > > I think there is one other implementation. The author has promised to > review and post ocmments to this list. > > john.loughney@nokia.com wrote: > > Well, review the document and let us know if the API defined is good > > or bad, or any recommendations and we'll take it from there. > > > > john > > > > > >>-----Original Message----- > >>From: ext Anders Kristensen [mailto:andersk@cisco.com] > >>Sent: 09 March, 2006 04:00 > >>To: Victor Fajardo > >>Cc: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org > >>Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > >> > >>So we're standardizing an API that hasn't been implemented? > >>That seems a bit dubious. > >> > >>Anders > >> > >>Victor Fajardo wrote: > >> > >> > >>>Hi John, > >>> > >>> > >>>>I'd like to start a WG last call on the Diameter API. The > >> > >>API is in > >> > >>>>use in the OpenDiameter project, and changes they have made > >> > >>for their > >> > >>>>implementation have been reflected > >>>>in the API. > >>>> > >>> > >>>We've significantly branched away from this API since our model > >>>evolved differently but I'll review the document regards, victor > >>> > >>> > >>>>WGLC ends on Friday March 24th. > >>>>Please review the document, send issues in the form of> > >>>> > >>>>Description of issue > >>>>Submitter name: Your_Name_Here > >>>>Submitter email address: Your_Email_Address_Here Date first > >>>>submitted: Insert_Date_Here > >>>>Reference: URL to e-mail describing problem, if available > >>>>Document: Document Requiring change [Diameter API] Comment type: > >>>>['T'echnical | 'E'ditorial] > >>>>Priority: ['S' Must fix | '1' Should fix | '2' May fix ] > >>>>Section: Insert_Section_Number_Here > >>>>Rationale/Explanation of issue: > >>>>Length description of problem > >>>> > >>>>Requested change: > >>>>Proposed changes to the document. Please be specific about > >> > >>what text > >> > >>>>you want to change, add or delete. Issues cannot be > >> > >>considered until > >> > >>>>specific text is provided. > >>>> > >>>>If you have read the document & think it is good to go, > >> > >>please send a > >> > >>>>mail to that respect. > >>>> > >>>>thanks, > >>>>John > >>>> > >>>> > >>>> > >>>> > >>>>>>From: ext dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] > >>>>>>Sent: 07 March, 2006 09:50 > >>>>>>To: i-d-announce@ietf.org > >>>>>>Cc: dime@ietf.org > >>>>>>Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-00.txt > >>>>>> > >>>>>>A New Internet-Draft is available from the on-line > >> > >>Internet-Drafts > >> > >>>>>>directories. > >>>>>>This draft is a work item of the Diameter Maintanence and > >>>>>>Extensions Working Group of the IETF. > >>>>>> > >>>>>> Title : The Diameter API > >>>>>> Author(s) : P. Calhoun, et al. > >>>>>> Filename : draft-ietf-dime-diameter-api-00.txt > >>>>>> Pages : 45 > >>>>>> Date : 2006-3-6 > >>>>>> > >>>>>>The Diameter authentication, authorization, and accounting (AAA) > >>>>>>protocol provides support for peering AAA transactions across the > >>>>>>Internet. This document describes a standardized API for the > >>>>>>Diameter protocol. The API is defined for the C language. The > >>>>>>intent of the API is to foster source code portability across > >>>>>>multiple programming platforms. > >>>>>> > >>>>>> > >>>>>>A URL for this Internet-Draft is: > >>>>>> > >> > >>http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.tx > >> > >>>>>>t > >>>>>> > >>>>>>To remove yourself from the I-D Announcement list, send a > >> > >>message to > >> > >>>>>>i-d-announce-request@ietf.org with the word unsubscribe > >> > >>in the body of > >> > >>>>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>>the message. > >>>>>>You can also visit > >> > >>https://www1.ietf.org/mailman/listinfo/I-D-announce > >> > >>>>>>to change your subscription settings. > >>>>>> > >>>>>> > >>>>>>Internet-Drafts are also available by anonymous FTP. > >> > >>Login with the > >> > >>>>>>username "anonymous" and a password of your e-mail address. After > >>>>>>logging in, type "cd internet-drafts" and then > >>>>>> "get draft-ietf-dime-diameter-api-00.txt". > >>>>>> > >>>>>>A list of Internet-Drafts directories can be found in > >>>>>>http://www.ietf.org/shadow.html or > >>>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>>> > >>>>>> > >>>>>>Internet-Drafts can also be obtained by e-mail. > >>>>>> > >>>>>>Send a message to: > >>>>>> mailserv@ietf.org. > >>>>>>In the body type: > >>>>>> "FILE /internet-drafts/draft-ietf-dime-diameter-api-00.txt". > >>>>>> > >>>>>>NOTE: The mail server at ietf.org can return the document in > >>>>>> MIME-encoded form by using the "mpack" utility. To use this > >>>>>> feature, insert the command "ENCODING mime" before the "FILE" > >>>>>> command. To decode the response(s), you will need > >> > >>"munpack" or > >> > >>>>>> a MIME-compliant mail reader. Different MIME-compliant mail > >>>>>> > >>>> > >>>>readers > >>>> > >>>> > >>>> > >>>>>> exhibit different behavior, especially when dealing with > >>>>>> "multipart" MIME messages (i.e. documents which have > >> > >>been split > >> > >>>>>> up into multiple messages), so check your local > >> > >>documentation on > >> > >>>>>> how to manipulate these messages. > >>>>>> > >>>>>> > >>>>>>Below is the data which will enable a MIME compliant mail reader > >>>>>>implementation to automatically retrieve the ASCII version of the > >>>>>>Internet-Draft. > >>>>>> > >>>>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>DiME mailing list > >>>>DiME@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/dime > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>>_______________________________________________ > >>>DiME mailing list > >>>DiME@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/dime > >>> > >> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 09:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHMSw-00089V-LW; Thu, 09 Mar 2006 09:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHMSv-00089Q-CN for dime@ietf.org; Thu, 09 Mar 2006 09:50:09 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHMSs-0004QQ-Sd for dime@ietf.org; Thu, 09 Mar 2006 09:50:09 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id C8FF19D036 for ; Thu, 9 Mar 2006 09:50:06 -0500 (EST) Received: from salut.ulticom.com (salut.ulticom.com [208.255.120.61]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id k29Eo3X7010781 for ; Thu, 9 Mar 2006 09:50:03 -0500 (EST) Received: from [172.25.33.127] (pc-lehmann-p.ulticom.com [172.25.33.127]) (authenticated bits=0) by salut.ulticom.com (8.13.4/8.13.4) with ESMTP id k29Eo21O003249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Mar 2006 09:50:03 -0500 (EST) Message-ID: <44104095.3080906@ulticom.com> Date: Thu, 09 Mar 2006 09:49:57 -0500 From: David Lehmann User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] DiME Interop & NDAs References: <1AA39B75171A7144A73216AED1D7478D01869DA2@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869DA2@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org As with all IETF interops, these events are 100% engineering events and not marketing/sales events. It is run by geeks and for geeks. :-) As John noted, the primary purpose is to solidify the protocol. However, each participating company benefits by being able to evaluate its own implementation. No report will be issued which reports any bugs/weaknesses in any company's implementation. Sorry, no ribbons/medals will be given. :-) The 2006 Olympics are over! -- David Lehmann Ulticom, Inc. http://www.ulticom.com john.loughney@nokia.com wrote: > Some folks had questions about possible NDAs for the upcoming interop. > I need to gauge what you all want. > > One option is no NDA. > > There would be no identification of who has what bug is to be done. This > is essentially what SIPIT does. The purpose of the interop is to > a. Check the correctness of implementations > b. Gauge the quality of the RFC being tested. > > The second one in my mind is more important and to expose the flaws in > document is necessary to disclose bugs/confusions/errors after the > event, without explicitly identifying the implementation affected. When > a anomaly shows up in one implementation it is a bug, if it shows up in > multiple implementations, frequently it is a documentation issue but > sometimes it is because an implementor copies the behavior of another > implementation. > > We encourage people to show up with pre-release code. If some external > people demand to know which implementation failed what and claim it is > their RIGHT to know, we tell them to get lost. > > Choice two would be: > > Use the NDA that is also used by the Connectathon > (). Please find it at > . > > A problem with NDAs is that you need them in order to get industrial > partners participating, but every participant wants a different NDA (at > least their legal departments). > > The Connectathon NDA has the advantage that it already has been signed > by almost every big network equipment manufacturer. Usually, this > signature required a check by the company's legal department. > > I'd prefer option one, but would that prevent anyone from actually > attending? > > John > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 10:42:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNHH-0000ud-HK; Thu, 09 Mar 2006 10:42:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNHH-0000to-72 for dime@ietf.org; Thu, 09 Mar 2006 10:42:11 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNHF-0005vP-Tz for dime@ietf.org; Thu, 09 Mar 2006 10:42:11 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 00CCB4E375 for ; Thu, 9 Mar 2006 10:42:09 -0500 (EST) Received: from salut.ulticom.com (salut.ulticom.com [208.255.120.61]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id k29Fg8qk018528 for ; Thu, 9 Mar 2006 10:42:08 -0500 (EST) Received: from [172.25.33.127] (pc-lehmann-p.ulticom.com [172.25.33.127]) (authenticated bits=0) by salut.ulticom.com (8.13.4/8.13.4) with ESMTP id k29ERO9g003188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Mar 2006 09:27:24 -0500 (EST) Message-ID: <44103B46.1000007@ulticom.com> Date: Thu, 09 Mar 2006 09:27:18 -0500 From: David Lehmann User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt References: <1AA39B75171A7144A73216AED1D7478D01869E9B@esebe100.NOE.Nokia.com> <440FD8AE.9090901@frascone.com> In-Reply-To: <440FD8AE.9090901@frascone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org David Frascone wrote: > > The API was used in sun's reference implementation. Opendiameter > moved away from it, since they're in c++. I question whether this is Sun's API. If someone from Sun can confirm or deny, please do. > > I think there is one other implementation. The author has promised to > review and post ocmments to this list. Please name it. As it stands right now, there is no known implementation which uses this API. As Anders stated, this is a bit dubious. Back in October 2005, I tried to raise a discussion on the AAA group about the API, but the authors were unresponsive. That being the case, we could not follow it because of its shortcomings and a general lack of maturity. In addition, there seemed to be no effort to make it mature. So now, a new draft suddenly appears and we immediately go to last call? IMHO, there should be much more discussion and there should be a couple of independent implementations. Without real implementations, there will be no meaningful discussions and the API will have serious shortcomings. A simple review of the draft will not cut it. IMHO, we are a least a year away from a last call. -- David Lehmann Ulticom, Inc. http://www.ulticom.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 10:47:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNMU-0008Ns-2N; Thu, 09 Mar 2006 10:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNMT-0008Nn-1Q for dime@ietf.org; Thu, 09 Mar 2006 10:47:33 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNMR-00062l-Ks for dime@ietf.org; Thu, 09 Mar 2006 10:47:33 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 0A0B68173; Thu, 9 Mar 2006 16:47:30 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FHNJ5-0002Db-Jx; Thu, 09 Mar 2006 16:44:03 +0100 Date: Thu, 9 Mar 2006 16:44:03 +0100 From: Julien Bournelle To: David Lehmann Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Message-ID: <20060309154403.GA8523@ipv6-3.int-evry.fr> References: <1AA39B75171A7144A73216AED1D7478D01869E9B@esebe100.NOE.Nokia.com> <440FD8AE.9090901@frascone.com> <44103B46.1000007@ulticom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44103B46.1000007@ulticom.com> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi David, On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: > David Frascone wrote: > > > >The API was used in sun's reference implementation. Opendiameter > >moved away from it, since they're in c++. > I question whether this is Sun's API. If someone from Sun can confirm > or deny, please do. > > > > >I think there is one other implementation. The author has promised to > >review and post ocmments to this list. > Please name it. I guess that's me but I'm not the author of the implementatiion. I'm using a Diameter Base Protocol which is based on this API on top of which I implement an application. I already posted some comments on it (Diameter API) both on AAA and DIME ML. I "promised" to compile all these comments. > As it stands right now, there is no known implementation which uses this > API. > As Anders stated, this is a bit dubious. > > Back in October 2005, I tried to raise a discussion on the AAA group > about the API, but > the authors were unresponsive. That being the case, we could not follow > it because of its > shortcomings and a general lack of maturity. In addition, there seemed > to be no effort to > make it mature. So now, a new draft suddenly appears and we immediately > go to last call? > IMHO, there should be much more discussion and there should be a couple > of independent > implementations. Without real implementations, there will be no > meaningful discussions > and the API will have serious shortcomings. A simple review of the > draft will not cut it. > IMHO, we are a least a year away from a last call. I agree that maybe this WG LC is a little bit premature. Julien Bournelle > > -- > > David Lehmann > Ulticom, Inc. > http://www.ulticom.com > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 10:50:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNPZ-0004uG-82; Thu, 09 Mar 2006 10:50:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNPY-0004pp-07 for dime@ietf.org; Thu, 09 Mar 2006 10:50:44 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNPX-00066q-H5 for dime@ietf.org; Thu, 09 Mar 2006 10:50:43 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k29FofOV020658; Thu, 9 Mar 2006 17:50:42 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 17:49:42 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 17:49:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Thu, 9 Mar 2006 17:49:41 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869EE4@esebe100.NOE.Nokia.com> In-Reply-To: <20060309154403.GA8523@ipv6-3.int-evry.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Thread-Index: AcZDkNpucvXxskG+RnCH4ngy88XYTwAAA0Gw From: To: , X-OriginalArrivalTime: 09 Mar 2006 15:49:42.0527 (UTC) FILETIME=[14D218F0:01C64391] X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Just as a note - if the document isn't ready, then make comments, the document will be revised and we can then see if the document needs another WGLC, etc. The focus should be getting the document finalized, if it takes more than one round, or additional revisions, then that's fine. John=20 >-----Original Message----- >From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 >Sent: 09 March, 2006 17:44 >To: David Lehmann >Cc: dime@ietf.org >Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > >Hi David, > >On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: >> David Frascone wrote: >> > >> >The API was used in sun's reference implementation. Opendiameter=20 >> >moved away from it, since they're in c++. >> I question whether this is Sun's API. If someone from Sun=20 >can confirm=20 >> or deny, please do. >>=20 >> > >> >I think there is one other implementation. The author has promised=20 >> >to review and post ocmments to this list. >> Please name it.=20 > > I guess that's me but I'm not the author of the implementatiion. > I'm using a Diameter Base > Protocol which is based on this API on top of which I=20 >implement an application. I already posted some comments on =20 >it (Diameter API) both on AAA and DIME ML.=20 > I "promised" to compile all these comments. > >> As it stands right now, there is no known implementation which uses=20 >> this API. >> As Anders stated, this is a bit dubious. >>=20 >> Back in October 2005, I tried to raise a discussion on the AAA group=20 >> about the API, but the authors were unresponsive. That being the=20 >> case, we could not follow it because of its shortcomings and=20 >a general=20 >> lack of maturity. In addition, there seemed to be no effort=20 >to make it=20 >> mature. So now, a new draft suddenly appears and we=20 >immediately go to=20 >> last call? >> IMHO, there should be much more discussion and there should be a=20 >> couple of independent implementations. Without real=20 >implementations,=20 >> there will be no meaningful discussions and the API will=20 >have serious=20 >> shortcomings. A simple review of the draft will not cut it. >> IMHO, we are a least a year away from a last call. > > I agree that maybe this WG LC is a little bit premature. > > Julien Bournelle > > >>=20 >> -- >>=20 >> David Lehmann >> Ulticom, Inc. >> http://www.ulticom.com >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > >-- >julien.bournelle at int-evry.fr > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 11:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNkv-00070t-8P; Thu, 09 Mar 2006 11:12:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNku-0006ui-3K for dime@ietf.org; Thu, 09 Mar 2006 11:12:48 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNks-0006wz-K0 for dime@ietf.org; Thu, 09 Mar 2006 11:12:48 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 45F59B583C for ; Thu, 9 Mar 2006 11:12:46 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k29GCh1h023360 for ; Thu, 9 Mar 2006 11:12:44 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Thu, 9 Mar 2006 10:52:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869EE4@esebe100.NOE.Nokia.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi John, What is the goal of this document? The draft says: "The intent of the API is to foster source code portability across multiple programming platforms." Is this really something done often by IETF? Protocols being procedures between two peers need to be standardized, but APIs are a local contract between a protocol layer and an application of that protocol. For that reason they won't cause interoperability problems and people won't be forced to comply with them. Although initially this seems like good news because there is no need to comply with them, this also is the reason, why they are not very useful -there are of course exceptions like the socket API-. BTW, any API also implies certain implementation decisions, aren't we intervening too much to implementation dependent details by defining an API as a WG-document? I think, any API document for Diameter is better to be a non-WG document. In this way, people which are interested can submit the "best" API according to them and we won't have one "officially endorsed by IETF" version of API. Thnaks, Tolga > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, March 09, 2006 10:50 AM > To: julien.bournelle@int-evry.fr; lehmann@ulticom.com > Cc: dime@ietf.org > Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > > > Just as a note - if the document isn't ready, then make comments, > the document will be revised and we can then see if the document > needs another WGLC, etc. > > The focus should be getting the document finalized, if it takes more > than one round, or additional revisions, then that's fine. > > John > > >-----Original Message----- > >From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > >Sent: 09 March, 2006 17:44 > >To: David Lehmann > >Cc: dime@ietf.org > >Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > > > >Hi David, > > > >On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: > >> David Frascone wrote: > >> > > >> >The API was used in sun's reference implementation. Opendiameter > >> >moved away from it, since they're in c++. > >> I question whether this is Sun's API. If someone from Sun > >can confirm > >> or deny, please do. > >> > >> > > >> >I think there is one other implementation. The author has promised > >> >to review and post ocmments to this list. > >> Please name it. > > > > I guess that's me but I'm not the author of the implementatiion. > > I'm using a Diameter Base > > Protocol which is based on this API on top of which I > >implement an application. I already posted some comments on > >it (Diameter API) both on AAA and DIME ML. > > I "promised" to compile all these comments. > > > >> As it stands right now, there is no known implementation which uses > >> this API. > >> As Anders stated, this is a bit dubious. > >> > >> Back in October 2005, I tried to raise a discussion on the AAA group > >> about the API, but the authors were unresponsive. That being the > >> case, we could not follow it because of its shortcomings and > >a general > >> lack of maturity. In addition, there seemed to be no effort > >to make it > >> mature. So now, a new draft suddenly appears and we > >immediately go to > >> last call? > >> IMHO, there should be much more discussion and there should be a > >> couple of independent implementations. Without real > >implementations, > >> there will be no meaningful discussions and the API will > >have serious > >> shortcomings. A simple review of the draft will not cut it. > >> IMHO, we are a least a year away from a last call. > > > > I agree that maybe this WG LC is a little bit premature. > > > > Julien Bournelle > > > > > >> > >> -- > >> > >> David Lehmann > >> Ulticom, Inc. > >> http://www.ulticom.com > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > > > >-- > >julien.bournelle at int-evry.fr > > > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 11:18:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNqh-0001QB-Ir; Thu, 09 Mar 2006 11:18:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNqg-0001Q6-FB for dime@ietf.org; Thu, 09 Mar 2006 11:18:46 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNqf-0007CU-UZ for dime@ietf.org; Thu, 09 Mar 2006 11:18:46 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 5D52D80FC; Thu, 9 Mar 2006 17:18:44 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FHNnJ-0002Eq-U3; Thu, 09 Mar 2006 17:15:17 +0100 Date: Thu, 9 Mar 2006 17:15:17 +0100 From: Julien Bournelle To: Tolga Asveren Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Message-ID: <20060309161517.GA8600@ipv6-3.int-evry.fr> References: <1AA39B75171A7144A73216AED1D7478D01869EE4@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, I don't know if it is something that should be done by IETF. What I know is that if I developp a Diameter Application using this Diameter API, I can then used any Diameter Base Protocol implementation complying with it. My 2 cents, Julien Bournelle On Thu, Mar 09, 2006 at 10:52:44AM -0500, Tolga Asveren wrote: > Hi John, > > What is the goal of this document? > > The draft says: > "The intent of the API is to foster source code portability across multiple > programming platforms." > > Is this really something done often by IETF? > > Protocols being procedures between two peers need to be standardized, but > APIs are a local contract between a protocol layer and an application of > that protocol. For that reason they won't cause interoperability problems > and people won't be forced to comply with them. Although initially this > seems like good news because there is no need to comply with them, this also > is the reason, why they are not very useful -there are of course exceptions > like the socket API-. BTW, any API also implies certain implementation > decisions, aren't we intervening too much to implementation dependent > details by defining an API as a WG-document? > > I think, any API document for Diameter is better to be a non-WG document. In > this way, people which are interested can submit the "best" API according to > them and we won't have one "officially endorsed by IETF" version of API. > > Thnaks, > Tolga > > > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Thursday, March 09, 2006 10:50 AM > > To: julien.bournelle@int-evry.fr; lehmann@ulticom.com > > Cc: dime@ietf.org > > Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > > > > > > Just as a note - if the document isn't ready, then make comments, > > the document will be revised and we can then see if the document > > needs another WGLC, etc. > > > > The focus should be getting the document finalized, if it takes more > > than one round, or additional revisions, then that's fine. > > > > John > > > > >-----Original Message----- > > >From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > >Sent: 09 March, 2006 17:44 > > >To: David Lehmann > > >Cc: dime@ietf.org > > >Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > > > > > >Hi David, > > > > > >On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: > > >> David Frascone wrote: > > >> > > > >> >The API was used in sun's reference implementation. Opendiameter > > >> >moved away from it, since they're in c++. > > >> I question whether this is Sun's API. If someone from Sun > > >can confirm > > >> or deny, please do. > > >> > > >> > > > >> >I think there is one other implementation. The author has promised > > >> >to review and post ocmments to this list. > > >> Please name it. > > > > > > I guess that's me but I'm not the author of the implementatiion. > > > I'm using a Diameter Base > > > Protocol which is based on this API on top of which I > > >implement an application. I already posted some comments on > > >it (Diameter API) both on AAA and DIME ML. > > > I "promised" to compile all these comments. > > > > > >> As it stands right now, there is no known implementation which uses > > >> this API. > > >> As Anders stated, this is a bit dubious. > > >> > > >> Back in October 2005, I tried to raise a discussion on the AAA group > > >> about the API, but the authors were unresponsive. That being the > > >> case, we could not follow it because of its shortcomings and > > >a general > > >> lack of maturity. In addition, there seemed to be no effort > > >to make it > > >> mature. So now, a new draft suddenly appears and we > > >immediately go to > > >> last call? > > >> IMHO, there should be much more discussion and there should be a > > >> couple of independent implementations. Without real > > >implementations, > > >> there will be no meaningful discussions and the API will > > >have serious > > >> shortcomings. A simple review of the draft will not cut it. > > >> IMHO, we are a least a year away from a last call. > > > > > > I agree that maybe this WG LC is a little bit premature. > > > > > > Julien Bournelle > > > > > > > > >> > > >> -- > > >> > > >> David Lehmann > > >> Ulticom, Inc. > > >> http://www.ulticom.com > > >> > > >> > > >> _______________________________________________ > > >> DiME mailing list > > >> DiME@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/dime > > > > > >-- > > >julien.bournelle at int-evry.fr > > > > > >_______________________________________________ > > >DiME mailing list > > >DiME@ietf.org > > >https://www1.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 11:37:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHO8i-00040d-Gk; Thu, 09 Mar 2006 11:37:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHO8h-00040Y-Tk for dime@ietf.org; Thu, 09 Mar 2006 11:37:23 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHO8g-0007r1-Dn for dime@ietf.org; Thu, 09 Mar 2006 11:37:23 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 367C2B6BE5 for ; Thu, 9 Mar 2006 11:37:22 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k29GbJDn027186 for ; Thu, 9 Mar 2006 11:37:21 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Thu, 9 Mar 2006 11:17:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <20060309161517.GA8600@ipv6-3.int-evry.fr> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, Yes of course, if the same API is used by two implementations, it is easy two switch between them. My point is, why this should be an official document of IETF? Just as an example, the current API draft relies on callbacks. This obviously is a design choice. I don't think it is a good idea to force everybody to use the same design choices. Thanks, Tolga > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > Sent: Thursday, March 09, 2006 11:15 AM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > > > Hi Tolga, > > I don't know if it is something that should be done by IETF. > > What I know is that if I developp a Diameter Application using this > Diameter API, I can then used any Diameter Base Protocol implementation > complying with it. > > My 2 cents, > > Julien Bournelle > > > On Thu, Mar 09, 2006 at 10:52:44AM -0500, Tolga Asveren wrote: > > Hi John, > > > > What is the goal of this document? > > > > The draft says: > > "The intent of the API is to foster source code portability > across multiple > > programming platforms." > > > > Is this really something done often by IETF? > > > > Protocols being procedures between two peers need to be > standardized, but > > APIs are a local contract between a protocol layer and an application of > > that protocol. For that reason they won't cause > interoperability problems > > and people won't be forced to comply with them. Although initially this > > seems like good news because there is no need to comply with > them, this also > > is the reason, why they are not very useful -there are of > course exceptions > > like the socket API-. BTW, any API also implies certain implementation > > decisions, aren't we intervening too much to implementation dependent > > details by defining an API as a WG-document? > > > > I think, any API document for Diameter is better to be a non-WG > document. In > > this way, people which are interested can submit the "best" API > according to > > them and we won't have one "officially endorsed by IETF" version of API. > > > > Thnaks, > > Tolga > > > > > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: Thursday, March 09, 2006 10:50 AM > > > To: julien.bournelle@int-evry.fr; lehmann@ulticom.com > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > > > > > > > > > Just as a note - if the document isn't ready, then make comments, > > > the document will be revised and we can then see if the document > > > needs another WGLC, etc. > > > > > > The focus should be getting the document finalized, if it takes more > > > than one round, or additional revisions, then that's fine. > > > > > > John > > > > > > >-----Original Message----- > > > >From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > >Sent: 09 March, 2006 17:44 > > > >To: David Lehmann > > > >Cc: dime@ietf.org > > > >Subject: Re: [Dime] WGLC on > ACTION:draft-ietf-dime-diameter-api-00.txt > > > > > > > >Hi David, > > > > > > > >On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: > > > >> David Frascone wrote: > > > >> > > > > >> >The API was used in sun's reference implementation. Opendiameter > > > >> >moved away from it, since they're in c++. > > > >> I question whether this is Sun's API. If someone from Sun > > > >can confirm > > > >> or deny, please do. > > > >> > > > >> > > > > >> >I think there is one other implementation. The author > has promised > > > >> >to review and post ocmments to this list. > > > >> Please name it. > > > > > > > > I guess that's me but I'm not the author of the implementatiion. > > > > I'm using a Diameter Base > > > > Protocol which is based on this API on top of which I > > > >implement an application. I already posted some comments on > > > >it (Diameter API) both on AAA and DIME ML. > > > > I "promised" to compile all these comments. > > > > > > > >> As it stands right now, there is no known implementation which uses > > > >> this API. > > > >> As Anders stated, this is a bit dubious. > > > >> > > > >> Back in October 2005, I tried to raise a discussion on the > AAA group > > > >> about the API, but the authors were unresponsive. That being the > > > >> case, we could not follow it because of its shortcomings and > > > >a general > > > >> lack of maturity. In addition, there seemed to be no effort > > > >to make it > > > >> mature. So now, a new draft suddenly appears and we > > > >immediately go to > > > >> last call? > > > >> IMHO, there should be much more discussion and there should be a > > > >> couple of independent implementations. Without real > > > >implementations, > > > >> there will be no meaningful discussions and the API will > > > >have serious > > > >> shortcomings. A simple review of the draft will not cut it. > > > >> IMHO, we are a least a year away from a last call. > > > > > > > > I agree that maybe this WG LC is a little bit premature. > > > > > > > > Julien Bournelle > > > > > > > > > > > >> > > > >> -- > > > >> > > > >> David Lehmann > > > >> Ulticom, Inc. > > > >> http://www.ulticom.com > > > >> > > > >> > > > >> _______________________________________________ > > > >> DiME mailing list > > > >> DiME@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/dime > > > > > > > >-- > > > >julien.bournelle at int-evry.fr > > > > > > > >_______________________________________________ > > > >DiME mailing list > > > >DiME@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > -- > julien.bournelle at int-evry.fr > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 09 12:19:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOns-0006m5-Vl; Thu, 09 Mar 2006 12:19:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOnr-0006i4-CY for dime@ietf.org; Thu, 09 Mar 2006 12:19:55 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHOno-0000fR-O7 for dime@ietf.org; Thu, 09 Mar 2006 12:19:55 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k29HI9kq021133; Thu, 9 Mar 2006 19:18:12 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 19:19:51 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 19:19:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Thu, 9 Mar 2006 19:19:50 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869EE7@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Thread-Index: AcZDl+ROdwmYsT9wSrioI5PxojdDBQABbm6Q From: To: , X-OriginalArrivalTime: 09 Mar 2006 17:19:50.0944 (UTC) FILETIME=[AC7D0A00:01C6439D] X-Spam-Score: 0.2 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org API document is informational, only. Like all API documents in the IETF. Noone is required to implement it. John=20 >-----Original Message----- >From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20 >Sent: 09 March, 2006 18:17 >To: dime@ietf.org >Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > >Hi Julien, > >Yes of course, if the same API is used by two implementations,=20 >it is easy two switch between them. My point is, why this=20 >should be an official document of IETF? > >Just as an example, the current API draft relies on callbacks.=20 >This obviously is a design choice. I don't think it is a good=20 >idea to force everybody to use the same design choices. > > Thanks, > Tolga > >> -----Original Message----- >> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] >> Sent: Thursday, March 09, 2006 11:15 AM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] WGLC on=20 >ACTION:draft-ietf-dime-diameter-api-00.txt >> >> >> Hi Tolga, >> >> I don't know if it is something that should be done by IETF. >> >> What I know is that if I developp a Diameter Application=20 >using this =20 >> Diameter API, I can then used any Diameter Base Protocol=20 >> implementation complying with it. >> >> My 2 cents, >> >> Julien Bournelle >> >> >> On Thu, Mar 09, 2006 at 10:52:44AM -0500, Tolga Asveren wrote: >> > Hi John, >> > >> > What is the goal of this document? >> > >> > The draft says: >> > "The intent of the API is to foster source code portability >> across multiple >> > programming platforms." >> > >> > Is this really something done often by IETF? >> > >> > Protocols being procedures between two peers need to be >> standardized, but >> > APIs are a local contract between a protocol layer and an=20 >> > application of that protocol. For that reason they won't cause >> interoperability problems >> > and people won't be forced to comply with them. Although initially=20 >> > this seems like good news because there is no need to comply with >> them, this also >> > is the reason, why they are not very useful -there are of >> course exceptions >> > like the socket API-. BTW, any API also implies certain=20 >> > implementation decisions, aren't we intervening too much to=20 >> > implementation dependent details by defining an API as a=20 >WG-document? >> > >> > I think, any API document for Diameter is better to be a non-WG >> document. In >> > this way, people which are interested can submit the "best" API >> according to >> > them and we won't have one "officially endorsed by IETF"=20 >version of API. >> > >> > Thnaks, >> > Tolga >> > >> > >> > >> > > -----Original Message----- >> > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> > > Sent: Thursday, March 09, 2006 10:50 AM >> > > To: julien.bournelle@int-evry.fr; lehmann@ulticom.com >> > > Cc: dime@ietf.org >> > > Subject: RE: [Dime] WGLC on=20 >> > > ACTION:draft-ietf-dime-diameter-api-00.txt >> > > >> > > >> > > Just as a note - if the document isn't ready, then make=20 >comments,=20 >> > > the document will be revised and we can then see if the document=20 >> > > needs another WGLC, etc. >> > > >> > > The focus should be getting the document finalized, if it takes=20 >> > > more than one round, or additional revisions, then that's fine. >> > > >> > > John >> > > >> > > >-----Original Message----- >> > > >From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] >> > > >Sent: 09 March, 2006 17:44 >> > > >To: David Lehmann >> > > >Cc: dime@ietf.org >> > > >Subject: Re: [Dime] WGLC on >> ACTION:draft-ietf-dime-diameter-api-00.txt >> > > > >> > > >Hi David, >> > > > >> > > >On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: >> > > >> David Frascone wrote: >> > > >> > >> > > >> >The API was used in sun's reference implementation. =20 >> > > >> >Opendiameter moved away from it, since they're in c++. >> > > >> I question whether this is Sun's API. If someone from Sun >> > > >can confirm >> > > >> or deny, please do. >> > > >> >> > > >> > >> > > >> >I think there is one other implementation. The author >> has promised >> > > >> >to review and post ocmments to this list. >> > > >> Please name it. >> > > > >> > > > I guess that's me but I'm not the author of the=20 >implementatiion. >> > > > I'm using a Diameter Base >> > > > Protocol which is based on this API on top of which I=20 >implement=20 >> > > >an application. I already posted some comments on it (Diameter=20 >> > > >API) both on AAA and DIME ML. >> > > > I "promised" to compile all these comments. >> > > > >> > > >> As it stands right now, there is no known=20 >implementation which=20 >> > > >> uses this API. >> > > >> As Anders stated, this is a bit dubious. >> > > >> >> > > >> Back in October 2005, I tried to raise a discussion on the >> AAA group >> > > >> about the API, but the authors were unresponsive. That being=20 >> > > >> the case, we could not follow it because of its shortcomings=20 >> > > >> and >> > > >a general >> > > >> lack of maturity. In addition, there seemed to be no effort >> > > >to make it >> > > >> mature. So now, a new draft suddenly appears and we >> > > >immediately go to >> > > >> last call? >> > > >> IMHO, there should be much more discussion and there=20 >should be=20 >> > > >> a couple of independent implementations. Without real >> > > >implementations, >> > > >> there will be no meaningful discussions and the API will >> > > >have serious >> > > >> shortcomings. A simple review of the draft will not cut it. >> > > >> IMHO, we are a least a year away from a last call. >> > > > >> > > > I agree that maybe this WG LC is a little bit premature. >> > > > >> > > > Julien Bournelle >> > > > >> > > > >> > > >> >> > > >> -- >> > > >> >> > > >> David Lehmann >> > > >> Ulticom, Inc. >> > > >> http://www.ulticom.com >> > > >> >> > > >> >> > > >> _______________________________________________ >> > > >> DiME mailing list >> > > >> DiME@ietf.org >> > > >> https://www1.ietf.org/mailman/listinfo/dime >> > > > >> > > >-- >> > > >julien.bournelle at int-evry.fr >> > > > >> > > >_______________________________________________ >> > > >DiME mailing list >> > > >DiME@ietf.org >> > > >https://www1.ietf.org/mailman/listinfo/dime >> > > > >> > > >> > > _______________________________________________ >> > > DiME mailing list >> > > DiME@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/dime >> > > >> > >> > >> > >> > _______________________________________________ >> > DiME mailing list >> > DiME@ietf.org >> > https://www1.ietf.org/mailman/listinfo/dime >> >> -- >> julien.bournelle at int-evry.fr >> > > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 10 02:58:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHcVw-0000Ru-1g; Fri, 10 Mar 2006 02:58:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHcU7-0006ms-PF for dime@ietf.org; Fri, 10 Mar 2006 02:56:27 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHcGy-0004RR-IA for dime@ietf.org; Fri, 10 Mar 2006 02:42:56 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2A7ffOs015078; Fri, 10 Mar 2006 09:41:46 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 09:42:47 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 09:42:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Fri, 10 Mar 2006 09:42:46 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869EF1@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Thread-Index: AcZDlFtmxR/rTnLIRsqKcaA5R+CnIQAgSuKQ From: To: , X-OriginalArrivalTime: 10 Mar 2006 07:42:47.0558 (UTC) FILETIME=[39C15A60:01C64416] X-Spam-Score: 0.2 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I don't think that meta-discussions are useful. Review the document, raise conserns - if there are things that are in the document are not good, then state that. If there isn't enough WG consensus to=20 approve the document, then the document doesn't get approved. The IETF has worked on APIs before, see: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-12.txt IPv6 Advanced IPv6 API http://www.ietf.org/rfc/rfc3542.txt=20 and a good search will find: https://datatracker.ietf.org/public/idindex.cgi?command=3Ddo_search_id&fi= l ename=3Dapi&id_tracker_state_id=3D-1&wg_id=3D0&other_group=3D&status_id=3D= 0&last_n ame=3D&first_name=3D John >-----Original Message----- >From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20 >Sent: 09 March, 2006 17:53 >To: dime@ietf.org >Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > >Hi John, > >What is the goal of this document? > >The draft says: >"The intent of the API is to foster source code portability=20 >across multiple programming platforms." > >Is this really something done often by IETF? > >Protocols being procedures between two peers need to be=20 >standardized, but APIs are a local contract between a protocol=20 >layer and an application of that protocol. For that reason=20 >they won't cause interoperability problems and people won't be=20 >forced to comply with them. Although initially this seems like=20 >good news because there is no need to comply with them, this=20 >also is the reason, why they are not very useful -there are of=20 >course exceptions like the socket API-. BTW, any API also=20 >implies certain implementation decisions, aren't we=20 >intervening too much to implementation dependent details by=20 >defining an API as a WG-document? > >I think, any API document for Diameter is better to be a=20 >non-WG document. In this way, people which are interested can=20 >submit the "best" API according to them and we won't have one=20 >"officially endorsed by IETF" version of API. > > Thnaks, > Tolga > > > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: Thursday, March 09, 2006 10:50 AM >> To: julien.bournelle@int-evry.fr; lehmann@ulticom.com >> Cc: dime@ietf.org >> Subject: RE: [Dime] WGLC on=20 >ACTION:draft-ietf-dime-diameter-api-00.txt >> >> >> Just as a note - if the document isn't ready, then make=20 >comments, the=20 >> document will be revised and we can then see if the document needs=20 >> another WGLC, etc. >> >> The focus should be getting the document finalized, if it takes more=20 >> than one round, or additional revisions, then that's fine. >> >> John >> >> >-----Original Message----- >> >From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] >> >Sent: 09 March, 2006 17:44 >> >To: David Lehmann >> >Cc: dime@ietf.org >> >Subject: Re: [Dime] WGLC on=20 >> >ACTION:draft-ietf-dime-diameter-api-00.txt >> > >> >Hi David, >> > >> >On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: >> >> David Frascone wrote: >> >> > >> >> >The API was used in sun's reference implementation. =20 >Opendiameter=20 >> >> >moved away from it, since they're in c++. >> >> I question whether this is Sun's API. If someone from Sun >> >can confirm >> >> or deny, please do. >> >> >> >> > >> >> >I think there is one other implementation. The author has=20 >> >> >promised to review and post ocmments to this list. >> >> Please name it. >> > >> > I guess that's me but I'm not the author of the implementatiion. >> > I'm using a Diameter Base >> > Protocol which is based on this API on top of which I=20 >implement an =20 >> >application. I already posted some comments on it (Diameter=20 >API) both=20 >> >on AAA and DIME ML. >> > I "promised" to compile all these comments. >> > >> >> As it stands right now, there is no known implementation=20 >which uses=20 >> >> this API. >> >> As Anders stated, this is a bit dubious. >> >> >> >> Back in October 2005, I tried to raise a discussion on the AAA=20 >> >> group about the API, but the authors were unresponsive. =20 >That being=20 >> >> the case, we could not follow it because of its shortcomings and >> >a general >> >> lack of maturity. In addition, there seemed to be no effort >> >to make it >> >> mature. So now, a new draft suddenly appears and we >> >immediately go to >> >> last call? >> >> IMHO, there should be much more discussion and there should be a=20 >> >> couple of independent implementations. Without real >> >implementations, >> >> there will be no meaningful discussions and the API will >> >have serious >> >> shortcomings. A simple review of the draft will not cut it. >> >> IMHO, we are a least a year away from a last call. >> > >> > I agree that maybe this WG LC is a little bit premature. >> > >> > Julien Bournelle >> > >> > >> >> >> >> -- >> >> >> >> David Lehmann >> >> Ulticom, Inc. >> >> http://www.ulticom.com >> >> >> >> >> >> _______________________________________________ >> >> DiME mailing list >> >> DiME@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/dime >> > >> >-- >> >julien.bournelle at int-evry.fr >> > >> >_______________________________________________ >> >DiME mailing list >> >DiME@ietf.org >> >https://www1.ietf.org/mailman/listinfo/dime >> > >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 10 11:32:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkX5-0001bj-6g; Fri, 10 Mar 2006 11:32:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkX3-0001be-S9 for dime@ietf.org; Fri, 10 Mar 2006 11:32:01 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHkX2-0004GR-7j for dime@ietf.org; Fri, 10 Mar 2006 11:32:01 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2006 08:31:59 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2AGVswN007155; Fri, 10 Mar 2006 08:31:57 -0800 (PST) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Mar 2006 08:31:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Fri, 10 Mar 2006 08:31:52 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B0A48B@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Thread-Index: AcZDlFtmxR/rTnLIRsqKcaA5R+CnIQAgSuKQABJWHEA= From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 10 Mar 2006 16:31:55.0625 (UTC) FILETIME=[2513ED90:01C64460] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org john.loughney@nokia.com supposedly = scribbled: > I don't think that meta-discussions are useful. =20 Actually, I think that they are extremely useful in establishing the = direction of the WG. > Review the document, > raise conserns - if there are things that are in the document are not > good, then state that. If there isn't enough WG consensus to approve > the document, then the document doesn't get approved. =20 No offense, but you seem to have missed a rather crucial step here: if = there isn't WG consensus to go to last call (which there doesn't appear = to be), there is no last call. =20 >=20 > The IETF has worked on APIs before, see: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-12.txt > IPv6 Advanced IPv6 API http://www.ietf.org/rfc/rfc3542.txt >=20 > and a good search will find: > = https://datatracker.ietf.org/public/idindex.cgi?command=3Ddo_search_id&fi= l > = ename=3Dapi&id_tracker_state_id=3D-1&wg_id=3D0&other_group=3D&status_id=3D= 0&last_n > ame=3D&first_name=3D Be that as it may, it doesn't mean that _this_ WG must (or even should) = work on APIs. I agree that this LC is premature, given the rather = checkered past of the document in question & the fact that the WG is not = even properly constituted as yet. >=20 > John >=20 >> -----Original Message----- >> From: ext Tolga Asveren [mailto:asveren@ulticom.com] >> Sent: 09 March, 2006 17:53 >> To: dime@ietf.org >> Subject: RE: [Dime] WGLC on >> ACTION:draft-ietf-dime-diameter-api-00.txt=20 >>=20 >> Hi John, >>=20 >> What is the goal of this document? >>=20 >> The draft says: >> "The intent of the API is to foster source code portability across >> multiple programming platforms." >>=20 >> Is this really something done often by IETF? >>=20 >> Protocols being procedures between two peers need to be standardized, >> but APIs are a local contract between a protocol layer and an >> application of that protocol. For that reason they won't cause >> interoperability problems and people won't be forced to comply with >> them. Although initially this seems like good news because there is >> no need to comply with them, this also is the reason, why they are >> not very useful -there are of course exceptions like the socket >> API-. BTW, any API also implies certain implementation decisions, >> aren't we intervening too much to implementation dependent details >> by defining an API as a WG-document?=20 >>=20 >> I think, any API document for Diameter is better to be a non-WG >> document. In this way, people which are interested can submit the >> "best" API according to them and we won't have one "officially >> endorsed by IETF" version of API.=20 >>=20 >> Thnaks, >> Tolga >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>> Sent: Thursday, March 09, 2006 10:50 AM >>> To: julien.bournelle@int-evry.fr; lehmann@ulticom.com >>> Cc: dime@ietf.org >>> Subject: RE: [Dime] WGLC on >> ACTION:draft-ietf-dime-diameter-api-00.txt >>>=20 >>>=20 >>> Just as a note - if the document isn't ready, then make comments, >>> the document will be revised and we can then see if the document >>> needs another WGLC, etc.=20 >>>=20 >>> The focus should be getting the document finalized, if it takes more >>> than one round, or additional revisions, then that's fine. >>>=20 >>> John >>>=20 >>>> -----Original Message----- >>>> From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] >>>> Sent: 09 March, 2006 17:44 To: David Lehmann >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] WGLC on >>>> ACTION:draft-ietf-dime-diameter-api-00.txt >>>>=20 >>>> Hi David, >>>>=20 >>>> On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: >>>>> David Frascone wrote: >>>>>>=20 >>>>>> The API was used in sun's reference implementation. Opendiameter >>>>>> moved away from it, since they're in c++. >>>>> I question whether this is Sun's API. If someone from Sun can >>>>> confirm or deny, please do.=20 >>>>>=20 >>>>>>=20 >>>>>> I think there is one other implementation. The author has >>>>>> promised to review and post ocmments to this list. Please name >>>>>> it.=20 >>>>=20 >>>> I guess that's me but I'm not the author of the implementatiion. >>>> I'm using a Diameter Base Protocol which is based on this API on >>>> top of which I implement an application. I already posted some >>>> comments on it (Diameter API) both on AAA and DIME ML. I >>>> "promised" to compile all these comments.=20 >>>>=20 >>>>> As it stands right now, there is no known implementation which >>>>> uses this API. As Anders stated, this is a bit dubious. >>>>>=20 >>>>> Back in October 2005, I tried to raise a discussion on the AAA >>>>> group about the API, but the authors were unresponsive. That being >>>>> the case, we could not follow it because of its shortcomings and >>>>> a general lack of maturity. In addition, there seemed to be no >>>>> effort to make it mature. So now, a new draft suddenly appears >>>>> and we immediately go to last call? IMHO, there should be much >>>>> more discussion and there should be a couple of independent >>>>> implementations. Without real implementations, there will be no >>>>> meaningful discussions and the API will have serious >>>>> shortcomings. A simple review of the draft will not cut it. >>>>> IMHO, we are a least a year away from a last call.=20 >>>>=20 >>>> I agree that maybe this WG LC is a little bit premature. >>>>=20 >>>> Julien Bournelle >>>>=20 >>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> David Lehmann >>>>> Ulticom, Inc. >>>>> http://www.ulticom.com >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>=20 >>>> -- >>>> julien.bournelle at int-evry.fr >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 10 11:38:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkdF-0001Go-Qd; Fri, 10 Mar 2006 11:38:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkdE-0001E0-I9 for dime@ietf.org; Fri, 10 Mar 2006 11:38:24 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHkdD-0004O0-DZ for dime@ietf.org; Fri, 10 Mar 2006 11:38:24 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id C883C0494A for ; Fri, 10 Mar 2006 11:38:22 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k2AGcJ5F009139 for ; Fri, 10 Mar 2006 11:38:21 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Fri, 10 Mar 2006 11:18:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869EF1@esebe100.NOE.Nokia.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, March 10, 2006 2:43 AM > To: asveren@ulticom.com; dime@ietf.org > Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > > > I don't think that meta-discussions are useful. Review the document, > raise conserns - if there are things that are in the document are > not good, then state that. If there isn't enough WG consensus to > approve the document, then the document doesn't get approved. [TOLGA]I just tried to present my personal opinion, but in any case it is a good idea to get things done with some result -where result could be a RFC or no document or etc...- > > The IETF has worked on APIs before, see: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-12.txt > IPv6 Advanced IPv6 API http://www.ietf.org/rfc/rfc3542.txt > > and a good search will find: > https://datatracker.ietf.org/public/idindex.cgi?command=do_search_id&fil > ename=api&id_tracker_state_id=-1&wg_id=0&other_group=&status_id=0&last_n > ame=&first_name= [TOLGA]The biggest reasons for the above APIs is that their predecessors were existing and well-accepted by the industry -SCTP socket API tries to mimic TCP socket API and similarly IPv6 API tries to mimic IPv4 API-. As counter example, there are many IETF defined protocols with no IETF defined APIs. > > John > > >-----Original Message----- > >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > >Sent: 09 March, 2006 17:53 > >To: dime@ietf.org > >Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > > > >Hi John, > > > >What is the goal of this document? > > > >The draft says: > >"The intent of the API is to foster source code portability > >across multiple programming platforms." > > > >Is this really something done often by IETF? > > > >Protocols being procedures between two peers need to be > >standardized, but APIs are a local contract between a protocol > >layer and an application of that protocol. For that reason > >they won't cause interoperability problems and people won't be > >forced to comply with them. Although initially this seems like > >good news because there is no need to comply with them, this > >also is the reason, why they are not very useful -there are of > >course exceptions like the socket API-. BTW, any API also > >implies certain implementation decisions, aren't we > >intervening too much to implementation dependent details by > >defining an API as a WG-document? > > > >I think, any API document for Diameter is better to be a > >non-WG document. In this way, people which are interested can > >submit the "best" API according to them and we won't have one > >"officially endorsed by IETF" version of API. > > > > Thnaks, > > Tolga > > > > > > > >> -----Original Message----- > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >> Sent: Thursday, March 09, 2006 10:50 AM > >> To: julien.bournelle@int-evry.fr; lehmann@ulticom.com > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] WGLC on > >ACTION:draft-ietf-dime-diameter-api-00.txt > >> > >> > >> Just as a note - if the document isn't ready, then make > >comments, the > >> document will be revised and we can then see if the document needs > >> another WGLC, etc. > >> > >> The focus should be getting the document finalized, if it takes more > >> than one round, or additional revisions, then that's fine. > >> > >> John > >> > >> >-----Original Message----- > >> >From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > >> >Sent: 09 March, 2006 17:44 > >> >To: David Lehmann > >> >Cc: dime@ietf.org > >> >Subject: Re: [Dime] WGLC on > >> >ACTION:draft-ietf-dime-diameter-api-00.txt > >> > > >> >Hi David, > >> > > >> >On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: > >> >> David Frascone wrote: > >> >> > > >> >> >The API was used in sun's reference implementation. > >Opendiameter > >> >> >moved away from it, since they're in c++. > >> >> I question whether this is Sun's API. If someone from Sun > >> >can confirm > >> >> or deny, please do. > >> >> > >> >> > > >> >> >I think there is one other implementation. The author has > >> >> >promised to review and post ocmments to this list. > >> >> Please name it. > >> > > >> > I guess that's me but I'm not the author of the implementatiion. > >> > I'm using a Diameter Base > >> > Protocol which is based on this API on top of which I > >implement an > >> >application. I already posted some comments on it (Diameter > >API) both > >> >on AAA and DIME ML. > >> > I "promised" to compile all these comments. > >> > > >> >> As it stands right now, there is no known implementation > >which uses > >> >> this API. > >> >> As Anders stated, this is a bit dubious. > >> >> > >> >> Back in October 2005, I tried to raise a discussion on the AAA > >> >> group about the API, but the authors were unresponsive. > >That being > >> >> the case, we could not follow it because of its shortcomings and > >> >a general > >> >> lack of maturity. In addition, there seemed to be no effort > >> >to make it > >> >> mature. So now, a new draft suddenly appears and we > >> >immediately go to > >> >> last call? > >> >> IMHO, there should be much more discussion and there should be a > >> >> couple of independent implementations. Without real > >> >implementations, > >> >> there will be no meaningful discussions and the API will > >> >have serious > >> >> shortcomings. A simple review of the draft will not cut it. > >> >> IMHO, we are a least a year away from a last call. > >> > > >> > I agree that maybe this WG LC is a little bit premature. > >> > > >> > Julien Bournelle > >> > > >> > > >> >> > >> >> -- > >> >> > >> >> David Lehmann > >> >> Ulticom, Inc. > >> >> http://www.ulticom.com > >> >> > >> >> > >> >> _______________________________________________ > >> >> DiME mailing list > >> >> DiME@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/dime > >> > > >> >-- > >> >julien.bournelle at int-evry.fr > >> > > >> >_______________________________________________ > >> >DiME mailing list > >> >DiME@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/dime > >> > > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > > > > > > > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 10 12:47:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHliM-00051d-Bc; Fri, 10 Mar 2006 12:47:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHliL-0004zT-F8 for dime@ietf.org; Fri, 10 Mar 2006 12:47:45 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHliK-0006cM-5R for dime@ietf.org; Fri, 10 Mar 2006 12:47:45 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 7F7E2A5857 for ; Fri, 10 Mar 2006 12:47:43 -0500 (EST) Received: from salut.ulticom.com (salut.ulticom.com [208.255.120.61]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id k2AHlgZu017418 for ; Fri, 10 Mar 2006 12:47:42 -0500 (EST) Received: from [172.25.33.127] (pc-lehmann-p.ulticom.com [172.25.33.127]) (authenticated bits=0) by salut.ulticom.com (8.13.4/8.13.4) with ESMTP id k2AHlfdF006461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Mar 2006 12:47:42 -0500 (EST) Message-ID: <4411BBB8.3010307@ulticom.com> Date: Fri, 10 Mar 2006 12:47:36 -0500 From: David Lehmann User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt References: <1AA39B75171A7144A73216AED1D7478D01869EF1@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869EF1@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org john.loughney@nokia.com wrote: > I don't think that meta-discussions are useful. Review the document, > raise conserns - if there are things that are in the document are > not good, then state that. If there isn't enough WG consensus to > approve the document, then the document doesn't get approved. > I have concerns about putting this very immature I-D in last call as if it went through extensive review/discussion and has real life, working implementations to back up its usefulness. > The IETF has worked on APIs before, see: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-12.txt > IPv6 Advanced IPv6 API http://www.ietf.org/rfc/rfc3542.txt > Notice that the SCTP socket API I-D still has not been made an RFC even though this I-D has been discussed for years and has real life working implementations. Both Solaris and Linux follow the SCTP API I-D and real applications are being developed on these platforms using this API. The API is getting extensive exercise to draw out its weaknesses. So by the time the I-D goes to RFC, it will be solid a API, cumulating years of discussion and real world experience. I believe the same can be said for the IPv6 API RFC. IMHO, the Diameter API I-D is nowhere near the maturity of SCTP's API and the Diameter API has virtually no following. So why is the Diameter API I-D being held to such low standards? The I-D is at least a year (realistically 2-3 years) away from qualifying for WGLC. IMHO, of course. -- David Lehmann Ulticom, Inc. http://www.ulticom.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 11 01:18:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHxRI-0000Tb-0u; Sat, 11 Mar 2006 01:18:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHxRG-0000P3-Rd for dime@ietf.org; Sat, 11 Mar 2006 01:18:54 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHxRA-0008Mc-3n for dime@ietf.org; Sat, 11 Mar 2006 01:18:51 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2B6Gvuv022522; Sat, 11 Mar 2006 08:16:59 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Mar 2006 08:18:24 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Mar 2006 08:18:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Sat, 11 Mar 2006 08:18:22 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869F12@esebe100.NOE.Nokia.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262501B0A48B@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Thread-Index: AcZDlFtmxR/rTnLIRsqKcaA5R+CnIQAgSuKQABJWHEAAHP8ZYA== From: To: X-OriginalArrivalTime: 11 Mar 2006 06:18:23.0217 (UTC) FILETIME=[9995FE10:01C644D3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Glenn, I think you are confused about this list - the Internet Debating Society is down the=20 hall. =20 No, seriously, the status is the following: The Diameter API draft was a WG draft from the AAA working group, and it was suggested as a charter item of DiME. There was plenty of time to comment on the charter, if people thought the charter was good or bad, if items should be added or removed. I asked the authors of the document if they had resolved the open issues on the draft, which they said yes. In order to ensure the WG is happy with the document, I have started a WGLC. Based upon technical feedback from the WG, we can see what the next steps are. We could endlessly cycle on debating non-technical issues, and get no closer to completing this work. I would like for people to read the draft and comment on if it is finished, if it needs fixes or a rethink. thanks, John >-----Original Message----- >From: ext Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 >Sent: 10 March, 2006 18:32 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: asveren@ulticom.com; dime@ietf.org >Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > >john.loughney@nokia.com =20 >supposedly scribbled: > >> I don't think that meta-discussions are useful. =20 > >Actually, I think that they are extremely useful in=20 >establishing the direction of the WG. > >> Review the document, >> raise conserns - if there are things that are in the=20 >document are not=20 >> good, then state that. If there isn't enough WG consensus to approve=20 >> the document, then the document doesn't get approved. > >No offense, but you seem to have missed a rather crucial step=20 >here: if there isn't WG consensus to go to last call (which=20 >there doesn't appear to be), there is no last call. >=20 >>=20 >> The IETF has worked on APIs before, see: >>=20 >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-12.txt >> IPv6 Advanced IPv6 API http://www.ietf.org/rfc/rfc3542.txt >>=20 >> and a good search will find: >>=20 >https://datatracker.ietf.org/public/idindex.cgi?command=3Ddo_search_id&f= >> il=20 >>=20 >ename=3Dapi&id_tracker_state_id=3D-1&wg_id=3D0&other_group=3D&status_id=3D= 0&last >> _n >> ame=3D&first_name=3D > >Be that as it may, it doesn't mean that _this_ WG must (or=20 >even should) work on APIs. I agree that this LC is premature,=20 >given the rather checkered past of the document in question &=20 >the fact that the WG is not even properly constituted as yet. > >>=20 >> John >>=20 >>> -----Original Message----- >>> From: ext Tolga Asveren [mailto:asveren@ulticom.com] >>> Sent: 09 March, 2006 17:53 >>> To: dime@ietf.org >>> Subject: RE: [Dime] WGLC on >>> ACTION:draft-ietf-dime-diameter-api-00.txt >>>=20 >>> Hi John, >>>=20 >>> What is the goal of this document? >>>=20 >>> The draft says: >>> "The intent of the API is to foster source code portability across=20 >>> multiple programming platforms." >>>=20 >>> Is this really something done often by IETF? >>>=20 >>> Protocols being procedures between two peers need to be=20 >standardized,=20 >>> but APIs are a local contract between a protocol layer and an=20 >>> application of that protocol. For that reason they won't cause=20 >>> interoperability problems and people won't be forced to comply with=20 >>> them. Although initially this seems like good news because there is=20 >>> no need to comply with them, this also is the reason, why they are=20 >>> not very useful -there are of course exceptions like the=20 >socket API-.=20 >>> BTW, any API also implies certain implementation decisions,=20 >aren't we=20 >>> intervening too much to implementation dependent details by=20 >defining=20 >>> an API as a WG-document? >>>=20 >>> I think, any API document for Diameter is better to be a non-WG=20 >>> document. In this way, people which are interested can submit the=20 >>> "best" API according to them and we won't have one "officially=20 >>> endorsed by IETF" version of API. >>>=20 >>> Thnaks, >>> Tolga >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>>> Sent: Thursday, March 09, 2006 10:50 AM >>>> To: julien.bournelle@int-evry.fr; lehmann@ulticom.com >>>> Cc: dime@ietf.org >>>> Subject: RE: [Dime] WGLC on >>> ACTION:draft-ietf-dime-diameter-api-00.txt >>>>=20 >>>>=20 >>>> Just as a note - if the document isn't ready, then make comments,=20 >>>> the document will be revised and we can then see if the document=20 >>>> needs another WGLC, etc. >>>>=20 >>>> The focus should be getting the document finalized, if it=20 >takes more=20 >>>> than one round, or additional revisions, then that's fine. >>>>=20 >>>> John >>>>=20 >>>>> -----Original Message----- >>>>> From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] >>>>> Sent: 09 March, 2006 17:44 To: David Lehmann >>>>> Cc: dime@ietf.org >>>>> Subject: Re: [Dime] WGLC on >>>>> ACTION:draft-ietf-dime-diameter-api-00.txt >>>>>=20 >>>>> Hi David, >>>>>=20 >>>>> On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: >>>>>> David Frascone wrote: >>>>>>>=20 >>>>>>> The API was used in sun's reference implementation.=20 >Opendiameter=20 >>>>>>> moved away from it, since they're in c++. >>>>>> I question whether this is Sun's API. If someone from Sun can=20 >>>>>> confirm or deny, please do. >>>>>>=20 >>>>>>>=20 >>>>>>> I think there is one other implementation. The author has=20 >>>>>>> promised to review and post ocmments to this list. Please name=20 >>>>>>> it. >>>>>=20 >>>>> I guess that's me but I'm not the author of the implementatiion. >>>>> I'm using a Diameter Base Protocol which is based on this API on=20 >>>>> top of which I implement an application. I already posted some=20 >>>>> comments on it (Diameter API) both on AAA and DIME ML. I=20 >"promised"=20 >>>>> to compile all these comments. >>>>>=20 >>>>>> As it stands right now, there is no known implementation which=20 >>>>>> uses this API. As Anders stated, this is a bit dubious. >>>>>>=20 >>>>>> Back in October 2005, I tried to raise a discussion on the AAA=20 >>>>>> group about the API, but the authors were unresponsive.=20 >That being=20 >>>>>> the case, we could not follow it because of its=20 >shortcomings and a=20 >>>>>> general lack of maturity. In addition, there seemed to be no=20 >>>>>> effort to make it mature. So now, a new draft suddenly=20 >appears and=20 >>>>>> we immediately go to last call? IMHO, there should be much more=20 >>>>>> discussion and there should be a couple of independent=20 >>>>>> implementations. Without real implementations, there will be no=20 >>>>>> meaningful discussions and the API will have serious=20 >shortcomings. =20 >>>>>> A simple review of the draft will not cut it. >>>>>> IMHO, we are a least a year away from a last call.=20 >>>>>=20 >>>>> I agree that maybe this WG LC is a little bit premature. >>>>>=20 >>>>> Julien Bournelle >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> David Lehmann >>>>>> Ulticom, Inc. >>>>>> http://www.ulticom.com >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>=20 >>>>> -- >>>>> julien.bournelle at int-evry.fr >>>>>=20 >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > >Hope this helps, > >~gwz > >Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 11 01:20:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHxSr-0002J8-MN; Sat, 11 Mar 2006 01:20:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHxSq-0002Im-Es for dime@ietf.org; Sat, 11 Mar 2006 01:20:32 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHxSm-0008PF-Sb for dime@ietf.org; Sat, 11 Mar 2006 01:20:32 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2B6IgLo023531; Sat, 11 Mar 2006 08:18:44 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Mar 2006 08:19:47 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Mar 2006 08:19:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Sat, 11 Mar 2006 08:19:46 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869F13@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Thread-Index: AcZEYZRj7xJBhiVQTzOIHIBahjYcgQAchKcw From: To: , X-OriginalArrivalTime: 11 Mar 2006 06:19:47.0199 (UTC) FILETIME=[CBA4A0F0:01C644D3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org The fact is, it is a charter item, and we should look at completing our charter. I'm really happy if people send technical comments of the draft, so we can judge if there needs to be changes, a rethink or if it is OK. =20 thanks, John=20 >-----Original Message----- >From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20 >Sent: 10 March, 2006 18:18 >To: dime@ietf.org >Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: Friday, March 10, 2006 2:43 AM >> To: asveren@ulticom.com; dime@ietf.org >> Subject: RE: [Dime] WGLC on=20 >ACTION:draft-ietf-dime-diameter-api-00.txt >> >> >> I don't think that meta-discussions are useful. Review the=20 >document,=20 >> raise conserns - if there are things that are in the=20 >document are not=20 >> good, then state that. If there isn't enough WG consensus to approve=20 >> the document, then the document doesn't get approved. >[TOLGA]I just tried to present my personal opinion, but in any=20 >case it is a good idea to get things done with some result=20 >-where result could be a RFC or no document or etc...- >> >> The IETF has worked on APIs before, see: >>=20 >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-12.txt >> IPv6 Advanced IPv6 API http://www.ietf.org/rfc/rfc3542.txt >> >> and a good search will find: >>=20 >https://datatracker.ietf.org/public/idindex.cgi?command=3Ddo_search_id&f= >> il=20 >>=20 >ename=3Dapi&id_tracker_state_id=3D-1&wg_id=3D0&other_group=3D&status_id=3D= 0&last >> _n >> ame=3D&first_name=3D >[TOLGA]The biggest reasons for the above APIs is that their=20 >predecessors were existing and well-accepted by the industry=20 >-SCTP socket API tries to mimic TCP socket API and similarly=20 >IPv6 API tries to mimic IPv4 API-. As counter example, there=20 >are many IETF defined protocols with no IETF defined APIs. >> >> John >> >> >-----Original Message----- >> >From: ext Tolga Asveren [mailto:asveren@ulticom.com] >> >Sent: 09 March, 2006 17:53 >> >To: dime@ietf.org >> >Subject: RE: [Dime] WGLC on=20 >> >ACTION:draft-ietf-dime-diameter-api-00.txt >> > >> >Hi John, >> > >> >What is the goal of this document? >> > >> >The draft says: >> >"The intent of the API is to foster source code portability across=20 >> >multiple programming platforms." >> > >> >Is this really something done often by IETF? >> > >> >Protocols being procedures between two peers need to be=20 >standardized,=20 >> >but APIs are a local contract between a protocol layer and an=20 >> >application of that protocol. For that reason they won't cause=20 >> >interoperability problems and people won't be forced to comply with=20 >> >them. Although initially this seems like good news because there is=20 >> >no need to comply with them, this also is the reason, why they are=20 >> >not very useful -there are of course exceptions like the=20 >socket API-.=20 >> >BTW, any API also implies certain implementation decisions,=20 >aren't we=20 >> >intervening too much to implementation dependent details by=20 >defining=20 >> >an API as a WG-document? >> > >> >I think, any API document for Diameter is better to be a non-WG=20 >> >document. In this way, people which are interested can submit the=20 >> >"best" API according to them and we won't have one "officially=20 >> >endorsed by IETF" version of API. >> > >> > Thnaks, >> > Tolga >> > >> > >> > >> >> -----Original Message----- >> >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> >> Sent: Thursday, March 09, 2006 10:50 AM >> >> To: julien.bournelle@int-evry.fr; lehmann@ulticom.com >> >> Cc: dime@ietf.org >> >> Subject: RE: [Dime] WGLC on >> >ACTION:draft-ietf-dime-diameter-api-00.txt >> >> >> >> >> >> Just as a note - if the document isn't ready, then make >> >comments, the >> >> document will be revised and we can then see if the=20 >document needs=20 >> >> another WGLC, etc. >> >> >> >> The focus should be getting the document finalized, if it takes=20 >> >> more than one round, or additional revisions, then that's fine. >> >> >> >> John >> >> >> >> >-----Original Message----- >> >> >From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] >> >> >Sent: 09 March, 2006 17:44 >> >> >To: David Lehmann >> >> >Cc: dime@ietf.org >> >> >Subject: Re: [Dime] WGLC on >> >> >ACTION:draft-ietf-dime-diameter-api-00.txt >> >> > >> >> >Hi David, >> >> > >> >> >On Thu, Mar 09, 2006 at 09:27:18AM -0500, David Lehmann wrote: >> >> >> David Frascone wrote: >> >> >> > >> >> >> >The API was used in sun's reference implementation. >> >Opendiameter >> >> >> >moved away from it, since they're in c++. >> >> >> I question whether this is Sun's API. If someone from Sun >> >> >can confirm >> >> >> or deny, please do. >> >> >> >> >> >> > >> >> >> >I think there is one other implementation. The author has=20 >> >> >> >promised to review and post ocmments to this list. >> >> >> Please name it. >> >> > >> >> > I guess that's me but I'm not the author of the implementatiion. >> >> > I'm using a Diameter Base >> >> > Protocol which is based on this API on top of which I >> >implement an >> >> >application. I already posted some comments on it (Diameter >> >API) both >> >> >on AAA and DIME ML. >> >> > I "promised" to compile all these comments. >> >> > >> >> >> As it stands right now, there is no known implementation >> >which uses >> >> >> this API. >> >> >> As Anders stated, this is a bit dubious. >> >> >> >> >> >> Back in October 2005, I tried to raise a discussion on the AAA=20 >> >> >> group about the API, but the authors were unresponsive. >> >That being >> >> >> the case, we could not follow it because of its=20 >shortcomings and >> >> >a general >> >> >> lack of maturity. In addition, there seemed to be no effort >> >> >to make it >> >> >> mature. So now, a new draft suddenly appears and we >> >> >immediately go to >> >> >> last call? >> >> >> IMHO, there should be much more discussion and there=20 >should be a=20 >> >> >> couple of independent implementations. Without real >> >> >implementations, >> >> >> there will be no meaningful discussions and the API will >> >> >have serious >> >> >> shortcomings. A simple review of the draft will not cut it. >> >> >> IMHO, we are a least a year away from a last call. >> >> > >> >> > I agree that maybe this WG LC is a little bit premature. >> >> > >> >> > Julien Bournelle >> >> > >> >> > >> >> >> >> >> >> -- >> >> >> >> >> >> David Lehmann >> >> >> Ulticom, Inc. >> >> >> http://www.ulticom.com >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> DiME mailing list >> >> >> DiME@ietf.org >> >> >> https://www1.ietf.org/mailman/listinfo/dime >> >> > >> >> >-- >> >> >julien.bournelle at int-evry.fr >> >> > >> >> >_______________________________________________ >> >> >DiME mailing list >> >> >DiME@ietf.org >> >> >https://www1.ietf.org/mailman/listinfo/dime >> >> > >> >> >> >> _______________________________________________ >> >> DiME mailing list >> >> DiME@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> > >> > >> > >> >_______________________________________________ >> >DiME mailing list >> >DiME@ietf.org >> >https://www1.ietf.org/mailman/listinfo/dime >> > >> > > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 13 01:49:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIgrh-0000Jf-K2; Mon, 13 Mar 2006 01:49:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIgrg-0000Ja-Lh for dime@ietf.org; Mon, 13 Mar 2006 01:49:12 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIgrc-0002gw-6c for dime@ietf.org; Mon, 13 Mar 2006 01:49:12 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2D6ltbn019317; Mon, 13 Mar 2006 08:47:56 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 08:49:04 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 08:49:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Date: Mon, 13 Mar 2006 08:49:03 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869F18@esebe100.NOE.Nokia.com> In-Reply-To: <4411BBB8.3010307@ulticom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt Thread-Index: AcZEas0sBne63k9bSLSvQLhyux6VoAB/z0NQ From: To: , X-OriginalArrivalTime: 13 Mar 2006 06:49:04.0020 (UTC) FILETIME=[379DBD40:01C6466A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org David, >IMHO, the Diameter API I-D is nowhere near the maturity of=20 >SCTP's API and the Diameter API has virtually no following. So=20 >why is the Diameter API I-D being held to such low standards? > >The I-D is at least a year (realistically 2-3 years) away from=20 >qualifying for WGLC. >IMHO, of course. WGLC implies nothing. It seems that in many working groups, noone reviews documents until WGLC. So, people need to review the current draft and raise issues. That's where we are at right now. If we need more working group last calls in order to complete the draft, then we will have them.=20 John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 13 02:04:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIh6H-0001ZP-7L; Mon, 13 Mar 2006 02:04:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIh6G-0001ZF-DV for dime@ietf.org; Mon, 13 Mar 2006 02:04:16 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIh6A-0002za-U3 for dime@ietf.org; Mon, 13 Mar 2006 02:04:16 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2D72Jt0002395 for ; Mon, 13 Mar 2006 09:02:20 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 09:04:09 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 09:04:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Mar 2006 09:04:08 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869F19@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DiME WG Agenda Thread-Index: AcZGbFNFcD9JZn9KTGyEL6OutDT//A== From: To: X-OriginalArrivalTime: 13 Mar 2006 07:04:09.0325 (UTC) FILETIME=[533851D0:01C6466C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Dime] DiME WG Agenda X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, This is the agenda for the DiME meeting, could the authors of the drafts below confirm who will present the drafts? Also, is there anything else that should be covered in this meeting? John DiME Working Group TUESDAY, March 21, 2006 1740-1840 Afternoon Session III=20 Room: Cortez AB =20 DiME WG update - Chairs - 5 Minutes Diameter Interop Event - Chairs - 5 minutes Interop Test plans - TBD - 10 mintues http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite-00.t xt Diameter API - TBD - 10 minutes http://tools.ietf.org/wg/dime/draft-ietf-dime-diameter-api/draft-ietf-di me-diameter-api-00.txt Diameter MIPv6 - TBD - 15 minutes http://tools.ietf.org/wg/dime/draft-tschofenig-dime-mip6-integrated-00.t xt http://tools.ietf.org/wg/dime/draft-tschofenig-dime-mip6-split-01.txt Diameter QoS - TBD - 15 minutes http://tools.ietf.org/wg/dime/draft-tschofenig-dime-diameter-qos-00.txt http://tools.ietf.org/wg/radext/draft-tschofenig-radext-qos-02.txt Diameter-RADIUS interworking - TBD - 15 minutes http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-01 .txt RFC3588 updating discussion - all - 30 minutes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 13 02:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIh99-0003yP-J8; Mon, 13 Mar 2006 02:07:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIh98-0003wy-7c; Mon, 13 Mar 2006 02:07:14 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIh96-00037a-Od; Mon, 13 Mar 2006 02:07:14 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2D75HTw005305; Mon, 13 Mar 2006 09:05:22 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 09:07:09 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 09:07:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Mar 2006 09:07:07 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869F1A@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869F19@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DiME WG Agenda updated Thread-Index: AcZGbFNFcD9JZn9KTGyEL6OutDT//AAAFnqA From: To: , X-OriginalArrivalTime: 13 Mar 2006 07:07:07.0609 (UTC) FILETIME=[BD7C4C90:01C6466C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Dime] DiME WG Agenda updated X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Sorry, had to revise the time alotment - we only have a 1 hour slot. John DiME Working Group TUESDAY, March 21, 2006 1740-1840 Afternoon Session III=20 Room: Cortez AB =20 DiME WG update - Chairs - 5 Minutes Diameter Interop Event - Chairs - 5 minutes Interop Test plans - TBD - 10 mintues http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite-00.t xt Diameter API - TBD - 10 minutes http://tools.ietf.org/wg/dime/draft-ietf-dime-diameter-api/draft-ietf-di me-diameter-api-00.txt Diameter MIPv6 - TBD - 10 minutes http://tools.ietf.org/wg/dime/draft-tschofenig-dime-mip6-integrated-00.t xt http://tools.ietf.org/wg/dime/draft-tschofenig-dime-mip6-split-01.txt Diameter QoS - TBD - 10 minutes http://tools.ietf.org/wg/dime/draft-tschofenig-dime-diameter-qos-00.txt http://tools.ietf.org/wg/radext/draft-tschofenig-radext-qos-02.txt Diameter-RADIUS interworking - TBD - 10 minutes http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-01 .txt RFC3588 updating discussion - all - remaining time. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 13 09:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoMq-0002Vl-BE; Mon, 13 Mar 2006 09:49:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoMp-0002Vb-LO for dime@ietf.org; Mon, 13 Mar 2006 09:49:51 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIoMo-0000Ix-FD for dime@ietf.org; Mon, 13 Mar 2006 09:49:51 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Mar 2006 09:49:50 -0500 X-IronPort-AV: i="4.02,187,1139202000"; d="scan'208"; a="83998967:sNHT27432944" Received: from [161.44.55.239] (dhcp-161-44-55-239.cisco.com [161.44.55.239]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2DEnoWc011054 for ; Mon, 13 Mar 2006 09:49:50 -0500 (EST) Message-ID: <4415868D.7010800@cisco.com> Date: Mon, 13 Mar 2006 09:49:49 -0500 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Dime] CER/CEA on an open connection X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org In its description of the peer state machine RFC 3588 goes out of its way to allow CER requests on an already open connection (section 5.6). Is the intention that either party can re-advertise its set of capabilities at any time? This raises some questions. For example, if TLS was not listed as supported in the first CER/CEA but is now, is it possible to carry out a TLS handshake after the exchange of non-CER/CEA traffic? What if no response is received for a "non-initial" CER (but other traffic, including DWR/DEA, continues to be exchanged), should the connection be reset? I wonder if the ability to exchange capabilities on an open connection is widely supported and whether it is really useful enough to warrant it being part of the spec. Should probably be part of the base protocol test suite if it is. Anders _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 13 10:12:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoim-0000DH-P5; Mon, 13 Mar 2006 10:12:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoil-00005z-6z for dime@ietf.org; Mon, 13 Mar 2006 10:12:31 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIoii-0001M9-Fz for dime@ietf.org; Mon, 13 Mar 2006 10:12:30 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2DFCRRo009229 for ; Mon, 13 Mar 2006 10:12:27 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2DFFHbx160550 for ; Mon, 13 Mar 2006 08:15:21 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k2DFCNPa022977 for ; Mon, 13 Mar 2006 08:12:23 -0700 Received: from d03nm114.boulder.ibm.com (d03nm114.boulder.ibm.com [9.17.195.140]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k2DFCNEt022970 for ; Mon, 13 Mar 2006 08:12:23 -0700 In-Reply-To: <4415868D.7010800@cisco.com> To: Anders Kristensen MIME-Version: 1.0 Subject: Re: [Dime] CER/CEA on an open connection X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Timothy Smith Date: Mon, 13 Mar 2006 10:15:22 -0500 X-MIMETrack: Serialize by Router on D03NM114/03/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/13/2006 08:15:24, Serialize complete at 03/13/2006 08:15:24 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0727815495==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0727815495== Content-Type: multipart/alternative; boundary="=_alternative 0053887885257130_=" This is a multipart message in MIME format. --=_alternative 0053887885257130_= Content-Type: text/plain; charset="US-ASCII" Hi Anders, I think there is a valid need for re-advertising capabilities. Applications may come and go over time. So this gives a means for an application to join an existing connection without having to bring it down and disrupt other applications that might already be using that connection. But I think the questions you raised are valid with regard to the definition of this renegotiation. It is subtle, but renegotiation is really defining an additional state in the state machine. If a CER is sent on an already negotiated connection, you have entered a new "Open-but-waiting_CEA" state. The questions that you raise should be addressed in that new state. I think it is a good function, but agree that it needs to be better defined. Best Regards, Timothy Smith tjsmith@us.ibm.com (919) 254-4723 Anders Kristensen 03/13/2006 09:49 AM To dime@ietf.org cc Subject [Dime] CER/CEA on an open connection In its description of the peer state machine RFC 3588 goes out of its way to allow CER requests on an already open connection (section 5.6). Is the intention that either party can re-advertise its set of capabilities at any time? This raises some questions. For example, if TLS was not listed as supported in the first CER/CEA but is now, is it possible to carry out a TLS handshake after the exchange of non-CER/CEA traffic? What if no response is received for a "non-initial" CER (but other traffic, including DWR/DEA, continues to be exchanged), should the connection be reset? I wonder if the ability to exchange capabilities on an open connection is widely supported and whether it is really useful enough to warrant it being part of the spec. Should probably be part of the base protocol test suite if it is. Anders _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --=_alternative 0053887885257130_= Content-Type: text/html; charset="US-ASCII"
Hi Anders,

I think there is a valid need for re-advertising capabilities.  Applications may come and go over time.  So this gives a means for an application to join an existing connection without having to bring it down and disrupt other applications that might already be using that connection.  But I think the questions you raised are valid with regard to the definition of this renegotiation.

It is subtle, but renegotiation is really defining an additional state in the state machine.  If a CER is sent on an already negotiated connection, you have entered a new "Open-but-waiting_CEA" state.  The questions that you raise should be addressed in that new state.

I think it is a good function, but agree that it needs to be better defined.

Best Regards,
Timothy Smith

tjsmith@us.ibm.com
(919) 254-4723


Anders Kristensen <andersk@cisco.com>

03/13/2006 09:49 AM

To
dime@ietf.org
cc
Subject
[Dime] CER/CEA on an open connection





In its description of the peer state machine RFC 3588 goes out of its
way to allow CER requests on an already open connection (section 5.6).
Is the intention that either party can re-advertise its set of
capabilities at any time? This raises some questions. For example, if
TLS was not listed as supported in the first CER/CEA but is now, is it
possible to carry out a TLS handshake after the exchange of non-CER/CEA
traffic? What if no response is received for a "non-initial" CER (but
other traffic, including DWR/DEA, continues to be exchanged), should the
connection be reset?

I wonder if the ability to exchange capabilities on an open connection
is widely supported and whether it is really useful enough to warrant it
being part of the spec. Should probably be part of the base protocol
test suite if it is.

Anders

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--=_alternative 0053887885257130_=-- --===============0727815495== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0727815495==-- From dime-bounces@ietf.org Mon Mar 13 10:39:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIp93-0007xL-7I; Mon, 13 Mar 2006 10:39:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIp91-0007xF-7T for dime@ietf.org; Mon, 13 Mar 2006 10:39:39 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIp90-00025X-Oy for dime@ietf.org; Mon, 13 Mar 2006 10:39:39 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k2DFdXHj031351; Mon, 13 Mar 2006 10:39:34 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44159238.5000406@tari.toshiba.com> Date: Mon, 13 Mar 2006 10:39:36 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy Smith Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > > Hi Anders, > > I think there is a valid need for re-advertising capabilities. > Applications may come and go over time. So this gives a means for an > application to join an existing connection without having to bring it > down and disrupt other applications that might already be using that > connection. But I think the questions you raised are valid with > regard to the definition of this renegotiation. > > It is subtle, but renegotiation is really defining an additional state > in the state machine. If a CER is sent on an already negotiated > connection, you have entered a new "Open-but-waiting_CEA" state. The > questions that you raise should be addressed in that new state. I agree, but i think renegotiation should be limited to app id support and not the transport type (i.e. TLS) as it is now. my 2 cents. victor > > I think it is a good function, but agree that it needs to be better > defined. > > Best Regards, > Timothy Smith > > tjsmith@us.ibm.com > (919) 254-4723 > > > > *Anders Kristensen * > > 03/13/2006 09:49 AM > > > To > dime@ietf.org > cc > > Subject > [Dime] CER/CEA on an open connection > > > > > > > > > > In its description of the peer state machine RFC 3588 goes out of its > way to allow CER requests on an already open connection (section 5.6). > Is the intention that either party can re-advertise its set of > capabilities at any time? This raises some questions. For example, if > TLS was not listed as supported in the first CER/CEA but is now, is it > possible to carry out a TLS handshake after the exchange of non-CER/CEA > traffic? What if no response is received for a "non-initial" CER (but > other traffic, including DWR/DEA, continues to be exchanged), should the > connection be reset? > > I wonder if the ability to exchange capabilities on an open connection > is widely supported and whether it is really useful enough to warrant it > being part of the spec. Should probably be part of the base protocol > test suite if it is. > > Anders > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > >------------------------------------------------------------------------ > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 14 08:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ9wd-0006Hp-QR; Tue, 14 Mar 2006 08:52:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ9wc-0006Hk-Lo for dime@ietf.org; Tue, 14 Mar 2006 08:52:14 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ9wb-0001bB-4C for dime@ietf.org; Tue, 14 Mar 2006 08:52:14 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2EDoFk6002311 for ; Tue, 14 Mar 2006 15:50:19 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 15:52:09 +0200 Received: from esebe107.NOE.Nokia.com ([172.21.143.89]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 15:52:09 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] application identifiers Date: Tue, 14 Mar 2006 15:52:07 +0200 Message-ID: <165947868C470B4889510CCB51416F6D95ECD0@esebe107.NOE.Nokia.com> In-Reply-To: <44066C58.8090909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] application identifiers Thread-Index: AcY9rQ+G8pk6r8urR4SiqFip7qRhkQJvqziA From: To: X-OriginalArrivalTime: 14 Mar 2006 13:52:09.0528 (UTC) FILETIME=[7CF89B80:01C6476E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > - Messages belonging to IETF defined apps will never have a=20 > Vendor-Specific-Application-Id (VSAI) AVP. > If they're correct it follows that a vendor specific=20 > application cannot reuse commands defined in the base spec or at > least that such messages cannot contain a Vendor-Specific-Application-Id > and hence must be considered part of the base app, not the vendor > specific app. =20 I think it is possible to re-use IETF defined command-code in vendor specific Diameter application. If the vendor specific application mandates that Vendor-Specific-Application-Id AVP has to be used with the command in the context of that application then it can be used (and must be used). When new Diameter applications are defined it should be considered whether to add application-id AVPs to ABNFs defined in the application or if it is enough to have the id as part of Diameter header. I think in most cases it is enough to have it in the header only. BR, Mikko Aittola > -----Original Message----- > From: ext Anders Kristensen [mailto:andersk@cisco.com]=20 > Sent: 02 March, 2006 05:54 > To: dime@ietf.org > Subject: [Dime] application identifiers >=20 > All, >=20 > I have some questions on application IDs. This is all pretty=20 > fundamental=20 > stuff so hopefully I didn't get it completely wrong ;) >=20 > Applications are identified by the combination of vendor ID and=20 > application ID with IETF defined apps having vendor ID 0=20 > (3588, 2.7). My=20 > understanding is that with the exception of CER and CEA which are=20 > special the following is true for all messages: >=20 > - Messages belonging to IETF defined apps will never have a=20 > Vendor-Specific-Application-Id (VSAI) AVP. >=20 > - Messages belonging to IETF defined apps may have either an=20 > Auth-Application-Id or an Acct-Application-Id AVP. If it does=20 > have one=20 > of those AVPs, the value will equal that of the=20 > Application-ID field in=20 > the message header. >=20 > - Messages belonging to non-IETF defined apps must have exactly one=20 > VSAI AVP. This AVP must contain either an Auth-Application-Id or an=20 > Acct-Application-Id whose value must equal that of the Application-ID=20 > field in the message header. [This is not actually what I get from=20 > reading 3588 (see below) but it's what makes sense, I think.] >=20 > Are these statements correct? >=20 > If they're correct it follows that a vendor specific=20 > application cannot=20 > reuse commands defined in the base spec or at least that such=20 > messages=20 > cannot contain a Vendor-Specific-Application-Id and hence must be=20 > considered part of the base app, not the vendor specific app. >=20 > Some questions on specific section of 3588: >=20 > Section 2.4: >=20 > Each Diameter application MUST have an IANA assigned Application > Identifier (see Section 11.3). The base protocol does=20 > not require an > Application Identifier since its support is mandatory. >=20 > All Diameter nodes have to understand CER, DWR and DPR requests but=20 > clearly not all Diameter nodes will know what to do with,=20 > say, an ACR so=20 > this seems wrong. >=20 >=20 > 6.11: >=20 > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > Grouped and is used to advertise support of a vendor-specific > Diameter Application. Exactly one of the Auth-Application-Id and > Acct-Application-Id AVPs MAY be present. > ... > ::=3D < AVP Header: 260 > > 1* [ Vendor-Id ] > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } >=20 > The sentence "Exactly one of the Auth-Application-Id and=20 > Acct-Application-Id AVPs MAY be present" seems odd. Should't it be a=20 > requirement that exactly one of the AVPs be present? As it stands a=20 > Vendor-Specific-Application-Id containing just a Vendor-Id=20 > would seem to=20 > be OK. >=20 > And why are multiple Vendor-Ids allowed here? Are there any known=20 > situations where messages contain a=20 > Vendor-Specific-Application-Id with=20 > more than one Vendor-Id? >=20 > Also, the text seems to rule out inclusion of both=20 > Auth-Application-Id=20 > and Acct-Application-Id but wouldn't it be possible for an=20 > app to have=20 > both an accounting and an authentication portion or is that just=20 > disallowed? (The base app has both, right?) >=20 >=20 > Section 11.3: >=20 > Both Application-Id and Acct-Application-Id AVPs use the same > Application Identifier space. >=20 > and Auth-Application-Id too, right? >=20 >=20 > Comments much appreciated. >=20 > Thanks, > Anders >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 14 09:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJAM4-0001zg-Vd; Tue, 14 Mar 2006 09:18:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJAM3-0001zX-Fg for dime@ietf.org; Tue, 14 Mar 2006 09:18:31 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJAM3-0002Ur-3S for dime@ietf.org; Tue, 14 Mar 2006 09:18:31 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k2EEIRvh035171; Tue, 14 Mar 2006 09:18:28 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4416D0B5.8040600@tari.toshiba.com> Date: Tue, 14 Mar 2006 09:18:29 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.aittola@nokia.com Subject: Re: [Dime] application identifiers References: <165947868C470B4889510CCB51416F6D95ECD0@esebe107.NOE.Nokia.com> In-Reply-To: <165947868C470B4889510CCB51416F6D95ECD0@esebe107.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Mikko, >Hi, > > > >>- Messages belonging to IETF defined apps will never have a >>Vendor-Specific-Application-Id (VSAI) AVP. >> >> > > > >>If they're correct it follows that a vendor specific >>application cannot reuse commands defined in the base spec or at >>least that such messages cannot contain a >> >> >Vendor-Specific-Application-Id > > >>and hence must be considered part of the base app, not the vendor >>specific app. >> >> > >I think it is possible to re-use IETF defined command-code in vendor >specific Diameter application. > > depends on which message and how you use it. session maintenance is one example (STR/STA, ASR/ASA) but generally one reason you define a vendor application is because your defining new message(s). i.e. new command-code. regards, victor >If the vendor specific application mandates that >Vendor-Specific-Application-Id AVP has to be used with the command in >the context of that application then it can be used (and must be used). > >When new Diameter applications are defined it should be >considered whether to add application-id AVPs to ABNFs defined >in the application or if it is enough to have the id as part of >Diameter header. I think in most cases it is enough to have it >in the header only. > > >BR, >Mikko Aittola > > > > >>-----Original Message----- >>From: ext Anders Kristensen [mailto:andersk@cisco.com] >>Sent: 02 March, 2006 05:54 >>To: dime@ietf.org >>Subject: [Dime] application identifiers >> >>All, >> >>I have some questions on application IDs. This is all pretty >>fundamental >>stuff so hopefully I didn't get it completely wrong ;) >> >>Applications are identified by the combination of vendor ID and >>application ID with IETF defined apps having vendor ID 0 >>(3588, 2.7). My >>understanding is that with the exception of CER and CEA which are >>special the following is true for all messages: >> >> - Messages belonging to IETF defined apps will never have a >>Vendor-Specific-Application-Id (VSAI) AVP. >> >> - Messages belonging to IETF defined apps may have either an >>Auth-Application-Id or an Acct-Application-Id AVP. If it does >>have one >>of those AVPs, the value will equal that of the >>Application-ID field in >>the message header. >> >> - Messages belonging to non-IETF defined apps must have exactly one >>VSAI AVP. This AVP must contain either an Auth-Application-Id or an >>Acct-Application-Id whose value must equal that of the Application-ID >>field in the message header. [This is not actually what I get from >>reading 3588 (see below) but it's what makes sense, I think.] >> >>Are these statements correct? >> >>If they're correct it follows that a vendor specific >>application cannot >>reuse commands defined in the base spec or at least that such >>messages >>cannot contain a Vendor-Specific-Application-Id and hence must be >>considered part of the base app, not the vendor specific app. >> >>Some questions on specific section of 3588: >> >>Section 2.4: >> >> Each Diameter application MUST have an IANA assigned Application >> Identifier (see Section 11.3). The base protocol does >>not require an >> Application Identifier since its support is mandatory. >> >>All Diameter nodes have to understand CER, DWR and DPR requests but >>clearly not all Diameter nodes will know what to do with, >>say, an ACR so >>this seems wrong. >> >> >>6.11: >> >> The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type >> Grouped and is used to advertise support of a vendor-specific >> Diameter Application. Exactly one of the Auth-Application-Id and >> Acct-Application-Id AVPs MAY be present. >> ... >> ::= < AVP Header: 260 > >> 1* [ Vendor-Id ] >> 0*1{ Auth-Application-Id } >> 0*1{ Acct-Application-Id } >> >>The sentence "Exactly one of the Auth-Application-Id and >>Acct-Application-Id AVPs MAY be present" seems odd. Should't it be a >>requirement that exactly one of the AVPs be present? As it stands a >>Vendor-Specific-Application-Id containing just a Vendor-Id >>would seem to >>be OK. >> >>And why are multiple Vendor-Ids allowed here? Are there any known >>situations where messages contain a >>Vendor-Specific-Application-Id with >>more than one Vendor-Id? >> >>Also, the text seems to rule out inclusion of both >>Auth-Application-Id >>and Acct-Application-Id but wouldn't it be possible for an >>app to have >>both an accounting and an authentication portion or is that just >>disallowed? (The base app has both, right?) >> >> >>Section 11.3: >> >> Both Application-Id and Acct-Application-Id AVPs use the same >> Application Identifier space. >> >>and Auth-Application-Id too, right? >> >> >>Comments much appreciated. >> >>Thanks, >>Anders >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www1.ietf.org/mailman/listinfo/dime >> >> >> > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 14 14:29:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJFD4-0000Wr-5z; Tue, 14 Mar 2006 14:29:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJFD2-0000Wl-Ub for dime@ietf.org; Tue, 14 Mar 2006 14:29:32 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJFD1-0002zx-3q for dime@ietf.org; Tue, 14 Mar 2006 14:29:32 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 880E5A1C07 for ; Tue, 14 Mar 2006 14:29:28 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k2EJTMkd015235 for ; Tue, 14 Mar 2006 14:29:28 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] application identifiers Date: Tue, 14 Mar 2006 14:08:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <165947868C470B4889510CCB51416F6D95ECD0@esebe107.NOE.Nokia.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Mikko, [.. snip ..] > When new Diameter applications are defined it should be > considered whether to add application-id AVPs to ABNFs defined > in the application or if it is enough to have the id as part of > Diameter header. I think in most cases it is enough to have it > in the header only. [TOLGA]Considering that all application Ids are assigned from a gloabal pool, what would be the criteria to include/exclude application-Id AVPs for new messages? _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 15 00:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJOiu-0003bl-PQ; Wed, 15 Mar 2006 00:39:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJOit-0003bg-Hw for dime@ietf.org; Wed, 15 Mar 2006 00:39:03 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJOit-0003Jw-3z for dime@ietf.org; Wed, 15 Mar 2006 00:39:03 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2F5b7Fa010460 for ; Wed, 15 Mar 2006 07:37:07 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 07:39:00 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 07:39:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Mar 2006 07:39:00 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869F90@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Jabber service for IETF meetings Thread-Index: AcZH6NViP19TeXceQriei26pCpihbAACenAQ From: To: X-OriginalArrivalTime: 15 Mar 2006 05:39:01.0943 (UTC) FILETIME=[C3CF2C70:01C647F2] X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Dime] FW: Jabber service for IETF meetings X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org FYI - if anyone is planning on participating remotely, let me know. John=20 >-----Original Message----- >From: ext IETF Secretariat [mailto:ietf-secretariat@ietf.org]=20 >Sent: 15 March, 2006 06:26 >To: Working Group Chairs >Subject: Jabber service for IETF meetings=20 > >Dear IETF WG Chairs, > >The Secretariat is pleased to announce a new Instant Messaging=20 >service. This service will provide jabber chat rooms to all=20 >IETF working groups for their text conferencing at IETF 65 and=20 >future meetings. > >The new jabber server is located at jabber.ietf.org and is=20 >currently accessible. For those who are interested, please=20 >visit the above location to join any of the available chat rooms. > >Over the next few days, please take the time to test this new=20 >service and provide us with all questions, comments, and=20 >suggestions. Your feedback is key to our success! > >Please note: > >All traffic within the defined rooms (except "noc") is being=20 >logged and updated every 5 minutes to the ietf.org website. > >To view the log directories, point your browser to=20 >http://www.ietf.org/meetings/ietf-logs/. > >If you click on a room directory, you will see one or more=20 >files named "YYYY-MM-DD.html", e.g. 2006-03-14.html. If you=20 >click on one of those files, you will see all logged traffic=20 >for that day. >=20 >Please visit the IETF Text Conferencing Web page >(http://www.ietf.org/meetings/text_conf.html) for more information. > >The IETF Secretariat. > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 15 05:37:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJTNh-0000i9-LS; Wed, 15 Mar 2006 05:37:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJTNh-0000i4-2Y for dime@ietf.org; Wed, 15 Mar 2006 05:37:29 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJTNf-00045w-Kq for dime@ietf.org; Wed, 15 Mar 2006 05:37:29 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2FAa7o9030822 for ; Wed, 15 Mar 2006 12:36:14 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 12:37:26 +0200 Received: from esebe107.NOE.Nokia.com ([172.21.143.89]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 12:37:26 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] application identifiers Date: Wed, 15 Mar 2006 12:37:24 +0200 Message-ID: <165947868C470B4889510CCB51416F6D95F18C@esebe107.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] application identifiers Thread-Index: AcZHnlYIZuXn2QJmTNGmeJdKXPT0lgAfIloA From: To: X-OriginalArrivalTime: 15 Mar 2006 10:37:26.0553 (UTC) FILETIME=[73C9D890:01C6481C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > [TOLGA]Considering that all application Ids are assigned from=20 > a gloabal pool, what would be the criteria to include/exclude=20 > application-Id AVPs for new messages?=20 I don't have any specific criteria in mind. Designers of new application should consider the issue and if they don't see any need for the separate app-id AVP then I think it can be left out of the ABNF defined by the application. BR, Mikko > -----Original Message----- > From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20 > Sent: 14 March, 2006 21:09 > To: dime@ietf.org > Subject: RE: [Dime] application identifiers >=20 > Hi Mikko, >=20 > [.. snip ..] > > When new Diameter applications are defined it should be > > considered whether to add application-id AVPs to ABNFs defined > > in the application or if it is enough to have the id as part of > > Diameter header. I think in most cases it is enough to have it > > in the header only. > [TOLGA]Considering that all application Ids are assigned from=20 > a gloabal > pool, what would be the criteria to include/exclude=20 > application-Id AVPs for > new messages? >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 15 14:35:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbly-0000Wh-Oj; Wed, 15 Mar 2006 14:35:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJblx-0000WX-Vu for dime@ietf.org; Wed, 15 Mar 2006 14:35:05 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJblx-0004cQ-IL for dime@ietf.org; Wed, 15 Mar 2006 14:35:05 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id A4BB82C1D2 for ; Wed, 15 Mar 2006 14:35:04 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k2FJZ27i003152 for ; Wed, 15 Mar 2006 14:35:03 -0500 (EST) From: "Tolga Asveren" To: Date: Wed, 15 Mar 2006 14:14:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [Dime] Comments about draft-fajardo-dime-interop-test-suite-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I have the following comments about draft-fajardo-dime-interop-test-suite-00: 1) There is no section about encoding/decoding of messages/AVPs. I believe it could be useful to have a section just for that with positive and negative test cases, e.g. messages/AVPs with invalid length, flag values, padding etc. . 2) Things like "Reconnecting", are they really interoperability issues? They seem to me totally local procedures. RFC3588 talks about the expected behavior but would it break interoprability if somebody does not attempt a reconnect at all? 3) The topology presented in 3.1.1.5. and the suggested of way of testing seem overcomplex to me for failover/failback testing. Isn't something like this enough: +------+ +---------+Node B| | +------+ +--+---+ |Node A| +--+---+ | +------+ +---------+Node C| +------+ Node A sends messages to Node B. When it detects that Node B is down, it retransmits messages to Node C with T-flag set. 4) 3.1.1.5 "o Negative test to generate DIAMETER_UNABLE_TO_DELIVER on answer message from B to A when Destination-Host is set to C." I didn't understand what we are trying to test here. 5) 3.1.1.5 For duplicate message detection -the last item in this section- i- I wouldn't call it a negative test case, IMO it is a positive test case, i.e. things are working the way they are supposed to work and nobody is misbehaving. ii- It seems like the suggesed way of testing won't allow the desired behavior. Answers from NodeC will be still forwarded to NodeA. This would both clean the pending request in the retransmission queue and even if no watchdog is exchanged would help to keep the connection alive. I suggest the following: Configure asymmetric IP routing on NodeB after capability exchange is done, i.e. it can receive packets from NodeA but can't send to NodeA. It can send/receive to/from NodeC. Node A will send requests to NodeA till it detects that NodeB is "down". All such requests will be forwarded to NodeC and corresponding answers will be sent to NodeB, but they won't be forwarded to NodeA. when NodeA failovers to NodeD, it will retransmit all requests it sent before via NodeD to NodeC. They need to be detected as duplicates. I think another test case for duplicate detection could be useful as well: Put the interface on NodeB down, now it can't communciate neither with NodeA, nor with NodeB. NodeA keeps sending till it detects the fialure. NodeA detects failure, retransmits. NodeC shouldn't detect requests as duplicate. 6) Why is "Peer State Machine" related tests -3.2.1- considered as optional. I believe from a black-box behavior point of view, all nodes MUST comply with peer state machine, i.e. in terms off expected sent/receive messages. 7) This is more a generic comment but it is easier to discuss about it in the context of an example: 4.1.1.2.1 o Positive test for proper client session establishment. Verify that sub-session id is supported and that the client can support event record generation at the least. Verify that the client should at least be able to support DELIVER_AND_GRANT. Test entities must be able to configure their server implementation to send this avp. Must conform to Section 9.4 and 9.8.7 of [RFC3588]. I would think, we should have step-by-step instructions for multiple test cases covering the behavior described in the RFC, for example what does it mean "supporting Sub-Session Id"? There should be test case verifying this which probably includes accounting messages in the same session for different subsessions, where one can observe that state machine processing is done properly for each of them. This type of test case description is rpeated at a few more cases, I believe it is hard to run a test case just based on that description, or in other words, it doesn't tell much more than RFC3588 itself. this comment applies largely for all Credit Control test cases as well. If we want to test local application behavior as well, I would expect test cases with expected message flows + local indications/observations. Something like -an example for Credit Control-: Client Server CCFH= CONTINUE | | | | | | | | ----CCR------------>| | (initial request) | | | Tx | Expires | | | <-Grant service | to user | | | 8) Certain test cases are a bit too much involving into application logic. An example: 4.2.1.8 o Positive test for a direct debiting enquiry with the CC Client including the requested units. Verify that the CC Server just deducts the corresponding monetary amount from the end user's account without performing rating. Verify that the granted service units can be of type time, volume, service specific, or money. I don't think something like verifying that correct amount is deducted from user account belongs to Diameter interoperability. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 15 15:31:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcer-0003pD-FH; Wed, 15 Mar 2006 15:31:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcel-0003mF-Ve for dime@ietf.org; Wed, 15 Mar 2006 15:31:44 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJcek-0006g1-LX for dime@ietf.org; Wed, 15 Mar 2006 15:31:43 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id F515A9A71C for ; Wed, 15 Mar 2006 15:31:42 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k2FKVdrb009326 for ; Wed, 15 Mar 2006 15:31:39 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Comments about draft-fajardo-dime-interop-test-suite-00 Date: Wed, 15 Mar 2006 15:10:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44187861.7070707@tari.toshiba.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, [.. snip ..] > >5) 3.1.1.5 > >For duplicate message detection -the last item in this section- > >i- I wouldn't call it a negative test case, IMO it is a positive > test case, > >i.e. things are working the way they are supposed to work and nobody is > >misbehaving. > >ii- It seems like the suggesed way of testing won't allow the desired > >behavior. Answers from NodeC will be still forwarded to NodeA. This would > >both clean the pending request in the retransmission queue and even if no > >watchdog is exchanged would help to keep the connection alive. I > suggest the > >following: > >Configure asymmetric IP routing on NodeB after capability > exchange is done, > >i.e. it can receive packets from NodeA but can't send to NodeA. It can > >send/receive to/from NodeC. Node A will send requests to NodeA till it > >detects that NodeB is "down". All such requests will be > forwarded to NodeC > >and corresponding answers will be sent to NodeB, but they won't > be forwarded > >to NodeA. when NodeA failovers to NodeD, it will retransmit all > requests it > >sent before via NodeD to NodeC. They need to be detected as duplicates. > > > > > ... or simply configure C to discard request from A. [TOLGA]Yes, that would do too, but I personally think if we can run test cases without code customization, it may be more handy. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 15 15:32:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcfH-0003wb-8a; Wed, 15 Mar 2006 15:32:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJceE-0003M9-Io for dime@ietf.org; Wed, 15 Mar 2006 15:31:10 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJcZP-0006N8-2c for dime@ietf.org; Wed, 15 Mar 2006 15:26:14 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k2FKQ7FU049883; Wed, 15 Mar 2006 15:26:08 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44187861.7070707@tari.toshiba.com> Date: Wed, 15 Mar 2006 15:26:09 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Comments about draft-fajardo-dime-interop-test-suite-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Comments below: >1) There is no section about encoding/decoding of messages/AVPs. I believe >it could be useful to have a section just for that with positive and >negative test cases, e.g. messages/AVPs with invalid length, flag values, >padding etc. . > > this could be an optional test case. though if this where to be included, i'm more interested in the test entity sending an answer with error bit set. >2) Things like "Reconnecting", are they really interoperability issues? They >seem to me totally local procedures. RFC3588 talks about the expected >behavior but would it break interoprability if somebody does not attempt a >reconnect at all? > > > i dont think a peer attempting reconnection will break interoperablity. this test can be move change to an optional test since its not mandated. >3) The topology presented in 3.1.1.5. and the suggested of way of testing >seem overcomplex to me for failover/failback testing. Isn't something like >this enough: > > +------+ > +---------+Node B| > | +------+ > +--+---+ > |Node A| > +--+---+ > | +------+ > +---------+Node C| > +------+ > >Node A sends messages to Node B. When it detects that Node B is down, it >retransmits messages to Node C with T-flag set. > > the topology is describe as such so that many vendors can participate during a single test scenario. this is in the interest of time. >4) 3.1.1.5 >"o Negative test to generate DIAMETER_UNABLE_TO_DELIVER on answer > message from B to A when Destination-Host is set to C." >I didn't understand what we are trying to test here. > > This should be read: "Negative test to generate DIAMETER_UNABLE_TO_DELIVER answer message from B to A when Destination-Host is set to C and link3 is disconnected" >5) 3.1.1.5 >For duplicate message detection -the last item in this section- >i- I wouldn't call it a negative test case, IMO it is a positive test case, >i.e. things are working the way they are supposed to work and nobody is >misbehaving. >ii- It seems like the suggesed way of testing won't allow the desired >behavior. Answers from NodeC will be still forwarded to NodeA. This would >both clean the pending request in the retransmission queue and even if no >watchdog is exchanged would help to keep the connection alive. I suggest the >following: >Configure asymmetric IP routing on NodeB after capability exchange is done, >i.e. it can receive packets from NodeA but can't send to NodeA. It can >send/receive to/from NodeC. Node A will send requests to NodeA till it >detects that NodeB is "down". All such requests will be forwarded to NodeC >and corresponding answers will be sent to NodeB, but they won't be forwarded >to NodeA. when NodeA failovers to NodeD, it will retransmit all requests it >sent before via NodeD to NodeC. They need to be detected as duplicates. > > ... or simply configure C to discard request from A. victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 15 16:22:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdSK-0002Ha-EU; Wed, 15 Mar 2006 16:22:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdSI-0002Gu-Dw for dime@ietf.org; Wed, 15 Mar 2006 16:22:54 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJdSI-0008Kp-1U for dime@ietf.org; Wed, 15 Mar 2006 16:22:54 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id F06CC02FD5 for ; Wed, 15 Mar 2006 16:22:53 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k2FLMqFY014313 for ; Wed, 15 Mar 2006 16:22:52 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Comments about draft-fajardo-dime-interop-test-suite-00 Date: Wed, 15 Mar 2006 16:02:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Oppssss, I realized that my comment wasn't right. Please see below. > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: Wednesday, March 15, 2006 3:11 PM > To: dime@ietf.org > Subject: RE: [Dime] Comments about > draft-fajardo-dime-interop-test-suite-00 > > > Hi Victor, > > [.. snip ..] > > >5) 3.1.1.5 > > >For duplicate message detection -the last item in this section- > > >i- I wouldn't call it a negative test case, IMO it is a positive > > test case, > > >i.e. things are working the way they are supposed to work and nobody is > > >misbehaving. > > >ii- It seems like the suggesed way of testing won't allow the desired > > >behavior. Answers from NodeC will be still forwarded to NodeA. > This would > > >both clean the pending request in the retransmission queue and > even if no > > >watchdog is exchanged would help to keep the connection alive. I > > suggest the > > >following: > > >Configure asymmetric IP routing on NodeB after capability > > exchange is done, > > >i.e. it can receive packets from NodeA but can't send to NodeA. It can > > >send/receive to/from NodeC. Node A will send requests to NodeA till it > > >detects that NodeB is "down". All such requests will be > > forwarded to NodeC > > >and corresponding answers will be sent to NodeB, but they won't > > be forwarded > > >to NodeA. when NodeA failovers to NodeD, it will retransmit all > > requests it > > >sent before via NodeD to NodeC. They need to be detected as duplicates. > > > > > > > > ... or simply configure C to discard request from A. > [TOLGA]Yes, that would do too, but I personally think if we can run test > cases without code customization, it may be more handy. [TOLGA]Actually that won't do. If we drop requests from NodeA, NodeC won't receive anything, so when requests are retransmitted, it will be the first time they are received by NodeC and they shouldn't be detected as duplicates -that IMO, should be another test case-. For this particular test case, requests should arrive at NodeC but answers shouldn't be received by NodeA. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 18 13:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKgWv-0005GU-Nx; Sat, 18 Mar 2006 13:52:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKgWu-0005GP-MY for dime@ietf.org; Sat, 18 Mar 2006 13:52:00 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKgWu-0003BL-0m for dime@ietf.org; Sat, 18 Mar 2006 13:52:00 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2IIod0s007270; Sat, 18 Mar 2006 20:50:39 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:51:57 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:51:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] CER/CEA on an open connection Date: Sat, 18 Mar 2006 20:51:56 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A034@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] CER/CEA on an open connection Thread-Index: AcZGsLxC0j849NlVT6ugZiFM1q+TqQEDBVZA From: To: , X-OriginalArrivalTime: 18 Mar 2006 18:51:57.0027 (UTC) FILETIME=[08022330:01C64ABD] X-Spam-Score: 0.5 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1727925803==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1727925803== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64ABD.07B8CCAB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64ABD.07B8CCAB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hmm, it seems to me that if we have to fix the state machine, that might be a significant change as it would affect people implementations. Would specifying the renegotiation be something that people are interested in? =20 John Hi Anders,=20 =09 I think there is a valid need for re-advertising capabilities. Applications may come and go over time. So this gives a means for an application to join an existing connection without having to bring it down and disrupt other applications that might already be using that connection. But I think the questions you raised are valid with regard to the definition of this renegotiation.=20 =09 It is subtle, but renegotiation is really defining an additional state in the state machine. If a CER is sent on an already negotiated connection, you have entered a new "Open-but-waiting_CEA" state. The questions that you raise should be addressed in that new state.=20 =09 I think it is a good function, but agree that it needs to be better defined.=20 =09 Best Regards,=20 Timothy Smith=20 =09 tjsmith@us.ibm.com (919) 254-4723 =09 =09 =09 =09 Anders Kristensen =20 03/13/2006 09:49 AM=20 To dime@ietf.org=20 cc Subject [Dime] CER/CEA on an open connection =09 In its description of the peer state machine RFC 3588 goes out of its=20 way to allow CER requests on an already open connection (section 5.6).=20 Is the intention that either party can re-advertise its set of=20 capabilities at any time? This raises some questions. For example, if=20 TLS was not listed as supported in the first CER/CEA but is now, is it=20 possible to carry out a TLS handshake after the exchange of non-CER/CEA=20 traffic? What if no response is received for a "non-initial" CER (but=20 other traffic, including DWR/DEA, continues to be exchanged), should the=20 connection be reset? =09 I wonder if the ability to exchange capabilities on an open connection=20 is widely supported and whether it is really useful enough to warrant it=20 being part of the spec. Should probably be part of the base protocol=20 test suite if it is. =09 Anders =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime =09 =09 ------_=_NextPart_001_01C64ABD.07B8CCAB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hmm, it seems to me that if we have to fix the = state=20 machine, that might be a significant change as it would affect people=20 implementations.   Would specifying the renegotiation be=20 something that people are interested in?
 
John


Hi Anders,

I think there is a valid need for re-advertising = capabilities.=20  Applications may come and go over time.  So this gives a = means for=20 an application to join an existing connection without having to bring = it down=20 and disrupt other applications that might already be using that = connection.=20  But I think the questions you raised are valid with regard to = the=20 definition of this renegotiation.

It is subtle, but renegotiation is really defining an = additional state=20 in the state machine.  If a CER is sent on an already negotiated=20 connection, you have entered a new "Open-but-waiting_CEA" state. =  The=20 questions that you raise should be addressed in that new state. =

I think it is a good = function, but agree=20 that it needs to be better defined.

Best Regards,
Timothy=20 Smith

tjsmith@us.ibm.com
(919)=20 254-4723



Anders = Kristensen=20 <andersk@cisco.com>

03/13/2006 09:49 AM =

To
dime@ietf.org=20
cc
Subject
[Dime] = CER/CEA on an=20 open connection

=




In its description of the peer state machine RFC 3588 = goes out of=20 its
way to allow CER requests on an already open connection = (section 5.6).=20
Is the intention that either party can re-advertise its set of=20
capabilities at any time? This raises some questions. For example, = if=20
TLS was not listed as supported in the first CER/CEA but is now, = is it=20
possible to carry out a TLS handshake after the exchange of = non-CER/CEA=20
traffic? What if no response is received for a "non-initial" CER = (but=20
other traffic, including DWR/DEA, continues to be exchanged), = should the=20
connection be reset?

I wonder if the ability to exchange=20 capabilities on an open connection
is widely supported and whether = it is=20 really useful enough to warrant it
being part of the spec. Should = probably=20 be part of the base protocol
test suite if it=20 = is.

Anders

_______________________________________________<= BR>DiME=20 mailing=20 = list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
<= /TT>
------_=_NextPart_001_01C64ABD.07B8CCAB-- --===============1727925803== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1727925803==-- From dime-bounces@ietf.org Sat Mar 18 14:14:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKgso-00075c-02; Sat, 18 Mar 2006 14:14:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKgsm-00074e-53 for dime@ietf.org; Sat, 18 Mar 2006 14:14:36 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKgsk-00046Y-MZ for dime@ietf.org; Sat, 18 Mar 2006 14:14:36 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2IJCSn2029247; Sat, 18 Mar 2006 21:12:28 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 21:14:33 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 21:14:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Application Date: Sat, 18 Mar 2006 21:14:32 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A039@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Application Thread-Index: AcY924uALAkCHBETRayAeauSegHe0QM5H/uw From: To: , X-OriginalArrivalTime: 18 Mar 2006 19:14:33.0229 (UTC) FILETIME=[305E23D0:01C64AC0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org In advance of the meeting, I'd like to put out a call - who is interested in QoS support in Diameter (not just this document, but in general)? Would anyone have cycles to review this and give input? thanks, John=20 >-----Original Message----- >From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 >Sent: 02 March, 2006 11:33 >To: dime@ietf.org >Subject: [Dime] Diameter QoS Application > >Hi all,=20 > >we have resubmitted our Diameter QoS application draft to the=20 >DIME working group.=20 > >Here is the new draft version: Diameter Quality of Service Application > >Abstract > > This document describes a Diameter application that performs > Authentication, Authorization, and Accounting for Quality of Service > (QoS) reservations. This protocol is used by elements=20 >along the path > of a given application flow to authenticate a reservation request, > ensure that the reservation is authorized, and to account for > resources consumed during the lifetime of the application flow. > Clients that implement the Diameter QoS application contact an > authorizing entity/application server that is located somewhere in > the network, allowing for a wide variety of flexible deployment > models. > >http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-diameter >-qos-00.t >xt > >This version of the draft is based on=20 >draft-alfano-aaa-qosprot-05.txt and contains feedback we=20 >received by John, Robert Hancock and Jerry Ash. >The issue tracker of this document can be found at: >http://www.tschofenig.priv.at:8080/diameter-qos/index > >Ciao >Hannes > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 18 14:15:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKgu5-0007QW-9h; Sat, 18 Mar 2006 14:15:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKgu4-0007Pn-R6 for dime@ietf.org; Sat, 18 Mar 2006 14:15:56 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKgu4-00049W-CZ for dime@ietf.org; Sat, 18 Mar 2006 14:15:56 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2IJFrTm029063; Sat, 18 Mar 2006 21:15:53 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 21:15:53 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 21:15:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: trailing [*fixed] section in messages [was: Re: [Dime] DiME WG meeting in Dallas] Date: Sat, 18 Mar 2006 21:15:52 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A03A@esebe100.NOE.Nokia.com> In-Reply-To: <4405C51C.4040302@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: trailing [*fixed] section in messages [was: Re: [Dime] DiME WG meeting in Dallas] Thread-Index: AcY9SU4iOVFTB74DS/mTIJR2dOcCZANdwIYg From: To: , X-OriginalArrivalTime: 18 Mar 2006 19:15:53.0305 (UTC) FILETIME=[6018C490:01C64AC0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Someone want to propose a simplified format? We could add that to the issues list. John=20 >-----Original Message----- >From: ext Anders Kristensen [mailto:andersk@cisco.com]=20 >Sent: 01 March, 2006 18:00 >To: Victor Fajardo >Cc: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org >Subject: trailing [*fixed] section in messages [was: Re:=20 >[Dime] DiME WG meeting in Dallas] > >(going through old email) > >Victor Fajardo wrote: > >> Hi, >>=20 >> I'd like to post a question regarding the trailing [*fixed]=20 >avp set of=20 >> diameter-message ABNF in Sec 3.2 of the base proto (where: >> diameter-message =3D header [*fixed] [*required] [*optional]=20 >[*fixed]).=20 >> I'm not familiar with the history of this layout but in which >> scenario(s) are trailing fixed avps used ? So far appending of=20 >> trailing avps are most relevant to proxies and relays but=20 >> route-records and proxy-info are normally tagged as optional as they=20 >> should be. And at the moment, there does'nt seem to be any=20 >application=20 >> defining a trailing fixed avp. Maybe this format can be=20 >relaxed to help simplify parsing. > >I also don't know the reason this was put in but I agree that=20 >it doesn't seem very useful. Presumably the reason for the=20 >first [*fixed] section is that having certain AVPs appear=20 >early can help allow implementations that are interested only=20 >in these specific AVPs to not have to parse or skip over other=20 >AVPs. This reason cannot apply to fixed AVPs at the end of=20 >messages as one cannot parse from the end (no way of telling=20 >where the last AVP started without making one's way from the start). > >Anders > >>=20 >> Victor >>=20 >>> Hi all, >>> >>> While our ADs are sorting out the chairing issues, I wanted to=20 >>> solicit input for the Dallas IETF meeting. I was thinking of=20 >>> summarizing some of the outstanding Diameter Base open=20 >issues (if you=20 >>> have any, send them to the mailing list!). Also, discussion of the=20 >>> upcoming Interop event, Diameter test plans, Diameter MIPv6 work,=20 >>> Diameter QoS working would all be good topics. Speak up if=20 >you have any topics you wish to discuss. >>> >>> John >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >>> =20 >>> >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >>=20 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 18 21:36:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKnmX-0000pd-Lq; Sat, 18 Mar 2006 21:36:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKnmW-0000pY-Ca for dime@ietf.org; Sat, 18 Mar 2006 21:36:36 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKnmU-0001Xs-Vf for dime@ietf.org; Sat, 18 Mar 2006 21:36:36 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2006 21:36:35 -0500 X-IronPort-AV: i="4.03,107,1141621200"; d="scan'208"; a="84450233:sNHT34551704" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2J2aYWc018655; Sat, 18 Mar 2006 21:36:34 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Mar 2006 21:36:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS Application Date: Sat, 18 Mar 2006 21:36:30 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6015B4994@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Application Thread-Index: AcY924uALAkCHBETRayAeauSegHe0QM5H/uwAA9vFIA= From: "Greg Weber \(gdweber\)" To: , X-OriginalArrivalTime: 19 Mar 2006 02:36:34.0273 (UTC) FILETIME=[F0244D10:01C64AFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org =20 > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: Saturday, March 18, 2006 2:15 PM > To: hannes.tschofenig@siemens.com; dime@ietf.org > Subject: RE: [Dime] Diameter QoS Application >=20 > In advance of the meeting, I'd like to put out a call - who is > interested > in QoS support in Diameter (not just this document, but in general)? >=20 > Would anyone have cycles to review this and give input? I'm interested in this work and can review the draft. Greg >=20 > thanks, > John=20 >=20 > >-----Original Message----- > >From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > >Sent: 02 March, 2006 11:33 > >To: dime@ietf.org > >Subject: [Dime] Diameter QoS Application > > > >Hi all,=20 > > > >we have resubmitted our Diameter QoS application draft to the=20 > >DIME working group.=20 > > > >Here is the new draft version: Diameter Quality of Service=20 > Application > > > >Abstract > > > > This document describes a Diameter application that performs > > Authentication, Authorization, and Accounting for Quality=20 > of Service > > (QoS) reservations. This protocol is used by elements=20 > >along the path > > of a given application flow to authenticate a reservation request, > > ensure that the reservation is authorized, and to account for > > resources consumed during the lifetime of the application flow. > > Clients that implement the Diameter QoS application contact an > > authorizing entity/application server that is located somewhere in > > the network, allowing for a wide variety of flexible deployment > > models. > > > >http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-diameter > >-qos-00.t > >xt > > > >This version of the draft is based on=20 > >draft-alfano-aaa-qosprot-05.txt and contains feedback we=20 > >received by John, Robert Hancock and Jerry Ash. > >The issue tracker of this document can be found at: > >http://www.tschofenig.priv.at:8080/diameter-qos/index > > > >Ciao > >Hannes > > > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 18 21:37:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKnno-0001UO-UL; Sat, 18 Mar 2006 21:37:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKnnn-0001UJ-4a for dime@ietf.org; Sat, 18 Mar 2006 21:37:55 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKnnl-0001Yl-Rr for dime@ietf.org; Sat, 18 Mar 2006 21:37:55 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k2J2bmCj062579; Sat, 18 Mar 2006 21:37:49 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <441CC3FE.1000700@tari.toshiba.com> Date: Sat, 18 Mar 2006 21:37:50 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: trailing [*fixed] section in messages [was: Re: [Dime] DiME WG meeting in Dallas] References: <1AA39B75171A7144A73216AED1D7478D0186A03A@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A03A@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > Someone want to propose a simplified format? We could add that > to the issues list. My proposal is a minor change to remove the trailing [*fixed] avps in Sec. 3.2. The diameter-message ABNF will change from: "diameter-message = header [ *fixed] [ *required] [ *optional] [ *fixed]" to "diameter-message = header [ *fixed] [ *required] [ *optional]" regards, victor > > John > >> -----Original Message----- >> From: ext Anders Kristensen [mailto:andersk@cisco.com] >> Sent: 01 March, 2006 18:00 >> To: Victor Fajardo >> Cc: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org >> Subject: trailing [*fixed] section in messages [was: Re: >> [Dime] DiME WG meeting in Dallas] >> >> (going through old email) >> >> Victor Fajardo wrote: >> >>> Hi, >>> >>> I'd like to post a question regarding the trailing [*fixed] >> >> avp set of >> >>> diameter-message ABNF in Sec 3.2 of the base proto (where: >>> diameter-message = header [*fixed] [*required] [*optional] >> >> [*fixed]). >> >>> I'm not familiar with the history of this layout but in which >>> scenario(s) are trailing fixed avps used ? So far appending of >>> trailing avps are most relevant to proxies and relays but >>> route-records and proxy-info are normally tagged as optional as they >>> should be. And at the moment, there does'nt seem to be any >> >> application >> >>> defining a trailing fixed avp. Maybe this format can be >> >> relaxed to help simplify parsing. >> >> I also don't know the reason this was put in but I agree that >> it doesn't seem very useful. Presumably the reason for the >> first [*fixed] section is that having certain AVPs appear >> early can help allow implementations that are interested only >> in these specific AVPs to not have to parse or skip over other >> AVPs. This reason cannot apply to fixed AVPs at the end of >> messages as one cannot parse from the end (no way of telling >> where the last AVP started without making one's way from the start). >> >> Anders >> >>> Victor >>> >>>> Hi all, >>>> >>>> While our ADs are sorting out the chairing issues, I wanted to >>>> solicit input for the Dallas IETF meeting. I was thinking of >>>> summarizing some of the outstanding Diameter Base open >>> >> issues (if you >> >>>> have any, send them to the mailing list!). Also, discussion of the >>>> upcoming Interop event, Diameter test plans, Diameter MIPv6 work, >>>> Diameter QoS working would all be good topics. Speak up if >>> >> you have any topics you wish to discuss. >> >>>> John >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 18 22:32:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKoeV-0005ZK-2u; Sat, 18 Mar 2006 22:32:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKoeT-0005LK-LW for dime@ietf.org; Sat, 18 Mar 2006 22:32:21 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKoeT-0003Br-Bp for dime@ietf.org; Sat, 18 Mar 2006 22:32:21 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k2J3WEXg062700; Sat, 18 Mar 2006 22:32:15 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <441CD0C0.5050701@tari.toshiba.com> Date: Sat, 18 Mar 2006 22:32:16 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Dime] CER/CEA on an open connection References: <1AA39B75171A7144A73216AED1D7478D0186A034@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A034@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > Comments inline: > Hmm, it seems to me that if we have to fix the state machine, that > might be a significant change as it would affect people > implementations. Would specifying the renegotiation be something > that people are interested in? It seems renegotiation has a valid point. To minimize the change in current implementations maybe we can add text that describes optional(??) functionality: 1. limiting scope of renegotiation to app id support 2. sender of the cer wishes to add or remove app support with peer. if removal of an app results in no common app, the connection should be closed. This event need not be represented in the fsm since 2nd paragraph in sec 5.3 already describes the behavior. 3. current stateful session affected by a removable will remain active until the session or the application itself ends. also applies to proxies. does not apply to stateless sessions, proxies or relays. hope this is helpful. regards, victor > > John > > > Hi Anders, > > I think there is a valid need for re-advertising capabilities. > Applications may come and go over time. So this gives a means > for an application to join an existing connection without having > to bring it down and disrupt other applications that might already > be using that connection. But I think the questions you raised > are valid with regard to the definition of this renegotiation. > > It is subtle, but renegotiation is really defining an additional > state in the state machine. If a CER is sent on an already > negotiated connection, you have entered a new > "Open-but-waiting_CEA" state. The questions that you raise should > be addressed in that new state. > > I think it is a good function, but agree that it needs to be > better defined. > > Best Regards, > Timothy Smith > > tjsmith@us.ibm.com > (919) 254-4723 > > > > *Anders Kristensen * > > 03/13/2006 09:49 AM > > > To > dime@ietf.org > cc > > Subject > [Dime] CER/CEA on an open connection > > > > > > > > > > In its description of the peer state machine RFC 3588 goes out of its > way to allow CER requests on an already open connection (section > 5.6). > Is the intention that either party can re-advertise its set of > capabilities at any time? This raises some questions. For example, if > TLS was not listed as supported in the first CER/CEA but is now, > is it > possible to carry out a TLS handshake after the exchange of > non-CER/CEA > traffic? What if no response is received for a "non-initial" CER (but > other traffic, including DWR/DEA, continues to be exchanged), > should the > connection be reset? > > I wonder if the ability to exchange capabilities on an open > connection > is widely supported and whether it is really useful enough to > warrant it > being part of the spec. Should probably be part of the base protocol > test suite if it is. > > Anders > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > >------------------------------------------------------------------------ > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Mar 19 08:18:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKxnR-0001YZ-Is; Sun, 19 Mar 2006 08:18:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKxnQ-0001YU-Bk for dime@ietf.org; Sun, 19 Mar 2006 08:18:12 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKxnO-0002D6-RE for dime@ietf.org; Sun, 19 Mar 2006 08:18:12 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JDI8bi025821 for ; Sun, 19 Mar 2006 15:18:09 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 15:18:05 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 15:18:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Need your presentations: [Dime] DiME WG Agenda updated Date: Sun, 19 Mar 2006 15:18:04 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A040@esebe100.NOE.Nokia.com> In-Reply-To: <4419D98B.3050608@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need your presentations: [Dime] DiME WG Agenda updated Thread-Index: AcZJQT30S0JEmMsVRTq+qUpkQC/M9QCFf2zA From: To: X-OriginalArrivalTime: 19 Mar 2006 13:18:04.0592 (UTC) FILETIME=[8E28E300:01C64B57] X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, I need your presentations by Monday night, so that I can post them prior to the meeting. Also, I need to have a note taker and jabber scribe. I figure many of you will take notes anyway, so please volunteer to be the minute taker. thanks, John >>DiME Working Group >> >>TUESDAY, March 21, 2006 >>1740-1840 Afternoon Session III=20 >>Room: Cortez AB =20 >> >>DiME WG update - Chairs - 5 Minutes >> >>Diameter Interop Event - Chairs - 5 minutes >> >>Interop Test plans - TBD - 10 mintues >>http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite-00 .txt >> >>Diameter API - TBD - 10 minutes >>http://tools.ietf.org/wg/dime/draft-ietf-dime-diameter-api/draft-ietf- dime-diameter-api-00.txt >> >>Diameter MIPv6 - TBD - 10 minutes >>http://tools.ietf.org/wg/dime/draft-tschofenig-dime-mip6-integrated-00 .txt >>http://tools.ietf.org/wg/dime/draft-tschofenig-dime-mip6-split-01.txt >> >>Diameter QoS - TBD - 10 minutes >>http://tools.ietf.org/wg/dime/draft-tschofenig-dime-diameter-qos-00.tx t >>http://tools.ietf.org/wg/radext/draft-tschofenig-radext-qos-02.txt >> >>Diameter-RADIUS interworking - TBD - 10 minutes >>http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas- 01.txt >> >>RFC3588 updating discussion - all - remaining time. >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www1.ietf.org/mailman/listinfo/dime >> >> >> >> =20 >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Mar 19 11:25:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0j5-0008AL-Nt; Sun, 19 Mar 2006 11:25:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0j4-0008AG-Db for dime@ietf.org; Sun, 19 Mar 2006 11:25:54 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0j4-0008Ho-3w for dime@ietf.org; Sun, 19 Mar 2006 11:25:54 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Mar 2006 08:25:54 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,107,1141632000"; d="scan'208"; a="23945948:sNHT25372812" Received: from [10.86.240.153] (che-vpn-cluster-1-153.cisco.com [10.86.240.153]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2JGPqVU012929; Sun, 19 Mar 2006 11:25:53 -0500 (EST) Message-ID: <441D860F.1060404@cisco.com> Date: Sun, 19 Mar 2006 11:25:51 -0500 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] CER/CEA on an open connection References: <1AA39B75171A7144A73216AED1D7478D0186A034@esebe100.NOE.Nokia.com> <441CD0C0.5050701@tari.toshiba.com> In-Reply-To: <441CD0C0.5050701@tari.toshiba.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org A simple alternative to renegotiation would be for nodes to terminate and reestablish connections. Not desirable but given that this is probably a rarely needed feature perhaps it could be acceptable. OTOH, if renegotiation is limited to changing supported applications as proposed by Victor and Timothy, then that seems manageable. More inline... Victor Fajardo wrote: >> > > > Comments inline: > >> Hmm, it seems to me that if we have to fix the state machine, that >> might be a significant change as it would affect people >> implementations. Would specifying the renegotiation be something >> that people are interested in? > > > It seems renegotiation has a valid point. To minimize the change in > current implementations maybe we can add text that describes > optional(??) functionality: > > 1. limiting scope of renegotiation to app id support > 2. sender of the cer wishes to add or remove app support with peer. if > removal of an app results in no common app, the connection should be > closed. This event need not be represented in the fsm since 2nd > paragraph in sec 5.3 already describes the behavior. I think that in this case the guy removing support for the one shared app should not send the CER but instead just terminate the connection. (Possibly sending new Disconnect-Cause, say NO_SHARED_APP.) > 3. current stateful session affected by a removable will remain active > until the session or the application itself ends. also applies to > proxies. does not apply to stateless sessions, proxies or relays. We might want to specify a new non-2xxx result-code that the recipient of an invalid "subsequent" CER can respond with. Invalid here meaning that the CER differs from the CER/CEA originally sent by the peer in aspects other than supported applications, e.g. different security or different Origin-Host/Origin-Realm values. Of course the CER can be rejected for other reasons, e.g. missing or illegal AVPs etc. We'll have to determine what happens with the connection in the case where the CER is rejected. One option is to say that it stays open in the state it was in prior to the failed CER. Both parties are then free to terminate it themselves if they feel like it. Anders > > hope this is helpful. regards, > victor > > >> >> John >> >> >> Hi Anders, >> >> I think there is a valid need for re-advertising capabilities. >> Applications may come and go over time. So this gives a means >> for an application to join an existing connection without having >> to bring it down and disrupt other applications that might already >> be using that connection. But I think the questions you raised >> are valid with regard to the definition of this renegotiation. >> >> It is subtle, but renegotiation is really defining an additional >> state in the state machine. If a CER is sent on an already >> negotiated connection, you have entered a new >> "Open-but-waiting_CEA" state. The questions that you raise should >> be addressed in that new state. >> >> I think it is a good function, but agree that it needs to be >> better defined. >> >> Best Regards, >> Timothy Smith >> >> tjsmith@us.ibm.com >> (919) 254-4723 >> >> >> >> *Anders Kristensen * >> >> 03/13/2006 09:49 AM >> >> >> To >> dime@ietf.org >> cc >> >> Subject >> [Dime] CER/CEA on an open connection >> >> >> >> >> >> >> >> >> >> In its description of the peer state machine RFC 3588 goes out of its >> way to allow CER requests on an already open connection (section >> 5.6). >> Is the intention that either party can re-advertise its set of >> capabilities at any time? This raises some questions. For example, if >> TLS was not listed as supported in the first CER/CEA but is now, >> is it >> possible to carry out a TLS handshake after the exchange of >> non-CER/CEA >> traffic? What if no response is received for a "non-initial" CER (but >> other traffic, including DWR/DEA, continues to be exchanged), >> should the >> connection be reset? >> >> I wonder if the ability to exchange capabilities on an open >> connection >> is widely supported and whether it is really useful enough to >> warrant it >> being part of the spec. Should probably be part of the base protocol >> test suite if it is. >> >> Anders >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 20 09:00:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKvk-0007rS-Pg; Mon, 20 Mar 2006 09:00:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKvc-0007nc-Ug for dime@ietf.org; Mon, 20 Mar 2006 09:00:13 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLKvX-0002wC-Df for dime@ietf.org; Mon, 20 Mar 2006 09:00:10 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 26ECDCF2B5 for ; Mon, 20 Mar 2006 09:00:06 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k2KE04oB015616 for ; Mon, 20 Mar 2006 09:00:05 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Mon, 20 Mar 2006 08:39:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <441D860F.1060404@cisco.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Comments inline. > -----Original Message----- > From: Anders Kristensen [mailto:andersk@cisco.com] > Sent: Sunday, March 19, 2006 11:26 AM > To: Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > A simple alternative to renegotiation would be for nodes to terminate > and reestablish connections. Not desirable but given that this is > probably a rarely needed feature perhaps it could be acceptable. [TOLGA]This IMO is a nice solution. That type of capability may really be usefull for cases where messages are exchanged between two nodes for different application types. That one application goes down/comes up should not affect the message exchange for the other application application. OTOH, one also could argue that for multiple application support, nodes could be visible with different Diameter identities, but to provide a decent solution for the generic case, I would think renegotiation of supported application is important. [..snip..] > > 3. current stateful session affected by a removable will remain active > > until the session or the application itself ends. also applies to > > proxies. does not apply to stateless sessions, proxies or relays. [TOLGA]That type of graceful shutdown could be useful but I am not sure whether it is equivalent to advertising application support. I can see that both type of operations may be usefull: a) Application logic is down -for some reason-, there is no way of continuing existing sessions. b) Application will be put down for maintainence. One would like to have a graceful shutdown. For a), I would expect DIAMETER_APPLICATION_UNSUPPORTED to be returned for incoming messages for that application type. It still would be good to send a CER, where the unavailability of the appllication is implied. For b), CER could be used but I would think it is a good idea to have a new AVP for it, e.g. Application-Shutdown ::= < AVP Header XYZ > *[ Auth-Application-Id ] *[ Acct-Application-Id ] *[Vendor-Specific-Application-Id ] This would allow us to distinguish clearly between immediate and graceful shutdown cases. BTW, I hope we also can do something about consolidating Application-Id AVPs in the future -I mean generally-. > > We might want to specify a new non-2xxx result-code that the recipient > of an invalid "subsequent" CER can respond with. Invalid here meaning > that the CER differs from the CER/CEA originally sent by the peer in > aspects other than supported applications, e.g. different security or > different Origin-Host/Origin-Realm values. Of course the CER can be > rejected for other reasons, e.g. missing or illegal AVPs etc. > > We'll have to determine what happens with the connection in the case > where the CER is rejected. One option is to say that it stays open in > the state it was in prior to the failed CER. Both parties are then free > to terminate it themselves if they feel like it. > > Anders > > > > > hope this is helpful. regards, > > victor > > > > > >> > >> John > >> > >> > >> Hi Anders, > >> > >> I think there is a valid need for re-advertising capabilities. > >> Applications may come and go over time. So this gives a means > >> for an application to join an existing connection without having > >> to bring it down and disrupt other applications that might already > >> be using that connection. But I think the questions you raised > >> are valid with regard to the definition of this renegotiation. > >> > >> It is subtle, but renegotiation is really defining an additional > >> state in the state machine. If a CER is sent on an already > >> negotiated connection, you have entered a new > >> "Open-but-waiting_CEA" state. The questions that you raise should > >> be addressed in that new state. > >> > >> I think it is a good function, but agree that it needs to be > >> better defined. > >> > >> Best Regards, > >> Timothy Smith > >> > >> tjsmith@us.ibm.com > >> (919) 254-4723 > >> > >> > >> > >> *Anders Kristensen * > >> > >> 03/13/2006 09:49 AM > >> > >> > >> To > >> dime@ietf.org > >> cc > >> > >> Subject > >> [Dime] CER/CEA on an open connection > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> In its description of the peer state machine RFC 3588 goes > out of its > >> way to allow CER requests on an already open connection (section > >> 5.6). > >> Is the intention that either party can re-advertise its set of > >> capabilities at any time? This raises some questions. For > example, if > >> TLS was not listed as supported in the first CER/CEA but is now, > >> is it > >> possible to carry out a TLS handshake after the exchange of > >> non-CER/CEA > >> traffic? What if no response is received for a > "non-initial" CER (but > >> other traffic, including DWR/DEA, continues to be exchanged), > >> should the > >> connection be reset? > >> > >> I wonder if the ability to exchange capabilities on an open > >> connection > >> is widely supported and whether it is really useful enough to > >> warrant it > >> being part of the spec. Should probably be part of the > base protocol > >> test suite if it is. > >> > >> Anders > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > >> > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 20 09:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLNc-0000Mp-NS; Mon, 20 Mar 2006 09:29:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLNb-0000LN-Pk for dime@ietf.org; Mon, 20 Mar 2006 09:29:07 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLNb-0003td-I9 for dime@ietf.org; Mon, 20 Mar 2006 09:29:07 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k2KET2np067195; Mon, 20 Mar 2006 09:29:02 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <441EBC2F.8060300@tari.toshiba.com> Date: Mon, 20 Mar 2006 09:29:03 -0500 From: Victor Fajardo User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Kristensen Subject: Re: [Dime] CER/CEA on an open connection References: <1AA39B75171A7144A73216AED1D7478D0186A034@esebe100.NOE.Nokia.com> <441CD0C0.5050701@tari.toshiba.com> <441D860F.1060404@cisco.com> In-Reply-To: <441D860F.1060404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Comments inline: > A simple alternative to renegotiation would be for nodes to terminate > and reestablish connections. Not desirable but given that this is > probably a rarely needed feature perhaps it could be acceptable. this has less impact to existing implementations but a bit disruptive. >> >> It seems renegotiation has a valid point. To minimize the change in >> current implementations maybe we can add text that describes >> optional(??) functionality: >> >> 1. limiting scope of renegotiation to app id support >> 2. sender of the cer wishes to add or remove app support with peer. >> if removal of an app results in no common app, the connection should >> be closed. This event need not be represented in the fsm since 2nd >> paragraph in sec 5.3 already describes the behavior. > > > I think that in this case the guy removing support for the one shared > app should not send the CER but instead just terminate the connection. > (Possibly sending new Disconnect-Cause, say NO_SHARED_APP.) i agree. > >> 3. current stateful session affected by a removable will remain >> active until the session or the application itself ends. also applies >> to proxies. does not apply to stateless sessions, proxies or relays. > > > We might want to specify a new non-2xxx result-code that the recipient > of an invalid "subsequent" CER can respond with. Invalid here meaning > that the CER differs from the CER/CEA originally sent by the peer in > aspects other than supported applications, e.g. different security or > different Origin-Host/Origin-Realm values. Of course the CER can be > rejected for other reasons, e.g. missing or illegal AVPs etc. i agree. i'm leaning more towards an error condition regarding differing origin-host/realm for subsequent CER. > > We'll have to determine what happens with the connection in the case > where the CER is rejected. One option is to say that it stays open in > the state it was in prior to the failed CER. Both parties are then > free to terminate it themselves if they feel like it. should we add a stricter behavior to this scenario ? we may leave a routing hole if the sender of the CER can no longer maintain an application it wishes to remove even if the opposing peer cannot comply (CEA with error code). The oppsing peer may think that the other peer still supports that app since the connection is still open. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 20 10:01:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLtP-0002xF-69; Mon, 20 Mar 2006 10:01:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLtO-0002x1-3s for dime@ietf.org; Mon, 20 Mar 2006 10:01:58 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLtM-0005aF-MI for dime@ietf.org; Mon, 20 Mar 2006 10:01:58 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2KF1msP000416; Mon, 20 Mar 2006 17:01:53 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 17:01:47 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 17:01:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Mar 2006 17:01:47 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A066@esebe100.NOE.Nokia.com> In-Reply-To: <000001c64c16$4e615170$9005120a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: Diameter CM state machine Thread-Index: AcZMF+TSipdHqObxRROgvXWE309FrgAFv3+Q From: To: , X-OriginalArrivalTime: 20 Mar 2006 15:01:47.0532 (UTC) FILETIME=[35BBECC0:01C64C2F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Dime] RE: [AAA-WG]: Diameter CM state machine X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Rajith, You should join the DiME working group, this is where we will clarify Diameter behavior. http://www.ietf.org/html.charters/dime-charter.html John=20 >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]=20 >On Behalf Of ext Rajith R >Sent: 20 March, 2006 14:03 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Diameter CM state machine > > >Hi > I have some doubts about the DIAMETER state machine=20 >(sec 5.6 of RFC 3588): > >1. R-Open R-Rcv-CER R-Snd-CEA R-Open > =20 >I-Open I-Rcv-CER I-Snd-CEA I-Open > >What is the use of the state transition considerations above?=20 >Could any one tell me how after the peers have exchanged=20 >CER-CEA (& thus moving to the open state) can receive a CER again? > >2. For the above 2 transitions, if the received CER has some=20 >protocol error, what should be the behaviour? Ignore / only=20 >send error CEA / send error CEA & close connection? > >Regards > >Rajith > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 21 10:30:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLioT-0006sT-HF; Tue, 21 Mar 2006 10:30:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLioR-0006pe-Fk for dime@ietf.org; Tue, 21 Mar 2006 10:30:23 -0500 Received: from mail.digitalroute.se ([213.142.6.23] helo=harmonica.digitalroute.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLioQ-00044E-0O for dime@ietf.org; Tue, 21 Mar 2006 10:30:23 -0500 Received: from [10.0.0.108] ([10.0.0.108]) by harmonica.digitalroute.se (8.12.8/8.12.8) with ESMTP id k2LFUKaM021843 for ; Tue, 21 Mar 2006 16:30:21 +0100 Message-ID: <44201BD6.9060008@digitalroute.com> Date: Tue, 21 Mar 2006 16:29:26 +0100 From: Andreas Fredriksson Organization: Digital Route AB User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Dime] CEA and the error bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi list, I think the status of CER/CEA and the use of the error bit is unclear in the Base RFC. What rules apply when a CER message cannot be decoded on the receiving end? Is sending a CEA with the error bit set a valid option, or should a proper CEA be produced with the ResultCode AVP set to some specific value? I've had this happen when interacting with various systems and currently we're unclear on how to handle the situation. Best regards, Andreas -- Andreas Fredriksson Software Engineer, Digital Route _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 21 10:58:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjFB-0006Wg-FI; Tue, 21 Mar 2006 10:58:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjFA-0006Vm-4N for dime@ietf.org; Tue, 21 Mar 2006 10:58:00 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjF8-0005GA-Pa for dime@ietf.org; Tue, 21 Mar 2006 10:58:00 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 1239306BF0 for ; Tue, 21 Mar 2006 10:57:58 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k2LFvu1f004907 for ; Tue, 21 Mar 2006 10:57:57 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] CEA and the error bit Date: Tue, 21 Mar 2006 10:37:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44201BD6.9060008@digitalroute.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Wouldn't following the generic error generating rules be sufficient, i.e. E-bit set for protocol errors, and adding Result-Code AVP and Failed-AVP AVP as applicable ? > -----Original Message----- > From: Andreas Fredriksson [mailto:andreas.fredriksson@digitalroute.com] > Sent: Tuesday, March 21, 2006 10:29 AM > To: dime@ietf.org > Subject: [Dime] CEA and the error bit > > > > Hi list, > > I think the status of CER/CEA and the use of the error bit is unclear in > the Base RFC. > > What rules apply when a CER message cannot be decoded on the receiving > end? Is sending a CEA with the error bit set a valid option, or should a > proper CEA be produced with the ResultCode AVP set to some specific value? > > I've had this happen when interacting with various systems and currently > we're unclear on how to handle the situation. > > Best regards, > Andreas > > -- > Andreas Fredriksson > Software Engineer, Digital Route > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 21 12:22:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkYt-0007wN-Oi; Tue, 21 Mar 2006 12:22:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkYs-0007wI-BK for dime@ietf.org; Tue, 21 Mar 2006 12:22:26 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkYq-0000Oj-TU for dime@ietf.org; Tue, 21 Mar 2006 12:22:26 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2LHMKWX016447 for ; Tue, 21 Mar 2006 19:22:24 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 19:22:19 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 19:22:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 19:22:19 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A0A4@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: remote participation & meeting material Thread-Index: AcZMWxB325D+G90ZTA61DuQZfz3VZQAsK+Iw From: To: X-OriginalArrivalTime: 21 Mar 2006 17:22:19.0621 (UTC) FILETIME=[02105950:01C64D0C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Dime] remote participation & meeting material X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Folks- I think this is a summary of the key information that remote folks will need to participate in today's meeting. Audio feed: http://videolab.uoregon.edu/events/ietf/ Jabber: HOST: rooms.jabber.ietf.org ROOM: dime Slides: =09 https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 5 John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 21 17:33:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpPc-0006WP-TI; Tue, 21 Mar 2006 17:33:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpPb-0006Vf-53 for dime@ietf.org; Tue, 21 Mar 2006 17:33:11 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLodc-0004Yr-9G for dime@ietf.org; Tue, 21 Mar 2006 16:43:36 -0500 Received: from bender-mail.tigertech.net ([64.62.209.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLoQT-0005kA-If for dime@ietf.org; Tue, 21 Mar 2006 16:30:05 -0500 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id CAA971CD8519 for ; Tue, 21 Mar 2006 13:29:59 -0800 (PST) Received: from [10.21.121.29] (sj-natpool-220.cisco.com [128.107.248.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id A63211CD82AA for ; Tue, 21 Mar 2006 13:29:57 -0800 (PST) Message-ID: <44207004.7060004@frascone.com> Date: Tue, 21 Mar 2006 15:28:36 -0600 From: David Frascone User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: X-Spam-Score: -2.6 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Dime] Diameter XML Dictionary draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org An updated version of the Diameter XML dictionary is now available at http://www.diameter.org/drafts/latest/draft-ietf-dime-xml-dictionary-00.txt I will submit this new version next week. The current revision had some editorial changes: 1) DTD snipets in the draft were removed. (They are still described, but the DTD is now in one place) 2) Other misc. nits were fixed. 3) Document was moved from aaa -> dime. 4) Source is now in xml instead of nroff (You don't care, but the authors are happy about it) -Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 21 17:42:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpYW-0004CR-QW; Tue, 21 Mar 2006 17:42:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpYV-0004CJ-9e; Tue, 21 Mar 2006 17:42:23 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpYU-0007sQ-KV; Tue, 21 Mar 2006 17:42:23 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k2LMgL9S029592; Tue, 21 Mar 2006 23:42:21 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k2LMgLTD012406; Tue, 21 Mar 2006 23:42:21 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 23:42:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 23:42:19 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: NSIS, Diameter & QoS Thread-Index: AcZNN++8ufsCnpHFTOqCiVbuki7/CQAAInXg From: "Tschofenig, Hannes" To: "Robert Hancock" , X-OriginalArrivalTime: 21 Mar 2006 22:42:21.0338 (UTC) FILETIME=[B72DD7A0:01C64D38] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: nsis Subject: [Dime] AW: [NSIS] RE: NSIS, Diameter & QoS X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Thank you Robert for your feedback.=20 For those who haven't followed the discussion on the Diameter QoS work: = Robert has provided a lot of feedback in the past. Some of his comments = are still subject for further discussion.=20 See http://www.tschofenig.priv.at:8080/diameter-qos/ Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 > Gesendet: Dienstag, 21. M=E4rz 2006 16:36 > An: dime@ietf.org > Cc: 'nsis' > Betreff: [NSIS] RE: NSIS, Diameter & QoS >=20 > hi, >=20 > to answer the question the other way round, I am interested in > AAA support for QoS authorisation. authorisation for differential > access to resources is a key part of the QoS story, and to me it > is a major deployment simplification if that authorisation can be > built as an extension to existing AAA infrastructures. >=20 > in other words, if QoS and AAA make sense individually, it makes > sense to define their interaction. >=20 > i have cycles and can provide input (proof: i have already done so). >=20 > r. >=20 >=20 > > In advance of the meeting, I'd like to put out a call - who is > > interested > > in QoS support in Diameter (not just this document, but in general)? >=20 > > Would anyone have cycles to review this and give input? >=20 > > thanks, > > John=20 >=20 > >-----Original Message----- > >From: ext Tschofenig, Hannes [mailto:hannes.tschofenig at=20 > siemens.com]=20 > >Sent: 02 March, 2006 11:33 > >To: dime at ietf.org > >Subject: [Dime] Diameter QoS Application > > > >Hi all,=20 > > > >we have resubmitted our Diameter QoS application draft to the=20 > >DIME working group.=20 > > > >Here is the new draft version: Diameter Quality of Service=20 > Application > > > >Abstract > > > > This document describes a Diameter application that performs > > Authentication, Authorization, and Accounting for Quality=20 > of Service > > (QoS) reservations. This protocol is used by elements=20 > >along the path > > of a given application flow to authenticate a reservation request, > > ensure that the reservation is authorized, and to account for > > resources consumed during the lifetime of the application flow. > > Clients that implement the Diameter QoS application contact an > > authorizing entity/application server that is located somewhere in > > the network, allowing for a wide variety of flexible deployment > > models. > > > >http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-diameter > >-qos-00.t > >xt > > > >This version of the draft is based on=20 > >draft-alfano-aaa-qosprot-05.txt and contains feedback we=20 > >received by John, Robert Hancock and Jerry Ash. > >The issue tracker of this document can be found at: > >http://www.tschofenig.priv.at:8080/diameter-qos/index > > > >Ciao > >Hannes > > > >_______________________________________________ > >DiME mailing list > >DiME at ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME at ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 >=20 >=20 > * References: >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 21 17:44:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpaG-0005Bt-J1; Tue, 21 Mar 2006 17:44:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpSu-0000BG-P5; Tue, 21 Mar 2006 17:36:36 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpSt-0007hk-5w; Tue, 21 Mar 2006 17:36:36 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2LMaRti007307; Tue, 21 Mar 2006 22:36:27 GMT Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 22:36:27 +0000 From: "Robert Hancock" To: Date: Tue, 21 Mar 2006 16:36:25 -0600 Message-ID: <001501c64d37$e3d190e0$73848182@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-OriginalArrivalTime: 21 Mar 2006 22:36:27.0692 (UTC) FILETIME=[E463BEC0:01C64D37] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Tue, 21 Mar 2006 17:44:11 -0500 Cc: 'nsis' Subject: [Dime] RE: NSIS, Diameter & QoS X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org hi, to answer the question the other way round, I am interested in AAA support for QoS authorisation. authorisation for differential access to resources is a key part of the QoS story, and to me it is a major deployment simplification if that authorisation can be built as an extension to existing AAA infrastructures. in other words, if QoS and AAA make sense individually, it makes sense to define their interaction. i have cycles and can provide input (proof: i have already done so). r. > In advance of the meeting, I'd like to put out a call - who is > interested > in QoS support in Diameter (not just this document, but in general)? > Would anyone have cycles to review this and give input? > thanks, > John >-----Original Message----- >From: ext Tschofenig, Hannes [mailto:hannes.tschofenig at siemens.com] >Sent: 02 March, 2006 11:33 >To: dime at ietf.org >Subject: [Dime] Diameter QoS Application > >Hi all, > >we have resubmitted our Diameter QoS application draft to the >DIME working group. > >Here is the new draft version: Diameter Quality of Service Application > >Abstract > > This document describes a Diameter application that performs > Authentication, Authorization, and Accounting for Quality of Service > (QoS) reservations. This protocol is used by elements >along the path > of a given application flow to authenticate a reservation request, > ensure that the reservation is authorized, and to account for > resources consumed during the lifetime of the application flow. > Clients that implement the Diameter QoS application contact an > authorizing entity/application server that is located somewhere in > the network, allowing for a wide variety of flexible deployment > models. > >http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-diameter >-qos-00.t >xt > >This version of the draft is based on >draft-alfano-aaa-qosprot-05.txt and contains feedback we >received by John, Robert Hancock and Jerry Ash. >The issue tracker of this document can be found at: >http://www.tschofenig.priv.at:8080/diameter-qos/index > >Ciao >Hannes > >_______________________________________________ >DiME mailing list >DiME at ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME at ietf.org https://www1.ietf.org/mailman/listinfo/dime * References: _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 21 17:52:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpif-0000oI-SR; Tue, 21 Mar 2006 17:52:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpie-0000mL-Se for dime@ietf.org; Tue, 21 Mar 2006 17:52:52 -0500 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpid-000852-J1 for dime@ietf.org; Tue, 21 Mar 2006 17:52:52 -0500 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id A34B11CD8519; Tue, 21 Mar 2006 14:52:50 -0800 (PST) Received: from [10.21.113.211] (sj-natpool-220.cisco.com [128.107.248.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id A641B1CD8017; Tue, 21 Mar 2006 14:52:49 -0800 (PST) Message-ID: <44208371.6000908@frascone.com> Date: Tue, 21 Mar 2006 16:51:29 -0600 From: David Frascone User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Frascone Subject: Re: [Dime] Diameter XML Dictionary draft References: <44207004.7060004@frascone.com> In-Reply-To: <44207004.7060004@frascone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org FYI - The XML dictionary was created by a design team commissioned by the AAA working group. It was later dropped due to lack of time (or maybe lack of interest) I'm refreshing / reposting it to gague interest . . . So, please comment on whether you think it should be addressed by this working group. The authors are finished with it, but the working group (either one) has not had time to digest it. (I am *not* trying to start a WGLC :) -Dave David Frascone wrote: > > An updated version of the Diameter XML dictionary is now available at > http://www.diameter.org/drafts/latest/draft-ietf-dime-xml-dictionary-00.txt > > I will submit this new version next week. The current revision had some > editorial changes: > > 1) DTD snipets in the draft were removed. (They are still described, > but the DTD is now in one place) > 2) Other misc. nits were fixed. > 3) Document was moved from aaa -> dime. > 4) Source is now in xml instead of nroff (You don't care, but the > authors are happy about it) > > -Dave > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 22 03:21:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLyam-0001lt-AJ; Wed, 22 Mar 2006 03:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLyak-0001h3-Ja for dime@ietf.org; Wed, 22 Mar 2006 03:21:18 -0500 Received: from mail.digitalroute.se ([213.142.6.23] helo=harmonica.digitalroute.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLyaj-0004Xt-6T for dime@ietf.org; Wed, 22 Mar 2006 03:21:18 -0500 Received: from [10.0.0.108] ([10.0.0.108]) by harmonica.digitalroute.se (8.12.8/8.12.8) with ESMTP id k2M8LCaM015750; Wed, 22 Mar 2006 09:21:15 +0100 Message-ID: <442108C8.9020900@digitalroute.com> Date: Wed, 22 Mar 2006 09:20:24 +0100 From: Andreas Fredriksson Organization: Digital Route AB User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] CEA and the error bit References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tolga Asveren wrote: > Wouldn't following the generic error generating rules be sufficient, i.e. > E-bit set for protocol errors, and adding Result-Code AVP and Failed-AVP AVP > as applicable ? Tolga, this makes perfect sense, and I believe this is what we do. I can imagine that some state machine implementations could be confused to see a CEA with the error bit set (I've seen strange behavior a few times), but in general it makes sense. Thanks, Andreas -- Andreas Fredriksson Software Engineer, Digital Route _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 23 20:08:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FManQ-00061G-Dg; Thu, 23 Mar 2006 20:08:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FManP-00061B-KL for dime@ietf.org; Thu, 23 Mar 2006 20:08:55 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FManO-0003ut-74 for dime@ietf.org; Thu, 23 Mar 2006 20:08:55 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2O18ocY016890; Fri, 24 Mar 2006 03:08:53 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 03:08:50 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 03:08:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Mar 2006 03:08:49 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A0F0@esebe100.NOE.Nokia.com> In-Reply-To: <20060324011309.535C116CC1@mail.nitros9.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RADIUS to Diameter gateways & extended attributes Thread-Index: AcZO3yhVi7m5tZtvQ8KH/uvD3R7TOwAADOIw From: To: , X-OriginalArrivalTime: 24 Mar 2006 01:08:51.0364 (UTC) FILETIME=[8344DE40:01C64EDF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: dime@ietf.org, radiusext@ops.ietf.org Subject: [Dime] RE: RADIUS to Diameter gateways & extended attributes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, >David Mitton wrote: >> I'd like to hear from people that actually have such things, as we=20 >> didn't get very many responses in the Dime meeting room. I'll chase=20 >> that in a different thread. > > Knowing current D->R gateway practices would help, thanks. Could some people on the DiME mailing list point out anything? I know that 3GPP has some plans for such things. Maybe someone could explain what is happening in 3GPP or other SD0s? John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 23 22:52:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMdM8-00082B-LH; Thu, 23 Mar 2006 22:52:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMdM7-00081g-FU for dime@ietf.org; Thu, 23 Mar 2006 22:52:55 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMdM5-0001ZJ-Da for dime@ietf.org; Thu, 23 Mar 2006 22:52:55 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWM009HE5HXW3@szxga01-in.huawei.com> for dime@ietf.org; Fri, 24 Mar 2006 11:53:57 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWM0078G5HXZW@szxga01-in.huawei.com> for dime@ietf.org; Fri, 24 Mar 2006 11:53:57 +0800 (CST) Received: from IBM4307EA0CEF3 ([202.108.56.39]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWM004MI5LA8K@szxml02-in.huawei.com>; Fri, 24 Mar 2006 11:56:13 +0800 (CST) Date: Fri, 24 Mar 2006 11:42:28 +0800 From: Tina TSOU Subject: Re: [Dime] RE: RADIUS to Diameter gateways & extended attributes To: john.loughney@nokia.com, aland@ox.org, david@mitton.com Message-id: <004401c64ef5$07f94ad0$cb00a8c0@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1AA39B75171A7144A73216AED1D7478D0186A0F0@esebe100.NOE.Nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: dime@ietf.org, radiusext@ops.ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org 3GPP I-WLAN Tina ----- Original Message ----- From: To: ; Cc: ; Sent: Friday, March 24, 2006 9:08 AM Subject: [Dime] RE: RADIUS to Diameter gateways & extended attributes Hi all, >David Mitton wrote: >> I'd like to hear from people that actually have such things, as we >> didn't get very many responses in the Dime meeting room. I'll chase >> that in a different thread. > > Knowing current D->R gateway practices would help, thanks. Could some people on the DiME mailing list point out anything? I know that 3GPP has some plans for such things. Maybe someone could explain what is happening in 3GPP or other SD0s? John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 24 09:00:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmq4-0003aW-VD; Fri, 24 Mar 2006 09:00:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmpu-0003ZI-MK for dime@ietf.org; Fri, 24 Mar 2006 09:00:19 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMmpt-0000RC-89 for dime@ietf.org; Fri, 24 Mar 2006 09:00:18 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 15:00:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes Date: Fri, 24 Mar 2006 15:00:09 +0100 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03BFADAA@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: RADIUS to Diameter gateways & extended attributes Thread-Index: AcZO3yhVi7m5tZtvQ8KH/uvD3R7TOwAADOIwABm9dcA= From: To: , , X-OriginalArrivalTime: 24 Mar 2006 14:00:15.0209 (UTC) FILETIME=[46972590:01C64F4B] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: dime@ietf.org, radiusext@ops.ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, The 3GPP I-WLAN spec 29.234 is the only place in 3GPP scope that I remember that has D->R and R->D cases (on Wa and Wd interfaces). Currently the spec only says that the D->R and R->D cases are done according to the NASREQ and the Diam-EAP. In 3GPP I-WLAN point of view there are couple open issues under this topic: o how to provide Diameter's NAS-Filter-Rule also on RADIUS (current reference is to now splitted radext-ieee802 draft) o how to provide Diameter's request redirecting on RADIUS side (redirect-host etc + the functionality) Cheers, Jouni =20 > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: 24. maaliskuuta 2006 3:09 > To: aland@ox.org; david@mitton.com > Cc: dime@ietf.org; radiusext@ops.ietf.org > Subject: [Dime] RE: RADIUS to Diameter gateways & extended attributes=20 >=20 > Hi all, >=20 > >David Mitton wrote: > >> I'd like to hear from people that actually have such things, as we=20 > >> didn't get very many responses in the Dime meeting room. =20 > I'll chase=20 > >> that in a different thread. > > > > Knowing current D->R gateway practices would help, thanks. >=20 > Could some people on the DiME mailing list point out anything? I know > that 3GPP has some plans for such things. Maybe someone could explain > what is happening in 3GPP or other SD0s? >=20 > John >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 24 09:20:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMn91-0002g4-Vm; Fri, 24 Mar 2006 09:20:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMn91-0002fn-0z for dime@ietf.org; Fri, 24 Mar 2006 09:20:03 -0500 Received: from bay106-f26.bay106.hotmail.com ([65.54.161.36] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMn8z-0001Du-OP for dime@ietf.org; Fri, 24 Mar 2006 09:20:03 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 24 Mar 2006 06:20:00 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 24 Mar 2006 14:19:57 GMT X-Originating-IP: [130.129.129.224] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03BFADAA@SEHAN021MB.tcad.telia.se> From: "Bernard Aboba" To: jouni.korhonen@teliasonera.com, john.loughney@nokia.com, aland@ox.org, david@mitton.com Bcc: Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes Date: Fri, 24 Mar 2006 06:19:57 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Mar 2006 14:20:00.0861 (UTC) FILETIME=[094B48D0:01C64F4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: dime@ietf.org, radiusext@ops.ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > o how to provide Diameter's NAS-Filter-Rule also on RADIUS > (current reference is to now splitted radext-ieee802 draft) As we discussed in the RADEXT WG meeting, it seems to make sense to define a NAS-Filter-Rule attribute in RADIUS, in addition to the Filter-ID and NAS-Traffic-Rule attributes. However, only one of these attributes can be included in a single packet. > o how to provide Diameter's request redirecting on RADIUS side > (redirect-host etc + the functionality) I was unaware of this request. I think that satisfying it will be difficult since RADIUS (unlike Diameter) requires pre-set credentials and does not support DNS-based location of servers. Therefore redirection support alone will not make this work; it is necessary to enhance the RADIUS protocol substantially. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 24 11:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMosX-0005S1-Km; Fri, 24 Mar 2006 11:11:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMosW-0005Rr-St for dime@ietf.org; Fri, 24 Mar 2006 11:11:08 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMosV-0006KB-GS for dime@ietf.org; Fri, 24 Mar 2006 11:11:08 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 17:11:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes Date: Fri, 24 Mar 2006 17:11:01 +0100 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03BFADB4@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: RADIUS to Diameter gateways & extended attributes Thread-Index: AcZPTgr3lVZrqhFZTx2dtGV/E4mDrAABgofQ From: To: , , , X-OriginalArrivalTime: 24 Mar 2006 16:11:06.0360 (UTC) FILETIME=[8E3DB780:01C64F5D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dime@ietf.org, radiusext@ops.ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Bernand, > > o how to provide Diameter's request redirecting on RADIUS side > > (redirect-host etc + the functionality) >=20 > I was unaware of this request. I think that satisfying it=20 Hmm.. I think 3GPP has not asked RADEXT to do anything on request redirecting, mostly because of the reasons you pointed out below. It is just an open issue for 3GPP under the same topic and as far as I know it will also stay as their headache. However, I wouldn't mind having some documented guidelines or facts on this as I think 3GPP might not be the only SDO / entity having the same issue. > will be difficult=20 > since RADIUS (unlike Diameter) requires pre-set credentials=20 > and does not=20 > support DNS-based location of servers. Therefore=20 > redirection support alone=20 > will not make this work; it is necessary to enhance the=20 > RADIUS protocol=20 > substantially. Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 24 20:17:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMxPj-0004IV-Sw; Fri, 24 Mar 2006 20:17:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMxPi-0004IQ-0j for dime@ietf.org; Fri, 24 Mar 2006 20:17:58 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMxPg-0004RX-J8 for dime@ietf.org; Fri, 24 Mar 2006 20:17:58 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2P1Homo028686; Sat, 25 Mar 2006 03:17:50 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Mar 2006 03:17:49 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Mar 2006 03:17:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes Date: Sat, 25 Mar 2006 03:17:48 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A10E@esebe100.NOE.Nokia.com> In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03BFADB4@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: RADIUS to Diameter gateways & extended attributes Thread-Index: AcZPTgr3lVZrqhFZTx2dtGV/E4mDrAABgofQABVvd3A= From: To: , , , X-OriginalArrivalTime: 25 Mar 2006 01:17:49.0680 (UTC) FILETIME=[EE8B1F00:01C64FA9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dime@ietf.org, radiusext@ops.ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Jouni, >> > o how to provide Diameter's request redirecting on RADIUS side >> > (redirect-host etc + the functionality) >>=20 >> I was unaware of this request. I think that satisfying it > >Hmm.. I think 3GPP has not asked RADEXT to do anything on=20 >request redirecting, mostly because of the reasons you pointed out below. >It is just an open issue for 3GPP under the same topic and as=20 >far as I know it will also stay as their headache. > >However, I wouldn't mind having some documented guidelines or=20 >facts on this as I think 3GPP might not be the only SDO /=20 >entity having the same issue. > >> will be difficult >> since RADIUS (unlike Diameter) requires pre-set credentials and does not >> support DNS-based location of servers. Therefore redirection support alone >> will not make this work; it is necessary to enhance the RADIUS=20 >> protocol substantially. So, what is it that you want, in ways of guidelines - why it won't work? John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 27 15:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNyhI-0003ue-EO; Mon, 27 Mar 2006 15:52:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNygL-0002iZ-Mi for dime@ietf.org; Mon, 27 Mar 2006 15:51:22 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNygI-0000IT-8t for dime@ietf.org; Mon, 27 Mar 2006 15:51:21 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9BF5B6949C for ; Mon, 27 Mar 2006 15:51:17 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k2RKpGWg015882 for ; Mon, 27 Mar 2006 15:51:17 -0500 (EST) From: "Tolga Asveren" To: Date: Mon, 27 Mar 2006 15:30:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Dime] Cost of duplicate detection X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org We faced a few unconveniences while implementing duplicate detection as defined in RFC3588. A few weeks ago, I asked some questions to have a feeling how other people feel about duplicate detection in DIME WG. I think it could be more handy to have a reference when discussing about this issue, so I prepared a draft: http://www.ietf.org/internet-drafts/draft-asveren-dime-ansack-00.txt It tries to summarize the duplicate detection mechanism -as far as I underdstand- and describes some extension to the base protocol to make the whole duplicate detection processing less storage-intensive, but please consider it just as an example idea. AFAICS the problems are: a) Duplicate detection consumes too much memory on the server b) There is no deterministic/theoretically safe way to decide when to delete stored data for duplicate detection purposes c) Improvements based on estimates, e.g. assuming a maximum diameter network delay, still require considerable amount of memory and require extra computing, e.g. timestamping etc... I don't know whether anything can be improved at all, I am just exploring for now. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 28 03:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO9gh-0006oI-Pk; Tue, 28 Mar 2006 03:36:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO9gg-0006jt-Gh; Tue, 28 Mar 2006 03:36:26 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO9gf-0005zk-8H; Tue, 28 Mar 2006 03:36:26 -0500 Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2S8YvMl029960; Tue, 28 Mar 2006 03:34:57 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2S8XE3P015632; Tue, 28 Mar 2006 03:33:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Mar 2006 10:36:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME WG Chairs Thread-Index: AcZSQqp+aT9Cdy1CTKav2oeS2hODSA== From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: iesg@ietf.org Subject: [Dime] DIME WG Chairs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1735982907==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1735982907== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65242.B17ACAF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65242.B17ACAF8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following the round of interviews and discussions hold during the last ten days we reached the decision to nominate John Loughney and Hannes Tschofening as co-chairs of the DIME Working Group.=20 =20 We must mention that we had a very good set of candidates to chose from, and this makes us confident that this WG has good chances of reaching its proposed goals.=20 =20 We would like to congratulate Hannes and John and wish them good luck in filling in these positions. =20 Bert, David and Dan =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C65242.B17ACAF8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Following the round=20 of interviews and discussions hold during the last ten days we reached the decision = to=20 nominate John Loughney and Hannes=20 Tschofening as co-chairs of the DIME Working=20 Group. 
 
We must mention=20 that we had a very good set of candidates to chose from, and this makes = us=20 confident that this WG has good chances of reaching its proposed goals.=20
 
We = would like to=20 congratulate Hannes and = John and=20 wish them good luck in = filling in=20 these positions.
 
Bert, David and = Dan
 
 
 
 
 
 
------_=_NextPart_001_01C65242.B17ACAF8-- --===============1735982907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1735982907==-- From dime-bounces@ietf.org Wed Mar 29 12:04:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOe67-0000MF-DV; Wed, 29 Mar 2006 12:04:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOe66-0000M7-1x for dime@ietf.org; Wed, 29 Mar 2006 12:04:42 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOe63-0006gZ-Hi for dime@ietf.org; Wed, 29 Mar 2006 12:04:42 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id F734C80D9D for ; Wed, 29 Mar 2006 12:04:39 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k2TH4b6n015595 for ; Wed, 29 Mar 2006 12:04:38 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Cost of duplicate detection Date: Wed, 29 Mar 2006 11:43:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Due to the lack of responses, maybe I should first ask this question: Is there anybody out there which implemented duplicate detection as defined in RFC3588? Thanks, Tolga > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: Monday, March 27, 2006 3:30 PM > To: dime@ietf.org > Subject: [Dime] Cost of duplicate detection > > > We faced a few unconveniences while implementing duplicate detection as > defined in RFC3588. A few weeks ago, I asked some questions to have a > feeling how other people feel about duplicate detection in DIME > WG. I think > it could be more handy to have a reference when discussing about > this issue, > so I prepared a draft: > > http://www.ietf.org/internet-drafts/draft-asveren-dime-ansack-00.txt > > > It tries to summarize the duplicate detection mechanism -as far as I > underdstand- and describes some extension to the base protocol to make the > whole duplicate detection processing less storage-intensive, but please > consider it just as an example idea. > > AFAICS the problems are: > a) Duplicate detection consumes too much memory on the server > b) There is no deterministic/theoretically safe way to decide > when to delete > stored data for duplicate detection purposes > c) Improvements based on estimates, e.g. assuming a maximum > diameter network > delay, still require considerable amount of memory and require extra > computing, e.g. timestamping etc... > > I don't know whether anything can be improved at all, I am just exploring > for now. > > Thanks, > Tolga > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 30 04:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtAf-0004kc-Qr; Thu, 30 Mar 2006 04:10:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtAe-0004kM-9p for dime@ietf.org; Thu, 30 Mar 2006 04:10:24 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOtAc-0000wy-Fa for dime@ietf.org; Thu, 30 Mar 2006 04:10:24 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWX0015TNLU4F@szxga01-in.huawei.com> for dime@ietf.org; Thu, 30 Mar 2006 16:58:42 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWX001B4NLRS6@szxga01-in.huawei.com> for dime@ietf.org; Thu, 30 Mar 2006 16:58:42 +0800 (CST) Received: from huawei1515 ([10.18.5.144]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWX00HLAOEO87@szxml01-in.huawei.com> for dime@ietf.org; Thu, 30 Mar 2006 17:16:01 +0800 (CST) Date: Thu, 30 Mar 2006 14:28:54 +0530 From: Rajith R To: dime@ietf.org Message-id: <000001c653d8$2cb77620$9005120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Dime] Diameter error codes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Why is "DIAMETER_UNKNOWN_PEER 3010" considered as a protocol error where as "DIAMETER_NO_COMMON_APPLICATION 5010" is considered a permanent error? w.r.t the "CER/CEA in open state" thread, if applications may come & go, should not DIAMETER_NO_COMMON_APPLICATION be treated as a transient failure? Regards Rajith _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime