From vfajardo@tari.toshiba.com Wed Apr 1 09:17:13 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406063A6826 for ; Wed, 1 Apr 2009 09:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6s+-BIVqxJd for ; Wed, 1 Apr 2009 09:17:12 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 4BAD63A6AF0 for ; Wed, 1 Apr 2009 09:17:12 -0700 (PDT) Received: from [127.0.0.1] (ns.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n31GMPVh018038 for ; Wed, 1 Apr 2009 11:22:26 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49D393C2.8060200@tari.toshiba.com> Date: Wed, 01 Apr 2009 12:18:10 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:17:13 -0000 As noted in IETF74, there were concerns on incrementing the version number for rfc3588bis. The latest rev of the bis draft has the diameter header version number set to 2. The main reason for incrementing the version number are the following non-backward compatible fixes/changes in bis: * TLS negotiation are no longer done within the context of CER/CEA. TLS connectivity is now established prior to any diameter traffic via a well known port. * Capabilities exchange in the open state is no longer supported. The concerns folks have raised for incrementing the version number in bis are as follows (pls correct me if I mis-state some of these issues or if I miss some issues): * The version increment was very sudden and seems to have been done without much discussion. The current changes in bis can be classified into either clarifications and bug fixes (the changes above are included). Both types of changes does not warrant a version increment given that no new significant feature is being introduced beyond these two types. * The changes above that triggered discussion of version increment are considered critical "bug fixes" anyway. The fixes should be considered as "updates/patches" that would require code change regardless since it leaves certain features of the original 3588 broken, un-secure or inter-operable. An incremental approach is better: i.e., bis as a patch and a new separate document as 3588 version 2. * Some clarifications may require code changes for some vendors (although care was always been taken to advertised proposed solutions on the list so this should be rare) but the code changes would have been required anyway for successful interop. * If the version number is incremented, it would be unclear what RFC3588 state would be. Whether the new version would deprecate 3588 or it would be a completely separate branch/track that's very similar yet slightly different from 3588. It creates more ambigouity and does not seem to warrant a version increment as well. * Using bis to create a new revision of Diameter will open it up to addition of new features that can further delay publication of needed bug fixes and clarifications. A possible middle-ground is to keep to the intent of bis as a bug fixing instrument and keep bis as version 1. With regards to the changes above: * The version number in the diamter header may not help the TLS negotiation anyway because we only see the version number after the first diameter message. So a bis implementation and an original 3588 may not be able to inter operate regardless of whether the version number is reved-up. * The capabilities exchange in 3588 was never really clearly specified (only hinted on in the statemachine). One possible solution is to keep the open-state capabilities exchange in bis have it as a "NO OP" process just to make it backward compatible with 3588. Then make sure we state this is clearly stated and that we intend to rely on draft-zorn-dime-capablities-update-00.txt in the future. Other possible approaches are welcomed. Comments appreciated. regards, victor From lionel.morand@orange-ftgroup.com Wed Apr 1 14:52:09 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B50028C0FC for ; Wed, 1 Apr 2009 14:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmqDCROfW2Vp for ; Wed, 1 Apr 2009 14:52:08 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 953C93A6863 for ; Wed, 1 Apr 2009 14:52:07 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 23:52:05 +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 Date: Wed, 1 Apr 2009 23:52:00 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> In-Reply-To: <49D393C2.8060200@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] rfc3588bis version number Thread-Index: Acmy5XeHvC4F9+q4Q/+JCAJ/E4JbOgAAj4pA References: <49D393C2.8060200@tari.toshiba.com> From: To: , X-OriginalArrivalTime: 01 Apr 2009 21:52:05.0589 (UTC) FILETIME=[18F05050:01C9B314] Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:52:09 -0000 Hi Victor, Thanks for the good summary of the discussion! I can just re-assess what I said during the meeting. In my understanding, the current scope of the work was "limited" to fix = bugs and clarify procedures/texts in the existing RFC 3588 (along with = Diameter application design guidelines draft). It was not foreseen to add "new features" to the set of Diameter base = protocol functionalities and backward compatibility was THE leitmotiv. = For example, some "proposed improvments" was recently rejected because = of non-backward compatibility issues. If there are issues that are required to be fixed in a way that is not = backward compatible with current Diameter base implementations, I think = that the rationale to accept them is that they are actually "issues"! = IMHO, solving issues takes precedence over keeping unchanged something = wrong... But this is not a reason to change the version. It is a reason to update = the specification of the current version. Without these changes, the = current implementation is just "incomplete" or "unstable" or "whatever": = these solutions should be deemed required. IETF, 3GPP, Wimax and other SDOs, as well as vendors are waiting for = this RFC 3588bis document for a while. We cannot take the liberty of = delaying again the publication of this document. And it is too late to = open a discussion on a v2 version, starting with a clear definition of = the new scope of the functional requirements and a clear version = negociation handling at the Diameter base protocol level. Whatever the final position taken about the issues and the proposed = solutions, the final document should describe the (new) recommended = implementation of the Diameter base protocol (i.e. v1). For the two current issues/solutions, I would recommend to use separate = threads, in order to separate the discussions: version number, TLS = negociation and Capabilities Exchange. BR, Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Victor Fajardo > Envoy=E9 : mercredi 1 avril 2009 18:18 > =C0 : dime@ietf.org > Objet : [Dime] rfc3588bis version number >=20 > As noted in IETF74, there were concerns on incrementing the=20 > version number for rfc3588bis. The latest rev of the bis=20 > draft has the diameter header version number set to 2. The=20 > main reason for incrementing the version number are the=20 > following non-backward compatible fixes/changes in bis: >=20 > * TLS negotiation are no longer done within the context of=20 > CER/CEA. TLS connectivity is now established prior to any=20 > diameter traffic via a well known port. >=20 > * Capabilities exchange in the open state is no longer supported. >=20 > The concerns folks have raised for incrementing the version=20 > number in bis are as follows (pls correct me if I mis-state=20 > some of these issues or if I miss some issues): >=20 > * The version increment was very sudden and seems to have=20 > been done without much discussion. The current changes in bis=20 > can be classified into either clarifications and bug fixes=20 > (the changes above are included). Both types of changes does=20 > not warrant a version increment given that no new=20 > significant feature is being introduced beyond these two types. >=20 > * The changes above that triggered discussion of version=20 > increment are considered critical "bug fixes" anyway. The=20 > fixes should be considered as "updates/patches" that would=20 > require code change regardless since it leaves certain=20 > features of the original 3588 broken, un-secure or=20 > inter-operable. An incremental approach is better: i.e., bis=20 > as a patch and a new separate document as 3588 version 2. >=20 > * Some clarifications may require code changes for some=20 > vendors (although care was always been taken to advertised=20 > proposed solutions on the list so this should be rare) but=20 > the code changes would have been required anyway for=20 > successful interop. >=20 > * If the version number is incremented, it would be unclear=20 > what RFC3588 state would be. Whether the new version would=20 > deprecate 3588 or it would be a completely separate=20 > branch/track that's very similar yet slightly different from=20 > 3588. It creates more ambigouity and does not seem to warrant=20 > a version increment as well. >=20 > * Using bis to create a new revision of Diameter will open it=20 > up to addition of new features that can further delay=20 > publication of needed bug fixes and clarifications. >=20 > A possible middle-ground is to keep to the intent of bis as a=20 > bug fixing instrument and keep bis as version 1. With regards=20 > to the changes above: >=20 > * The version number in the diamter header may not help the=20 > TLS negotiation anyway because we only see the version number=20 > after the first diameter message. So a bis implementation and=20 > an original 3588 may not be able to inter operate regardless=20 > of whether the version number is reved-up. >=20 > * The capabilities exchange in 3588 was never really clearly=20 > specified (only hinted on in the statemachine). One possible=20 > solution is to keep the open-state capabilities exchange in=20 > bis have it as a "NO OP" process just to make it backward=20 > compatible with 3588. Then make sure we state this is clearly=20 > stated and that we intend to rely on=20 > draft-zorn-dime-capablities-update-00.txt > es-update-00.txt> > in the future. Other possible approaches are welcomed. >=20 > Comments appreciated. >=20 > regards, > victor >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From sdecugis@nict.go.jp Wed Apr 1 18:02:01 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62EC33A67CC for ; Wed, 1 Apr 2009 18:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTSDC2HJnKTo for ; Wed, 1 Apr 2009 18:02:00 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id D583D3A6821 for ; Wed, 1 Apr 2009 18:01:59 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n3212vgX026944 for ; Thu, 2 Apr 2009 10:02:57 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n3212vJG020321 for ; Thu, 2 Apr 2009 10:02:57 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n3212vJU020317 for ; Thu, 2 Apr 2009 10:02:57 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NiCT Mail) with ESMTP id 6349C16A55 for ; Thu, 2 Apr 2009 10:02:57 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NiCT Mail) with ESMTP id 4E79416A0D for ; Thu, 2 Apr 2009 10:02:57 +0900 (JST) Message-ID: <49D40EBE.2010208@nict.go.jp> Date: Thu, 02 Apr 2009 10:02:54 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: dime@ietf.org References: <49D393C2.8060200@tari.toshiba.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:02:01 -0000 Hello all, I would like to comment on this "version 2" change. I think that incrementing the version number in the header does not mean we have to redesign and improve the whole protocol. It does not mean a "major update". It is simply a hint for implementations indicating what behavior is expected (state machine, ...) >> * The version number in the diamter header may not help the >> TLS negotiation anyway because we only see the version number >> after the first diameter message. So a bis implementation and >> an original 3588 may not be able to inter operate regardless >> of whether the version number is reved-up. >> This is true for some situations, but there are also cases where a different version number would be very useful for an implementation that tries to be compatible with both specifications. On a technical point of view, changing the version number in the code is a trivial change, especially compared with all the other changes that are in the "bis" document. I don't see a reason why an implementor would complain about having to do this change on the version number -- if they are willing to deploy the changes from this revision, at least. On the contrary, on a marketing point of view, "We support Diameter 2" is more attractive IMO :) In any case, we will have to distinguish between the original Diameter or the revised version. Talking about "version 1" and "version 2" is more convenient and less error-prone. In my opinion, not incrementing the version number will add even more complexity to the protocol and implementations, leading to even less people understanding it and wanting to use it... Thank you for reading. Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From julien.bournelle@gmail.com Thu Apr 2 01:09:24 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB993A6CDF for ; Thu, 2 Apr 2009 01:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qqXeUzI7WcG for ; Thu, 2 Apr 2009 01:09:23 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 312AD3A6BEF for ; Thu, 2 Apr 2009 01:09:23 -0700 (PDT) Received: by qyk36 with SMTP id 36so824508qyk.29 for ; Thu, 02 Apr 2009 01:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2O+IQbbouVRlCpVVJ5qYj5ws4U8hW5KXxsSO0mFUF6o=; b=UcVnUsrvxWBE13RO5aeSliXJngCCtd3uCx8HnRSlANoZTK1PQojufFsRNe4s8ItEna zrU9AjwtXcNeHg7JW18mG8PJd5piVg/TYiXdjTn7nLKBxKT8QXJeOKwBx7WvfzDI2K/2 wZUS9sxZkKJsPM+8xcPQZQZaelq86zz+TQHeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rB+2Ewg9gNrK6BlXPw8Am2A31l9iIq+03xyPyK6ppTWgEHRFnqvDSCFCnDHVhKhQhE 1r5o6dxrCs5ikggHZdofajotBykvolj4xc81FbE1PobtqqkPAwCU3BaYshcTdbGg4/dQ pobDy2sIC+/8seD7fDVPjHvaKmLj6tO+gsgKA= MIME-Version: 1.0 Received: by 10.220.96.196 with SMTP id i4mr4601731vcn.57.1238659821611; Thu, 02 Apr 2009 01:10:21 -0700 (PDT) In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> References: <49D393C2.8060200@tari.toshiba.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> Date: Thu, 2 Apr 2009 10:10:21 +0200 Message-ID: <5e2406980904020110q6c81168epa9c055ffb00ca4f9@mail.gmail.com> From: Julien Bournelle To: lionel.morand@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 08:09:24 -0000 Hi, I second lionel's comments. I thought this version Bis was about correcting bugs and clarify some process and not about adding new functionalities to the protocol. So, I would prefer to stick with Version 1 in the header. Regards, Julien On Wed, Apr 1, 2009 at 11:52 PM, wrote: > Hi Victor, > > Thanks for the good summary of the discussion! > > I can just re-assess what I said during the meeting. > > In my understanding, the current scope of the work was "limited" to fix b= ugs and clarify procedures/texts in the existing RFC 3588 (along with Diame= ter application design guidelines draft). > It was not foreseen to add "new features" to the set of Diameter base pro= tocol functionalities and backward compatibility was THE leitmotiv. For exa= mple, some "proposed improvments" was recently rejected because of non-back= ward compatibility issues. > > If there are issues that are required to be fixed in a way that is not ba= ckward compatible with current Diameter base implementations, I think that = the rationale to accept them is that they are actually "issues"! IMHO, solv= ing issues takes precedence over keeping unchanged something wrong... > > But this is not a reason to change the version. It is a reason to update = the specification of the current version. Without these changes, the curren= t implementation is just "incomplete" or "unstable" or "whatever": these so= lutions should be deemed required. > > IETF, 3GPP, Wimax and other SDOs, as well as vendors are waiting for this= RFC 3588bis document for a while. We cannot take the liberty of delaying a= gain the publication of this document. And it is too late to open a discuss= ion on a v2 version, starting with a clear definition of the new scope of t= he functional requirements and a clear version negociation handling at the = Diameter base protocol level. > > Whatever the final position taken about the issues and the proposed solut= ions, the final document should describe the (new) recommended implementati= on of the Diameter base protocol (i.e. v1). > > For the two current issues/solutions, I would recommend to use separate t= hreads, in order to separate the discussions: version number, TLS negociati= on and Capabilities Exchange. > > BR, > > Lionel > > > >> -----Message d'origine----- >> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De >> la part de Victor Fajardo >> Envoy=E9 : mercredi 1 avril 2009 18:18 >> =C0 : dime@ietf.org >> Objet : [Dime] rfc3588bis version number >> >> As noted in IETF74, there were concerns on incrementing the >> version number for rfc3588bis. The latest rev of the bis >> draft has the diameter header version number set to 2. The >> main reason for incrementing the version number are the >> following non-backward compatible fixes/changes in bis: >> >> * TLS negotiation are no longer done within the context of >> CER/CEA. TLS connectivity is now established prior to any >> diameter traffic via a well known port. >> >> * Capabilities exchange in the open state is no longer supported. >> >> The concerns folks have raised for incrementing the version >> number in bis are as follows (pls correct me if I mis-state >> some of these issues or if I miss some issues): >> >> * The version increment was very sudden and seems to have >> been done without much discussion. The current changes in bis >> can be classified into either clarifications and bug fixes >> (the changes above are included). Both types of changes does >> not warrant a =A0version increment given that no new >> significant feature is being introduced beyond these two types. >> >> * The changes above that triggered discussion of version >> increment are considered critical "bug fixes" anyway. The >> fixes should be considered as "updates/patches" that would >> require code change regardless since it leaves certain >> features of the original 3588 broken, un-secure or >> inter-operable. An incremental approach is better: i.e., bis >> as a patch and a new separate document as 3588 version 2. >> >> * Some clarifications may require code changes for some >> vendors (although care was always been taken to advertised >> proposed solutions on the list so this should be rare) but >> the code changes would have been required anyway for >> successful interop. >> >> * If the version number is incremented, it would be unclear >> what RFC3588 state would be. Whether the new version would >> deprecate 3588 or it would be a completely separate >> branch/track that's very similar yet slightly different from >> 3588. It creates more ambigouity and does not seem to warrant >> a version increment as well. >> >> * Using bis to create a new revision of Diameter will open it >> up to addition of new features that can further delay >> publication of needed bug fixes and clarifications. >> >> A possible middle-ground is to keep to the intent of bis as a >> bug fixing instrument and keep bis as version 1. With regards >> to the changes above: >> >> * The version number in the diamter header may not help the >> TLS negotiation anyway because we only see the version number >> after the first diameter message. So a bis implementation and >> an original 3588 may not be able to inter operate regardless >> of whether the version number is reved-up. >> >> * The capabilities exchange in 3588 was never really clearly >> specified (only hinted on in the statemachine). One possible >> solution is to keep the open-state capabilities exchange in >> bis have it as a "NO OP" process just to make it backward >> compatible with 3588. Then make sure we state this is clearly >> stated and that we intend to rely on >> draft-zorn-dime-capablities-update-00.txt >> > es-update-00.txt> >> in the future. Other possible approaches are welcomed. >> >> Comments appreciated. >> >> regards, >> victor >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From lionel.morand@orange-ftgroup.com Thu Apr 2 02:54:52 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 700363A6A05 for ; Thu, 2 Apr 2009 02:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9wVx0OSf5YN for ; Thu, 2 Apr 2009 02:54:51 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 00FA93A6A2C for ; Thu, 2 Apr 2009 02:54:50 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 11:55:43 +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 Date: Thu, 2 Apr 2009 11:55:41 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> In-Reply-To: <49D40EBE.2010208@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] rfc3588bis version number Thread-Index: AcmzLsffyE48wbguSXeMT9pMCzjHfQAQ/2Vg References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> From: To: , X-OriginalArrivalTime: 02 Apr 2009 09:55:43.0380 (UTC) FILETIME=[2FF57540:01C9B379] Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 09:54:52 -0000 Diameter is not anymore only an academic topic as we used to hear in the = recent past. There are existing implementations running the Diameter base protocol = and "introducing" a new version of the protocol is not as simple as just = incrementing only the value of the version field in the message header. = If a v2 is created, what should we do with existing v1 implementations? = Upgrade any Diameter existing implementation to v2? Any v2 = implementation will have to support both v1 and v2? And so on... Recent discussions in other fora about version handling for different = protocols (including protocols based on Diameter applications for = instance) showed that issues with versioning and interworking are often = reasons good enough to be stuck with the previous version and postpone = (forever?) the migration to the new version. At this stage, what it is = required is not a new version of the protocol. It is just a version of = the protocol that is good enough to remove any existing open issue with = the current specification. Having a new document describing the correct = implementation of the Diameter base protocol doesn't require a v2. The = new document can just make obsolete the previous document. And again, going for a v2 without a clear pre-existing requirement = definition phase and deciding the version update at the latest stage = would be counterproductive and an open door for a v3 discussion, even = maybe before the effective deployment of the v2, without collecting = feedback from the operational field. Having a long-term stable base = protocol should be our goal, to ensure a successful deployment of any = application running on top of the base protocol. Especially for a = protocol used over interfaces between different administrative domains. BR, Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Sebastien Decugis > Envoy=E9 : jeudi 2 avril 2009 03:03 > =C0 : dime@ietf.org > Objet : Re: [Dime] rfc3588bis version number >=20 > Hello all, >=20 > I would like to comment on this "version 2" change. >=20 > I think that incrementing the version number in the header=20 > does not mean we have to redesign and improve the whole=20 > protocol. It does not mean a "major update". It is simply a=20 > hint for implementations indicating what behavior is expected=20 > (state machine, ...) >=20 > >> * The version number in the diamter header may not help the TLS=20 > >> negotiation anyway because we only see the version number=20 > after the=20 > >> first diameter message. So a bis implementation and an=20 > original 3588=20 > >> may not be able to inter operate regardless of whether the version=20 > >> number is reved-up. > >> =20 > This is true for some situations, but there are also cases=20 > where a different version number would be very useful for an=20 > implementation that tries to be compatible with both specifications. >=20 > On a technical point of view, changing the version number in=20 > the code is a trivial change, especially compared with all=20 > the other changes that are in the "bis" document. I don't see=20 > a reason why an implementor would complain about having to do=20 > this change on the version number -- if they are willing to=20 > deploy the changes from this revision, at least. On the=20 > contrary, on a marketing point of view, "We support Diameter=20 > 2" is more attractive IMO :) >=20 > In any case, we will have to distinguish between the original=20 > Diameter or the revised version. Talking about "version 1"=20 > and "version 2" is more convenient and less error-prone. > In my opinion, not incrementing the version number will add=20 > even more complexity to the protocol and implementations,=20 > leading to even less people understanding it and wanting to use it... >=20 > Thank you for reading. >=20 > Sebastien. >=20 > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From vfajardo@tari.toshiba.com Thu Apr 2 06:04:44 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EED63A689E for ; Thu, 2 Apr 2009 06:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8izXS7j1ZaQC for ; Thu, 2 Apr 2009 06:04:43 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 2891928C206 for ; Thu, 2 Apr 2009 06:03:08 -0700 (PDT) Received: from [127.0.0.1] (smtp.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n32D8Kiu027721; Thu, 2 Apr 2009 08:08:20 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49D4B7C8.7000508@tari.toshiba.com> Date: Thu, 02 Apr 2009 09:04:08 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Sebastien Decugis References: <49D393C2.8060200@tari.toshiba.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> In-Reply-To: <49D40EBE.2010208@nict.go.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:04:44 -0000 Hi Sebastien, > I think that incrementing the version number in the header does not > mean we have to redesign and improve the whole protocol. It does not > mean a "major update". It is simply a hint for implementations > indicating what behavior is expected (state machine, ...) > I guess it's really a question of what the version number in the header indicates. So far, its the opinion of most folks that the version number means ONLY "major update and/or new significant features" and bis is merely an update/patch to an existing version. > >>> * The version number in the diamter header may not help the >>> TLS negotiation anyway because we only see the version number >>> after the first diameter message. So a bis implementation and >>> an original 3588 may not be able to inter operate regardless >>> of whether the version number is reved-up. >>> >>> > This is true for some situations, but there are also cases where a > different version number would be very useful for an implementation that > tries to be compatible with both specifications. > Typically yes. But 1) we should confine ourselves to the changes in bis because those are the only changes that exist/relevant. 2) If bis is treated as fix/patch to problems that renders certain features in 3588 as non-interoperable then why would an implementation need to support both version ? regards, victor > On a technical point of view, changing the version number in the code is > a trivial change, especially compared with all the other changes that > are in the "bis" document. I don't see a reason why an implementor would > complain about having to do this change on the version number -- if they > are willing to deploy the changes from this revision, at least. On the > contrary, on a marketing point of view, "We support Diameter 2" is more > attractive IMO :) > > In any case, we will have to distinguish between the original Diameter > or the revised version. Talking about "version 1" and "version 2" is > more convenient and less error-prone. > In my opinion, not incrementing the version number will add even more > complexity to the protocol and implementations, leading to even less > people understanding it and wanting to use it... > > Thank you for reading. > > Sebastien. > > From Mark.Jones@bridgewatersystems.com Thu Apr 2 06:21:46 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D19D3A6A4E for ; Thu, 2 Apr 2009 06:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njh+V-L2YOnk for ; Thu, 2 Apr 2009 06:21:45 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 325A23A6919 for ; Thu, 2 Apr 2009 06:21:45 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 2 Apr 2009 09:22:45 -0400 From: Mark Jones To: "dime@ietf.org" Date: Thu, 2 Apr 2009 09:22:43 -0400 Thread-Topic: [Dime] rfc3588bis version number Thread-Index: Acmy5YBxwCqcIoksS7Kul1XUVjq2VwAq7AFQ Message-ID: References: <49D393C2.8060200@tari.toshiba.com> In-Reply-To: <49D393C2.8060200@tari.toshiba.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:21:46 -0000 I agree with Victor's summary and the conclusion to keep 3588bis at version= 1. I am not against adding a Diameter v2 work item to the charter but this= was clearly not the intent for 3588bis. The 3588bis was started was starte= d over 2 years ago and we made lots of compromises in how we addressed 3588= issues in order to ensure backwards compatibility. If we'd wanted a v2, we= would have tackled those issues differently. In addition, 3588bis is needed immediately to guide implementors towards a = successful interop of v1. Moving to v2 now effectively orphans v1 just when= other SDOs are completing specifications of their Diameter-based applicati= ons and operators are planning deployments. Regards Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Victor Fajardo > Sent: April 1, 2009 12:18 PM > To: dime@ietf.org > Subject: [Dime] rfc3588bis version number >=20 > As noted in IETF74, there were concerns on incrementing the version=20 > number for rfc3588bis. The latest rev of the bis draft has=20 > the diameter=20 > header version number set to 2. The main reason for incrementing the=20 > version number are the following non-backward compatible=20 > fixes/changes=20 > in bis: >=20 > * TLS negotiation are no longer done within the context of=20 > CER/CEA. TLS=20 > connectivity is now established prior to any diameter traffic=20 > via a well=20 > known port. >=20 > * Capabilities exchange in the open state is no longer supported. >=20 > The concerns folks have raised for incrementing the version number in=20 > bis are as follows (pls correct me if I mis-state some of=20 > these issues=20 > or if I miss some issues): >=20 > * The version increment was very sudden and seems to have been done=20 > without much discussion. The current changes in bis can be classified=20 > into either clarifications and bug fixes (the changes above are=20 > included). Both types of changes does not warrant a version=20 > increment=20 > given that no new significant feature is being introduced=20 > beyond these=20 > two types. >=20 > * The changes above that triggered discussion of version=20 > increment are=20 > considered critical "bug fixes" anyway. The fixes should be=20 > considered=20 > as "updates/patches" that would require code change=20 > regardless since it=20 > leaves certain features of the original 3588 broken, un-secure or=20 > inter-operable. An incremental approach is better: i.e., bis=20 > as a patch=20 > and a new separate document as 3588 version 2. >=20 > * Some clarifications may require code changes for some vendors=20 > (although care was always been taken to advertised proposed=20 > solutions on=20 > the list so this should be rare) but the code changes would have been=20 > required anyway for successful interop. >=20 > * If the version number is incremented, it would be unclear=20 > what RFC3588=20 > state would be. Whether the new version would deprecate 3588=20 > or it would=20 > be a completely separate branch/track that's very similar yet=20 > slightly=20 > different from 3588. It creates more ambigouity and does not seem to=20 > warrant a version increment as well. >=20 > * Using bis to create a new revision of Diameter will open it up to=20 > addition of new features that can further delay publication of needed=20 > bug fixes and clarifications. >=20 > A possible middle-ground is to keep to the intent of bis as a=20 > bug fixing=20 > instrument and keep bis as version 1. With regards to the=20 > changes above: >=20 > * The version number in the diamter header may not help the TLS=20 > negotiation anyway because we only see the version number after the=20 > first diameter message. So a bis implementation and an=20 > original 3588 may=20 > not be able to inter operate regardless of whether the=20 > version number is=20 > reved-up. >=20 > * The capabilities exchange in 3588 was never really clearly=20 > specified=20 > (only hinted on in the statemachine). One possible solution=20 > is to keep=20 > the open-state capabilities exchange in bis have it as a "NO=20 > OP" process=20 > just to make it backward compatible with 3588. Then make sure=20 > we state=20 > this is clearly stated and that we intend to rely on=20 > draft-zorn-dime-capablities-update-00.txt=20 > es-update-00.txt>=20 > in the future. Other possible approaches are welcomed. >=20 > Comments appreciated. >=20 > regards, > victor >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = From avi@bridgewatersystems.com Thu Apr 2 11:33:13 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F133A68DC for ; Thu, 2 Apr 2009 11:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQkUHKmUry3B for ; Thu, 2 Apr 2009 11:33:13 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 19D323A67E5 for ; Thu, 2 Apr 2009 11:32:48 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 2 Apr 2009 14:33:48 -0400 From: Avi Lior To: "dime@ietf.org" Date: Thu, 2 Apr 2009 14:33:48 -0400 Thread-Topic: [Dime] rfc3588bis version number Thread-Index: Acmy5YBxwCqcIoksS7Kul1XUVjq2VwAq7AFQAAvlK4M= Message-ID: <8A8CFE8F89C38B41A749C19328C76D6308D680CC46@exchange02.bridgewatersys.com> References: <49D393C2.8060200@tari.toshiba.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 18:33:14 -0000 The summary correctly captures the discussion. I support keeping 3588bis at version 1.=20 I would support adding a Diameter v2 work item to the charter. Furthermore, we should identify the areas that need to be enhanced by way o= f problem statements into a single draft or a set of drafts. A design team or teams should then tackle the solutions space. Avi= From sdecugis@nict.go.jp Thu Apr 2 19:14:31 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B23928C26F for ; Thu, 2 Apr 2009 19:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0zqRBVHo9hQ for ; Thu, 2 Apr 2009 19:14:30 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 9A10D28C0FA for ; Thu, 2 Apr 2009 19:14:29 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n332FTl9004653; Fri, 3 Apr 2009 11:15:29 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n332FTBR016370; Fri, 3 Apr 2009 11:15:29 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n332FTwb016367; Fri, 3 Apr 2009 11:15:29 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NiCT Mail) with ESMTP id 5A330169C4; Fri, 3 Apr 2009 11:15:29 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NiCT Mail) with ESMTP id 53565169A8; Fri, 3 Apr 2009 11:15:29 +0900 (JST) Message-ID: <49D57138.3000701@nict.go.jp> Date: Fri, 03 Apr 2009 11:15:20 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Victor Fajardo References: <49D393C2.8060200@tari.toshiba.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <49D4B7C8.7000508@tari.toshiba.com> In-Reply-To: <49D4B7C8.7000508@tari.toshiba.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 02:14:31 -0000 Hi, > I guess it's really a question of what the version number in the > header indicates. So far, its the opinion of most folks that the > version number means ONLY "major update and/or new significant > features" and bis is merely an update/patch to an existing version. Well, what about calling it "version 1.1" in the draft and changing the header field to some stupid value like 0x11 ? Would it release the psychologic barrier ? :) > > Typically yes. But 1) we should confine ourselves to the changes in > bis because those are the only changes that exist/relevant. 2) If bis > is treated as fix/patch to problems that renders certain features in > 3588 as non-interoperable then why would an implementation need to > support both version ? As pointed out by Lionel, we need to support both versions *because* equipment already exist and is deployed that implement the original 3588. What do you do when you have to equipments bought at different times, that support the same protocol, and that are unable to interoperate? Especially in the case of several administrative domains... To me, not changing the version number in the header will lead to a lot more problems than changing it. I am now starting to deploy Diameter in an academic environment. I plan to use the revised version of the protocol. Then I will interconnect this as much as possible with other organizations. If these organizations already run a Diameter infrastructure, they will very likely implement the original RFC. How is it possible to interconnect with them? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Thu Apr 2 19:29:37 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04FDA28C270 for ; Thu, 2 Apr 2009 19:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.78 X-Spam-Level: X-Spam-Status: No, score=-0.78 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q99aZWVTxn3T for ; Thu, 2 Apr 2009 19:29:36 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id C6ACF28C27D for ; Thu, 2 Apr 2009 19:28:45 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n332Tk1L005779; Fri, 3 Apr 2009 11:29:46 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n332Tk38018800; Fri, 3 Apr 2009 11:29:46 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n332Tkbi018797; Fri, 3 Apr 2009 11:29:46 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NiCT Mail) with ESMTP id F3FAE16B06; Fri, 3 Apr 2009 11:29:45 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NiCT Mail) with ESMTP id EB0CB16B03; Fri, 3 Apr 2009 11:29:45 +0900 (JST) Message-ID: <49D57490.2000606@nict.go.jp> Date: Fri, 03 Apr 2009 11:29:36 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lionel.morand@orange-ftgroup.com References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 02:29:37 -0000 Hi Lionel, > Diameter is not anymore only an academic topic as we used to hear in the recent past. > There are existing implementations running the Diameter base protocol and "introducing" a new version of the protocol is not as simple as just incrementing only the value of the version field in the message header. If a v2 is created, what should we do with existing v1 implementations? Upgrade any Diameter existing implementation to v2? Any v2 implementation will have to support both v1 and v2? And so on... > How is it different with the bis version? Regardless of the header in the message, we *are* introducing a new version of the protocol, since it is not interoperable with original RFC3588. The exact same questions apply. At least by bumping the version number, the situation is easier to manage, IMHO. > Recent discussions in other fora about version handling for different protocols (including protocols based on Diameter applications for instance) showed that issues with versioning and interworking are often reasons good enough to be stuck with the previous version and postpone (forever?) the migration to the new version. At this stage, what it is required is not a new version of the protocol. It is just a version of the protocol that is good enough to remove any existing open issue with the current specification. Having a new document describing the correct implementation of the Diameter base protocol doesn't require a v2. The new document can just make obsolete the previous document. > Ok, you obsolete the original document. What about existing implementations of this original document? > And again, going for a v2 without a clear pre-existing requirement definition phase and deciding the version update at the latest stage would be counterproductive and an open door for a v3 discussion, even maybe before the effective deployment of the v2, without collecting feedback from the operational field. Having a long-term stable base protocol should be our goal, to ensure a successful deployment of any application running on top of the base protocol. Especially for a protocol used over interfaces between different administrative domains. > Now, if 3588 and 3588bis protocols *were* interoperable, I totally support that we should not bump the version number and save the not-interoperable changes to a v2 version later, following the whole clean process. I guess I did not make my point very clear. What I want to enforce is that if we are introducing changes that make original and revised RFCs not interoperable, then the version number MUST be bumped. I have no problem with saving these changes for a future revision (a real v2) and going with an interoperable version in rfc3588bis. I think this is the reasonable approach that everyone supports in the WG. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From stefan.winter@restena.lu Thu Apr 2 23:13:38 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4C328C10E for ; Thu, 2 Apr 2009 23:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BCsuRZQ3lDQ for ; Thu, 2 Apr 2009 23:13:38 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id E0DDD3A6BFA for ; Thu, 2 Apr 2009 23:13:37 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 676C9AF039; Fri, 3 Apr 2009 08:14:39 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 58FACAF038; Fri, 3 Apr 2009 08:14:39 +0200 (CEST) Message-ID: <49D5A94F.3030309@restena.lu> Date: Fri, 03 Apr 2009 08:14:39 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Sebastien Decugis References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> In-Reply-To: <49D57490.2000606@nict.go.jp> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 06:13:38 -0000 Hi, > How is it different with the bis version? Regardless of the header in > the message, we *are* introducing a new version of the protocol, since > it is not interoperable with original RFC3588. The exact same questions > apply. At least by bumping the version number, the situation is easier > to manage, IMHO. > [...] > Now, if 3588 and 3588bis protocols *were* interoperable, I totally > support that we should not bump the version number and save the > not-interoperable changes to a v2 version later, following the whole > clean process. > > I guess I did not make my point very clear. What I want to enforce is > that if we are introducing changes that make original and revised RFCs > not interoperable, then the version number MUST be bumped. I have no > problem with saving these changes for a future revision (a real v2) and > going with an interoperable version in rfc3588bis. I think this is the > reasonable approach that everyone supports in the WG. > I fully support Sebastien. If bis is not given a new version number, there are different protocols in the wild which claim to be the very same protocol. These protocols are not interoperable with each other, and their differences are subtle. I suspect implementation nightmares dead ahead. I acknowledge that it's a pity that the plan not to introduce incompatible changes in bis couldn't be upheld. But regardless of that: these *are* two different protocols, and they *really really should* be easily distinguishable from each other. Giving bis the version number 2 doesn't at all prevent future backwards-incompatible cleanups (those that were rejected earlier for bis, and others) from happening: such a revision simply can get version 3. The Version field is 8 bits - It's not like we're running short of integers. Greetings, Stefan Winter P.S.: Why am I reminded of the subtle differences of MS-CHAPv2 in EAP-FAST vs. elsewhere, and the confusion and fuss that was generated by the two having the same EAP type. I'd prefer things like that not to happen yet another time. -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From lionel.morand@orange-ftgroup.com Fri Apr 3 05:47:26 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43253A6B82 for ; Fri, 3 Apr 2009 05:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgyL2YczQJ9G for ; Fri, 3 Apr 2009 05:47:26 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 890163A6944 for ; Fri, 3 Apr 2009 05:47:25 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 14:48:05 +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 Date: Fri, 3 Apr 2009 14:48:12 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026065AB9E1@ftrdmel2> In-Reply-To: <49D5A94F.3030309@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] rfc3588bis version number Thread-Index: Acm0I523JeLq7X9US9OapVQGqoYZ/gANDLjA References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> From: To: , X-OriginalArrivalTime: 03 Apr 2009 12:48:05.0423 (UTC) FILETIME=[6EB5BBF0:01C9B45A] Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:47:27 -0000 Hi Stephan, Sebastien, The proposed changes are there BECAUSE there are issues with the current = Diameter implementation. What you are saying is that the RFC3588 would = remain with open issues (from the standard point of view) that would be = fixed by some vendor-specific solutions in the operational network or = not solved at all. So basically, how will the interoperatbility with a = v1 implementation be properly ensured if you don't even know how excatly = the remote v1 AAA entity behave? I prefer to find some texts saying: "sorry guys! Some mistakes were present in the first edition of the spec = and here is the correct version of the specification, with the correct = implementation!" Instead of something like: "The RFC3588 had some problems and a new version was created. But of = course, you can still use the old version version and you are free to = interwork with"=20 The industry and other fora uses to handle protocol issues in that way. = The version update is not the ONLY solution to fix protocol issues. = Version update is always consider a carefully thought-out plan and a = last resort solution. BR, Lionel > -----Message d'origine----- > De : Stefan Winter [mailto:stefan.winter@restena.lu]=20 > Envoy=E9 : vendredi 3 avril 2009 08:15 > =C0 : Sebastien Decugis > Cc : MORAND Lionel RD-CORE-ISS; dime@ietf.org > Objet : Re: [Dime] rfc3588bis version number >=20 > Hi, >=20 > > How is it different with the bis version? Regardless of the=20 > header in=20 > > the message, we *are* introducing a new version of the=20 > protocol, since=20 > > it is not interoperable with original RFC3588. The exact same=20 > > questions apply. At least by bumping the version number,=20 > the situation=20 > > is easier to manage, IMHO. > > =20 > [...] > > Now, if 3588 and 3588bis protocols *were* interoperable, I totally=20 > > support that we should not bump the version number and save the=20 > > not-interoperable changes to a v2 version later, following=20 > the whole=20 > > clean process. > > > > I guess I did not make my point very clear. What I want to=20 > enforce is=20 > > that if we are introducing changes that make original and=20 > revised RFCs=20 > > not interoperable, then the version number MUST be bumped.=20 > I have no=20 > > problem with saving these changes for a future revision (a real v2)=20 > > and going with an interoperable version in rfc3588bis. I=20 > think this is=20 > > the reasonable approach that everyone supports in the WG. > > =20 >=20 > I fully support Sebastien. If bis is not given a new version=20 > number, there are different protocols in the wild which claim=20 > to be the very same protocol. These protocols are not=20 > interoperable with each other, and their differences are=20 > subtle. I suspect implementation nightmares dead ahead. >=20 > I acknowledge that it's a pity that the plan not to introduce=20 > incompatible changes in bis couldn't be upheld. But=20 > regardless of that: > these *are* two different protocols, and they *really really=20 > should* be easily distinguishable from each other. >=20 > Giving bis the version number 2 doesn't at all prevent future=20 > backwards-incompatible cleanups (those that were rejected=20 > earlier for bis, and others) from happening: such a revision=20 > simply can get version 3. The Version field is 8 bits - It's=20 > not like we're running short of integers. >=20 > Greetings, >=20 > Stefan Winter >=20 > P.S.: Why am I reminded of the subtle differences of=20 > MS-CHAPv2 in EAP-FAST vs. elsewhere, and the confusion and=20 > fuss that was generated by the two having the same EAP type.=20 > I'd prefer things like that not to happen yet another time. >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education=20 > Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 >=20 From vfajardo@tari.toshiba.com Fri Apr 3 06:34:22 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0263C3A6DEE for ; Fri, 3 Apr 2009 06:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgO5ElWUEH9I for ; Fri, 3 Apr 2009 06:34:21 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id F08C83A6D51 for ; Fri, 3 Apr 2009 06:33:09 -0700 (PDT) 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 n33DcJxR038790; Fri, 3 Apr 2009 08:38:20 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49D61051.8010105@tari.toshiba.com> Date: Fri, 03 Apr 2009 09:34:09 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Sebastien Decugis References: <49D393C2.8060200@tari.toshiba.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <49D4B7C8.7000508@tari.toshiba.com> <49D57138.3000701@nict.go.jp> In-Reply-To: <49D57138.3000701@nict.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:34:22 -0000 Hi Sebastien, >> I guess it's really a question of what the version number in the >> header indicates. So far, its the opinion of most folks that the >> version number means ONLY "major update and/or new significant >> features" and bis is merely an update/patch to an existing version. >> > Well, what about calling it "version 1.1" in the draft and changing the > header field to some stupid value like 0x11 ? Would it release the > psychologic barrier ? :) > Hmmm ... I think we are really diverging from the core point of the discussion and the closure that I want to come to. So, pls see my comments below. > >> Typically yes. But 1) we should confine ourselves to the changes in >> bis because those are the only changes that exist/relevant. 2) If bis >> is treated as fix/patch to problems that renders certain features in >> 3588 as non-interoperable then why would an implementation need to >> support both version ? >> > As pointed out by Lionel, we need to support both versions *because* > equipment already exist and is deployed that implement the original > 3588. What do you do when you have to equipments bought at different > times, that support the same protocol, and that are unable to > interoperate? Especially in the case of several administrative domains... > > I think that point is already obvious to anyone, right ? :) The point I'm trying to make is based on item (1) below. But I guess that is still not clear at this point :) ... so to re-iterate one more time, the options are: 1. Keep the old version number (v1) and revert/fix the changes that made bis non-interoperable with 3588. This keeps bis within the context of being a bug fix/patch instrument. This is why those changes were enumerated in the summary ... so if we choose this option then I think it is better on commenting on how to revert/fix the new changes instead of focusing on why the version number was invented. The reasons for going this directions are those enumerated on the summary. 2. Rev-up the version number to v2. We're free to make any changes we want but with the current state of bis and the dependencies of other work on that document, we really have to consider if this is a good approach at this point. Again, see the summary. So, lets focus the discussion on these and hopefully we can come to a quick conclusion. -- victor From Mark.Jones@bridgewatersystems.com Fri Apr 3 07:23:46 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096873A6C6F for ; Fri, 3 Apr 2009 07:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q85JTweVI-Zy for ; Fri, 3 Apr 2009 07:23:45 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id EDC7F3A68A3 for ; Fri, 3 Apr 2009 07:23:44 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Fri, 3 Apr 2009 10:24:46 -0400 From: Mark Jones To: "dime@ietf.org" Date: Fri, 3 Apr 2009 10:24:45 -0400 Thread-Topic: [Dime] rfc3588bis version number Thread-Index: Acm0I4lMvnKLB/+iRYOTTiDWka83cwANcWGA Message-ID: References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> In-Reply-To: <49D5A94F.3030309@restena.lu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:23:46 -0000 > I fully support Sebastien. If bis is not given a new version number, > there are different protocols in the wild which claim to be the very > same protocol. These protocols are not interoperable with each other, > and their differences are subtle. I suspect implementation nightmares > dead ahead. >=20 Version 1 is already out in the wild and two independent implementations of= RFC3588 may not interoperate. So we spent 18 months on bug fixes in 3588bi= s to greatly improve the odds that they can interoperate. Implementers find= ing contradictions or ambiguities in RFC3588 have been able to turn to 3588= bis for clarification. Throughout that time Victor was strict in enforcing = solutions that were backwards compatible. Recently we discover two issues (TLS negotiation and capabilities update) a= nd find we can not fix them without breaking backwards compatibility. Given= that no one noticed these problems until now, I strongly suspect these are= not critical features of the Diameter base protocol. For Capabilities Upda= te, we chose to deprecate the feature in bis rather than fix it and Glen ca= ptured a solution in a separate draft. If offered the choice at that point,= I believe the majority of delegates would have been preferred a similar ap= proach for TLS negotiation rather than bump the version. > I acknowledge that it's a pity that the plan not to introduce > incompatible changes in bis couldn't be upheld. But=20 > regardless of that: > these *are* two different protocols, and they *really really=20 > should* be > easily distinguishable from each other. >=20 The original plan for 3588bis was sound and is still required. IMO the deci= sion to address TLS negotiation in bis knowing that the fix was not backwar= ds compatible was our error. I vote we deprecate this feature in 3588bis, m= ove the proposed solution to a new draft (Diameter v2 if required) and get = 3588bis out the door. Regards Mark From sdecugis@nict.go.jp Sun Apr 5 18:19:04 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53F773A6AA2 for ; Sun, 5 Apr 2009 18:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.369 X-Spam-Level: X-Spam-Status: No, score=0.369 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_40=-0.185, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKwsu1YyRqDs for ; Sun, 5 Apr 2009 18:19:03 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 0B4263A697B for ; Sun, 5 Apr 2009 18:19:02 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n361K348009504; Mon, 6 Apr 2009 10:20:03 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n361K3dY012473; Mon, 6 Apr 2009 10:20:03 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n361K3hv012470; Mon, 6 Apr 2009 10:20:03 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NiCT Mail) with ESMTP id 1CBDB2C1F3; Mon, 6 Apr 2009 10:20:03 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NiCT Mail) with ESMTP id 14AA22C1D0; Mon, 6 Apr 2009 10:20:03 +0900 (JST) Message-ID: <49D958BB.3020206@nict.go.jp> Date: Mon, 06 Apr 2009 10:19:55 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mark Jones References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 01:19:04 -0000 Hi, > The original plan for 3588bis was sound and is still required. IMO the decision to address TLS negotiation in bis knowing that the fix was not backwards compatible was our error. I vote we deprecate this feature in 3588bis, move the proposed solution to a new draft (Diameter v2 if required) and get 3588bis out the door. > This sounds reasonable to me, and I support this approach. Although this issue with TLS *is* a security vulnerability and should result in the Diameter protocol version 1 be deprecated quite soon to the benefit of a secure version 2... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From jouni.nospam@gmail.com Mon Apr 6 23:53:09 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B07B3A6D89 for ; Mon, 6 Apr 2009 23:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwu6s+zKnhSp for ; Mon, 6 Apr 2009 23:53:03 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 77E173A6D83 for ; Mon, 6 Apr 2009 23:53:03 -0700 (PDT) Received: by ewy9 with SMTP id 9so2265046ewy.37 for ; Mon, 06 Apr 2009 23:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=VMFvYtMJbOTxrO8sBTwNC81LmdqNffR/K1NrNNTzSuU=; b=KWwKJfald70vIgUsNlHeTfw2pqbp+tFtbGxsLFfX3JJd+a4gqipni8T1DX8DOG7p6X DMYRRD075XBxbH5/uqYs3K5T2qdFGFZ2jVzH3f9l5MSgMqsws2smJwrTba92r73+Qhwj vDuG8qTjjG+++VdHXJ+nuDLqgTrDzJQySIn2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=dpyJRIy3z2LAFMYzqi4Cf5VMq/hDP3PwSCFAnUssbZQjrOn+SMWuCvo2W+2LL/cHhZ Y08iDHnJxwRmoyOrGWAMA/S4fZD3SS4Mw2hVlYaxvQ377zXiTq2nZm+lyY4rVb3oTbtD ccdw9ta9B/95c+K94SdbAofnfjXNfOU7Pr10Q= Received: by 10.216.6.213 with SMTP id 63mr1416920wen.208.1239087248815; Mon, 06 Apr 2009 23:54:08 -0700 (PDT) Received: from ?10.183.180.248? ([192.100.124.156]) by mx.google.com with ESMTPS id q9sm14359858gve.3.2009.04.06.23.54.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Apr 2009 23:54:08 -0700 (PDT) Message-Id: From: jouni korhonen To: Mark Jones In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 09:54:06 +0300 References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> X-Mailer: Apple Mail (2.930.3) Cc: "dime@ietf.org" Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 06:53:09 -0000 Hi, I fully agree what Mark said here. (Originally, I was for v2 but after some more thoughts, I think it was a premature conclusion). Cheers, Jouni On Apr 3, 2009, at 5:24 PM, Mark Jones wrote: >> I fully support Sebastien. If bis is not given a new version number, >> there are different protocols in the wild which claim to be the very >> same protocol. These protocols are not interoperable with each other, >> and their differences are subtle. I suspect implementation nightmares >> dead ahead. >> > > Version 1 is already out in the wild and two independent > implementations of RFC3588 may not interoperate. So we spent 18 > months on bug fixes in 3588bis to greatly improve the odds that they > can interoperate. Implementers finding contradictions or ambiguities > in RFC3588 have been able to turn to 3588bis for clarification. > Throughout that time Victor was strict in enforcing solutions that > were backwards compatible. > > Recently we discover two issues (TLS negotiation and capabilities > update) and find we can not fix them without breaking backwards > compatibility. Given that no one noticed these problems until now, I > strongly suspect these are not critical features of the Diameter > base protocol. For Capabilities Update, we chose to deprecate the > feature in bis rather than fix it and Glen captured a solution in a > separate draft. If offered the choice at that point, I believe the > majority of delegates would have been preferred a similar approach > for TLS negotiation rather than bump the version. > >> I acknowledge that it's a pity that the plan not to introduce >> incompatible changes in bis couldn't be upheld. But >> regardless of that: >> these *are* two different protocols, and they *really really >> should* be >> easily distinguishable from each other. >> > > The original plan for 3588bis was sound and is still required. IMO > the decision to address TLS negotiation in bis knowing that the fix > was not backwards compatible was our error. I vote we deprecate this > feature in 3588bis, move the proposed solution to a new draft > (Diameter v2 if required) and get 3588bis out the door. > > Regards > Mark > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From stefan.winter@restena.lu Tue Apr 7 00:17:42 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A993A67FD for ; Tue, 7 Apr 2009 00:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b+m6Jc6HpbD for ; Tue, 7 Apr 2009 00:17:41 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 49F533A6816 for ; Tue, 7 Apr 2009 00:17:41 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id EDB39A9F4A; Tue, 7 Apr 2009 09:18:46 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id DE710AF039; Tue, 7 Apr 2009 09:18:46 +0200 (CEST) Message-ID: <49DAFE56.1030107@restena.lu> Date: Tue, 07 Apr 2009 09:18:46 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Mark Jones References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Cc: "dime@ietf.org" Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 07:17:42 -0000 Hi, > The original plan for 3588bis was sound and is still required. IMO the decision to address TLS negotiation in bis knowing that the fix was not backwards compatible was our error. I vote we deprecate this feature in 3588bis, move the proposed solution to a new draft (Diameter v2 if required) and get 3588bis out the door. > Deprecating what? Use of TLS altogether? IIRC, the use of IPSec is not mandatory to implement any more in bis: 2.2. Securing Diameter Messages Connections between Diameter peers SHOULD be protected by TLS. All Diameter base protocol implementations MUST support the use of TLS. If desired, alternative security mechanisms that are independent of Diameter, such as IPsec [RFC4301 ], can be deployed to secure connections between peers. The Diameter protocol MUST NOT be used without any security mechanism. So, with TLS being deprecated and IPsec being optional, one can not be sure to have *any* interoperable security profile. A suggestion to deprecate TLS would have to make IPSec mandatory again. NB: There's a superfluous condition in 2.1, the wording could be cleared: When connecting to a peer and either zero or more transports are specified, TCP SHOULD be tried first, followed by SCTP. See Section 5.2 for more information on peer discovery. "either zero or more transports are specified" : this condition always evaluates to TRUE. You cannot by definition define a negative amount of transports. The sentence can be shortened to: When connecting to a peer, TCP SHOULD be tried first, followed by SCTP. See Section 5.2 for more information on peer discovery. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From hannes.tschofenig@nsn.com Tue Apr 7 04:42:31 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C9A3A6924 for ; Tue, 7 Apr 2009 04:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.604 X-Spam-Level: X-Spam-Status: No, score=-3.604 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOiYHevAt662 for ; Tue, 7 Apr 2009 04:42:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1025F3A6784 for ; Tue, 7 Apr 2009 04:42:29 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n37BhYiZ014822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Apr 2009 13:43:34 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n37BhYdZ006233 for ; Tue, 7 Apr 2009 13:43:34 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 13:43: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 Date: Tue, 7 Apr 2009 14:44:57 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45013E7F50@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting Minutes - DIME IETF#74 Thread-Index: Acm3dkbMZvoIH//uS+eaGBasFx88tA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 07 Apr 2009 11:43:33.0542 (UTC) FILETIME=[148A9460:01C9B776] Subject: [Dime] Meeting Minutes - DIME IETF#74 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 11:42:31 -0000 Victor has uploaded the meeting minutes:=20 http://www.ietf.org/proceedings/09mar/minutes/dime.txt Ciao Hannes From glenzorn@comcast.net Sun Apr 12 21:35:48 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0F53A6B92 for ; Sun, 12 Apr 2009 21:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLOrm161dKdZ for ; Sun, 12 Apr 2009 21:35:47 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 2D3353A68BB for ; Sun, 12 Apr 2009 21:35:46 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id enXK1b0010b6N64A2scw1Z; Mon, 13 Apr 2009 04:36:56 +0000 Received: from gwzPC ([124.120.227.14]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id esce1b00E0KGRiL8Psckgt; Mon, 13 Apr 2009 04:36:54 +0000 From: "Glen Zorn" To: Date: Mon, 13 Apr 2009 11:36:32 +0700 Message-ID: <006901c9bbf1$75a0ba70$60e22f50$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm78WTWEYSs2qwqTcmEHXFpt9dPZQ== Content-Language: en-us x-cr-hashedpuzzle: YSc= AhSE A7bD F77I I4JV JRrx KuiY Pt2U RAf2 R6oi Tugj YhLZ cHtf dn8w gaoI g8e1; 3; ZABpAG0AZQAtAGMAaABhAGkAcgBzAEAAaQBlAHQAZgAuAG8AcgBnADsAZABpAG0AZQBAAGkAZQB0AGYALgBvAHIAZwA7AHQAZQBuAGEAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sosha1_v1; 7; {ED89B07C-25B9-45A5-BBCD-082C69DA69AD}; ZwBsAGUAbgB6AG8AcgBuAEAAYwBvAG0AYwBhAHMAdAAuAG4AZQB0AA==; Mon, 13 Apr 2009 04:36:21 GMT; UwB0AGEAdAB1AHMAIABvAGYAIABkAHIAYQBmAHQALQB6AG8AcgBuAC0AZABpAG0AZQAtAGMAYQBwAGEAYgBsAGkAdABpAGUAcwAtAHUAcABkAGEAdABlAC0AMAAwAD8A x-cr-puzzleid: {ED89B07C-25B9-45A5-BBCD-082C69DA69AD} Cc: dime@ietf.org Subject: [Dime] Status of draft-zorn-dime-capablities-update-00? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 04:35:48 -0000 I had thought that this had been accepted as a WG doc in SF but I've heard nothing since... ~gwz Nuclear power: more toxic than Britney Spears. From gwz@net-zen.net Sun Apr 12 21:47:28 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189473A6A7F for ; Sun, 12 Apr 2009 21:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5S938gqg02M for ; Sun, 12 Apr 2009 21:47:28 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id DCEF83A68A3 for ; Sun, 12 Apr 2009 21:47:27 -0700 (PDT) Received: (qmail 10459 invoked from network); 13 Apr 2009 04:41:58 -0000 Received: from unknown (124.120.227.14) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 13 Apr 2009 04:41:57 -0000 From: "Glen Zorn" To: Date: Mon, 13 Apr 2009 11:41:49 +0700 Organization: Network Zen Message-ID: <006a01c9bbf2$2b1361a0$813a24e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm78ih3vmYxfgKFQpyXIGV8DXeH3Q== Content-Language: en-us Cc: dime@ietf.org Subject: [Dime] Status of Diameter MIB documents? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 04:47:28 -0000 I was under the impression after the SF meeting that these drafts would at least considered as WG documents. What's happening with this? ~gwz At one time in the US, in the mid-nineteenth century, working for wage labor was considered not very different from chattel slavery...anyone who thinks it's legitimate to be a wage laborer is internalizing oppression in a way which would have seemed intolerable to people in the mills 150 years ago. -- Noam Chomsky, "Propaganda & the Public Mind" From gwz@net-zen.net Sun Apr 12 21:59:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3005D3A6C3F for ; Sun, 12 Apr 2009 21:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qzdXULK92Ar for ; Sun, 12 Apr 2009 21:59:04 -0700 (PDT) Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by core3.amsl.com (Postfix) with SMTP id 4C8E43A6C20 for ; Sun, 12 Apr 2009 21:59:04 -0700 (PDT) Received: (qmail 3550 invoked from network); 13 Apr 2009 05:00:09 -0000 Received: from unknown (124.120.227.14) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 13 Apr 2009 05:00:08 -0000 From: "Glen Zorn" To: Date: Mon, 13 Apr 2009 12:00:00 +0700 Organization: Network Zen Message-ID: <007401c9bbf4$b54dd100$1fe97300$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm79ItI4inGMvXhRDuKZKDrTCIwuAAABBag Content-Language: en-us Subject: [Dime] FW: New Version Notification for draft-zorn-dime-capablities-update-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 04:59:05 -0000 FYI A new version of I-D, draft-zorn-dime-capablities-update-01.txt has been = successfuly submitted by Glen Zorn and posted to the IETF repository. Filename: draft-zorn-dime-capablities-update Revision: 01 Title: The Diameter Capabilities Update Application Creation_date: 2009-04-13 WG ID: Independent Submission Number_of_pages: 7 Abstract: This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of Diameter peer capabilities while the peer-to-peer connection is in the open state. = =20 The IETF Secretariat. From dromasca@avaya.com Mon Apr 13 02:57:57 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2203A6D31 for ; Mon, 13 Apr 2009 02:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIKftUS+DIUS; Mon, 13 Apr 2009 02:57:56 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DB17B3A6D23; Mon, 13 Apr 2009 02:57:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,179,1238990400"; d="scan'208";a="142907272" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Apr 2009 05:59:04 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Apr 2009 05:59:03 -0400 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 Apr 2009 11:58:41 +0200 Message-ID: In-reply-to: <006a01c9bbf2$2b1361a0$813a24e0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Status of Diameter MIB documents? Thread-index: Acm78ih3vmYxfgKFQpyXIGV8DXeH3QAKdWbQ References: <006a01c9bbf2$2b1361a0$813a24e0$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , Cc: dime@ietf.org Subject: Re: [Dime] Status of Diameter MIB documents? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 09:57:57 -0000 I have a similar recollection from the discussions in the meeting, with at least two vendors mentioned as using MIB modules and SNMP for management, and with the standard RADIUS MIB documents mentioned as the example of the case where the fact that standard-track RFCs led to the MIB modules being adopted by vendors.=20 Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Glen Zorn > Sent: Monday, April 13, 2009 7:42 AM > To: dime-chairs@ietf.org > Cc: dime@ietf.org > Subject: [Dime] Status of Diameter MIB documents? >=20 > I was under the impression after the SF meeting that these=20 > drafts would at least considered as WG documents. What's=20 > happening with this? >=20 > ~gwz >=20 > At one time in the US, in the mid-nineteenth century, working=20 > for wage labor was considered not very different from chattel=20 > slavery...anyone who thinks it's legitimate to be a wage=20 > laborer is internalizing oppression in a way which would have=20 > seemed intolerable to people in the mills 150 years ago. > -- Noam Chomsky, "Propaganda & the Public Mind" >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From Hannes.Tschofenig@gmx.net Mon Apr 13 11:00:33 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67BBE3A6968 for ; Mon, 13 Apr 2009 11:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzLa4COn92YG for ; Mon, 13 Apr 2009 11:00:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 45F943A6990 for ; Mon, 13 Apr 2009 11:00:30 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2009 17:55:00 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 13 Apr 2009 19:55:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/kvPE341XkuBgZlmFracKQdv/enfpUIpwqILuBwp X58GxiNVzuKRVe From: "Hannes Tschofenig" To: "'Glen Zorn'" , References: <006901c9bbf1$75a0ba70$60e22f50$@net> Date: Mon, 13 Apr 2009 20:56:26 +0300 Message-ID: <012101c9bc61$2ac78c20$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <006901c9bbf1$75a0ba70$60e22f50$@net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm78WTWEYSs2qwqTcmEHXFpt9dPZQAb37cg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: dime@ietf.org Subject: Re: [Dime] Status of draft-zorn-dime-capablities-update-00? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 18:00:33 -0000 I will send mails around to confirm the decisions on the mailing lists. I also have a quick post-IETF#74 chat with Dan tomorrow about the new documents. The decision Dan needs to make is when to add new milestones to DIME given that we have added new documents already in January 2009 and they have not left the group yet. Ciao Hannes >-----Original Message----- >From: Glen Zorn [mailto:glenzorn@comcast.net] >Sent: 13 April, 2009 07:37 >To: dime-chairs@ietf.org >Cc: dime@ietf.org; 'Tina TSOU' >Subject: Status of draft-zorn-dime-capablities-update-00? > >I had thought that this had been accepted as a WG doc in SF >but I've heard nothing since... > >~gwz > >Nuclear power: more toxic than Britney Spears. > > From Hannes.Tschofenig@gmx.net Mon Apr 13 11:01:25 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE0F3A682D for ; Mon, 13 Apr 2009 11:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukH5DRGpPtKS for ; Mon, 13 Apr 2009 11:01:25 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9CE5F3A6968 for ; Mon, 13 Apr 2009 11:01:24 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2009 17:55:53 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp061) with SMTP; 13 Apr 2009 19:55:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/sZtAYXGfsUhyjPl+4hUXMzH7vwclUhp/TCyMd/p GtjZnGL2jG1RdJ From: "Hannes Tschofenig" To: "'Glen Zorn'" , References: <006a01c9bbf2$2b1361a0$813a24e0$@net> Date: Mon, 13 Apr 2009 20:57:19 +0300 Message-ID: <012201c9bc61$4abba1b0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <006a01c9bbf2$2b1361a0$813a24e0$@net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm78ih3vmYxfgKFQpyXIGV8DXeH3QAbwbtQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: dime@ietf.org Subject: Re: [Dime] Status of Diameter MIB documents? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 18:01:25 -0000 My reply for the draft-zorn-dime-capablities-update-00 document is applicable here as well. >-----Original Message----- >From: Glen Zorn [mailto:gwz@net-zen.net] >Sent: 13 April, 2009 07:42 >To: dime-chairs@ietf.org >Cc: dime@ietf.org; 'Subash Comerica (subashtc)' >Subject: Status of Diameter MIB documents? > >I was under the impression after the SF meeting that these >drafts would at least considered as WG documents. What's >happening with this? > >~gwz > >At one time in the US, in the mid-nineteenth century, working >for wage labor was considered not very different from chattel >slavery...anyone who thinks it's legitimate to be a wage >laborer is internalizing oppression in a way which would have >seemed intolerable to people in the mills 150 years ago. > -- Noam Chomsky, "Propaganda & the Public Mind" > > From Hannes.Tschofenig@gmx.net Mon Apr 13 11:03:23 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880A53A6D1F for ; Mon, 13 Apr 2009 11:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXb6o8rqba5r for ; Mon, 13 Apr 2009 11:03:23 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EF4D43A6968 for ; Mon, 13 Apr 2009 11:03:22 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2009 17:57:52 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp006) with SMTP; 13 Apr 2009 19:57:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19fvcZLfx9fDTogw3JW14XHWtf+X76G/XJa4QYuVO lk5cFXFU2PTqGv From: "Hannes Tschofenig" To: "'Romascanu, Dan \(Dan\)'" , "'Glen Zorn'" , References: <006a01c9bbf2$2b1361a0$813a24e0$@net> Date: Mon, 13 Apr 2009 20:59:18 +0300 Message-ID: <012301c9bc61$919b6660$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm78ih3vmYxfgKFQpyXIGV8DXeH3QAKdWbQABFanwA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: dime@ietf.org Subject: Re: [Dime] Status of Diameter MIB documents? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 18:03:23 -0000 One vendor claiming that they have implemented it (namely Cisco) and one other vendor (Bridgewater) claiming that they would implement them if they become RFC. Not a lot, in my view, but the group was OK with picking them up. Ciao Hannes >-----Original Message----- >From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >Sent: 13 April, 2009 12:59 >To: Glen Zorn; dime-chairs@ietf.org >Cc: dime@ietf.org >Subject: RE: [Dime] Status of Diameter MIB documents? > >I have a similar recollection from the discussions in the >meeting, with at least two vendors mentioned as using MIB >modules and SNMP for management, and with the standard RADIUS >MIB documents mentioned as the example of the case where the >fact that standard-track RFCs led to the MIB modules being >adopted by vendors. > >Dan > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf >> Of Glen Zorn >> Sent: Monday, April 13, 2009 7:42 AM >> To: dime-chairs@ietf.org >> Cc: dime@ietf.org >> Subject: [Dime] Status of Diameter MIB documents? >> >> I was under the impression after the SF meeting that these drafts >> would at least considered as WG documents. What's happening with >> this? >> >> ~gwz >> >> At one time in the US, in the mid-nineteenth century, >working for wage >> labor was considered not very different from chattel >slavery...anyone >> who thinks it's legitimate to be a wage laborer is internalizing >> oppression in a way which would have seemed intolerable to people in >> the mills 150 years ago. >> -- Noam Chomsky, "Propaganda & the Public Mind" >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From Hannes.Tschofenig@gmx.net Mon Apr 13 12:32:01 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163633A6894 for ; Mon, 13 Apr 2009 12:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRebKX9s6Jis for ; Mon, 13 Apr 2009 12:32:00 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E56E43A6819 for ; Mon, 13 Apr 2009 12:31:59 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2009 19:33:09 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp006) with SMTP; 13 Apr 2009 21:33:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19WxRtlmFVWhSKuRsGVXb9Sbx/+ds3lodaKdkiXDe IPWvwn+JDpo6BP From: "Hannes Tschofenig" To: Date: Mon, 13 Apr 2009 22:34:35 +0300 Message-ID: <013201c9bc6e$e0f8b570$0201a8c0@nsnintra.net> 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.3350 Thread-Index: Acm8buBNK3tHtcoyR3aOQLEKf1ZJXw== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Subject: [Dime] Confirming HUM regarding draft-brockners-diameter-nat-control-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:32:01 -0000 Hi all, at the IETF#74 DIME meeting we had a presentation about the "Diameter NAT Control Application" document: http://www.ietf.org/internet-drafts/draft-brockners-diameter-nat-control-00. txt The group was in favor of turning this document into a working group item. If you have objections or if you weren't at the meeting and would like to express your support for it please let us know by the 24th April 2009. Ciao Hannes & Dave From Hannes.Tschofenig@gmx.net Mon Apr 13 12:32:22 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1031E3A6A86 for ; Mon, 13 Apr 2009 12:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKXBkc5CtFYY for ; Mon, 13 Apr 2009 12:32:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D5BF93A6894 for ; Mon, 13 Apr 2009 12:32:20 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2009 19:33:31 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp007) with SMTP; 13 Apr 2009 21:33:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18krMNVJo0kkPLxp5HueAE6Xuq8pIJ5UHrzwsPXPg itEi4f+bDjpzQy From: "Hannes Tschofenig" To: Date: Mon, 13 Apr 2009 22:34:56 +0300 Message-ID: <013301c9bc6e$eda7ee80$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0134_01C9BC88.12F52680" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm8bu0WtLik6K3HQwi6fiT98KX7Rg== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68,0.67 Subject: [Dime] Confirming HUM regarding draft-zorn-dime-diameter-base-protocol-mib-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:32:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0134_01C9BC88.12F52680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, at the IETF#74 DIME meeting we had a presentation about the "Diameter Base Protocol MIB" document: http://tools.ietf.org/html/draft-zorn-dime-diameter-base-protocol-mib-05 The group was in favor of turning this document into a working group item. If you have objections or if you weren't at the meeting and would like to express your support for it please let us know by the 24th April 2009. Ciao Hannes & Dave ------=_NextPart_000_0134_01C9BC88.12F52680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirming HUM regarding = draft-zorn-dime-diameter-base-protocol-mib-05

Hi all,

at the IETF#74 DIME meeting we = had a presentation about the "Diameter Base Protocol MIB" = document:
http://tools.ietf.org/html/draft-zorn-dime-diameter-base-protocol-mi= b-05

The group was in favor of turning = this document into a working group item.

If you have objections or if you = weren't at the meeting and would like to express your support for it = please let us know by the 24th April 2009.

Ciao
Hannes & Dave








------=_NextPart_000_0134_01C9BC88.12F52680-- From Hannes.Tschofenig@gmx.net Mon Apr 13 12:32:45 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF8E3A6924 for ; Mon, 13 Apr 2009 12:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIV4OKq8byeD for ; Mon, 13 Apr 2009 12:32:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E8F163A6894 for ; Mon, 13 Apr 2009 12:32:43 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2009 19:33:54 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp025) with SMTP; 13 Apr 2009 21:33:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19wH9ZiaYFwGzTg0Mhfbs4DErJ8yIEU2Lc2iPBKlp cpTmUbrX8y0fTu From: "Hannes Tschofenig" To: Date: Mon, 13 Apr 2009 22:35:20 +0300 Message-ID: <013801c9bc6e$fb6e3ce0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0139_01C9BC88.20BB74E0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm8bvrjJRnZ9ql2S2SB3RpAe9bgaw== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67,0.67 Subject: [Dime] Confirming HUM regarding draft-zorn-dime-diameter-cc-appl-mib-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:32:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0139_01C9BC88.20BB74E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, at the IETF#74 DIME meeting we had a presentation about the "Diameter Credit Control Application MIB" document: http://tools.ietf.org/id/draft-zorn-dime-diameter-cc-appl-mib-05.txt The group was in favor of turning this document into a working group item. If you have objections or if you weren't at the meeting and would like to express your support for it please let us know by the 24th April 2009. Ciao Hannes & Dave ------=_NextPart_000_0139_01C9BC88.20BB74E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirming HUM regarding = draft-zorn-dime-diameter-cc-appl-mib-05.txt

Hi all,

at the IETF#74 DIME meeting we = had a presentation about the "Diameter Credit Control Application = MIB" document:
http://tools.ietf.org/id/draft-zorn-dime-diameter-cc-appl-mib-05.txt=

The group was in favor of turning = this document into a working group item.

If you have objections or if you = weren't at the meeting and would like to express your support for it = please let us know by the 24th April 2009.

Ciao
Hannes & Dave









------=_NextPart_000_0139_01C9BC88.20BB74E0-- From Hannes.Tschofenig@gmx.net Mon Apr 13 12:33:06 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267E13A6924 for ; Mon, 13 Apr 2009 12:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3TuLCaIJy+1 for ; Mon, 13 Apr 2009 12:33:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F27003A6A86 for ; Mon, 13 Apr 2009 12:33:01 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2009 19:34:12 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp056) with SMTP; 13 Apr 2009 21:34:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19H1ONhI8ZHJF3gN9OyU/9rwZUGzr+qQj7VjraB52 /KZ+TPdrCpZcYW From: "Hannes Tschofenig" To: Date: Mon, 13 Apr 2009 22:35:38 +0300 Message-ID: <013d01c9bc6f$062d8cd0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013E_01C9BC88.2B7AC4D0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm8bwWe4CheyARST/mRAQpUTOJVFQ== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7,0.6899999999999999 Subject: [Dime] Confirming HUM regarding draft-zorn-dime-capablities-update-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:33:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_013E_01C9BC88.2B7AC4D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, at the IETF#74 DIME meeting we had a presentation about the "The Diameter Capabilities Update Application" document: http://tools.ietf.org/html/draft-zorn-dime-capablities-update-00 The group was in favor of turning this document into a working group item. If you have objections or if you weren't at the meeting and would like to express your support for it please let us know by the 24th April 2009. Ciao Hannes & Dave ------=_NextPart_000_013E_01C9BC88.2B7AC4D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirming HUM regarding = draft-zorn-dime-capablities-update-00

Hi all,

at the IETF#74 DIME meeting we = had a presentation about the "The Diameter Capabilities Update = Application" document:
http://tools.ietf.org/html/draft-zorn-dime-capablities-update-00

The group was in favor of turning = this document into a working group item.

If you have objections or if you = weren't at the meeting and would like to express your support for it = please let us know by the 24th April 2009.

Ciao
Hannes & Dave







------=_NextPart_000_013E_01C9BC88.2B7AC4D0-- From dromasca@avaya.com Tue Apr 14 02:47:02 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4313A67F4 for ; Tue, 14 Apr 2009 02:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDoRyGtjwiyf for ; Tue, 14 Apr 2009 02:47:01 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id A0E5D3A67A1 for ; Tue, 14 Apr 2009 02:47:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238990400"; d="scan'208";a="158327452" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 14 Apr 2009 05:48:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2009 05:48:11 -0400 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, 14 Apr 2009 11:48:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-mip6-split-16.txt Thread-index: Acm85h7c60JwolWiTp6KGCRtJX8mNQ== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] draft-ietf-dime-mip6-split-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 09:47:02 -0000 I placed draft-ietf-dime-mip6-split-16.txt on the agenda of the telechat on 4/23. My question is whether the issues raised by the IANA review were answered and the actions confirmed. Specifically, Amanda Baber asked in her review:=20 - In the "MIP6 Authentication Mode (MIP6-Auth-Mode AVP)" registry, is 0 reserved or available for assignment? Also, does this registry have an upper limit? Thanks and Regards, Dan =20 From jouni.nospam@gmail.com Tue Apr 14 03:24:27 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5B93A6840 for ; Tue, 14 Apr 2009 03:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xj1W95amxzS3 for ; Tue, 14 Apr 2009 03:24:26 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 375FF3A677C for ; Tue, 14 Apr 2009 03:24:26 -0700 (PDT) Received: by ewy9 with SMTP id 9so2558953ewy.37 for ; Tue, 14 Apr 2009 03:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=8tCIgYtq8vh1CP6aL9q18+NZ0qmgKYUebkuPsRWerHc=; b=AiwuEFTJcqZ/eLwe3ChCSMUGp8t9MCV+W+iRS0umXYD+E8lrkHZQAUCnjlRdIZsAwr 5D3bbKKfJlMsNr5NaAQkd6yzkcHUT98QrBuKgan2vbrZVNasgVvaijM1Czqzpm8NRvnW CB38mswnEz+0M1awonWCigNZGddoYqmO7goVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=NKTZF7wltAWsLkQTNrInp/hAbS4tXy2iQiWab9/jgIR492gilWC1cIm0zj1GbwtyJt dNbu1j4Sbq3BnutbmdWZqXQ9MjN2sNJi9QgvqIIpF8NPv2nDm93h0eHcUUyfrMvXCY6b W5ne/lR7rSfNUYe40Wxmr+7M3Nr83CJ4l86eM= Received: by 10.216.55.201 with SMTP id k51mr1734580wec.184.1239704736967; Tue, 14 Apr 2009 03:25:36 -0700 (PDT) Received: from ?10.183.180.77? ([192.100.124.156]) by mx.google.com with ESMTPS id t2sm15348903gve.2.2009.04.14.03.25.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 03:25:36 -0700 (PDT) Message-Id: From: jouni korhonen To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 13:25:34 +0300 References: X-Mailer: Apple Mail (2.930.3) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-mip6-split-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:24:27 -0000 Hi Dan, Yes, I responded to that on March 13, 2009 2:00:32 AM GMT+02:00. See below: >> >> - In the "MIP6 Authentication Mode (MIP6-Auth-Mode AVP)" registry, is >> 0 reserved or available for assignment? Also, does this registry have >> an upper limit? > > Good catch. The value 0 (zero) is reserved. The upper limit is > 4294967295 (i.e. 2^32-1). I also spotted an error in the proposed IANA allocations: >> >> Action 6 (Section 9.5): >> >> Upon approval of this document, IANA will create the following >> registry at >> http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml >> >> Registry Name: MIP6 Authentication Mode (MIP6-Auth-Mode AVP) >> Allocation Policy: Specification Required >> Initial contents of this sub-registry will be: >> >> Value Token Reference >> ---- ----- --------- >> 1 MIP6_SPLIT [RFC-dime-mip6-split-16] > > The token is: MIP6_AUTH_MN_AAA > > > Cheers, > Jouni Jouni On Apr 14, 2009, at 12:48 PM, Romascanu, Dan (Dan) wrote: > I placed draft-ietf-dime-mip6-split-16.txt on the agenda of the > telechat > on 4/23. My question is whether the issues raised by the IANA review > were answered and the actions confirmed. Specifically, Amanda Baber > asked in her review: > > - In the "MIP6 Authentication Mode (MIP6-Auth-Mode AVP)" registry, is > 0 reserved or available for assignment? Also, does this registry have > an upper limit? > > Thanks and Regards, > > Dan > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Tue Apr 14 03:26:47 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C92B3A68BA for ; Tue, 14 Apr 2009 03:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj1ZPMPavXnZ for ; Tue, 14 Apr 2009 03:26:46 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 86D4B3A677C for ; Tue, 14 Apr 2009 03:26:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238990400"; d="scan'208";a="158330174" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 14 Apr 2009 06:27:57 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 14 Apr 2009 06:27:56 -0400 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, 14 Apr 2009 12:27:53 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-ietf-dime-mip6-split-16.txt Thread-index: Acm861uHDpAJ16oxRuWaUmitcyBb2wAAByXA References: From: "Romascanu, Dan (Dan)" To: "jouni korhonen" Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-mip6-split-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:26:47 -0000 Thanks.=20 Do we need any changes in text by RFC Editor notes? If we do please recommend.=20 Dan =20 > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Tuesday, April 14, 2009 1:26 PM > To: Romascanu, Dan (Dan) > Cc: dime@ietf.org > Subject: Re: [Dime] draft-ietf-dime-mip6-split-16.txt >=20 > Hi Dan, >=20 > Yes, I responded to that on March 13, 2009 2:00:32 AM GMT+02:00. See > below: >=20 > >> > >> - In the "MIP6 Authentication Mode (MIP6-Auth-Mode AVP)"=20 > registry, is=20 > >> 0 reserved or available for assignment? Also, does this=20 > registry have=20 > >> an upper limit? > > > > Good catch. The value 0 (zero) is reserved. The upper limit is > > 4294967295 (i.e. 2^32-1). >=20 > I also spotted an error in the proposed IANA allocations: >=20 > >> > >> Action 6 (Section 9.5): > >> > >> Upon approval of this document, IANA will create the following=20 > >> registry at=20 > >> http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml > >> > >> Registry Name: MIP6 Authentication Mode (MIP6-Auth-Mode AVP)=20 > >> Allocation Policy: Specification Required Initial contents of this=20 > >> sub-registry will be: > >> > >> Value Token Reference > >> ---- ----- --------- > >> 1 MIP6_SPLIT [RFC-dime-mip6-split-16] > > > > The token is: MIP6_AUTH_MN_AAA > > > > > > Cheers, > > Jouni >=20 > Jouni >=20 > On Apr 14, 2009, at 12:48 PM, Romascanu, Dan (Dan) wrote: >=20 > > I placed draft-ietf-dime-mip6-split-16.txt on the agenda of the=20 > > telechat on 4/23. My question is whether the issues raised=20 > by the IANA=20 > > review were answered and the actions confirmed.=20 > Specifically, Amanda=20 > > Baber asked in her review: > > > > - In the "MIP6 Authentication Mode (MIP6-Auth-Mode AVP)"=20 > registry, is=20 > > 0 reserved or available for assignment? Also, does this=20 > registry have=20 > > an upper limit? > > > > Thanks and Regards, > > > > Dan > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 >=20 From dromasca@avaya.com Tue Apr 14 03:38:14 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D13D3A6D3E for ; Tue, 14 Apr 2009 03:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxq0Ve84GYRw for ; Tue, 14 Apr 2009 03:38:13 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 952C63A6AE3 for ; Tue, 14 Apr 2009 03:38:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,184,1238990400"; d="scan'208";a="158330917" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 14 Apr 2009 06:39:24 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2009 06:39:23 -0400 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, 14 Apr 2009 12:39:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-mip6-split-16.txt Thread-index: Acm4vcbRP28x3vMrSXGjK0bnlFKKwQEL1Sxw From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: draft-ietf-dime-mip6-split-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:38:14 -0000 Have these comments been addressed?=20 Dan =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Donald Eastlake Sent: Thursday, April 09, 2009 5:49 AM To: iesg@ietf.org; secdir@ietf.org; David Frascone; jouni@gmail.com; Hannes.Tschofenig@gmx.net; julien.bournelle@orange-ftgroup.com; gerardo.giaretta@gmail.com; madjid.nakhjiri@motorola.com Subject: draft-ietf-dime-mip6-split-16.txt I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document primarily specifies the interaction between a Mobile IP Home Agent and a Diameter server when an IPv6 Mobile Mode wants to bootstrap its operations dynamically through interaction between its Home Agent and the Diameter server of a Mobile Service Provider. General: I'm always a bit suspicious of draft that include several options and alternatives. These at least make the document more complex and increase the probability that some security flaw in one of the options/alternatives will be overlooked. Security: The Security Considerations section of this draft is pretty short and primarily refers to the Security Considerations of three other RFCs. It appears that the referenced documents, particularly RFC 5026 and the RFCs referenced by the Securities Considerations section of RFC 5026, are adequate. Nits: Given that the first two messages in the Figure 2 message flow diagram are annotated "(1)" and "(2)", it would seem like a good idea to add those annotations at an appropriate place in the subsequent text. "a IKEv2" -> "an IKEv2". First paragraph of 5.1: "a number AVPs" -> "a number of AVPs". Second paragraph of 5.2.1: "with a replay protection related information" -> "with replay protection related information". 9.5: "values" -> "value". 10: "in in" -> "in". Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com From jouni.nospam@gmail.com Tue Apr 14 04:36:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC593A6880 for ; Tue, 14 Apr 2009 04:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajBcoITWs49r for ; Tue, 14 Apr 2009 04:36:04 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 4F6223A6840 for ; Tue, 14 Apr 2009 04:35:41 -0700 (PDT) Received: by ewy9 with SMTP id 9so2589800ewy.37 for ; Tue, 14 Apr 2009 04:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=CFLGnOhbBDa22BX+nI4Ac0A1YHYDbILe6ybkDCcmVko=; b=JgI5tso7/LSuTvexZyM4kAFLetlCHrf9nolvnuxTt7FBTS3lYdVyv/nEIxaDjFdjII GUEdTAVb+9nLAebuoR5wyZFTWFdxa/AiVtgvI8HLmcUYRdl1vo0TmnW5xyJmUwitMIMX N7XzY7p2osd3MUJ+mX+fzS+HWzXMRsfV4+oZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=q2m/VLLH51VsUM/TYCsG87ViWhKtxdGqoGFrTqnxfot7BB/6j55pTYfAsCXgec6pHl U2wHzZukMjuobS8FWLV5M4xb++fvv0qW318hpX+Dr06yTjqtImbR6Ms3ijf1iYqH6IgV /LOaEM9FDzqgQohS5J3Iq5HrJPY8VLuaxFKUI= Received: by 10.216.29.84 with SMTP id h62mr1746635wea.122.1239709011968; Tue, 14 Apr 2009 04:36:51 -0700 (PDT) Received: from ?10.183.180.77? ([192.100.124.156]) by mx.google.com with ESMTPS id m5sm15420688gve.10.2009.04.14.04.36.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 04:36:51 -0700 (PDT) Message-Id: <31A97382-EB3B-4235-857D-D40F7F04797F@gmail.com> From: jouni korhonen To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 14:36:48 +0300 References: X-Mailer: Apple Mail (2.930.3) Cc: dime@ietf.org Subject: Re: [Dime] FW: draft-ietf-dime-mip6-split-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 11:36:05 -0000 Hi Dan, No they have not as I have not received the email (my email is wrong in that). I can take a look at them shortly. Cheers, Jouni On Apr 14, 2009, at 1:39 PM, Romascanu, Dan (Dan) wrote: > Have these comments been addressed? > > Dan > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of > Donald Eastlake > Sent: Thursday, April 09, 2009 5:49 AM > To: iesg@ietf.org; secdir@ietf.org; David Frascone; jouni@gmail.com; > Hannes.Tschofenig@gmx.net; julien.bournelle@orange-ftgroup.com; > gerardo.giaretta@gmail.com; madjid.nakhjiri@motorola.com > Subject: draft-ietf-dime-mip6-split-16.txt > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. > Document editors and WG chairs should treat these comments just like > any > other last call comments. > > This document primarily specifies the interaction between a Mobile IP > Home Agent and a Diameter server when an IPv6 Mobile Mode wants to > bootstrap its operations dynamically through interaction between its > Home Agent and the Diameter server of a Mobile Service Provider. > > General: I'm always a bit suspicious of draft that include several > options and alternatives. These at least make the document more > complex > and increase the probability that some security flaw in one of the > options/alternatives will be overlooked. > > Security: The Security Considerations section of this draft is pretty > short and primarily refers to the Security Considerations of three > other > RFCs. It appears that the referenced documents, particularly RFC > 5026 and the RFCs referenced by the Securities Considerations > section of > RFC 5026, are adequate. > > Nits: > > Given that the first two messages in the Figure 2 message flow diagram > are annotated "(1)" and "(2)", it would seem like a good idea to add > those annotations at an appropriate place in the subsequent text. > > "a IKEv2" -> "an IKEv2". > > First paragraph of 5.1: "a number AVPs" -> "a number of AVPs". > > Second paragraph of 5.2.1: "with a replay protection related > information" -> "with replay protection related information". > > 9.5: "values" -> "value". > > 10: "in in" -> "in". > > Thanks, > Donald > > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3@gmail.com > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Apr 14 04:59:20 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FD33A6D86 for ; Tue, 14 Apr 2009 04:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFZCmiL2WOuT for ; Tue, 14 Apr 2009 04:59:20 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 918BD3A6A90 for ; Tue, 14 Apr 2009 04:59:19 -0700 (PDT) Received: by ewy9 with SMTP id 9so2599990ewy.37 for ; Tue, 14 Apr 2009 05:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=lw3D/IG+3xwStk4lV9NT8mIpcXwbmOIRP78iyTQvmqo=; b=vkJF9LOEeE71SOp9fwRlrhGhdxTSuSvgO11MwwbXIP9QxmM57IpfZ1cet5hGDNfDWV YQp9WjxRxhgIDjqJdgNTQEwXnawJSeQqtR9k84g2Ltnyb2/aSGFom58rq2IuuMysutyT Xten83vCN5HcWM0IsnSv/x1xGQ6vJQP2zj5lA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=U2wwDS854lloTwcg6JOjDAm/FTzGHSsoy0v23Od40L5fGrewjJPl5mK6U7rGeE22Z1 ILzMg/wylv7TC87n5ARgjzqwYv9TfdWhHYmZMUHoaggs6WiStFLYDDEpcQe99hbGgi+W peLc1+Vm7sdRrM3MCGgRqP+2yYwTOBs0/krtU= Received: by 10.216.36.79 with SMTP id v57mr1760213wea.19.1239710430236; Tue, 14 Apr 2009 05:00:30 -0700 (PDT) Received: from ?10.183.180.77? ([192.100.124.156]) by mx.google.com with ESMTPS id q9sm6159573gve.15.2009.04.14.05.00.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 05:00:29 -0700 (PDT) Message-Id: From: jouni korhonen To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 15:00:27 +0300 References: X-Mailer: Apple Mail (2.930.3) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-mip6-split-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 11:59:21 -0000 Hi Dan, The IANA considerations in the draft are correct (regarding the Action 6). For the clarification on the "MIP6 Authentication Mode" registry I would replace the text in Section 9.5: OLD: IANA is requested to create a new registry "MIP6 Authentication Mode" registry for use with the enumerated MIP6-Auth-Mode AVP. The registry will initially contain the following values: Token | Value | Description ---------------------------------------------+---------- +------------ MIP6_AUTH_MN_AAA | 1 | RFC TBD NEW: IANA is requested to create a new registry "MIP6 Authentication Mode" registry for use with the enumerated MIP6-Auth-Mode AVP. The value 0 (zero) is reserved and the maximum value is 4294967295 (i.e. 2^32-1). The registry will initially contain the following values: Token | Value | Description ---------------------------------------------+---------- +------------ MIP6_AUTH_MN_AAA | 1 | RFC TBD Cheers, jouni On Apr 14, 2009, at 1:27 PM, Romascanu, Dan (Dan) wrote: > Thanks. > > Do we need any changes in text by RFC Editor notes? If we do please > recommend. > > Dan > > >> -----Original Message----- >> From: jouni korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Tuesday, April 14, 2009 1:26 PM >> To: Romascanu, Dan (Dan) >> Cc: dime@ietf.org >> Subject: Re: [Dime] draft-ietf-dime-mip6-split-16.txt >> >> Hi Dan, >> >> Yes, I responded to that on March 13, 2009 2:00:32 AM GMT+02:00. See >> below: >> >>>> >>>> - In the "MIP6 Authentication Mode (MIP6-Auth-Mode AVP)" >> registry, is >>>> 0 reserved or available for assignment? Also, does this >> registry have >>>> an upper limit? >>> >>> Good catch. The value 0 (zero) is reserved. The upper limit is >>> 4294967295 (i.e. 2^32-1). >> >> I also spotted an error in the proposed IANA allocations: >> >>>> >>>> Action 6 (Section 9.5): >>>> >>>> Upon approval of this document, IANA will create the following >>>> registry at >>>> http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml >>>> >>>> Registry Name: MIP6 Authentication Mode (MIP6-Auth-Mode AVP) >>>> Allocation Policy: Specification Required Initial contents of this >>>> sub-registry will be: >>>> >>>> Value Token Reference >>>> ---- ----- --------- >>>> 1 MIP6_SPLIT [RFC-dime-mip6-split-16] >>> >>> The token is: MIP6_AUTH_MN_AAA >>> >>> >>> Cheers, >>> Jouni >> >> Jouni >> >> On Apr 14, 2009, at 12:48 PM, Romascanu, Dan (Dan) wrote: >> >>> I placed draft-ietf-dime-mip6-split-16.txt on the agenda of the >>> telechat on 4/23. My question is whether the issues raised >> by the IANA >>> review were answered and the actions confirmed. >> Specifically, Amanda >>> Baber asked in her review: >>> >>> - In the "MIP6 Authentication Mode (MIP6-Auth-Mode AVP)" >> registry, is >>> 0 reserved or available for assignment? Also, does this >> registry have >>> an upper limit? >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> >> From dromasca@avaya.com Tue Apr 14 05:01:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE633A67E6 for ; Tue, 14 Apr 2009 05:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH91din4GrK8 for ; Tue, 14 Apr 2009 05:01:04 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id CC5193A6D3E for ; Tue, 14 Apr 2009 05:00:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,184,1238990400"; d="scan'208,217";a="158336853" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 14 Apr 2009 08:02:08 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2009 08:02:07 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BCF8.C430218A" Date: Tue, 14 Apr 2009 14:01:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-ietf-dime-mip6-split-16.txt Thread-index: Acm8+KECKqTy4tn+SxW0zJM9GG12xQAABHMa References: From: "Romascanu, Dan (Dan)" To: "jouni korhonen" Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-mip6-split-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 12:01:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BCF8.C430218A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, thanks - I will create the appropriate notes to the RFC Editor.=20 Regards, Dan -----Original Message----- From: jouni korhonen [mailto:jouni.nospam@gmail.com] Sent: Tue 4/14/2009 3:00 PM To: Romascanu, Dan (Dan) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-mip6-split-16.txt =20 Hi Dan, The IANA considerations in the draft are correct (regarding the Action =20 6). For the clarification on the "MIP6 Authentication Mode" registry I =20 would replace the text in Section 9.5: OLD: IANA is requested to create a new registry "MIP6 Authentication =20 Mode" registry for use with the enumerated MIP6-Auth-Mode AVP. The registry will initially contain the following values: Token | Value | =20 Description ---------------------------------------------+----------=20 +------------ MIP6_AUTH_MN_AAA | 1 | RFC TBD NEW: IANA is requested to create a new registry "MIP6 Authentication =20 Mode" registry for use with the enumerated MIP6-Auth-Mode AVP. The value 0 (zero) is reserved and the maximum value is 4294967295 (i.e. =20 2^32-1). The registry will initially contain the following values: Token | Value | =20 Description ---------------------------------------------+----------=20 +------------ MIP6_AUTH_MN_AAA | 1 | RFC TBD Cheers, jouni On Apr 14, 2009, at 1:27 PM, Romascanu, Dan (Dan) wrote: > Thanks. > > Do we need any changes in text by RFC Editor notes? If we do please > recommend. > > Dan > > >> -----Original Message----- >> From: jouni korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Tuesday, April 14, 2009 1:26 PM >> To: Romascanu, Dan (Dan) >> Cc: dime@ietf.org >> Subject: Re: [Dime] draft-ietf-dime-mip6-split-16.txt >> >> Hi Dan, >> >> Yes, I responded to that on March 13, 2009 2:00:32 AM GMT+02:00. See >> below: >> >>>> >>>> - In the "MIP6 Authentication Mode (MIP6-Auth-Mode AVP)" >> registry, is >>>> 0 reserved or available for assignment? Also, does this >> registry have >>>> an upper limit? >>> >>> Good catch. The value 0 (zero) is reserved. The upper limit is >>> 4294967295 (i.e. 2^32-1). >> >> I also spotted an error in the proposed IANA allocations: >> >>>> >>>> Action 6 (Section 9.5): >>>> >>>> Upon approval of this document, IANA will create the following >>>> registry at >>>> http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml >>>> >>>> Registry Name: MIP6 Authentication Mode (MIP6-Auth-Mode AVP) >>>> Allocation Policy: Specification Required Initial contents of this >>>> sub-registry will be: >>>> >>>> Value Token Reference >>>> ---- ----- --------- >>>> 1 MIP6_SPLIT [RFC-dime-mip6-split-16] >>> >>> The token is: MIP6_AUTH_MN_AAA >>> >>> >>> Cheers, >>> Jouni >> >> Jouni >> >> On Apr 14, 2009, at 12:48 PM, Romascanu, Dan (Dan) wrote: >> >>> I placed draft-ietf-dime-mip6-split-16.txt on the agenda of the >>> telechat on 4/23. My question is whether the issues raised >> by the IANA >>> review were answered and the actions confirmed. >> Specifically, Amanda >>> Baber asked in her review: >>> >>> - In the "MIP6 Authentication Mode (MIP6-Auth-Mode AVP)" >> registry, is >>> 0 reserved or available for assignment? Also, does this >> registry have >>> an upper limit? >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> >> ------_=_NextPart_001_01C9BCF8.C430218A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Dime] draft-ietf-dime-mip6-split-16.txt

OK, thanks - I will create the appropriate notes to = the RFC Editor.

Regards,

Dan

-----Original Message-----
From: jouni korhonen [mailto:jouni.nospam@gmail.com]=
Sent: Tue 4/14/2009 3:00 PM
To: Romascanu, Dan (Dan)
Cc: dime@ietf.org
Subject: Re: [Dime] draft-ietf-dime-mip6-split-16.txt


Hi Dan,

The IANA considerations in the draft are correct (regarding the = Action 
6). For the clarification on the "MIP6 Authentication Mode" = registry I 
would replace the text in Section 9.5:

OLD:

    IANA is requested to create a new registry "MIP6 = Authentication 
Mode"
    registry for use with the enumerated MIP6-Auth-Mode = AVP.  The
    registry will initially contain the following = values:

    = Token           &n= bsp;           &nb= sp;           &nbs= p;    | Value    | 
Description
    = ---------------------------------------------+----------
+------------
    = MIP6_AUTH_MN_AAA         &nb= sp;           &nbs= p;       | = 1        | RFC TBD

NEW:

    IANA is requested to create a new registry "MIP6 = Authentication 
Mode"
    registry for use with the enumerated MIP6-Auth-Mode = AVP. The value
    0 (zero) is reserved and the maximum value is = 4294967295 (i.e. 
2^32-1).
    The registry will initially contain the following = values:

    = Token           &n= bsp;           &nb= sp;           &nbs= p;    | Value    | 
Description
    = ---------------------------------------------+----------
+------------
    = MIP6_AUTH_MN_AAA         &nb= sp;           &nbs= p;       | = 1        | RFC TBD


Cheers,
        jouni



On Apr 14, 2009, at 1:27 PM, Romascanu, Dan (Dan) wrote:

> Thanks.
>
> Do we need any changes in text by RFC Editor notes? If we do = please
> recommend.
>
> Dan
>
>
>> -----Original Message-----
>> From: jouni korhonen [mailto:jouni.nospam@gmail.com]=
>> Sent: Tuesday, April 14, 2009 1:26 PM
>> To: Romascanu, Dan (Dan)
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] draft-ietf-dime-mip6-split-16.txt
>>
>> Hi Dan,
>>
>> Yes, I responded to that on March 13, 2009 2:00:32 AM = GMT+02:00. See
>> below:
>>
>>>>
>>>> - In the "MIP6 Authentication Mode (MIP6-Auth-Mode = AVP)"
>> registry, is
>>>> 0 reserved or available for assignment? Also, does = this
>> registry have
>>>> an upper limit?
>>>
>>> Good catch. The value 0 (zero) is reserved. The upper limit = is
>>> 4294967295 (i.e. 2^32-1).
>>
>> I also spotted an error in the proposed IANA allocations:
>>
>>>>
>>>> Action 6 (Section 9.5):
>>>>
>>>> Upon approval of this document, IANA will create the = following
>>>> registry at
>>>> = http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml
>>>>
>>>> Registry Name: MIP6 Authentication Mode (MIP6-Auth-Mode = AVP)
>>>> Allocation Policy: Specification Required Initial = contents of this
>>>> sub-registry will be:
>>>>
>>>> Value Token Reference
>>>> ---- ----- ---------
>>>> 1 MIP6_SPLIT [RFC-dime-mip6-split-16]
>>>
>>> The token is: MIP6_AUTH_MN_AAA
>>>
>>>
>>> Cheers,
>>>     Jouni
>>
>> Jouni
>>
>> On Apr 14, 2009, at 12:48 PM, Romascanu, Dan (Dan) wrote:
>>
>>> I placed draft-ietf-dime-mip6-split-16.txt on the agenda of = the
>>> telechat on 4/23. My question is whether the issues = raised
>> by the IANA
>>> review were answered and the actions confirmed.
>> Specifically, Amanda
>>> Baber asked in her review:
>>>
>>> - In the "MIP6 Authentication Mode (MIP6-Auth-Mode = AVP)"
>> registry, is
>>> 0 reserved or available for assignment? Also, does this
>> registry have
>>> an upper limit?
>>>
>>> Thanks and Regards,
>>>
>>> Dan
>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/= mailman/listinfo/dime
>>
>>

------_=_NextPart_001_01C9BCF8.C430218A-- From frascone@gmail.com Tue Apr 14 06:32:53 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579BC3A68DF for ; Tue, 14 Apr 2009 06:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh4F54iS4WQD for ; Tue, 14 Apr 2009 06:32:52 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 9062E3A6873 for ; Tue, 14 Apr 2009 06:32:52 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2220216rvb.49 for ; Tue, 14 Apr 2009 06:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=dKIVXUMwoB4V/hY3f1FJA+6LAKMXTUtVm3fLpSK/WrM=; b=Bp6S+vgQMksusOVLd+UflJyMeNCYTToxHl9yU5BFwQ8WcoLBrEIf22bkuOx9oO2W23 db3l5h1wxQ/9clddFYbpE+Qu7zDZZTF8HhPCl3phXMurGqJgyhOPaw1ohZyrcHj7uxJX ae4Ohl5Ax42c6nqF4Phj4IO36+x40ItZHUZOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=BzZc83XfBarV0SPJLfp5y6FIi3eoj3u+jyF+qvsa/HIDoFguFE8amgnrep96mJ+zGU rzm7ju5ki/BZ5Bmm0Ba4Mfm3T/vYSvzieiKrXg69vFPpxFh9ZijHcmkHjrjg1MTqd6yv HxDm9hE+9E2l9wruQzO7uTrhQQijCz7fmBLqE= MIME-Version: 1.0 Sender: frascone@gmail.com Received: by 10.141.4.20 with SMTP id g20mr3203224rvi.173.1239716044010; Tue, 14 Apr 2009 06:34:04 -0700 (PDT) In-Reply-To: <013201c9bc6e$e0f8b570$0201a8c0@nsnintra.net> References: <013201c9bc6e$e0f8b570$0201a8c0@nsnintra.net> Date: Tue, 14 Apr 2009 09:34:03 -0400 X-Google-Sender-Auth: 3ac4af440647c355 Message-ID: <9cf5ced20904140634j54c3dd3bl85a6070b02a268e2@mail.gmail.com> From: David Frascone To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=000e0cd0ebda6cf5b7046783e2f4 Cc: dime@ietf.org Subject: Re: [Dime] Confirming HUM regarding draft-brockners-diameter-nat-control-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 13:32:53 -0000 --000e0cd0ebda6cf5b7046783e2f4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I support moving forward with this. -Dave On Mon, Apr 13, 2009 at 3:34 PM, Hannes Tschofenig < Hannes.Tschofenig@gmx.net> wrote: > Hi all, > > at the IETF#74 DIME meeting we had a presentation about the "Diameter NAT > Control Application" document: > > http://www.ietf.org/internet-drafts/draft-brockners-diameter-nat-control-00. > txt > > The group was in favor of turning this document into a working group item. > > If you have objections or if you weren't at the meeting and would like to > express your support for it please let us know by the 24th April 2009. > > Ciao > Hannes & Dave > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --000e0cd0ebda6cf5b7046783e2f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support moving forward with this.

-Dave

On Mon, Apr 13, 2009 at 3:34 PM, Hannes Tschofenig <Hannes.Tscho= fenig@gmx.net> wrote:
Hi all,

at the IETF#74 DIME meeting we had a presentation about the "Diameter = NAT
Control Application" document:
http://www.ietf.org/internet-drafts/draft-brockners-= diameter-nat-control-00.
txt

The group was in favor of turning this document into a working group item.<= br>
If you have objections or if you weren't at the meeting and would like = to
express your support for it please let us know by the 24th April 2009.

Ciao
Hannes & Dave

_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--000e0cd0ebda6cf5b7046783e2f4-- From root@core3.amsl.com Thu Apr 16 01:45:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2E3C63A684F; Thu, 16 Apr 2009 01:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090416084501.2E3C63A684F@core3.amsl.com> Date: Thu, 16 Apr 2009 01:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-pmip6-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 08:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-pmip6-02.txt Pages : 19 Date : 2009-04-16 This specification defines the Diameter support for the Proxy Mobile IPv6 and the corresponding mobility service session setup. The policy information needed by the Proxy Mobile IPv6 is defined in mobile node's policy profile, which could be downloaded from the Diameter server to the Mobile Access Gateway once the mobile node attaches to a Proxy Mobile IPv6 Domain and performs access authentication. During the binding update exchange between the Mobile Access Gateway and the Local Mobility Anchor, the Local Mobility Anchor can interact with the Diameter server in order to update the remote policy store with the mobility session related information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dime-pmip6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-16013753.I-D@ietf.org> --NextPart-- From vfajardo@tari.toshiba.com Thu Apr 16 07:52:46 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA573A6F75 for ; Thu, 16 Apr 2009 07:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM2UP7TxCruL for ; Thu, 16 Apr 2009 07:52:31 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id 572223A6DA8 for ; Thu, 16 Apr 2009 07:52:31 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id n3GErhes003816 for ; Thu, 16 Apr 2009 23:53:43 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id n3GErhXe014271 for dime@ietf.org; Thu, 16 Apr 2009 23:53:43 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id ZAA14269; Thu, 16 Apr 2009 23:53:43 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id n3GErgc3012445 for ; Thu, 16 Apr 2009 23:53:42 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n3GErgi0012148; Thu, 16 Apr 2009 23:53:42 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n3GErg18008111 for ; Thu, 16 Apr 2009 23:53:42 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n3GEreLR027084 for ; Thu, 16 Apr 2009 23:53:41 +0900 (JST) Received: from [127.0.0.1] (mail.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n3GEvCnw058328 for ; Thu, 16 Apr 2009 10:57:12 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49E74673.7030109@tari.toshiba.com> Date: Thu, 16 Apr 2009 10:53:39 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "dime@ietf.org" References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 14:52:46 -0000 If there are no more comments/objections/opinions, we will incorporate Mark's proposal into the next rev of bis. Here's a summary: * Capabilities update will be kept in bis for backward compatibility but will be considered a 'noop' and text will be added that this feature is deprecated and that future work will properly cover this functionality. * Fixes to TLS negotiation will be rolled back to retain backward compatibility but strong language regarding its vulnerability will be added. Additional text noting that fixes to this issue will be done in the new revision of diameter will be introduced. regards, victor >> I fully support Sebastien. If bis is not given a new version number, >> there are different protocols in the wild which claim to be the very >> same protocol. These protocols are not interoperable with each other, >> and their differences are subtle. I suspect implementation nightmares >> dead ahead. >> >> > > Version 1 is already out in the wild and two independent implementations of RFC3588 may not interoperate. So we spent 18 months on bug fixes in 3588bis to greatly improve the odds that they can interoperate. Implementers finding contradictions or ambiguities in RFC3588 have been able to turn to 3588bis for clarification. Throughout that time Victor was strict in enforcing solutions that were backwards compatible. > > Recently we discover two issues (TLS negotiation and capabilities update) and find we can not fix them without breaking backwards compatibility. Given that no one noticed these problems until now, I strongly suspect these are not critical features of the Diameter base protocol. For Capabilities Update, we chose to deprecate the feature in bis rather than fix it and Glen captured a solution in a separate draft. If offered the choice at that point, I believe the majority of delegates would have been preferred a similar approach for TLS negotiation rather than bump the version. > > >> I acknowledge that it's a pity that the plan not to introduce >> incompatible changes in bis couldn't be upheld. But >> regardless of that: >> these *are* two different protocols, and they *really really >> should* be >> easily distinguishable from each other. >> >> > > The original plan for 3588bis was sound and is still required. IMO the decision to address TLS negotiation in bis knowing that the fix was not backwards compatible was our error. I vote we deprecate this feature in 3588bis, move the proposed solution to a new draft (Diameter v2 if required) and get 3588bis out the door. > > Regards > Mark > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > From lionel.morand@orange-ftgroup.com Fri Apr 17 00:36:16 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550923A68DB for ; Fri, 17 Apr 2009 00:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqlmTIrq-D+a for ; Fri, 17 Apr 2009 00:36:15 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 07A893A685A for ; Fri, 17 Apr 2009 00:36:14 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 09: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 09:37:23 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026065E7EB6@ftrdmel2> In-Reply-To: <49E74673.7030109@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] rfc3588bis version number Thread-Index: Acm+ozFUYQ+JriiJQDO6mEZY6eBSbwAi2FXQ References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp><49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> From: To: , X-OriginalArrivalTime: 17 Apr 2009 07:37:26.0453 (UTC) FILETIME=[5ACD1E50:01C9BF2F] Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 07:36:16 -0000 I can live with this proposal. But I would definitly prefer to fix in this version existing issues that = cause anyway interoperability or vulnerability problem. There is no shame to say: "Sorry, we messed up!". And we can do it = without changing the version number. Fixing bugs is something inherent = to a protocol live cycle and this Bis version could be one them for = Diameter. Increasing the version number should be reserved for = functional protocol updates. Just "my humble opinion"... BR, Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Victor Fajardo > Envoy=E9 : jeudi 16 avril 2009 16:54 > =C0 : dime@ietf.org > Objet : Re: [Dime] rfc3588bis version number >=20 > If there are no more comments/objections/opinions, we will=20 > incorporate Mark's proposal into the next rev of bis. Here's=20 > a summary: >=20 > * Capabilities update will be kept in bis for backward=20 > compatibility but will be considered a 'noop' and text will=20 > be added that this feature is deprecated and that future work=20 > will properly cover this functionality. >=20 > * Fixes to TLS negotiation will be rolled back to retain=20 > backward compatibility but strong language regarding its=20 > vulnerability will be added. Additional text noting that=20 > fixes to this issue will be done in the new revision of=20 > diameter will be introduced. >=20 > regards, > victor >=20 > >> I fully support Sebastien. If bis is not given a new=20 > version number,=20 > >> there are different protocols in the wild which claim to=20 > be the very=20 > >> same protocol. These protocols are not interoperable with=20 > each other,=20 > >> and their differences are subtle. I suspect implementation=20 > nightmares=20 > >> dead ahead. > >> > >> =20 > > > > Version 1 is already out in the wild and two independent=20 > implementations of RFC3588 may not interoperate. So we spent=20 > 18 months on bug fixes in 3588bis to greatly improve the odds=20 > that they can interoperate. Implementers finding=20 > contradictions or ambiguities in RFC3588 have been able to=20 > turn to 3588bis for clarification. Throughout that time=20 > Victor was strict in enforcing solutions that were backwards=20 > compatible. > > > > Recently we discover two issues (TLS negotiation and=20 > capabilities update) and find we can not fix them without=20 > breaking backwards compatibility. Given that no one noticed=20 > these problems until now, I strongly suspect these are not=20 > critical features of the Diameter base protocol. For=20 > Capabilities Update, we chose to deprecate the feature in bis=20 > rather than fix it and Glen captured a solution in a separate=20 > draft. If offered the choice at that point, I believe the=20 > majority of delegates would have been preferred a similar=20 > approach for TLS negotiation rather than bump the version. > > > > =20 > >> I acknowledge that it's a pity that the plan not to introduce=20 > >> incompatible changes in bis couldn't be upheld. But regardless of=20 > >> that: > >> these *are* two different protocols, and they *really really > >> should* be > >> easily distinguishable from each other. > >> > >> =20 > > > > The original plan for 3588bis was sound and is still=20 > required. IMO the decision to address TLS negotiation in bis=20 > knowing that the fix was not backwards compatible was our=20 > error. I vote we deprecate this feature in 3588bis, move the=20 > proposed solution to a new draft (Diameter v2 if required)=20 > and get 3588bis out the door. > > > > Regards > > Mark > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > =20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From gwz@net-zen.net Fri Apr 17 00:38:01 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA51C3A6991 for ; Fri, 17 Apr 2009 00:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7gATyOsj93I for ; Fri, 17 Apr 2009 00:38:01 -0700 (PDT) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-01.prod.mesa1.secureserver.net [64.202.165.235]) by core3.amsl.com (Postfix) with SMTP id 0CCFE3A68DB for ; Fri, 17 Apr 2009 00:38:00 -0700 (PDT) Received: (qmail 373 invoked from network); 17 Apr 2009 07:39:14 -0000 Received: from unknown (124.120.230.129) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 17 Apr 2009 07:39:13 -0000 From: "Glen Zorn" To: "'Victor Fajardo'" , References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> In-Reply-To: <49E74673.7030109@tari.toshiba.com> Date: Fri, 17 Apr 2009 14:38:59 +0700 Organization: Network Zen Message-ID: <000001c9bf2f$94ab4430$be01cc90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+oy4mXJYMxvbIQDGPimloKPSD/AAiC+Dg Content-Language: en-us Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 07:38:02 -0000 Victor Fajardo [mailto://vfajardo@tari.toshiba.com] writes: > If there are no more comments/objections/opinions, we will incorporate > Mark's proposal into the next rev of bis. Here's a summary: > > * Capabilities update will be kept in bis for backward compatibility > but > will be considered a 'noop' and text will be added that this feature is > deprecated and that future work will properly cover this functionality. > > * Fixes to TLS negotiation will be rolled back to retain backward > compatibility but strong language regarding its vulnerability will be > added. Additional text noting that fixes to this issue will be done in > the new revision of diameter will be introduced. If these are really the only two problems, is such a drastic approach really necessary? It seems to me that the problems could be fairly easily solved with appropriate weasel-wording - no, I mean clever usage of standards language ;-). For example, something like Implementations MAY {old way of doing X}; however, implementations SHOULD {new way of doing X. If one way or the other is required, say so w/a MUST. Doesn't this work? > > regards, > victor > > >> I fully support Sebastien. If bis is not given a new version number, > >> there are different protocols in the wild which claim to be the very > >> same protocol. These protocols are not interoperable with each > other, > >> and their differences are subtle. I suspect implementation > nightmares > >> dead ahead. > >> > >> > > > > Version 1 is already out in the wild and two independent > implementations of RFC3588 may not interoperate. So we spent 18 months > on bug fixes in 3588bis to greatly improve the odds that they can > interoperate. Implementers finding contradictions or ambiguities in > RFC3588 have been able to turn to 3588bis for clarification. Throughout > that time Victor was strict in enforcing solutions that were backwards > compatible. > > > > Recently we discover two issues (TLS negotiation and capabilities > update) and find we can not fix them without breaking backwards > compatibility. Given that no one noticed these problems until now, I > strongly suspect these are not critical features of the Diameter base > protocol. For Capabilities Update, we chose to deprecate the feature in > bis rather than fix it and Glen captured a solution in a separate > draft. If offered the choice at that point, I believe the majority of > delegates would have been preferred a similar approach for TLS > negotiation rather than bump the version. > > > > > >> I acknowledge that it's a pity that the plan not to introduce > >> incompatible changes in bis couldn't be upheld. But > >> regardless of that: > >> these *are* two different protocols, and they *really really > >> should* be > >> easily distinguishable from each other. > >> > >> > > > > The original plan for 3588bis was sound and is still required. IMO > the decision to address TLS negotiation in bis knowing that the fix was > not backwards compatible was our error. I vote we deprecate this > feature in 3588bis, move the proposed solution to a new draft (Diameter > v2 if required) and get 3588bis out the door. > > > > Regards > > Mark > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange-ftgroup.com Fri Apr 17 01:52:02 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEC43A6841 for ; Fri, 17 Apr 2009 01:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeUb6l7VQK8F for ; Fri, 17 Apr 2009 01:52:01 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 9051028C150 for ; Fri, 17 Apr 2009 01:52:00 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 10:53:06 +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 Date: Fri, 17 Apr 2009 10:53:09 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> In-Reply-To: <000001c9bf2f$94ab4430$be01cc90$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] rfc3588bis version number Thread-Index: Acm+oy4mXJYMxvbIQDGPimloKPSD/AAiC+DgAAFOFfA= References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> From: To: , , X-OriginalArrivalTime: 17 Apr 2009 08:53:06.0248 (UTC) FILETIME=[ECBADC80:01C9BF39] Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:52:02 -0000 =20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Glen Zorn > Envoy=E9 : vendredi 17 avril 2009 09:39 > =C0 : 'Victor Fajardo'; dime@ietf.org > Objet : Re: [Dime] rfc3588bis version number >=20 > Victor Fajardo [mailto://vfajardo@tari.toshiba.com] writes: >=20 > > If there are no more comments/objections/opinions, we will=20 > incorporate=20 > > Mark's proposal into the next rev of bis. Here's a summary: > >=20 > > * Capabilities update will be kept in bis for backward=20 > compatibility=20 > > but will be considered a 'noop' and text will be added that this=20 > > feature is deprecated and that future work will properly cover this=20 > > functionality. > >=20 > > * Fixes to TLS negotiation will be rolled back to retain backward=20 > > compatibility but strong language regarding its=20 > vulnerability will be=20 > > added. Additional text noting that fixes to this issue will=20 > be done in=20 > > the new revision of diameter will be introduced. >=20 > If these are really the only two problems, is such a drastic=20 > approach really necessary? It seems to me that the problems=20 > could be fairly easily solved with appropriate weasel-wording=20 > - no, I mean clever usage of standards language ;-). For=20 > example, something like=20 >=20 > Implementations MAY {old way of doing X}; however,=20 > implementations SHOULD {new way of doing X. >=20 > If one way or the other is required, say so w/a MUST. =20 > Doesn't this work? If keeping track of the previous way of doing is something foreseen, I = would go for this approach. I was assuming that having a new RFC number obsoleting the previous one = had the same purpose. It is a hint for vendors for checking what should = be fixed in their pre-existing Diameter implementation and up to them to = do the necessary changes. And the Diameter vendor newbees, they are not = bothered by "old stuff". At least, it was the way of doing for MIPv4 for = instance that has been be updated something like four times, a standard = solution without any version number... Lionel >=20 > =20 > >=20 > > regards, > > victor > >=20 > > >> I fully support Sebastien. If bis is not given a new version=20 > > >> number, there are different protocols in the wild which=20 > claim to be=20 > > >> the very same protocol. These protocols are not=20 > interoperable with=20 > > >> each > > other, > > >> and their differences are subtle. I suspect implementation > > nightmares > > >> dead ahead. > > >> > > >> > > > > > > Version 1 is already out in the wild and two independent > > implementations of RFC3588 may not interoperate. So we=20 > spent 18 months=20 > > on bug fixes in 3588bis to greatly improve the odds that they can=20 > > interoperate. Implementers finding contradictions or ambiguities in > > RFC3588 have been able to turn to 3588bis for clarification.=20 > > Throughout that time Victor was strict in enforcing solutions that=20 > > were backwards compatible. > > > > > > Recently we discover two issues (TLS negotiation and capabilities > > update) and find we can not fix them without breaking backwards=20 > > compatibility. Given that no one noticed these problems=20 > until now, I=20 > > strongly suspect these are not critical features of the=20 > Diameter base=20 > > protocol. For Capabilities Update, we chose to deprecate=20 > the feature=20 > > in bis rather than fix it and Glen captured a solution in a=20 > separate=20 > > draft. If offered the choice at that point, I believe the=20 > majority of=20 > > delegates would have been preferred a similar approach for TLS=20 > > negotiation rather than bump the version. > > > > > > > > >> I acknowledge that it's a pity that the plan not to introduce=20 > > >> incompatible changes in bis couldn't be upheld. But=20 > regardless of=20 > > >> that: > > >> these *are* two different protocols, and they *really really > > >> should* be > > >> easily distinguishable from each other. > > >> > > >> > > > > > > The original plan for 3588bis was sound and is still required. IMO > > the decision to address TLS negotiation in bis knowing that the fix=20 > > was not backwards compatible was our error. I vote we=20 > deprecate this=20 > > feature in 3588bis, move the proposed solution to a new draft=20 > > (Diameter > > v2 if required) and get 3588bis out the door. > > > > > > Regards > > > Mark > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > > > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From hannes.tschofenig@nsn.com Fri Apr 17 05:13:52 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1E73A6F6F for ; Fri, 17 Apr 2009 05:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjSEFrlCvdgd for ; Fri, 17 Apr 2009 05:13:51 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 7C2B43A6DCA for ; Fri, 17 Apr 2009 05:13:50 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3HCF23n014177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Apr 2009 14:15:02 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3HCF2oW027723 for ; Fri, 17 Apr 2009 14:15:02 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 14:15:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BF56.222214A0" Date: Fri, 17 Apr 2009 15:16:29 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501449790@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME Meeting Minutes - IETF#74 Thread-Index: Acm/VlYzYC8/4NwaTnCbVrZpeQa3zg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 17 Apr 2009 12:15:02.0265 (UTC) FILETIME=[22705690:01C9BF56] Subject: [Dime] DIME Meeting Minutes - IETF#74 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 12:13:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF56.222214A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For some reason this mail did not appear on the DIME mailing list archive.=20 ---- Victor has uploaded the meeting minutes:=20 http://www.ietf.org/proceedings/09mar/minutes/dime.txt Ciao Hannes ------_=_NextPart_001_01C9BF56.222214A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIME Meeting Minutes - IETF#74

For some reason this mail did not = appear on the DIME mailing list archive.

----

Victor has uploaded the meeting = minutes:
http://www.ietf.org/proceedings/09mar/minutes/dime.txt

Ciao
Hannes

------_=_NextPart_001_01C9BF56.222214A0-- From vfajardo@tari.toshiba.com Fri Apr 17 05:57:56 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574023A6833 for ; Fri, 17 Apr 2009 05:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XR0apD8zkl+e for ; Fri, 17 Apr 2009 05:57:55 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id E78D23A69CA for ; Fri, 17 Apr 2009 05:57:54 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id n3HCx7eE004339; Fri, 17 Apr 2009 21:59:07 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id n3HCx7vI017302; Fri, 17 Apr 2009 21:59:07 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id XAA17301; Fri, 17 Apr 2009 21:59:07 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id n3HCx7Va018385; Fri, 17 Apr 2009 21:59:07 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n3HCx7jO000894; Fri, 17 Apr 2009 21:59:07 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n3HCx6kM008819; Fri, 17 Apr 2009 21:59:06 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n3HCx52h024119; Fri, 17 Apr 2009 21:59:05 +0900 (JST) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n3HD2XP7070587; Fri, 17 Apr 2009 09:02:34 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49E87D17.6040400@tari.toshiba.com> Date: Fri, 17 Apr 2009 08:59:03 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: lionel.morand@orange-ftgroup.com References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 12:57:56 -0000 Hi, >> If these are really the only two problems, is such a drastic >> approach really necessary? It seems to me that the problems >> could be fairly easily solved with appropriate weasel-wording >> - no, I mean clever usage of standards language ;-). For >> example, something like >> >> Implementations MAY {old way of doing X}; however, >> implementations SHOULD {new way of doing X. >> >> If one way or the other is required, say so w/a MUST. >> Doesn't this work? >> > > If keeping track of the previous way of doing is something foreseen, I would go for this approach. > I don't mind going with Glen's approach. It would work in our give case. Any other thoughts ? -- victor > I was assuming that having a new RFC number obsoleting the previous one had the same purpose. It is a hint for vendors for checking what should be fixed in their pre-existing Diameter implementation and up to them to do the necessary changes. And the Diameter vendor newbees, they are not bothered by "old stuff". At least, it was the way of doing for MIPv4 for instance that has been be updated something like four times, a standard solution without any version number... > > Lionel > > >> >> >>> regards, >>> victor >>> >>> >>>>> I fully support Sebastien. If bis is not given a new version >>>>> number, there are different protocols in the wild which >>>>> >> claim to be >> >>>>> the very same protocol. These protocols are not >>>>> >> interoperable with >> >>>>> each >>>>> >>> other, >>> >>>>> and their differences are subtle. I suspect implementation >>>>> >>> nightmares >>> >>>>> dead ahead. >>>>> >>>>> >>>>> >>>> Version 1 is already out in the wild and two independent >>>> >>> implementations of RFC3588 may not interoperate. So we >>> >> spent 18 months >> >>> on bug fixes in 3588bis to greatly improve the odds that they can >>> interoperate. Implementers finding contradictions or ambiguities in >>> RFC3588 have been able to turn to 3588bis for clarification. >>> Throughout that time Victor was strict in enforcing solutions that >>> were backwards compatible. >>> >>>> Recently we discover two issues (TLS negotiation and capabilities >>>> >>> update) and find we can not fix them without breaking backwards >>> compatibility. Given that no one noticed these problems >>> >> until now, I >> >>> strongly suspect these are not critical features of the >>> >> Diameter base >> >>> protocol. For Capabilities Update, we chose to deprecate >>> >> the feature >> >>> in bis rather than fix it and Glen captured a solution in a >>> >> separate >> >>> draft. If offered the choice at that point, I believe the >>> >> majority of >> >>> delegates would have been preferred a similar approach for TLS >>> negotiation rather than bump the version. >>> >>>> >>>>> I acknowledge that it's a pity that the plan not to introduce >>>>> incompatible changes in bis couldn't be upheld. But >>>>> >> regardless of >> >>>>> that: >>>>> these *are* two different protocols, and they *really really >>>>> should* be >>>>> easily distinguishable from each other. >>>>> >>>>> >>>>> >>>> The original plan for 3588bis was sound and is still required. IMO >>>> >>> the decision to address TLS negotiation in bis knowing that the fix >>> was not backwards compatible was our error. I vote we >>> >> deprecate this >> >>> feature in 3588bis, move the proposed solution to a new draft >>> (Diameter >>> v2 if required) and get 3588bis out the door. >>> >>>> Regards >>>> Mark >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> > > > > From julien.bournelle@gmail.com Fri Apr 17 06:16:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD563A6ABC; Fri, 17 Apr 2009 06:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifFhtucZu2p9; Fri, 17 Apr 2009 06:16:04 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 0F9ED3A6A5D; Fri, 17 Apr 2009 06:15:49 -0700 (PDT) Received: by bwz7 with SMTP id 7so157837bwz.37 for ; Fri, 17 Apr 2009 06:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=X/+wSWy2hWddfEaYVslHi8HvHE8Y0oU/dTR596mtm3k=; b=acVG2JY1TAIy0IOxzXHHOB5D4gcIh/c7HlvxK8HRkGyXEXXf0DKMebntqJe5d2cPvI Fv7kj2ExojtIVXgB1y2+VwnlQgpXWZOCCM4ZxK7eG+vPJiLXnuFZO+tIn/GKLm9sYzFv 3Q8j8OxlXMhq+8FdpbwSwy3hqNTRW8qGGYvmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aTNVkJE3IYyC/TmlEoLqAVn+JXZbbQrG/lbOwGOUQURFXNOxj/Koaat1frCKIiKDtU lHM9sOlODkNU3rmODD80LiWAXl0DGqNqMTCpJwgGcZwXKFpA20EiYPKUtfJMHXw2EH/U mvo4ZJDQPRwadtBw/dCiT0oC7h0S1awQnWLME= MIME-Version: 1.0 Received: by 10.239.135.130 with SMTP id d2mr90399hbd.163.1239974222706; Fri, 17 Apr 2009 06:17:02 -0700 (PDT) In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501449790@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B4501449790@FIESEXC015.nsn-intra.net> Date: Fri, 17 Apr 2009 15:17:02 +0200 Message-ID: <5e2406980904170617r465a67b8s1c6346c94fb30d21@mail.gmail.com> From: Julien Bournelle To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org, hokey@ietf.org Subject: Re: [Dime] DIME Meeting Minutes - IETF#74 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 13:16:05 -0000 Hi all, (CCing hokey WG) Concerning Diameter ERP, my feeling is that we should wait for an input from HOKEY WG concerning the architecture of the solution. Does the WG also share this opininon ? Regards, Julien Bournelle On Fri, Apr 17, 2009 at 2:16 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > For some reason this mail did not appear on the DIME mailing list archive. > > ---- > > Victor has uploaded the meeting minutes: > http://www.ietf.org/proceedings/09mar/minutes/dime.txt > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From hannes.tschofenig@nsn.com Fri Apr 17 06:18:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDF73A6D46; Fri, 17 Apr 2009 06:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.543 X-Spam-Level: X-Spam-Status: No, score=-5.543 tagged_above=-999 required=5 tests=[AWL=1.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3SJ3uQGyN2L; Fri, 17 Apr 2009 06:18:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id AC1D93A6833; Fri, 17 Apr 2009 06:18:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3HDJGQc023532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Apr 2009 15:19:16 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3HDJE88025184; Fri, 17 Apr 2009 15:19:16 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 15:19:14 +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, 17 Apr 2009 16:20:26 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450144981D@FIESEXC015.nsn-intra.net> In-Reply-To: <5e2406980904170617r465a67b8s1c6346c94fb30d21@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DIME Meeting Minutes - IETF#74 Thread-Index: Acm/Xs++gvEUbGSWQ2KYxIMdQg8GaQAAEcMA References: <3D3C75174CB95F42AD6BCC56E5555B4501449790@FIESEXC015.nsn-intra.net> <5e2406980904170617r465a67b8s1c6346c94fb30d21@mail.gmail.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Julien Bournelle" X-OriginalArrivalTime: 17 Apr 2009 13:19:14.0864 (UTC) FILETIME=[1AC44B00:01C9BF5F] Cc: dime@ietf.org, hokey@ietf.org Subject: Re: [Dime] DIME Meeting Minutes - IETF#74 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 13:18:05 -0000 Question to the HOKEY chairs:=20 What exactly and when are we supposed to get something from HOKEY to make progress with our work?=20 Ciao Hannes =20 >-----Original Message----- >From: ext Julien Bournelle [mailto:julien.bournelle@gmail.com]=20 >Sent: 17 April, 2009 16:17 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: dime@ietf.org; hokey@ietf.org >Subject: Re: [Dime] DIME Meeting Minutes - IETF#74 > >Hi all, > > (CCing hokey WG) > > Concerning Diameter ERP, my feeling is that we should wait=20 >for an input from HOKEY WG concerning the architecture of the solution. > > Does the WG also share this opininon ? > > Regards, > > Julien Bournelle > >On Fri, Apr 17, 2009 at 2:16 PM, Tschofenig, Hannes (NSN -=20 >FI/Espoo) wrote: >> For some reason this mail did not appear on the DIME mailing=20 >list archive. >> >> ---- >> >> Victor has uploaded the meeting minutes: >> http://www.ietf.org/proceedings/09mar/minutes/dime.txt >> >> Ciao >> Hannes >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> > From gwz@net-zen.net Fri Apr 17 20:52:58 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5FC3A6C94 for ; Fri, 17 Apr 2009 20:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tylEZn5vYiBJ for ; Fri, 17 Apr 2009 20:52:58 -0700 (PDT) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-01.prod.mesa1.secureserver.net [64.202.165.235]) by core3.amsl.com (Postfix) with SMTP id 2DB353A6CDD for ; Fri, 17 Apr 2009 20:52:58 -0700 (PDT) Received: (qmail 29864 invoked from network); 18 Apr 2009 03:54:11 -0000 Received: from unknown (124.120.225.87) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 18 Apr 2009 03:54:10 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <3D3C75174CB95F42AD6BCC56E5555B4501449790@FIESEXC015.nsn-intra.net> <5e2406980904170617r465a67b8s1c6346c94fb30d21@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B450144981D@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450144981D@FIESEXC015.nsn-intra.net> Date: Sat, 18 Apr 2009 10:54:00 +0700 Organization: Network Zen Message-ID: <002f01c9bfd9$51582770$f4087650$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm/Xs++gvEUbGSWQ2KYxIMdQg8GaQAAEcMAAB5mhZA= Content-Language: en-us Cc: dime@ietf.org, hokey@ietf.org Subject: Re: [Dime] [HOKEY] DIME Meeting Minutes - IETF#74 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 03:52:58 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto://hannes.tschofenig@nsn.com] writes: > Question to the HOKEY chairs: > > What exactly and when are we supposed to get something from HOKEY to > make progress with our work? As I believe I've mentioned, the document in question may be a work item in the new hokey WG charter (if any); the rechartering question will be brought up after the existing work items are complete, which is expected to be accomplished before the Stockholm meeting. ... From sdecugis@nict.go.jp Sun Apr 19 18:42:47 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40303A6DB2 for ; Sun, 19 Apr 2009 18:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.525 X-Spam-Level: X-Spam-Status: No, score=0.525 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_50=0.001, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQPdWXf+q40r for ; Sun, 19 Apr 2009 18:42:47 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 721443A6F27 for ; Sun, 19 Apr 2009 18:42:46 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n3K1hxTs017193; Mon, 20 Apr 2009 10:43:59 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n3K1hxXA001548; Mon, 20 Apr 2009 10:43:59 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n3K1hxcZ001545; Mon, 20 Apr 2009 10:43:59 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NiCT Mail) with ESMTP id 4058A1631B; Mon, 20 Apr 2009 10:43:59 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NiCT Mail) with ESMTP id 3A3BA1630B; Mon, 20 Apr 2009 10:43:59 +0900 (JST) Message-ID: <49EBD35A.6060600@nict.go.jp> Date: Mon, 20 Apr 2009 10:43:54 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Victor Fajardo References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> In-Reply-To: <49E87D17.6040400@tari.toshiba.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 01:42:47 -0000 > > I don't mind going with Glen's approach. It would work in our give > case. Any other thoughts ? Hi, In my humble opinion, saying that an implementation MAY do A, but SHOULD do B, when A and B are contradictory, is equivalent to saying nothing at all. So basically you end up not specifying how TLS should be handled, which is very not what I would expect from the spec... My 2 cents Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Sun Apr 19 21:11:07 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC4B3A6A4D for ; Sun, 19 Apr 2009 21:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cItnzXzKBck3 for ; Sun, 19 Apr 2009 21:11:07 -0700 (PDT) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id 02BCA3A6C92 for ; Sun, 19 Apr 2009 21:11:06 -0700 (PDT) Received: (qmail 28922 invoked from network); 20 Apr 2009 04:12:22 -0000 Received: from unknown (124.120.225.34) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 20 Apr 2009 04:12:21 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" , "'Victor Fajardo'" References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> <49EBD35A.6060600@nict.go.jp> In-Reply-To: <49EBD35A.6060600@nict.go.jp> Date: Mon, 20 Apr 2009 11:12:14 +0700 Organization: Network Zen Message-ID: <002801c9c16e$31747990$945d6cb0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnBWX9f5sXkZ3x4SR6pxhtxJrHURQAFC8Vw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 04:11:07 -0000 Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes > > I don't mind going with Glen's approach. It would work in our give > > case. Any other thoughts ? > Hi, > > In my humble opinion, saying that an implementation MAY do A, but > SHOULD > do B, when A and B are contradictory, is equivalent to saying nothing > at > all. Are you saying that "SHOULD" and "MAY" are equivalent, then? > So basically you end up not specifying how TLS should be handled, > which is very not what I would expect from the spec... I don't understand: in actual point of fact, that is exactly what we are saying... ... From sdecugis@nict.go.jp Sun Apr 19 21:54:39 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598D93A6F52 for ; Sun, 19 Apr 2009 21:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUFnSuRSgXUL for ; Sun, 19 Apr 2009 21:54:38 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id EB05C3A6A4D for ; Sun, 19 Apr 2009 21:54:37 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n3K4tpAK005985; Mon, 20 Apr 2009 13:55:51 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n3K4tp9u019030; Mon, 20 Apr 2009 13:55:51 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n3K4tpCU019027; Mon, 20 Apr 2009 13:55:51 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NiCT Mail) with ESMTP id 5E958161F6; Mon, 20 Apr 2009 13:55:51 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NiCT Mail) with ESMTP id 57B27161F0; Mon, 20 Apr 2009 13:55:51 +0900 (JST) Message-ID: <49EC0051.1060004@nict.go.jp> Date: Mon, 20 Apr 2009 13:55:45 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glen Zorn References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> <49EBD35A.6060600@nict.go.jp> <002801c9c16e$31747990$945d6cb0$@net> In-Reply-To: <002801c9c16e$31747990$945d6cb0$@net> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 04:54:39 -0000 > Are you saying that "SHOULD" and "MAY" are equivalent, then? > No, I mean that the implementation can do A or B and claim to be conformant; i.e. the specification does not restrict the possibilities. In our case, a new implementation would do B since it's a SHOULD, but an existing implementation that already do A will not need to be modified to claim conformance. Hence my conclusion... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Sun Apr 19 23:42:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D893A69FD for ; Sun, 19 Apr 2009 23:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4y2b3TS-bUQ for ; Sun, 19 Apr 2009 23:42:05 -0700 (PDT) Received: from p3plsmtpa01-08.prod.phx3.secureserver.net (p3plsmtpa01-08.prod.phx3.secureserver.net [72.167.82.88]) by core3.amsl.com (Postfix) with SMTP id E43AB3A6928 for ; Sun, 19 Apr 2009 23:42:04 -0700 (PDT) Received: (qmail 19555 invoked from network); 20 Apr 2009 06:43:20 -0000 Received: from unknown (124.120.225.34) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 20 Apr 2009 06:43:19 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> <49EBD35A.6060600@nict.go.jp> <002801c9c16e$31747990$945d6cb0$@net> <49EC0051.1060004@nict.go.jp> In-Reply-To: <49EC0051.1060004@nict.go.jp> Date: Mon, 20 Apr 2009 13:43:10 +0700 Organization: Network Zen Message-ID: <005301c9c183$47aa9d10$d6ffd730$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnBdEtFiDgDoJ7rTOaIylz3YiUIMgADnGxg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 06:42:05 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > > Are you saying that "SHOULD" and "MAY" are equivalent, then? > > > > No, I mean that the implementation can do A or B and claim to be > conformant; i.e. the specification does not restrict the possibilities. > In our case, a new implementation would do B since it's a SHOULD, but > an > existing implementation that already do A will not need to be modified > to claim conformance. I'm still not seeing the problem: that seems to me to be pretty much the definition of "backward compatibility" ;-). As long as both ways work, it shouldn't matter WRT interoperability & hopefully, legacy implementations would upgrade over time; in any case, v2 could deprecate the old behavior. > > Hence my conclusion... > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sdecugis@nict.go.jp Mon Apr 20 00:06:14 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156FA3A6D3F for ; Mon, 20 Apr 2009 00:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.764 X-Spam-Level: X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmxXcXrCwQKo for ; Mon, 20 Apr 2009 00:06:13 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 5C91C3A6FBD for ; Mon, 20 Apr 2009 00:05:55 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n3K778IE025981; Mon, 20 Apr 2009 16:07:08 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n3K778lB004025; Mon, 20 Apr 2009 16:07:08 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n3K778C9004022; Mon, 20 Apr 2009 16:07:08 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NiCT Mail) with ESMTP id 41FC516206; Mon, 20 Apr 2009 16:07:08 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NiCT Mail) with ESMTP id 3AC5D161FC; Mon, 20 Apr 2009 16:07:08 +0900 (JST) Message-ID: <49EC1F14.8090102@nict.go.jp> Date: Mon, 20 Apr 2009 16:07:00 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glen Zorn References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> <49EBD35A.6060600@nict.go.jp> <002801c9c16e$31747990$945d6cb0$@net> <49EC0051.1060004@nict.go.jp> <005301c9c183$47aa9d10$d6ffd730$@net> In-Reply-To: <005301c9c183$47aa9d10$d6ffd730$@net> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:06:14 -0000 > I'm still not seeing the problem: that seems to me to be pretty much the > definition of "backward compatibility" ;-). As long as both ways work, it > shouldn't matter WRT interoperability & hopefully, legacy implementations > would upgrade over time; in any case, v2 could deprecate the old behavior. > I'd say "backward compatibility" if an implementation that supports Diameter v2 can also support v1. Since we are not changing the version number, it is very difficult for the implementation to determine if it is running in "old" or "new" Diameter. I think that we *will* end up with different implementations of Diameter that are not able to talk together... Which I'd like to avoid, at least at the specification step. Of course I may be missing experience here, I'm just talking from my implementation point of view... Thank you for your patience ^_^ Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Mon Apr 20 00:40:10 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCCA3A68E2 for ; Mon, 20 Apr 2009 00:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRUEb6Y0vfLO for ; Mon, 20 Apr 2009 00:40:09 -0700 (PDT) Received: from p3plsmtpa01-06.prod.phx3.secureserver.net (p3plsmtpa01-06.prod.phx3.secureserver.net [72.167.82.86]) by core3.amsl.com (Postfix) with SMTP id 7F0433A6912 for ; Mon, 20 Apr 2009 00:40:09 -0700 (PDT) Received: (qmail 20220 invoked from network); 20 Apr 2009 07:41:23 -0000 Received: from unknown (124.120.225.34) by p3plsmtpa01-06.prod.phx3.secureserver.net (72.167.82.86) with ESMTP; 20 Apr 2009 07:41:22 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> <49EBD35A.6060600@nict.go.jp> <002801c9c16e$31747990$945d6cb0$@net> <49EC0051.1060004@nict.go.jp> <005301c9c183$47aa9d10$d6ffd730$@net> <49EC1F14.8090102@nict.go.jp> In-Reply-To: <49EC1F14.8090102@nict.go.jp> Date: Mon, 20 Apr 2009 14:41:14 +0700 Organization: Network Zen Message-ID: <005d01c9c18b$63fe60c0$2bfb2240$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnBhqLtRM4a+hPaQn2+oUN4izcEMwAAz3eg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:40:10 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > > I'm still not seeing the problem: that seems to me to be pretty much > the > > definition of "backward compatibility" ;-). As long as both ways > work, it > > shouldn't matter WRT interoperability & hopefully, legacy > implementations > > would upgrade over time; in any case, v2 could deprecate the old > behavior. > > > I'd say "backward compatibility" if an implementation that supports > Diameter v2 can also support v1. > Since we are not changing the version number, it is very difficult for > the implementation to determine if it is running in "old" or "new" > Diameter. This is how I think that it would work: For TLS, it's pretty easy: if the peer connected to you on the new "special" port, then TLS is already active; otherwise, you start it the old way. For CER/CEA in the open state, it's not that bad, either, if we leave Capabilities Update as a separate application. Of course, since we're not taking anything out, new implementations would have to support the old way of doing things (which implies that my quick-and-dirty standards language mock-up might not be completely correct, but I still think it may be doable... > I think that we *will* end up with different implementations of > Diameter > that are not able to talk together... I'd be very surprised if that wasn't true in any case. > Which I'd like to avoid, at least > at the specification step. > > Of course I may be missing experience here, I'm just talking from my > implementation point of view... I would prefer to increment the version number, too; I'm just trying to break the log jam here. > > Thank you for your patience ^_^ > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sdecugis@nict.go.jp Mon Apr 20 01:00:26 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3054E3A693E for ; Mon, 20 Apr 2009 01:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+XHsXulRhq9 for ; Mon, 20 Apr 2009 01:00:25 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id CE85B3A67D1 for ; Mon, 20 Apr 2009 01:00:24 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n3K81dB1018754; Mon, 20 Apr 2009 17:01:39 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n3K81bNq019256; Mon, 20 Apr 2009 17:01:37 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n3K81bkh019246; Mon, 20 Apr 2009 17:01:37 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NiCT Mail) with ESMTP id 0DE981633E; Mon, 20 Apr 2009 17:01:37 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NiCT Mail) with ESMTP id 0276E16329; Mon, 20 Apr 2009 17:01:37 +0900 (JST) Message-ID: <49EC2BD8.6080903@nict.go.jp> Date: Mon, 20 Apr 2009 17:01:28 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glen Zorn References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> <49EBD35A.6060600@nict.go.jp> <002801c9c16e$31747990$945d6cb0$@net> <49EC0051.1060004@nict.go.jp> <005301c9c183$47aa9d10$d6ffd730$@net> <49EC1F14.8090102@nict.go.jp> <005d01c9c18b$63fe60c0$2bfb2240$@net> In-Reply-To: <005d01c9c18b$63fe60c0$2bfb2240$@net> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:00:26 -0000 > This is how I think that it would work: > [...] Well, if the bis describes how to handle the interoperability with "pure" rfc3588, and the solution is not very very dirty, then I'd agree for this type of solution ^^ But I'd prefer to see the actual description, before saying it's possible... To me it looks complex, especially for the initiator's side. >> I think that we *will* end up with different implementations of > I'd be very surprised if that wasn't true in any case. > But if at least we don't know it before releasing the new specification, it's better... Isn't it? ^^' > I would prefer to increment the version number, too; I'm just trying to > break the log jam here. > Well, not pushing the change to TLS into the Bis version seemed a good approach to me. If the implementation must be backward-compatible with 3588, it will remain open to the security vulnerability anyway... I'd also rather see a *clean* version 2 where this vulnerability is fixed; even if this version comes later with a new re-chartering or i-don-t-know-what process to fix a vulnerability.... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Mon Apr 20 01:25:32 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E613A6D21 for ; Mon, 20 Apr 2009 01:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao88WEL7sKIY for ; Mon, 20 Apr 2009 01:25:31 -0700 (PDT) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id CB2023A6D30 for ; Mon, 20 Apr 2009 01:25:28 -0700 (PDT) Received: (qmail 32633 invoked from network); 20 Apr 2009 08:26:42 -0000 Received: from unknown (124.120.225.34) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 20 Apr 2009 08:26:42 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> <49EBD35A.6060600@nict.go.jp> <002801c9c16e$31747990$945d6cb0$@net> <49EC0051.1060004@nict.go.jp> <005301c9c183$47aa9d10$d6ffd730$@net> <49EC1F14.8090102@nict.go.jp> <005d01c9c18b$63fe60c0$2bfb2240$@net> <49EC2BD8.6080903@nict.go.jp> In-Reply-To: <49EC2BD8.6080903@nict.go.jp> Date: Mon, 20 Apr 2009 15:26:38 +0700 Organization: Network Zen Message-ID: <006401c9c191$bbb6d530$33247f90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnBjj//jw+QcfU0TiW8Pct+9gJ3+AAAhbbA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:25:32 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > > This is how I think that it would work: > > > [...] > > Well, if the bis describes how to handle the interoperability with > "pure" rfc3588, and the solution is not very very dirty, then I'd agree > for this type of solution ^^ > But I'd prefer to see the actual description, before saying it's > possible... To me it looks complex, especially for the initiator's > side. Let's just take TLS, for simplicity's sake. The old and new ways use two different ports, right? As long as an implementation knows which of the two the connection came in on, it knows what to do (or not to do), right? On the initiator side, a new implementation would try the special port first (because it's a "SHOULD") & if no answer then fall back to the old way (because it's a "MAY", though we can specify this behavior more precisely). That sounds fairly simple to me. If we leave capabilities update as a separate app, then we don't have to worry about that for bis. ... > > > I would prefer to increment the version number, too; I'm just trying > to > > break the log jam here. > > > Well, not pushing the change to TLS into the Bis version seemed a good > approach to me. > If the implementation must be backward-compatible with 3588, it will > remain open to the security vulnerability anyway... Not unless it actually practices the old way. ... From gwz@net-zen.net Mon Apr 20 01:56:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289BC3A6CB8 for ; Mon, 20 Apr 2009 01:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fW4jObsomd9 for ; Mon, 20 Apr 2009 01:56:04 -0700 (PDT) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by core3.amsl.com (Postfix) with SMTP id F27B83A6A97 for ; Mon, 20 Apr 2009 01:55:43 -0700 (PDT) Received: (qmail 21154 invoked from network); 20 Apr 2009 08:56:59 -0000 Received: from unknown (124.120.225.34) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 20 Apr 2009 08:56:58 -0000 From: "Glen Zorn" To: "'Glen Zorn'" , "'Sebastien Decugis'" References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> <49EBD35A.6060600@nict.go.jp> <002801c9c16e$31747990$945d6cb0$@net> <49EC0051.1060004@nict.go.jp> <005301c9c183$47aa9d10$d6ffd730$@net> <49EC1F14.8090102@nict.go.jp> <005d01c9c18b$63fe60c0$2bfb2240$@net> <49EC2BD8.6080903@nict.go.jp> <006401c9c191$bbb6d530$33247f90$@net> In-Reply-To: <006401c9c191$bbb6d530$33247f90$@net> Date: Mon, 20 Apr 2009 15:56:53 +0700 Organization: Network Zen Message-ID: <006801c9c195$f64f74a0$e2ee5de0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnBjj//jw+QcfU0TiW8Pct+9gJ3+AAAhbbAAAFVbnA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:56:05 -0000 Sorry, I didn't realize that I had said "right?" twice in two sentences ;-) -- reading it, it sounds a little confrontational which was not my intent. > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Glen Zorn > Sent: Monday, April 20, 2009 3:27 PM > To: 'Sebastien Decugis' > Cc: dime@ietf.org > Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number > > Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > > > > > This is how I think that it would work: > > > > > [...] > > > > Well, if the bis describes how to handle the interoperability with > > "pure" rfc3588, and the solution is not very very dirty, then I'd > agree > > for this type of solution ^^ > > But I'd prefer to see the actual description, before saying it's > > possible... To me it looks complex, especially for the initiator's > > side. > > Let's just take TLS, for simplicity's sake. The old and new ways use > two > different ports, right? As long as an implementation knows which of > the two > the connection came in on, it knows what to do (or not to do), right? > On > the initiator side, a new implementation would try the special port > first > (because it's a "SHOULD") & if no answer then fall back to the old way > (because it's a "MAY", though we can specify this behavior more > precisely). > That sounds fairly simple to me. If we leave capabilities update as a > separate app, then we don't have to worry about that for bis. > > ... > > > > > > I would prefer to increment the version number, too; I'm just > trying > > to > > > break the log jam here. > > > > > Well, not pushing the change to TLS into the Bis version seemed a > good > > approach to me. > > If the implementation must be backward-compatible with 3588, it will > > remain open to the security vulnerability anyway... > > Not unless it actually practices the old way. > > ... > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Mon Apr 20 18:16:29 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F743A6AD8 for ; Mon, 20 Apr 2009 18:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 339+Cl9ie5N0 for ; Mon, 20 Apr 2009 18:16:28 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id D724D3A69CD for ; Mon, 20 Apr 2009 18:16:27 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n3L1Hgxr017303; Tue, 21 Apr 2009 10:17:42 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n3L1HgIb007203; Tue, 21 Apr 2009 10:17:42 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n3L1Hg5A007200; Tue, 21 Apr 2009 10:17:42 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NiCT Mail) with ESMTP id 48399163B4; Tue, 21 Apr 2009 10:17:42 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NiCT Mail) with ESMTP id 41C3D16364; Tue, 21 Apr 2009 10:17:42 +0900 (JST) Message-ID: <49ED1EB0.2050707@nict.go.jp> Date: Tue, 21 Apr 2009 10:17:36 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glen Zorn References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> <49EBD35A.6060600@nict.go.jp> <002801c9c16e$31747990$945d6cb0$@net> <49EC0051.1060004@nict.go.jp> <005301c9c183$47aa9d10$d6ffd730$@net> <49EC1F14.8090102@nict.go.jp> <005d01c9c18b$63fe60c0$2bfb2240$@net> <49EC2BD8.6080903@nict.go.jp> <006401c9c191$bbb6d530$33247f90$@net> In-Reply-To: <006401c9c191$bbb6d530$33247f90$@net> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 01:16:29 -0000 Hello again, > On > the initiator side, a new implementation would try the special port first > (because it's a "SHOULD") & if no answer then fall back to the old way > (because it's a "MAY", though we can specify this behavior more precisely). > That sounds fairly simple to me. So the initiator has to try two protocols (SCTP, TCP) and two ports (legacy, new TLS) when attempting a new connection... I would not call this "fairly simple" ;) I guess it's doable... Just adding even more complexity to Diameter. In any case, these changes (TLS and CER/CEA) require at least precise instructions in the draft, if we want to avoid multiple implementations that are not interoperable. Do we agree on this? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Mon Apr 20 20:48:42 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489953A69FA for ; Mon, 20 Apr 2009 20:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hLm0zAyYfK4 for ; Mon, 20 Apr 2009 20:48:41 -0700 (PDT) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id 806DD3A6B20 for ; Mon, 20 Apr 2009 20:48:38 -0700 (PDT) Received: (qmail 11988 invoked from network); 21 Apr 2009 03:49:53 -0000 Received: from unknown (124.120.231.79) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 21 Apr 2009 03:49:52 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <49D393C2.8060200@tari.toshiba.com><7DBAFEC6A76F3E42817DF1EBE64CB0260656E7F5@ftrdmel2> <49D40EBE.2010208@nict.go.jp> <7DBAFEC6A76F3E42817DF1EBE64CB0260656E97E@ftrdmel2> <49D57490.2000606@nict.go.jp> <49D5A94F.3030309@restena.lu> <49E74673.7030109@tari.toshiba.com> <000001c9bf2f$94ab4430$be01cc90$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F10@ftrdmel2> <49E87D17.6040400@tari.toshiba.com> <49EBD35A.6060600@nict.go.jp> <002801c9c16e$31747990$945d6cb0$@net> <49EC0051.1060004@nict.go.jp> <005301c9c183$47aa9d10$d6ffd730$@net> <49EC1F14.8090102@nict.go.jp> <005d01c9c18b$63fe60c0$2bfb2240$@net> <49EC2BD8.6080903@nict.go.jp> <006401c9c191$bbb6d530$33247f90$@net> <49ED1EB0.2050707@nict.go.jp> In-Reply-To: <49ED1EB0.2050707@nict.go.jp> Date: Tue, 21 Apr 2009 10:49:40 +0700 Organization: Network Zen Message-ID: <00b301c9c234$3501fb20$9f05f160$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnCHvwIy4fPQICZQGK8x092WujOOQAFBT+A Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 03:48:42 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > Hello again, > > On > > the initiator side, a new implementation would try the special port > first > > (because it's a "SHOULD") & if no answer then fall back to the old > way > > (because it's a "MAY", though we can specify this behavior more > precisely). > > That sounds fairly simple to me. > So the initiator has to try two protocols (SCTP, TCP) and two ports > (legacy, new TLS) when attempting a new connection... In the worst case, yes; however, I imagine that this would happen rarely outside of conformance testing. Diameter peers don't just connect "out of the blue", so I would expect that in The Real World (TM) peers would either be initially configured to use the right combination or (if they were smart) remember the result of the discovery process. > I would not call > this "fairly simple" ;) > > I guess it's doable... Just adding even more complexity to Diameter. > > In any case, these changes (TLS and CER/CEA) require at least precise > instructions in the draft, if we want to avoid multiple implementations > that are not interoperable. I think that we can leave capabilities update out of bis: it would be harder to maintain backward compatibility (since it would change the state machine) and it works cleanly as a separate app. > Do we agree on this? Precise specification is almost always a good thing. > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From dwing@cisco.com Tue Apr 21 08:22:30 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0683A6A67 for ; Tue, 21 Apr 2009 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LibFNcrKaMrk for ; Tue, 21 Apr 2009 08:22:29 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6F0F53A6A0B for ; Tue, 21 Apr 2009 08:22:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,224,1238976000"; d="scan'208";a="290117272" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Apr 2009 15:23:45 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3LFNjqh024674; Tue, 21 Apr 2009 08:23:45 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3LFNjQh011993; Tue, 21 Apr 2009 15:23:45 GMT From: "Dan Wing" To: "'Hannes Tschofenig'" , References: <013201c9bc6e$e0f8b570$0201a8c0@nsnintra.net> Date: Tue, 21 Apr 2009 08:23:45 -0700 Message-ID: <01fa01c9c295$2976d8a0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm8buBNK3tHtcoyR3aOQLEKf1ZJXwGJaB8A In-Reply-To: <013201c9bc6e$e0f8b570$0201a8c0@nsnintra.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1396; t=1240327425; x=1241191425; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Dime]=20Confirming=20HUM=20regardingdr aft-brockners-diameter-nat-control-00.txt |Sender:=20; bh=n/rxJ2Gr0ZzuXozW7ziCwRvBdVAUiPATUWvbBeZ1I+Y=; b=js5HvUOZ+CTc/TYHTVto+RzaTIeKndr5X/iP9fHqqrRxWxUUJoMF+OO5DV zG4IozY6POVPbKZf1efG+PFwp/PpLNhI1FNZHNvcKCVW6U9Dqkr4JIwXtEmK gE8jpsiXh4YfYx6JoDU8kfMgU5iS+442lW/3Yel2S/yusf1apsodY=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Dime] Confirming HUM regardingdraft-brockners-diameter-nat-control-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 15:22:30 -0000 I wasn't at the DIME meeting, but I support this document. Remembering my experience with the SAFE BoF, the IESG will likely want to see a comparison of this protocol with other, existing protocols. Some content is already in slides 3-5 of http://www.ietf.org/proceedings/09mar/slides/behave-3.pdf and could be integrated into an appendix of this document or as a companion Internet Draft (which I expect would not need to be published as an RFC). -d > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Monday, April 13, 2009 12:35 PM > To: dime@ietf.org > Subject: [Dime] Confirming HUM > regardingdraft-brockners-diameter-nat-control-00.txt > > Hi all, > > at the IETF#74 DIME meeting we had a presentation about the > "Diameter NAT > Control Application" document: > http://www.ietf.org/internet-drafts/draft-brockners-diameter-n > at-control-00. > txt > > The group was in favor of turning this document into a > working group item. > > If you have objections or if you weren't at the meeting and > would like to > express your support for it please let us know by the 24th > April 2009. > > Ciao > Hannes & Dave > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From vfajardo@tari.toshiba.com Tue Apr 21 08:22:51 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1F23A6A0B for ; Tue, 21 Apr 2009 08:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9GksrDT1LVB for ; Tue, 21 Apr 2009 08:22:50 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id DFD713A6C94 for ; Tue, 21 Apr 2009 08:22:49 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id n3LFO5Ew015310 for ; Wed, 22 Apr 2009 00:24:05 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id n3LFO5bQ000486 for dime@ietf.org; Wed, 22 Apr 2009 00:24:05 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id AAA00485; Wed, 22 Apr 2009 00:24:04 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id n3LFO4Rp023126 for ; Wed, 22 Apr 2009 00:24:04 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n3LFO39H012004; Wed, 22 Apr 2009 00:24:03 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n3LFO2Rj027090 for ; Wed, 22 Apr 2009 00:24:02 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n3LFO1gX005605 for ; Wed, 22 Apr 2009 00:24:01 +0900 (JST) 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 n3LFRI29003464 for ; Tue, 21 Apr 2009 11:27:18 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49EDE510.7060506@tari.toshiba.com> Date: Tue, 21 Apr 2009 11:24:00 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dime] PROTO writeup review of draft-ietf-dime-diameter-qos-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 15:22:51 -0000 Hi, Just a few comments on draft-ietf-dime-diameter-qos-07.txt: * In Figure 2, the legend depicts "signaling flow". Is this QoS signaling flow ? * Can we simplify this sentence: "A Category 1 Application Endpoint has QoS capability at neither the application nor the network level. This type of AppE may set.." to "A Category 1 Application Endpoint has no QoS capability at either the application nor the network level. This type of AppE may set.." * In the sentence: "It is obvious that the eligible QoS scheme is correlated to the AppE's capability in the context of QoS authorization. Since Category 1 and 2 AppEs cannot initiate the QoS resource requests by means of network signaling, the IntServ model is not applicable to them in general." Why is IntServ not applicable to Category 2 ? Will DiffServ cover Cat 2 ? * Can we clarify the follow: "When the IntServ scheme is employed by a Category 3 endpoint, the authorization process is typically initiated by a NE when a trigger such as network signaling is received from the endpoint." to: "When the IntServ scheme is employed by a Category 3 endpoint, the authorization process is typically initiated by a NE when a trigger is received from the endpoint such as network signaling (what kind ? is it Qos signaling ?)." * Can we re-phrase this sentence: "Three basic authorization schemes for Pull mode exist: one two-party and two three-party schemes. The notation adopted here is in respect ..." Is it one-party, two-party and three-party scheme ? I'm still half-way through the review. I'll try to finish ASAP and send out the proto writeup once everything is cleared. best regards, victor From gdweber@gmail.com Tue Apr 21 10:32:26 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67023A6B2D for ; Tue, 21 Apr 2009 10:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKhTcWBPR91S for ; Tue, 21 Apr 2009 10:32:25 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id A28AC3A6B9A for ; Tue, 21 Apr 2009 10:32:25 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so3924042ywh.49 for ; Tue, 21 Apr 2009 10:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=W/teVINTyGXqft5m/iYXt4Ls+B9/KSdUg02LzVNt3A0=; b=miZv3DQiTRgX7PbS0tEJf4vLRtBgCdJ6RjU1zIsV1vVA/OLRBbIyxMfFj9mSwWsgRe B7X36EClZrtU+ewp5w6V1QuHBD/x8BzL37tPRd01NpEPKV/82SUmGDVvVfK35JGfRCAs qA7bz/KFTvS1g/J4At3U9edQkFbOh9DhC0vvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ABCeVMTUCLojtmX/tKwUUF+Aiac3IPlcQ2lweip3FbTXtTdJWmMHJuEqBsMkrq2W4F W9FRf0pAyrSy2XJBxgcMlJl3rv/zeO76whD/pUFzk8sSrmLM6N3njaa7/CcyPPA4HSME y2IXtly0G0WJvIV5n94AoLEssVcwDLpAcqfU0= MIME-Version: 1.0 Received: by 10.151.108.5 with SMTP id k5mr3733504ybm.108.1240335222058; Tue, 21 Apr 2009 10:33:42 -0700 (PDT) Date: Tue, 21 Apr 2009 13:33:41 -0400 Message-ID: From: Greg Weber To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: [Dime] Additional HUMs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 17:32:26 -0000 I wasn't present at the SF meeting, and I'd like to add HUMs in support of pursuing the NAT control app and the base protocol MIB. I've reviewed earlier versions of both drafts and believe they're in suitable form for adoption as WG items. Greg On Mon, Apr 13, 2009 at 3:34 PM, Hannes Tschofenig wrote: > Hi all, > > at the IETF#74 DIME meeting we had a presentation about the "Diameter NAT > Control Application" document: > http://www.ietf.org/internet-drafts/draft-brockners-diameter-nat-control-00. > txt > > The group was in favor of turning this document into a working group item. > > If you have objections or if you weren't at the meeting and would like to > express your support for it please let us know by the 24th April 2009. > > Ciao > Hannes & Dave > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From vfajardo@tari.toshiba.com Wed Apr 22 06:58:57 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB9E28C4F5 for ; Wed, 22 Apr 2009 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDP3O+WvWRJ5 for ; Wed, 22 Apr 2009 06:58:56 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 3584128C512 for ; Wed, 22 Apr 2009 06:58:56 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id n3ME0C5e008817 for ; Wed, 22 Apr 2009 23:00:12 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id n3ME0CR2020212 for dime@ietf.org; Wed, 22 Apr 2009 23:00:12 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id ZAA20211; Wed, 22 Apr 2009 23:00:12 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id n3ME0BXI022758 for ; Wed, 22 Apr 2009 23:00:11 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n3ME0B4O021301; Wed, 22 Apr 2009 23:00:11 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n3ME0BJZ027418 for ; Wed, 22 Apr 2009 23:00:11 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n3ME08Hh015716 for ; Wed, 22 Apr 2009 23:00:08 +0900 (JST) 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 n3ME3NX3008810 for ; Wed, 22 Apr 2009 10:03:23 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49EF22E7.7060104@tari.toshiba.com> Date: Wed, 22 Apr 2009 10:00:07 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "dime@ietf.org" References: <49EDE510.7060506@tari.toshiba.com> In-Reply-To: <49EDE510.7060506@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Dime] PROTO writeup review of draft-ietf-dime-diameter-qos-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:58:57 -0000 Review Part 2/2: * Some contradictions ? In page 12, it says: For Category 1 and 2 Application Endpoints, Push mode is required. For a Category 3 AppE, either Push mode or Pull mode may be used. In page 16 it says: A Category 1 AppE requires network-initiated Push mode and a Category 2 AppE may use either mode * In the sentence: "or a link layer signaling protocol. A description of these protocols is also outside the scope of this document and a tight coupling with these protocols is not desirable since this applications aims to be generic." Is the last sentence a recommendation to implementations regarding coupling ? I'm not sure if that is needed If so, it maybe better to re-word to: or a link layer signaling protocol. A description of these protocols is outside the scope of this document. * Editorial: "The NE generates a QAR message in which the required objects from the QoS signaling message to Diameter AVPs." to: "The NE generates a QAR message in which the required objects from the QoS signaling message is converted to Diameter AVPs." * Sec 4.2.3. Is this section talking about how to connect to an adjacent diameter peer ? or is it talking about discovery of another Diameter Qos node ? If its the former then there maybe no need to talk about it. If its the later, we have to keep in mind that there is no such functionality as discovering diameter nodes supporting specific applications that are several diameter peer hops away. * Editorial in Sec 5.2., s/[ Acc-Multisession-Id ]/[ Acct-Multisession-Id ]/ * In Sec 5.3, Pls expand /Authz/Authorization/ so as not be confused with some other AVPs. Maybe this check should be done for the whole document. * Sec 5.5, We don't need to repeat the ABNF for RAR. We can just add a reference to 3588. Same goes for RAA, STR and STA. * In Sec 6. we can re-word: "The QoS application reuses the authorization state machine defined in Section 8.1 of the Base Protocol ([RFC3588]) with its own messages as defined in Section 5 and QoS AVPs as defined in Section 7. .." to: "The QoS application defines its own state machine that is based on the Base Protocol authorization state machine defined in Section 8.1 of ([RFC3588]). The Qos state machine uses own messages as defined in Section 5 and QoS AVPs as defined in Section 7. .." * Sec 6.1. we can re-word: "In addition to the reused state machines, the following states are supplemented to first 2 state machines in which the session state is maintained on the Server, and MUST be supported in any QoS application implementations in support of server initiated push mode (see (Section 4.2.2))." to: "Using the Base Protocol state machine as a basis, the following states are supplemented to first 2 state machines in which the session state is maintained on the Server. This MUST be supported in any QoS application implementations in support of server initiated push mode (see (Section 4.2.2))." AND fix this: "The following states are supplemented to the state machine on the client when state is maintained on the server as defined in Section 8.1 of the Base Protocol [RFC3588]: to: "The following states are supplemented to the state machine on the client when state is maintained on the client as defined in Section 8.1 of the Base Protocol [RFC3588]:" * In Sec 7.2, It maybe time to remove: |P - Indicates the need for encryption for end-to-end security. | and it's associated column I'll send out the PROTO writeup once these issues have been resolved. regards, victor From vfajardo@tari.toshiba.com Wed Apr 22 07:13:27 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE2428C52A for ; Wed, 22 Apr 2009 07:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.758 X-Spam-Level: X-Spam-Status: No, score=-3.758 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xven+s6XHG8c for ; Wed, 22 Apr 2009 07:13:26 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id AA4AF28C530 for ; Wed, 22 Apr 2009 07:13:26 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id n3MEEhbo010631 for ; Wed, 22 Apr 2009 23:14:43 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id n3MEEhIP023547 for dime@ietf.org; Wed, 22 Apr 2009 23:14:43 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id ZAA23546; Wed, 22 Apr 2009 23:14:43 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id n3MEEgqM029587 for ; Wed, 22 Apr 2009 23:14:42 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n3MEEgcZ029931; Wed, 22 Apr 2009 23:14:42 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n3MEEfEn008527 for ; Wed, 22 Apr 2009 23:14:41 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n3MEEe7N017925 for ; Wed, 22 Apr 2009 23:14:41 +0900 (JST) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n3MEHt4m008920 for ; Wed, 22 Apr 2009 10:17:55 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49EF264F.5030307@tari.toshiba.com> Date: Wed, 22 Apr 2009 10:14:39 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "dime@ietf.org" References: <49EDE510.7060506@tari.toshiba.com> <49EF22E7.7060104@tari.toshiba.com> In-Reply-To: <49EF22E7.7060104@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Dime] PROTO writeup review of draft-ietf-dime-diameter-qos-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 14:13:27 -0000 Can we also fix the following nits (other than the TBDs): idnits 2.11.08 tmp/draft-ietf-dime-diameter-qos-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions Section 6.b License Notice from 10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is required now. (See http://trustee.ietf.org/license-info/) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.). trust-12-feb-2009 Section 6.c.iii text: "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD1' is mentioned on line 1376, but not defined ' ::= < Diameter Header: [TBD1], REQ, PXY >...' == Missing Reference: 'TBD2' is mentioned on line 1401, but not defined ' ::= < Diameter Header: [TBD2], PXY >...' == Missing Reference: 'TBD3' is mentioned on line 1430, but not defined ' ::= < Diameter Header: [TBD3], REQ, PXY >...' == Missing Reference: 'TBD4' is mentioned on line 1455, but not defined ' ::= < Diameter Header: [TBD4], PXY >...' == Missing Reference: 'TBD5' is mentioned on line 1348, but not defined 'by including the value of [TBD5] in the Auth-Application-Id or th...' == Outdated reference: A later version (-11) exists of draft-ietf-dime-qos-attributes-08 == Outdated reference: A later version (-10) exists of draft-ietf-dime-qos-parameters-07 ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-19) exists of draft-ietf-nsis-ntlp-17 -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 2 errors (**), 10 warnings (==), 1 comment (--). From dromasca@avaya.com Thu Apr 23 10:27:07 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A413A6E98 for ; Thu, 23 Apr 2009 10:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdrjyVWfHXEy for ; Thu, 23 Apr 2009 10:27:06 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 660133A6AAE for ; Thu, 23 Apr 2009 10:27:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238990400"; d="scan'208";a="159333743" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 23 Apr 2009 13:28:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 23 Apr 2009 13:28:23 -0400 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, 23 Apr 2009 19:28:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-mip6-split in Revised ID needed Thread-Index: AcnEOOaNOcLtRHGITGuWgd0KIn5vBg== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] draft-ietf-dime-mip6-split in Revised ID needed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 17:27:07 -0000 draft-ietf-dime-mip6-split was discussed in the IESG telechat today, and placed in Revised ID Needed status in order to solve the issues raised by Pasi Eronen in his DISCUSS. Please work ahead to solve these issues and get a new ID published as soon as possible.=20 Thanks and Regards, Dan From root@core3.amsl.com Tue Apr 28 04:45:02 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 869023A6B14; Tue, 28 Apr 2009 04:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090428114502.869023A6B14@core3.amsl.com> Date: Tue, 28 Apr 2009 04:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-17.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-17.txt Pages : 42 Date : 2009-04-28 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP Home Agent and a Diameter server. This document defines the Home Agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dime-mip6-split-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-28044016.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Apr 28 06:00:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C4A5828C216; Tue, 28 Apr 2009 06:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090428130001.C4A5828C216@core3.amsl.com> Date: Tue, 28 Apr 2009 06:00:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-api-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 13:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : The Diameter API Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-diameter-api-08.txt Pages : 46 Date : 2009-04-28 The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes an 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-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dime-diameter-api-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-28055430.I-D@ietf.org> --NextPart-- From Hannes.Tschofenig@gmx.net Wed Apr 29 12:58:41 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199303A6C90 for ; Wed, 29 Apr 2009 12:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9zgOvsx4zV4 for ; Wed, 29 Apr 2009 12:58:40 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B87C53A68DC for ; Wed, 29 Apr 2009 12:58:39 -0700 (PDT) Received: (qmail invoked by alias); 29 Apr 2009 20:00:01 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 29 Apr 2009 22:00:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+gtS8VVJGg4SM0G2A+pgvYa/O6zB/Mfuj4d1Mvjk k0PBosyOnjJDd+ From: "Hannes Tschofenig" To: Date: Wed, 29 Apr 2009 23:01:35 +0300 Message-ID: <00d501c9c905$4cf899f0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01C9C91E.7245D1F0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnJBUyD+4XsaCgZTu2zNfl0zQRkKw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75,0.75 Subject: [Dime] DIME Virtual Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:58:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D6_01C9C91E.7245D1F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, we are planning to schedule a virtual interim meeting for DIME. Please indicate your availability here: http://www.doodle.com/r5t4mh8zttyy4afu Ciao Hannes & Dave ------=_NextPart_000_00D6_01C9C91E.7245D1F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIME Virtual Interim Meeting

Hi all,

we are planning to schedule a = virtual interim meeting for DIME.
Please indicate your = availability here:
http://www.doodle.com/r5t4mh8zttyy4afu

Ciao
Hannes & Dave

------=_NextPart_000_00D6_01C9C91E.7245D1F0-- From dongsun@alcatel-lucent.com Wed Apr 29 18:22:11 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFBFF3A692C for ; Wed, 29 Apr 2009 18:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6vVVtrxTCvP for ; Wed, 29 Apr 2009 18:22:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id C7A063A68FE for ; Wed, 29 Apr 2009 18:22:09 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n3U1NSLC013990; Wed, 29 Apr 2009 20:23:29 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.11]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 20:23:28 -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 Date: Wed, 29 Apr 2009 20:23:25 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D028DB42B@ILEXC2U01.ndc.lucent.com> In-Reply-To: <49EDE510.7060506@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] PROTO writeup review of draft-ietf-dime-diameter-qos-07.txt thread-index: AcnClTm/4UGub1GjSEuXfJh5htbL3wFvrzzg References: <49EDE510.7060506@tari.toshiba.com> From: "Sun, Dong (Dong)" To: "Victor Fajardo" , X-OriginalArrivalTime: 30 Apr 2009 01:23:28.0273 (UTC) FILETIME=[43F95010:01C9C932] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [Dime] PROTO writeup review of draft-ietf-dime-diameter-qos-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 01:22:11 -0000 Victor, Thanks for review and comments. See inline...=20 Cheers, Dong -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Tuesday, April 21, 2009 11:24 AM To: dime@ietf.org Subject: [Dime] PROTO writeup review of draft-ietf-dime-diameter-qos-07.txt Hi, Just a few comments on draft-ietf-dime-diameter-qos-07.txt: * In Figure 2, the legend depicts "signaling flow". Is this QoS signaling flow ? [ds]yes. You may see the flow goes up to "Signaling msg processing" box. * Can we simplify this sentence: "A Category 1 Application Endpoint has QoS capability at neither the application nor the network level. This type of AppE may set.." to "A Category 1 Application Endpoint has no QoS capability at either the application nor the network level. This type of AppE may set.." [ds] done. * In the sentence: "It is obvious that the eligible QoS scheme is correlated to the AppE's capability in the context of QoS authorization. Since Category 1 and 2 AppEs cannot initiate the QoS resource requests by means of network signaling, the IntServ model is not applicable to them in general." Why is IntServ not applicable to Category 2 ? Will DiffServ cover Cat 2 ? [ds] as said, Cat 2 is unable to send a RSVP like on path signaling.=20 Therefore the flow spec of IntServ model cannot be signaled across the network by this means. In fact the IntServ might be applicable. The texts are modified as follows: "Since Category 1 and 2 AppEs cannot initiate the QoS resource requests by means of network signaling, using the current mechanism of IntServ model to=20 signal QoS information across the network is not applicable to them in general." * Can we clarify the follow: "When the IntServ scheme is employed by a Category 3 endpoint, the authorization process is typically initiated by a NE when a trigger such as network signaling is received from the endpoint." to: "When the IntServ scheme is employed by a Category 3 endpoint, the authorization process is typically initiated by a NE when a trigger is received from the endpoint such as network signaling (what kind ? is it Qos signaling ?)." [ds] yes. Refers to RSVP like. So modified as follows: "When the IntServ scheme is employed by a Category 3 endpoint, the authorization process is typically initiated by a NE when a trigger is received from the endpoint such as network QoS signaling" * Can we re-phrase this sentence: "Three basic authorization schemes for Pull mode exist: one two-party and two three-party schemes. The notation adopted here is in respect ..." Is it one-party, two-party and three-party scheme ? [ds] my understanding is one type of two-party scheme, two types of three-party schemes. The texts are updated accordlingly. "Three types of basic authorization schemes for Pull mode exist: one type of two-party scheme and two types of three-party schemes. " I'm still half-way through the review. I'll try to finish ASAP and send out the proto writeup once everything is cleared. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dongsun@alcatel-lucent.com Wed Apr 29 18:22:37 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6B73A68FE for ; Wed, 29 Apr 2009 18:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MekiRy47lSmK for ; Wed, 29 Apr 2009 18:22:36 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id B8A583A681D for ; Wed, 29 Apr 2009 18:22:36 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n3U1NsBt023823; Wed, 29 Apr 2009 20:23:54 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.11]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 20:23:54 -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 Date: Wed, 29 Apr 2009 20:23:51 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D028DB42C@ILEXC2U01.ndc.lucent.com> In-Reply-To: <49EF22E7.7060104@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] PROTO writeup review ofdraft-ietf-dime-diameter-qos-07.txt thread-index: AcnDUrA5N++CZJx1QVa2b/hGEnoRowF2RhMQ References: <49EDE510.7060506@tari.toshiba.com> <49EF22E7.7060104@tari.toshiba.com> From: "Sun, Dong (Dong)" To: "Victor Fajardo" , X-OriginalArrivalTime: 30 Apr 2009 01:23:54.0146 (UTC) FILETIME=[53653820:01C9C932] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Dime] PROTO writeup review ofdraft-ietf-dime-diameter-qos-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 01:22:37 -0000 See inline... Please let me know if have further comments. The draft will be updated accordingly. Thanks, Dong=20 -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Wednesday, April 22, 2009 10:00 AM To: dime@ietf.org Subject: Re: [Dime] PROTO writeup review ofdraft-ietf-dime-diameter-qos-07.txt Review Part 2/2: * Some contradictions ? In page 12, it says: For Category 1 and 2 Application Endpoints, Push mode is required. For a Category 3 AppE, either Push mode or Pull mode may be used. In page 16 it says: A Category 1 AppE requires network-initiated Push mode and a Category 2 AppE may use either mode [ds] good catch. pp 12 is correct, pp 16 is aligned. * In the sentence: "or a link layer signaling protocol. A description of these protocols is also outside the scope of this document and a tight coupling with these protocols is not desirable since this applications aims to be generic." Is the last sentence a recommendation to implementations regarding coupling ? I'm not sure if that is needed If so, it maybe better to re-word to: or a link layer signaling protocol. A description of these protocols is outside the scope of this document. * Editorial: "The NE generates a QAR message in which the required objects from the QoS signaling message to Diameter AVPs." to: "The NE generates a QAR message in which the required objects from the QoS signaling message is converted to Diameter AVPs." * Sec 4.2.3. Is this section talking about how to connect to an adjacent diameter peer ? or is it talking about discovery of another Diameter Qos node ? If its the former then there maybe no need to talk about it. If its the later, we have to keep in mind that there is no such functionality as discovering diameter nodes supporting specific applications that are several diameter peer hops away. * Editorial in Sec 5.2., s/[ Acc-Multisession-Id ]/[ Acct-Multisession-Id ]/ * In Sec 5.3, Pls expand /Authz/Authorization/ so as not be confused with some other AVPs. Maybe this check should be done for the whole document. * Sec 5.5, We don't need to repeat the ABNF for RAR. We can just add a reference to 3588. Same goes for RAA, STR and STA. * In Sec 6. we can re-word: "The QoS application reuses the authorization state machine defined in Section 8.1 of the Base Protocol ([RFC3588]) with its own messages as defined in Section 5 and QoS AVPs as defined in Section 7. .." to: "The QoS application defines its own state machine that is based on=20 the Base Protocol authorization state machine defined in Section 8.1 of ([RFC3588]). The Qos state machine uses own messages as defined in Section 5 and QoS AVPs as defined in Section 7. .." * Sec 6.1. we can re-word: "In addition to the reused state machines, the following states are supplemented to first 2 state machines in which the session state is maintained on the Server, and MUST be supported in any QoS application implementations in support of server initiated push mode (see (Section 4.2.2))." to: "Using the Base Protocol state machine as a basis, the following states are supplemented to first 2 state machines in which the session state is maintained on the Server. This MUST be supported in any QoS application implementations in support of server initiated push mode (see (Section 4.2.2))." AND fix this: "The following states are supplemented to the state machine on the client when state is maintained on the server as defined in Section 8.1 of the Base Protocol [RFC3588]: to: "The following states are supplemented to the state machine on the client when state is maintained on the client as defined in Section 8.1 of the Base Protocol [RFC3588]:" * In Sec 7.2, It maybe time to remove:=20 |P - Indicates the need for encryption for end-to-end security. | and it's associated column I'll send out the PROTO writeup once these issues have been resolved. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dongsun@alcatel-lucent.com Wed Apr 29 18:32:37 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF253A68AC for ; Wed, 29 Apr 2009 18:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ze7PGhnosBQ for ; Wed, 29 Apr 2009 18:32:36 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id A99383A681D for ; Wed, 29 Apr 2009 18:32:36 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n3U1Xu2W009664; Wed, 29 Apr 2009 20:33:57 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.11]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 20:33:56 -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 Date: Wed, 29 Apr 2009 20:33:55 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D028DB42D@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-index: AcnJM7mqwXDR9SfMTeqHVh8HqD0QlQ== From: "Sun, Dong (Dong)" To: "Victor Fajardo" , X-OriginalArrivalTime: 30 Apr 2009 01:33:56.0865 (UTC) FILETIME=[BAA4D710:01C9C933] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [Dime] (no subject) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 01:32:37 -0000 ******* Wrong email for Part 2/2 response. Please drop it and see the attached in this email. ******** See inline... Please let me know if have further comments. The draft will be updated accordingly. Thanks, Dong=20 -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Wednesday, April 22, 2009 10:00 AM To: dime@ietf.org Subject: Re: [Dime] PROTO writeup review ofdraft-ietf-dime-diameter-qos-07.txt Review Part 2/2: * Some contradictions ? In page 12, it says: For Category 1 and 2 Application Endpoints, Push mode is required. For a Category 3 AppE, either Push mode or Pull mode may be used. In page 16 it says: A Category 1 AppE requires network-initiated Push mode and a Category 2 AppE may use either mode [ds] in pp 12 it refers to Push and Pull modes. in pp 16 it refers to two types of Push mode. The texts in pp. 16 is modified as follows: "A Category 1 AppE requires network-initiated Push mode and a Category 2 AppE may use either type of Push Mode" * In the sentence: "or a link layer signaling protocol. A description of these protocols is also outside the scope of this document and a tight coupling with these protocols is not desirable since this applications aims to be generic." Is the last sentence a recommendation to implementations regarding coupling ? I'm not sure if that is needed If so, it maybe better to re-word to: or a link layer signaling protocol. A description of these protocols is outside the scope of this document. [ds] ok. * Editorial: "The NE generates a QAR message in which the required objects from the QoS signaling message to Diameter AVPs." to: "The NE generates a QAR message in which the required objects from the QoS signaling message is converted to Diameter AVPs." [ds] ok. * Sec 4.2.3. Is this section talking about how to connect to an adjacent diameter peer ? or is it talking about discovery of another Diameter Qos node ? If its the former then there maybe no need to talk about it. If its the later, we have to keep in mind that there is no such functionality as discovering diameter nodes supporting specific applications that are several diameter peer hops away. [ds] This session addresses two feature: discovery of peer Diameter QoS node, and selection of right instances from the pool of peer nodes. I think the discovery is defined in 3588, e.g. based on application ID, is it correct?=20 The selection is a new feature specific to QoS application, but only required in either client or Server node. In fact, it is an application level feature rather than protocol level. =20 The subtitles are added to each paragraph. * Editorial in Sec 5.2., s/[ Acc-Multisession-Id ]/[ Acct-Multisession-Id ]/ Ok. * In Sec 5.3, Pls expand /Authz/Authorization/ so as not be confused with some other AVPs. Maybe this check should be done for the whole document. Done. * Sec 5.5, We don't need to repeat the ABNF for RAR. We can just add a reference to 3588. Same goes for RAA, STR and STA. There are some new AVPs added into command. How to show them without the ABNF? * In Sec 6. we can re-word: "The QoS application reuses the authorization state machine defined in Section 8.1 of the Base Protocol ([RFC3588]) with its own messages as defined in Section 5 and QoS AVPs as defined in Section 7. .." to: "The QoS application defines its own state machine that is based on=20 the Base Protocol authorization state machine defined in Section 8.1 of ([RFC3588]). The Qos state machine uses own messages as defined in Section 5 and QoS AVPs as defined in Section 7. .." done * Sec 6.1. we can re-word: "In addition to the reused state machines, the following states are supplemented to first 2 state machines in which the session state is maintained on the Server, and MUST be supported in any QoS application implementations in support of server initiated push mode (see (Section 4.2.2))." to: "Using the Base Protocol state machine as a basis, the following states are supplemented to first 2 state machines in which the session state is maintained on the Server. This MUST be supported in any QoS application implementations in support of server initiated push mode (see (Section 4.2.2))." Done. AND fix this: "The following states are supplemented to the state machine on the client when state is maintained on the server as defined in Section 8.1 of the Base Protocol [RFC3588]: to: "The following states are supplemented to the state machine on the client when state is maintained on the client as defined in Section 8.1 of the Base Protocol [RFC3588]:" Done. * In Sec 7.2, It maybe time to remove:=20 |P - Indicates the need for encryption for end-to-end security. | and it's associated column Done. I'll send out the PROTO writeup once these issues have been resolved. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From vfajardo@tari.toshiba.com Wed Apr 29 19:06:58 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106233A692E for ; Wed, 29 Apr 2009 19:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YCmSeMYddeu for ; Wed, 29 Apr 2009 19:06:57 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id D0A063A6BAF for ; Wed, 29 Apr 2009 19:06:56 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id n3U28EMQ019072; Thu, 30 Apr 2009 11:08:14 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id n3U28Em8024622; Thu, 30 Apr 2009 11:08:14 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id MAA24619; Thu, 30 Apr 2009 11:08:14 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id n3U28DNC023982; Thu, 30 Apr 2009 11:08:13 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n3U28DRr012699; Thu, 30 Apr 2009 11:08:13 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n3U28C8H024227; Thu, 30 Apr 2009 11:08:12 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n3U28BHQ028124; Thu, 30 Apr 2009 11:08:12 +0900 (JST) 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 n3U2B46A050281; Wed, 29 Apr 2009 22:11:05 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49F90809.1050900@tari.toshiba.com> Date: Wed, 29 Apr 2009 22:08:09 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "Sun, Dong (Dong)" References: <49EDE510.7060506@tari.toshiba.com> <49EF22E7.7060104@tari.toshiba.com> <09C9068466B79E4C938DC7737562404D028DB42C@ILEXC2U01.ndc.lucent.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D028DB42C@ILEXC2U01.ndc.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] PROTO writeup review ofdraft-ietf-dime-diameter-qos-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 02:06:58 -0000 Sounds good. I'll send out the writeup after the draft gets updated. > See inline... > > Please let me know if have further comments. The draft will be updated > accordingly. > > Thanks, > Dong > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Victor Fajardo > Sent: Wednesday, April 22, 2009 10:00 AM > To: dime@ietf.org > Subject: Re: [Dime] PROTO writeup review > ofdraft-ietf-dime-diameter-qos-07.txt > > Review Part 2/2: > > > * Some contradictions ? In page 12, it says: > > For Category 1 and 2 Application Endpoints, Push mode is required. > For a Category 3 AppE, either Push mode or Pull mode may be used. > > In page 16 it says: > > A Category 1 AppE requires network-initiated Push mode and a Category > 2 AppE may use either mode > > [ds] good catch. pp 12 is correct, pp 16 is aligned. > > * In the sentence: > > "or a link layer signaling protocol. A description of these protocols > is also outside the scope of this document and a tight coupling with > these protocols is not desirable since this applications aims to be > generic." > > Is the last sentence a recommendation to implementations regarding > coupling ? I'm not sure if that is needed If so, it maybe better to > re-word to: > > or a link layer signaling protocol. A description of these protocols > is outside the scope of this document. > > * Editorial: > > "The NE generates a QAR message in which the required objects from > the QoS > signaling message to Diameter AVPs." > > to: > > "The NE generates a QAR message in which the required objects from > the QoS > signaling message is converted to Diameter AVPs." > > * Sec 4.2.3. Is this section talking about how to connect to an adjacent > diameter peer ? or is it talking about discovery of another Diameter Qos > node ? > If its the former then there maybe no need to talk about it. If its > the later, we have to keep in mind that there is no such functionality > as discovering > diameter nodes supporting specific applications that are several > diameter peer hops away. > > * Editorial in Sec 5.2., s/[ Acc-Multisession-Id ]/[ > Acct-Multisession-Id ]/ > > * In Sec 5.3, Pls expand /Authz/Authorization/ so as not be confused > with some other AVPs. Maybe this check should be done for the whole > document. > > * Sec 5.5, We don't need to repeat the ABNF for RAR. We can just add a > reference to 3588. Same goes for RAA, STR and STA. > > * In Sec 6. we can re-word: > > "The QoS application reuses the authorization state machine defined > in > Section 8.1 of the Base Protocol ([RFC3588]) with its own messages as > defined in Section 5 and QoS AVPs as defined in Section 7. .." > > to: > > "The QoS application defines its own state machine that is based on > the Base Protocol authorization state machine defined in > Section 8.1 of ([RFC3588]). The Qos state machine uses own messages > as > defined in Section 5 and QoS AVPs as defined in Section 7. .." > > * Sec 6.1. we can re-word: > > "In addition to the reused state machines, the following states are > supplemented to first 2 state machines in which the session state is > maintained on the Server, and MUST be supported in any QoS > application implementations in support of server initiated push mode > (see (Section 4.2.2))." > > to: > > "Using the Base Protocol state machine as a basis, the following > states > are supplemented to first 2 state machines in which the session > state is > maintained on the Server. This MUST be supported in any QoS > application implementations in support of server initiated push mode > (see (Section 4.2.2))." > > AND fix this: > > "The following states are supplemented to the state machine on the > client when state is maintained on the server as defined in Section > 8.1 of the Base Protocol [RFC3588]: > > to: > > "The following states are supplemented to the state machine on the > client when state is maintained on the client as defined in Section > 8.1 of the Base Protocol [RFC3588]:" > > * In Sec 7.2, It maybe time to remove: > > |P - Indicates the need for encryption for end-to-end security. | > > and it's associated column > > > I'll send out the PROTO writeup once these issues have been resolved. > > regards, > victor > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > >