From dime-bounces@ietf.org Thu Apr 10 14:23:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C440E28C23C; Thu, 10 Apr 2008 14:23:31 -0700 (PDT) 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 B23E13A67F8 for ; Thu, 10 Apr 2008 14:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.732, 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 HSRPyw-hGgs0 for ; Thu, 10 Apr 2008 14:23:30 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7601228C1A3 for ; Thu, 10 Apr 2008 14:23:28 -0700 (PDT) Received: (qmail invoked by alias); 10 Apr 2008 21:23:49 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp025) with SMTP; 10 Apr 2008 23:23:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18/ph1SSKQ/GtVKyqpfe2i0XzkkMK0Ob6gg44WqUw QrjRYARq61hNs/ Message-ID: <47FE8564.30009@gmx.net> Date: Fri, 11 Apr 2008 00:23:48 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 Subject: [Dime] Diameter QoS Application Draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I quickly read through the draft to see whether it is ready for WGLC. I noticed the following issues * Section 7.2 "QoS Application Defined AVPs" should actually be renamed to "AVP Flag Table" and then it should list all the AVPs relevant for this document. At least we should indicate how the AVP flag setting would look like in this application. One option would be to leave the AVP flag setting unchanged. I believe we should, however, use a different AVP flag setting of the QoS-Resources AVP, namely: +------------------+ | AVP Flag Rules | +-------------------------------------------------|----+---+----+----+ | AVP Section |MUST|MAY|SHLD|MUST| | Attribute Name Code Defined Data Type | | | NOT| NOT| +-------------------------------------------------+----+---+----+----+ |QoS-Capability TBD 3.1 Grouped | |M,P| | V | |QoS-Profile-Template TBD 3.2 Unsigned64 | |M,P| | V | |QoS-Resources TBD 3.3 Grouped | |M,P| | V | |Extended-QoS-Filter-Rule TBD 3.4 Grouped | |M,P| | V | |QoS-Semantics TBD 3.5 Enumerated | |M,P| | V | |QoS-Parameters TBD 3.6 OctetString| |M,P| | V | |QoS-Rule-Precedence TBD 3.7 Unsigned32 | |M,P| | V | +-------------------------------------------------+----+---+----+----+ * We don't seem to include the QoS-Capability AVP in the document. I believe, however, we should do that. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 10 16:33:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC4328C4F9; Thu, 10 Apr 2008 16:33:59 -0700 (PDT) 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 3DBA128C4F9 for ; Thu, 10 Apr 2008 16:33:58 -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 KQggNbRutbYz for ; Thu, 10 Apr 2008 16:33:57 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 4C65628C500 for ; Thu, 10 Apr 2008 16:33:57 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m3ANY88D026867; Thu, 10 Apr 2008 18:34:14 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.10]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 18:33:19 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 10 Apr 2008 18:33:18 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01699399@ILEXC2U01.ndc.lucent.com> In-Reply-To: <47FE8564.30009@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Application Draft Thread-Index: AcibUS6h5q7Gb7CYSgyiqNVcSLDtTgADl1mA References: <47FE8564.30009@gmx.net> From: "Sun, Dong \(Dong\)" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 10 Apr 2008 23:33:19.0621 (UTC) FILETIME=[42490B50:01C89B63] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Dime] Diameter QoS Application Draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes, I agree that current structure is not very clean since section 7.2 includes both reused AVPs from the I-D "QoS-attributes" and new AVPs defined by this doc (i.e. QoS-Authz-Data and Bound-Auth-Session-Id). We may separate the reused AVPs from newly defined AVPs into 2 subsections, in addition, I suggest to only list the name, AVP code and reference as that in section 7.1, instead of replicating the entire AVP flag table . It can ensure the consistency between the reused AVPs and original definition. (BTW, do you think which flag setting of thos reused AVP needs to be changed? What's the reason?) The section 7.2 can be revised as follows: ~~~~~~~~~~~~~~ 7.2 Reused QoS Application AVPs The QoS application uses the QoS application AVPs, defined in the QoS-attributes ([I-D.ietf-dime-qos-attributes]). Attribute Name AVP Code Reference [I-D.ietf-dime-qos-attributes] QoS-Capability TBD section 3.1 QoS-Profile-Template TBD section 3.2 QoS-Resources TBD section 3.3 Extended-QoS-Filter-Rule TBD section 3.4 QoS-Semantics TBD section 3.5 QoS-Parameters TBD section 3.6 QoS-Rule-Precedence TBD section 3.7 7.3 New QoS Application AVPs This section lists the AVPs that are introduced specifically for this application. The following new AVPs are defined: Bound-Auth- Session-Id and the QoS-Authz-Data AVP. .... ~~~~~~~~~~~~~~~ Any comment? Regards, Dong -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, April 10, 2008 5:24 PM To: dime@ietf.org Subject: [Dime] Diameter QoS Application Draft I quickly read through the draft to see whether it is ready for WGLC. I noticed the following issues * Section 7.2 "QoS Application Defined AVPs" should actually be renamed to "AVP Flag Table" and then it should list all the AVPs relevant for this document. At least we should indicate how the AVP flag setting would look like in this application. One option would be to leave the AVP flag setting unchanged. I believe we should, however, use a different AVP flag setting of the QoS-Resources AVP, namely: +------------------+ | AVP Flag Rules | +-------------------------------------------------|----+---+----+----+ | AVP Section |MUST|MAY|SHLD|MUST| | Attribute Name Code Defined Data Type | | | NOT| NOT| +-------------------------------------------------+----+---+----+----+ |QoS-Capability TBD 3.1 Grouped | |M,P| | V | |QoS-Profile-Template TBD 3.2 Unsigned64 | |M,P| | V | |QoS-Resources TBD 3.3 Grouped | |M,P| | V | |Extended-QoS-Filter-Rule TBD 3.4 Grouped | |M,P| | V | |QoS-Semantics TBD 3.5 Enumerated | |M,P| | V | |QoS-Parameters TBD 3.6 OctetString| |M,P| | V | |QoS-Rule-Precedence TBD 3.7 Unsigned32 | |M,P| | V | +-------------------------------------------------+----+---+----+----+ * We don't seem to include the QoS-Capability AVP in the document. I believe, however, we should do that. Ciao Hannes _______________________________________________ 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 dime-bounces@ietf.org Sat Apr 12 07:06:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75E73A689E; Sat, 12 Apr 2008 07:06:44 -0700 (PDT) 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 0B7B43A68ED for ; Sat, 12 Apr 2008 07:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 SBtjPvGon-q4 for ; Sat, 12 Apr 2008 07:06:37 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.232]) by core3.amsl.com (Postfix) with ESMTP id A49473A696D for ; Sat, 12 Apr 2008 07:06:36 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id o21so873458qba.9 for ; Sat, 12 Apr 2008 07:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=B1vdiJMmiUPLCq6eAz5/TbQ4HrSbybT/TjAozLekqqc=; b=NjSB5K6ceYkdXcWcFMteGMzdsk9dwtQaL/5wn9591/eLxVdWMI8vh+5nqnoD16cDDuAnkaY3s0vYrEZSC1555QOWKSQLqW0CBP16OnwDd8almky4A6heTfR24bGRgoCHKplGKeGbDRbGxhSICLFGHdq11d/vTKqikjbnI6POMUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=qwvEfCfvZX4fm25DEJc1P36xPIW/EsnterpbFgP20pe6UQr8RXouuQ5uRxPG8OZKh39YZlT6csNt+Xm8KP7XD9hgUaW7wJOG3/Wb6pKG43KNSgor11uje79C2Yul6/3OvPc4nTqpoMI9BtAb5WouAO8GsF5o9WBEgryBWzXJyTY= Received: by 10.142.242.8 with SMTP id p8mr1169239wfh.17.1208009220771; Sat, 12 Apr 2008 07:07:00 -0700 (PDT) Received: by 10.142.83.8 with HTTP; Sat, 12 Apr 2008 07:07:00 -0700 (PDT) Message-ID: <3bd0c5da0804120707o14567123sdb71d529c9b4e87b@mail.gmail.com> Date: Sat, 12 Apr 2008 19:37:00 +0530 From: "Ravi N" To: dime@ietf.org MIME-Version: 1.0 Subject: [Dime] Peer FSM and TLS Handshake 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: , Content-Type: multipart/mixed; boundary="===============1317835735==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1317835735== Content-Type: multipart/alternative; boundary="----=_Part_11577_14549279.1208009220778" ------=_Part_11577_14549279.1208009220778 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, As per RFC 3588, the TLS handshake is done in the open state and if the handshake fails, the state moves to closed state. Is there any reason why the TLS handshake is not put as a state in the Peer FSM? -Ravi ------=_Part_11577_14549279.1208009220778 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
  As per RFC 3588, the TLS handshake is done in the open state and if the handshake fails, the state moves to closed state.  Is there any reason why the TLS handshake is not put as a state in the Peer FSM?
 
-Ravi
------=_Part_11577_14549279.1208009220778-- --===============1317835735== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1317835735==-- From dime-bounces@ietf.org Thu Apr 17 02:36:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B1B3A6FE7; Thu, 17 Apr 2008 02:36:48 -0700 (PDT) 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 64E443A6F99 for ; Thu, 17 Apr 2008 02:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.919 X-Spam-Level: * X-Spam-Status: No, score=1.919 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 l2SHvlI+RXcb for ; Thu, 17 Apr 2008 02:36:46 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [61.144.161.7]) by core3.amsl.com (Postfix) with ESMTP id 9E3323A6968 for ; Thu, 17 Apr 2008 02:36:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZG003U9QQ1SN@szxga04-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 17:37:13 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZG00FOFQQ19C@szxga04-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 17:37:13 +0800 (CST) Received: from huawei1515 ([10.18.23.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JZG00MU5QQ0S9@szxml04-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 17:37:13 +0800 (CST) Date: Thu, 17 Apr 2008 15:07:12 +0530 From: Rajith R To: dime@ietf.org Message-id: <001b01c8a06e$9d8365a0$3a17120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acigbpy/9g7/BMthSs+jqBuTeOPfAA== Subject: [Dime] Hop-by-Hop identifier in relays X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi If a relay does not use local storage for transaction state (it uses Proxy-Info AVP instead), MUST it still replace the Hop-by-Hop identifier with a locally unique value (as described in sec.6.1.9 of RFC-3588-bis-10)? Regards Rajith _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 17 03:19:21 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F56128C510; Thu, 17 Apr 2008 03:19:21 -0700 (PDT) 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 71DB728C531; Thu, 17 Apr 2008 03:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 9eH4CuSto268; Thu, 17 Apr 2008 03:19:15 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id AC7C728C510; Thu, 17 Apr 2008 03:19:14 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m3HA58qJ017779; Thu, 17 Apr 2008 15:35:08 +0530 Received: from webmail.asian.ad.aricent.com (webmail [10.203.158.17]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m3HA574p017761; Thu, 17 Apr 2008 15:35:07 +0530 In-Reply-To: <001b01c8a06e$9d8365a0$3a17120a@china.huawei.com> To: rajithr@huawei.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Thu, 17 Apr 2008 15:49:30 +0530 X-MIMETrack: Serialize by Router on WebMail/HSS(Build V655_10312005|October 31, 2005) at 04/17/2008 03:49:49 PM, Serialize complete at 04/17/2008 03:49:49 PM Cc: dime-bounces@ietf.org, dime@ietf.org Subject: Re: [Dime] Hop-by-Hop identifier in relays 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: , Content-Type: multipart/mixed; boundary="===============0469676585==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0469676585== Content-Type: multipart/alternative; boundary="=_alternative 0038BCB16525742E_=" This is a multipart message in MIME format. --=_alternative 0038BCB16525742E_= Content-Type: text/plain; charset="US-ASCII" Hi Rajith ! While describing relaying and proxying requests, RFC 3588 implies following " The Hop-by-Hop identifier in the request is saved, and replaced with a locally unique value. The source of the request is also saved, which includes the IP address, port and protocol." Hence as per above, relay should generate the new id while forwarding the requests Relay node shall receive requests from multiple nodes and in some rare scenario 2 requests coming from the different nodes can be same. So it is mandatory for the relay node to generate its' own unique hop-by-hop Id for each request, on forwarding it further, so that it can match the response with the request regards Preeti Rajith R Sent by: dime-bounces@ietf.org 04/17/2008 03:07 PM Please respond to rajithr@huawei.com To dime@ietf.org cc Subject [Dime] Hop-by-Hop identifier in relays Hi If a relay does not use local storage for transaction state (it uses Proxy-Info AVP instead), MUST it still replace the Hop-by-Hop identifier with a locally unique value (as described in sec.6.1.9 of RFC-3588-bis-10)? Regards Rajith _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime *********************** Aricent-Unclassified *********************** --=_alternative 0038BCB16525742E_= Content-Type: text/html; charset="US-ASCII"
Hi Rajith !

While describing relaying and proxying requests, RFC 3588 implies following

"   The Hop-by-Hop identifier in the request is saved, and replaced with
   a locally unique value.  The source of the request is also saved,
   which includes the IP address, port and protocol."

Hence as per above, relay should generate the new id while forwarding the requests

Relay node shall receive requests from multiple nodes and in some rare scenario 2 requests coming from the different nodes can be same. So it is mandatory for the relay node to generate its' own unique hop-by-hop Id for each request, on forwarding it further, so that it can match the response with the request

regards
Preeti


Rajith R <rajithr@huawei.com>
Sent by: dime-bounces@ietf.org

04/17/2008 03:07 PM
Please respond to
rajithr@huawei.com
To
dime@ietf.org
cc
Subject
[Dime] Hop-by-Hop identifier in relays





Hi
                If a relay does not use local storage for transaction state (it uses
Proxy-Info AVP instead), MUST it still replace the Hop-by-Hop identifier
with a locally unique value (as described in sec.6.1.9 of RFC-3588-bis-10)?


Regards
Rajith

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


***********************  Aricent-Unclassified   *********************** --=_alternative 0038BCB16525742E_=-- --===============0469676585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0469676585==-- From dime-bounces@ietf.org Thu Apr 17 03:38:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809B43A6A90; Thu, 17 Apr 2008 03:38:27 -0700 (PDT) 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 DFCA73A6BF3 for ; Thu, 17 Apr 2008 03:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 MbLv8AHqq4bA for ; Thu, 17 Apr 2008 03:38:26 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [61.144.161.54]) by core3.amsl.com (Postfix) with ESMTP id EBDF53A69FA for ; Thu, 17 Apr 2008 03:38:25 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZG00B0KTEVAL@szxga02-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 18:35:19 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZG00KT1TEU1M@szxga02-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 18:35:19 +0800 (CST) Received: from huawei1515 ([10.18.23.58]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JZG001QZTEP85@szxml03-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 18:35:18 +0800 (CST) Date: Thu, 17 Apr 2008 16:05:12 +0530 From: Rajith R In-reply-to: To: 'Preeti Shandilya' Message-id: <001f01c8a076$badaddb0$3a17120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcigdJZmAdIEWhvJTzi3eWiPl7Oo1gAAccDg Cc: dime@ietf.org Subject: Re: [Dime] Hop-by-Hop identifier in relays X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi If the relay uses local storage for txn state, I agree to your point on why the relay must replace the hop-by-hop id. However, when the relay uses Proxy-Info AVP for txn state (& no local storage, that means no need to match response with a request), I am not sure why the relay *MUST* replace the hop-by-hop id. Regards Rajith ________________________________________ From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com] = Sent: Thursday, April 17, 2008 3:50 PM To: rajithr@huawei.com Cc: dime@ietf.org; dime-bounces@ietf.org Subject: Re: [Dime] Hop-by-Hop identifier in relays Hi Rajith ! = While describing relaying and proxying requests, RFC 3588 implies following = " =A0 The Hop-by-Hop identifier in the request is saved, and replaced with = =A0 =A0a locally unique value. =A0The source of the request is also saved, = =A0 =A0which includes the IP address, port and protocol." = Hence as per above, relay should generate the new id while forwarding the requests = Relay node shall receive requests from multiple nodes and in some rare scenario 2 requests coming from the different nodes can be same. So it is mandatory for the relay node to generate its' own unique hop-by-hop Id for each request, on forwarding it further, so that it can match the response with the request = regards = Preeti = Rajith R = Sent by: dime-bounces@ietf.org = 04/17/2008 03:07 PM = Please respond to rajithr@huawei.com To dime@ietf.org = cc Subject [Dime] Hop-by-Hop identifier in relays Hi =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If a relay does not use local storage for t= ransaction state (it uses Proxy-Info AVP instead), MUST it still replace the Hop-by-Hop identifier with a locally unique value (as described in sec.6.1.9 of RFC-3588-bis-10)? Regards Rajith _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime *********************** =A0Aricent-Unclassified =A0 *********************** _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 17 05:03:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BB928C100; Thu, 17 Apr 2008 05:03:27 -0700 (PDT) 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 21F283A6BF3 for ; Thu, 17 Apr 2008 05:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 foHozE0ku2Ti for ; Thu, 17 Apr 2008 05:03:19 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [61.144.161.54]) by core3.amsl.com (Postfix) with ESMTP id C810A3A67FB for ; Thu, 17 Apr 2008 05:03:13 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZG00D06XI2ZB@szxga02-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 20:03:38 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZG00BWFXHZIB@szxga02-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 20:03:38 +0800 (CST) Received: from santosh ([10.18.24.53]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JZG001FGXHY85@szxml03-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 20:03:35 +0800 (CST) Date: Thu, 17 Apr 2008 17:33:34 +0530 From: Santhosh To: dime@ietf.org Message-id: <001501c8a083$105e3af0$3518120a@china.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Aciggw+o0U8y/FoUQxqQCn+iM/j2Hw== Subject: [Dime] regarding proxy info avp location in a message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: santhoshkk@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0901555317==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0901555317== Content-type: multipart/alternative; boundary="Boundary_(ID_Lyur7OM31hg8Ih770VyVFQ)" This is a multi-part message in MIME format. --Boundary_(ID_Lyur7OM31hg8Ih770VyVFQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I think it is worth adding a recommendation in rfc 3588 on where to add the proxy onfo avp in a message.. 1)Any node in the message path MUST add proxy info avp only at the end. 2)In the response also add the m to the end. This eases the the processing at the diameter nodes.i.e. multiple copies of the messages could be avoided.. What you guys think on this... This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_Lyur7OM31hg8Ih770VyVFQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I think it is worth adding a recommendation in rfc 3588 on where to add the proxy onfo avp in a message..

1)Any node in the message path MUST add proxy info avp only at the end.

2)In the response also add the m to the end.

This eases the the processing at the diameter nodes.i.e. multiple copies of the messages could be avoided..

What you guys think on this…..

 

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

 

--Boundary_(ID_Lyur7OM31hg8Ih770VyVFQ)-- --===============0901555317== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0901555317==-- From dime-bounces@ietf.org Thu Apr 17 05:08:09 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736FA28C100; Thu, 17 Apr 2008 05:08:09 -0700 (PDT) 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 F062F3A6B73 for ; Thu, 17 Apr 2008 05:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.013 X-Spam-Level: ** X-Spam-Status: No, score=2.013 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 MkWyKBY4VvYn for ; Thu, 17 Apr 2008 05:08:05 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [61.144.161.55]) by core3.amsl.com (Postfix) with ESMTP id C2AA83A6B86 for ; Thu, 17 Apr 2008 05:08:03 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZG00DP0XQ30F@szxga03-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 20:08:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZG00CROXQ2TO@szxga03-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 20:08:27 +0800 (CST) Received: from santosh ([10.18.24.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JZG00MURXQ1S9@szxml04-in.huawei.com> for dime@ietf.org; Thu, 17 Apr 2008 20:08:26 +0800 (CST) Date: Thu, 17 Apr 2008 17:38:24 +0530 From: Santhosh To: dime@ietf.org Message-id: <002001c8a083$bd52a890$3518120a@china.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acigg7zIlocsG63uTFq8nLal7Aj7vg== Subject: [Dime] regarding proxy info avp location in a message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: santhoshkk@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1595670534==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1595670534== Content-type: multipart/alternative; boundary="Boundary_(ID_p4gsX0CCN7pV6eHbbClEKg)" This is a multi-part message in MIME format. --Boundary_(ID_p4gsX0CCN7pV6eHbbClEKg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT (Forget the disclaimer in the previous mail.) I think it is worth adding a recommendation in rfc 3588 on where to add the proxy onfo avp in a message.. 1)Any node in the message path MUST add proxy info avp only at the end. 2)In the response also add the m to the end. This eases the the processing at the diameter nodes.i.e. multiple copies of the messages could be avoided.. What you guys think on this... --Boundary_(ID_p4gsX0CCN7pV6eHbbClEKg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

(Forget the disclaimer in the previous mail…)

I think it is worth adding a recommendation in rfc 3588 on where to add the proxy onfo avp in a message..

 

1)Any node in the message path MUST add proxy info avp only at the end.

 

2)In the response also add the m to the end.

 

This eases the the processing at the diameter nodes.i.e. multiple copies of the messages could be avoided..

 

What you guys think on this…..

 

 

--Boundary_(ID_p4gsX0CCN7pV6eHbbClEKg)-- --===============1595670534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1595670534==-- From dime-bounces@ietf.org Thu Apr 17 12:21:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5C83A6A67; Thu, 17 Apr 2008 12:21:14 -0700 (PDT) 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 CA8403A6A67 for ; Thu, 17 Apr 2008 12:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 hSMq-jHH7RFd for ; Thu, 17 Apr 2008 12:21:11 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.190]) by core3.amsl.com (Postfix) with ESMTP id 86D433A699C for ; Thu, 17 Apr 2008 12:21:11 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id e27so160966rng.18 for ; Thu, 17 Apr 2008 12:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=nVQYJWcae/xnIW9BavpV9qnJgTb2A+qX/hMlonYJX4I=; b=YZl2ZifQ8DBbz9+x9x4Wi62dHViD5j08UxuIm7d+rxLpjntRSAbD1ylLD+lIw35VDKO9Vl19/5BnwPYlWW7MBXgcLu3T9HU/Aq2CSgtwt+lAZ7v/3PAJ+YKS/cFQnsGZtn2izJG4XhfBtwz5mceMBbEfIHJhNWUF5/1K/7s02lQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=k7+zyWzX4iYKDffBRBDKrWy1n/RioGYp358sW/dhS5/+/7dZ6FhQCkGXxUQIFwqmsOZZpwZT9gN27DEQfmxt2/iLJQwWwuyP1KEVAGL35z3Yh3MoszDrtBF0MXaCk2PlN8MRFCmE+A52lMrmxrdI9REPJjcoDOi+7qWKUuPCoNo= Received: by 10.142.142.16 with SMTP id p16mr518590wfd.176.1208460109103; Thu, 17 Apr 2008 12:21:49 -0700 (PDT) Received: by 10.142.132.16 with HTTP; Thu, 17 Apr 2008 12:21:49 -0700 (PDT) Message-ID: Date: Fri, 18 Apr 2008 00:51:49 +0530 From: "Harish R Prabhu" To: rajithr@huawei.com In-Reply-To: <001f01c8a076$badaddb0$3a17120a@china.huawei.com> MIME-Version: 1.0 References: <001f01c8a076$badaddb0$3a17120a@china.huawei.com> Cc: Preeti Shandilya , dime@ietf.org Subject: Re: [Dime] Hop-by-Hop identifier in relays 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: , Content-Type: multipart/mixed; boundary="===============0273999709==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0273999709== Content-Type: multipart/alternative; boundary="----=_Part_1661_8002536.1208460109098" ------=_Part_1661_8002536.1208460109098 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think it can affect response routing since the contents of 'Proxy-State' is opaque and hence implementation dependent. Interop issue? cheers, Harish On Thu, Apr 17, 2008 at 4:05 PM, Rajith R wrote: > Hi > If the relay uses local storage for txn state, I agree to your > point > on why the relay must replace the hop-by-hop id. However, when the relay > uses Proxy-Info AVP for txn state (& no local storage, that means no need > to > match response with a request), I am not sure why the relay *MUST* replace > the hop-by-hop id. > > Regards > > Rajith > > ________________________________________ > From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com] > Sent: Thursday, April 17, 2008 3:50 PM > To: rajithr@huawei.com > Cc: dime@ietf.org; dime-bounces@ietf.org > Subject: Re: [Dime] Hop-by-Hop identifier in relays > > > Hi Rajith ! > > While describing relaying and proxying requests, RFC 3588 implies > following > > " The Hop-by-Hop identifier in the request is saved, and replaced with > a locally unique value. The source of the request is also saved, > which includes the IP address, port and protocol." > > Hence as per above, relay should generate the new id while forwarding the > requests > > Relay node shall receive requests from multiple nodes and in some rare > scenario 2 requests coming from the different nodes can be same. So it is > mandatory for the relay node to generate its' own unique hop-by-hop Id for > each request, on forwarding it further, so that it can match the response > with the request > > regards > Preeti > > Rajith R > Sent by: dime-bounces@ietf.org > 04/17/2008 03:07 PM > Please respond to > rajithr@huawei.com > > To > dime@ietf.org > cc > > Subject > [Dime] Hop-by-Hop identifier in relays > > > > > > > > Hi > If a relay does not use local storage for transaction > state > (it uses > Proxy-Info AVP instead), MUST it still replace the Hop-by-Hop identifier > with a locally unique value (as described in sec.6.1.9 of > RFC-3588-bis-10)? > > > Regards > Rajith > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > *********************** Aricent-Unclassified *********************** > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > -- Harish R Prabhu Bangalore, India. ------=_Part_1661_8002536.1208460109098 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think it can affect response routing since the contents of 'Proxy-State' is opaque and hence implementation dependent. Interop issue?

cheers,
Harish

On Thu, Apr 17, 2008 at 4:05 PM, Rajith R <rajithr@huawei.com> wrote:
Hi
       If the relay uses local storage for txn state, I agree to your point
on why the relay must replace the hop-by-hop id. However, when the relay
uses Proxy-Info AVP for txn state (& no local storage, that means no need to
match response with a request), I am not sure why the relay *MUST* replace
the hop-by-hop id.

Regards

Rajith

________________________________________
From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]
Sent: Thursday, April 17, 2008 3:50 PM
To: rajithr@huawei.com
Cc: dime@ietf.org; dime-bounces@ietf.org
Subject: Re: [Dime] Hop-by-Hop identifier in relays


Hi Rajith !

While describing relaying and proxying requests, RFC 3588 implies following

"   The Hop-by-Hop identifier in the request is saved, and replaced with
   a locally unique value.  The source of the request is also saved,
   which includes the IP address, port and protocol."

Hence as per above, relay should generate the new id while forwarding the
requests

Relay node shall receive requests from multiple nodes and in some rare
scenario 2 requests coming from the different nodes can be same. So it is
mandatory for the relay node to generate its' own unique hop-by-hop Id for
each request, on forwarding it further, so that it can match the response
with the request

regards
Preeti

Rajith R <rajithr@huawei.com>
Sent by: dime-bounces@ietf.org
04/17/2008 03:07 PM
Please respond to
rajithr@huawei.com

To
dime@ietf.org
cc

Subject
[Dime] Hop-by-Hop identifier in relays







Hi
                If a relay does not use local storage for transaction state
(it uses
Proxy-Info AVP instead), MUST it still replace the Hop-by-Hop identifier
with a locally unique value (as described in sec.6.1.9 of RFC-3588-bis-10)?


Regards
Rajith

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



***********************  Aricent-Unclassified   ***********************

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



--
Harish R Prabhu
Bangalore, India. ------=_Part_1661_8002536.1208460109098-- --===============0273999709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0273999709==-- From dime-bounces@ietf.org Thu Apr 17 13:16:38 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE83B3A6FB6; Thu, 17 Apr 2008 13:16:38 -0700 (PDT) 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 583403A6A1A; Thu, 17 Apr 2008 13:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 sDWnVh+oNC3y; Thu, 17 Apr 2008 13:16:35 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id BE0393A6FE4; Thu, 17 Apr 2008 13:16:02 -0700 (PDT) Received: from mesico.nist.gov (csme13.ncsl.nist.gov [129.6.54.47]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m3HKFsFp019360; Thu, 17 Apr 2008 16:15:54 -0400 Message-Id: <7.0.1.0.2.20080417160616.02403730@nist.gov> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 17 Apr 2008 16:15:54 -0400 To: ietf@ietf.org, dime@ietf.org, radiusext@ops.ietf.org From: Katrin Hoeper Mime-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: katrin.hoeper@nist.gov Subject: [Dime] Invitation to join IETF proxy mailing list 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: , Content-Type: multipart/mixed; boundary="===============1038060830==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1038060830== Content-Type: multipart/alternative; boundary="=====================_22428828==.ALT" --=====================_22428828==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Security problems related to network proxies persistently come up in several IETF WGs and may affect the security of existing IETF network solutions while slowing down the progress of some current Internet Drafts. For this reason, Tim Polk and I organized an informal meeting in Philadelphia at IETF 71 to discuss these so-called "proxy problems" and their implications. As a result of our meeting, a proxy email list was created to further investigate the proxy problems. We decided to use AAA proxies as a starting point for our discussion on the list. The long-term (and ideal) goal could be to extend the results of the AAA proxy discussion in order to address proxy-related security issues in general. However, for now we will focus on AAA proxies. This email serves as an invitation for anybody interested to join our discussions on the list. Please subscribe at: https://www.ietf.org/mailman/listinfo/proxies Best regards, Katrin Hoeper ---------- Katrin Hoeper Computer Security Division National Institute of Standards and Technology (NIST) 100 Bureau Dr. Mail stop: 8930 Gaithersburg, MD 20878 (301) 975 - 4024 --=====================_22428828==.ALT Content-Type: text/html; charset="us-ascii" Hi,

Security problems related to network proxies persistently come up in several IETF WGs and may affect the security of existing IETF network solutions while slowing down the progress of some current Internet Drafts.

For this reason, Tim Polk and I organized an informal meeting in Philadelphia at IETF 71 to discuss these so-called "proxy problems" and their implications. As a
result of our meeting, a proxy email list was created to further investigate the proxy problems.

We decided to use AAA proxies as a starting point for our discussion on the list. The long-term (and ideal) goal could be to extend the results of the AAA proxy discussion in order to address proxy-related security issues in general. However, for now we will focus on AAA proxies.

This email serves as an invitation for anybody interested to join our discussions on the list.
Please subscribe at: https://www.ietf.org/mailman/listinfo/proxies

Best regards,
Katrin Hoeper

Katrin Hoeper
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20878
(301) 975 - 4024
 --=====================_22428828==.ALT-- --===============1038060830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1038060830==-- From dime-bounces@ietf.org Thu Apr 17 21:32:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3994828C130; Thu, 17 Apr 2008 21:32:52 -0700 (PDT) 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 2D5153A6986; Thu, 17 Apr 2008 21:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 Ir6yQ+warBmC; Thu, 17 Apr 2008 21:32:47 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id 739BF3A6C56; Thu, 17 Apr 2008 21:32:46 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m3I4I00g028811; Fri, 18 Apr 2008 09:48:01 +0530 Received: from webmail.asian.ad.aricent.com (webmail [10.203.158.17]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m3I4I0ia028774; Fri, 18 Apr 2008 09:48:00 +0530 In-Reply-To: <001f01c8a076$badaddb0$3a17120a@china.huawei.com> To: rajithr@huawei.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Fri, 18 Apr 2008 10:02:28 +0530 X-MIMETrack: Serialize by Router on WebMail/HSS(Build V655_10312005|October 31, 2005) at 04/18/2008 10:02:44 AM, Serialize complete at 04/18/2008 10:02:44 AM Cc: dime-bounces@ietf.org, dime@ietf.org Subject: Re: [Dime] Hop-by-Hop identifier in relays 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: , Content-Type: multipart/mixed; boundary="===============0219497204==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0219497204== Content-Type: multipart/related; boundary="=_related 0018F6D66525742F_=" This is a multipart message in MIME format. --=_related 0018F6D66525742F_= Content-Type: multipart/alternative; boundary="=_alternative 0018F6D96525742F_=" --=_alternative 0018F6D96525742F_= Content-Type: text/plain; charset="US-ASCII" Hi ! Your point is valid that you can find the source of the request message from the proxy-info AVP, storing some local state information. But consider the following case Source-1 sends a request with hop-by-hop Id as 'X', Relay forwards the requests to the destination with unique proxy-info AVP. Before Destination could send the response back, source-2 sends a request with the same hop-by-hop Id 'X' (this is possible as source-1 and source-2 are generating the hop-by-hop Id independently). Relay forwards the request with the same hop-by-hop Id X but with unique proxy-info AVP. When this request reaches to destination, it shall find that another request has come from the same node with the duplicate hop-by-hop Id. Since it is not supposed to look into the proxy-info AVP, it may discard the message considering it as invalid since hop-by-hop Id has to be unique. regards preeti Rajith R Sent by: dime-bounces@ietf.org 04/17/2008 04:05 PM Please respond to rajithr@huawei.com To Preeti Shandilya/HSS@HSS cc dime@ietf.org Subject Re: [Dime] Hop-by-Hop identifier in relays Hi If the relay uses local storage for txn state, I agree to your point on why the relay must replace the hop-by-hop id. However, when the relay uses Proxy-Info AVP for txn state (& no local storage, that means no need to match response with a request), I am not sure why the relay *MUST* replace the hop-by-hop id. Regards Rajith ________________________________________ From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com] Sent: Thursday, April 17, 2008 3:50 PM To: rajithr@huawei.com Cc: dime@ietf.org; dime-bounces@ietf.org Subject: Re: [Dime] Hop-by-Hop identifier in relays Hi Rajith ! While describing relaying and proxying requests, RFC 3588 implies following " The Hop-by-Hop identifier in the request is saved, and replaced with a locally unique value. The source of the request is also saved, which includes the IP address, port and protocol." Hence as per above, relay should generate the new id while forwarding the requests Relay node shall receive requests from multiple nodes and in some rare scenario 2 requests coming from the different nodes can be same. So it is mandatory for the relay node to generate its' own unique hop-by-hop Id for each request, on forwarding it further, so that it can match the response with the request regards Preeti Rajith R Sent by: dime-bounces@ietf.org 04/17/2008 03:07 PM Please respond to rajithr@huawei.com To dime@ietf.org cc Subject [Dime] Hop-by-Hop identifier in relays Hi If a relay does not use local storage for transaction state (it uses Proxy-Info AVP instead), MUST it still replace the Hop-by-Hop identifier with a locally unique value (as described in sec.6.1.9 of RFC-3588-bis-10)? Regards Rajith _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime *********************** Aricent-Unclassified *********************** _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime *********************** Aricent-Unclassified *********************** --=_alternative 0018F6D96525742F_= Content-Type: text/html; charset="US-ASCII"
Hi !

Your point is valid that you can find the source of the request message from the proxy-info AVP, storing some local state information. But consider the following case




Source-1 sends a request with hop-by-hop Id as 'X', Relay forwards the requests to the destination with unique proxy-info AVP. Before Destination could send the response back, source-2 sends a request with the same hop-by-hop Id 'X' (this is possible as source-1 and source-2 are generating the hop-by-hop Id independently). Relay forwards the request with the same hop-by-hop Id X but with unique proxy-info AVP. When this request reaches to destination, it shall find that another request has come from the same node with the duplicate hop-by-hop Id. Since it is not supposed to look into the proxy-info AVP, it may discard the message considering it as invalid since hop-by-hop Id has to be unique.

regards
preeti



Rajith R <rajithr@huawei.com>
Sent by: dime-bounces@ietf.org

04/17/2008 04:05 PM
Please respond to
rajithr@huawei.com
To
Preeti Shandilya/HSS@HSS
cc
dime@ietf.org
Subject
Re: [Dime] Hop-by-Hop identifier in relays





Hi
                If the relay uses local storage for txn state, I agree to your point
on why the relay must replace the hop-by-hop id. However, when the relay
uses Proxy-Info AVP for txn state (& no local storage, that means no need to
match response with a request), I am not sure why the relay *MUST* replace
the hop-by-hop id.

Regards

Rajith

________________________________________
From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]
Sent: Thursday, April 17, 2008 3:50 PM
To: rajithr@huawei.com
Cc: dime@ietf.org; dime-bounces@ietf.org
Subject: Re: [Dime] Hop-by-Hop identifier in relays


Hi Rajith !

While describing relaying and proxying requests, RFC 3588 implies following

"   The Hop-by-Hop identifier in the request is saved, and replaced with
   a locally unique value.  The source of the request is also saved,
   which includes the IP address, port and protocol."

Hence as per above, relay should generate the new id while forwarding the
requests

Relay node shall receive requests from multiple nodes and in some rare
scenario 2 requests coming from the different nodes can be same. So it is
mandatory for the relay node to generate its' own unique hop-by-hop Id for
each request, on forwarding it further, so that it can match the response
with the request

regards
Preeti

Rajith R <rajithr@huawei.com>
Sent by: dime-bounces@ietf.org
04/17/2008 03:07 PM
Please respond to
rajithr@huawei.com

To
dime@ietf.org
cc

Subject
[Dime] Hop-by-Hop identifier in relays







Hi
                If a relay does not use local storage for transaction state
(it uses
Proxy-Info AVP instead), MUST it still replace the Hop-by-Hop identifier
with a locally unique value (as described in sec.6.1.9 of RFC-3588-bis-10)?


Regards
Rajith

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



***********************  Aricent-Unclassified   ***********************

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


***********************  Aricent-Unclassified   *********************** --=_alternative 0018F6D96525742F_=-- --=_related 0018F6D66525742F_= Content-Type: image/gif Content-ID: <_1_06789A6006788C100018F6D16525742F> Content-Transfer-Encoding: base64 R0lGODlhNQK1AOcAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAANQK1AEAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDFgwgsmRDkiZTqlzJsqXLlzBjyuyI8uTA mgBQ1txJEKfAAECBKvTpkOjMo0iTKl3KtKlTiEafTtQpVKrVq1izat3qNCrXoRerfh1LtqzZs2jT hgyqtq3bt3DjylUqdq7du3jz6tXLdq/fv4ADC27pdfBIw1oLIy662K9inI/hKm58NHLPiJMXZo65 mTJar0HFiq7al61orp09uwQduu7N0TtJlhY6W7btnK5h405NkbdqrD59/xX+2yRxz8eLr8bcurnz 59CjS59Ovfp05Uyta9/Ovbt369iRJv8PT768+fPjz6tfz15w+vbw48tv+36+/fv4pdbPz78//e8A BrjdYf4VaKBy+3V14IIM/paaTpfldNOEFEbYU18STtXghhy6d1eCHYYoYlMgZjfiiSiqVeJSK6bo 4otrgWXhchK1COONOIYFFoavjSTbT3XxyKNBQ9qU45FIcvbhSTYm6WSKAkYpJXRrufbklVguWGSW XHZ5n5VehimmelOWaWaUXp6p5ppTjolRk2nBmZ+cS7ppkWVEtfYTkRDumRWdX2pG5GulEZihn4f2 eChkEfJknJ13lsfmpJRW2l2gkCJkWXiA2tepXJ9imumopP5Z6qmokpjqqqwq2eqrsJb/FGqstGY6 a6240ldnrrz2V9itMj4EbK/EvjVsSscWq+xZycq67LPtWSotldBWa16zImFr7bYK2qUtt+AmNZlp rmIW7rmNPRbVaEBOSFqQYM4oLLr0DvYrgYwuWmGiiApaY70AD7drwAR7OzChBSfM7MFMKuzwU99+ lGC8D1cc5pYWZ5wlxhp3nCTHHoeMI8Uil+wiySanLCLIKrdsYMSqdgnzVzMzWDNdaYrKK2uhGenW zarx3HOkRLNY7KZ5nobwbkwDl3Ow+wpJG7nuBvcubXxehvJGQL/sL795VshT14Zu/HW/oCGar75+ Ooq22sgezRLZg8qsM619cvr0fHTD/7eupHvL1zfgPmM3uGGHd+tm4i43rp/jkHsa+eR+U245mZdn Th7jmnf+qOegpxv66IiTbjpgnJ+uuoartz5X6q6XCjtj/MYe+uyF22460rO6Pa/uqmeWG9xtK52h 7wf5hjvwqP7qe95U5c028m9Dxfzpy599PejZQ729590nFP73izNM/uXTpq/n+eCbz/7k4yf/fufx 1z0/+u7f3zjvL7Gsqf74Ex/O/gVAygkvOMQ7nvGg5z3aFTByD6qe29a2LyAFiXUPhJzzoka8Qokt gfIjYAYdV7+yjbBlJbxQCk94soNtjYUFW2G/+CRDGBaohp3xnw2rhcPevHCHverhm/9+CERYCZEj OiyiEn24xCbSpIZOTBkRo0hFTUGxiiGbIha32DQuenEoWvyiE5MoRiqSsYxjDCMalajGNQKxjW5k 4RWLZjbJEWuOFcGjWfQoMbltLnDx4SNiBGkuu9kxiITjEiGR6EcBzjBrxgKk/Wq3mEV6CGqb0pUh HSkv7YlQcTvTTJEcNUEQWsWSW8lkAvvEytgwsG3tapQFH9nHO34NgWXD2p4Oh8rEeJJ6uPmgMNv1 SglWECS9FBgmLfRKeKVSkrk0FCt3mahSBlNCP5KlKZHZSJUkLplOO2QokcU5cF7FnHkMIhz5Ak32 oBNUwAxaO9fzzp+F7Y+bFFyrKFb9z0liqZ+FPNXWANrJJxH0d6Mi4kFp6aSF5k5M64zj/CIqUfZR tKLkuyhGt6fRjTKvox7VHUhDGruRkrR1Jj1p8ByqUjultKWkeylMb8fSmV6spjaVGU5zurGd8vRK Mv0p+nwq1I8RtahHCipSIXjUpd5IqU7dX1OjerKpUlVcu4LqVTmEQ61utUNH/Grz8idWlzKEaoRR o1XLajROMjRbBW0gWyGlLisq6jRXU+FDPTlXszowX9Z85Pr+98m+0tV70ismBd96TIQa9rACHKXV FAgZeK1rsA58rF9fp1lbkbWz//wsaA0q2tF+rLSmTSpqUzuy1bIWRmF97ZUCAgA7 --=_related 0018F6D66525742F_=-- --===============0219497204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0219497204==-- From dime-bounces@ietf.org Mon Apr 21 04:20:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887C93A6A2B; Mon, 21 Apr 2008 04:20:20 -0700 (PDT) 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 E24A53A69AB for ; Mon, 21 Apr 2008 04:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 CdmsDIYTqiVx for ; Mon, 21 Apr 2008 04:20:19 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id ADAD83A6A2B for ; Mon, 21 Apr 2008 04:20:18 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 13:20:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 13:20:21 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7CC05@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mip6 split and HA switch thread-index: Acijoa/qXJl/nXmcRrKo7ianQm8Q1Q== From: To: X-OriginalArrivalTime: 21 Apr 2008 11:20:23.0198 (UTC) FILETIME=[B0D6ABE0:01C8A3A1] Subject: [Dime] mip6 split and HA switch 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, I was looking into the document again and came to think that maybe we need a way to signal from AAA to HA that the HA needs to be changed. This would be useful in conjunction with the HA switch functionality (RFC 5142). Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 22 06:54:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEA43A6CE1; Tue, 22 Apr 2008 06:54:30 -0700 (PDT) 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 4F9A93A6D72 for ; Tue, 22 Apr 2008 06:54:29 -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 XNs8W61CGLZt for ; Tue, 22 Apr 2008 06:54:28 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by core3.amsl.com (Postfix) with ESMTP id 858BF3A69DB for ; Tue, 22 Apr 2008 06:54:28 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 50so1170278wra.13 for ; Tue, 22 Apr 2008 06:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xxGZC1kQ7pTZ7rN1HqMvV8mgKsMAETmWNQqDH7khzYg=; b=jXOR7XgBOWTJ2UbJz235/50mBFarEHdDHUSMqAnleQT4LHkd1f8ryVKLIdayVD6jaYcuT9tOysZNzXYoYdwq8baKF+i4HRIZpnBzdtjWgj9aWoKnnfcTtT1mFG2UaIV9e4nlLvF1Yn/qaFLUT4hCBM/n6M3W2v8PR9ULvxkeAnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mhAwo6HnMDGkKaMeA/aSQViwGzM9NroIsFwP1g3JF83Key0o9PtARfakm/ryz5eNB6PS2AwMRo2VjeeyumQJSsGmc0LyCYDrgxun54KTAGs/GN2v8ulCjkRJf0Ft2X1s2/yYRuQ/W58zsxWyGo51cI/qaKzCOB6e8iruMXfVKpY= Received: by 10.100.95.19 with SMTP id s19mr441721anb.27.1208872472339; Tue, 22 Apr 2008 06:54:32 -0700 (PDT) Received: by 10.100.249.18 with HTTP; Tue, 22 Apr 2008 06:54:32 -0700 (PDT) Message-ID: <5e2406980804220654g38b9ee09jc03cf7858b0da432@mail.gmail.com> Date: Tue, 22 Apr 2008 15:54:32 +0200 From: "Julien Bournelle" To: jouni.korhonen@teliasonera.com In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED302C7CC05@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Disposition: inline References: <59D7431DE2527D4CB0F1EFEDA5683ED302C7CC05@SEHAN021MB.tcad.telia.se> Cc: dime@ietf.org Subject: Re: [Dime] mip6 split and HA switch 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi jouni, I agree with you. Regards, Julien On Mon, Apr 21, 2008 at 1:20 PM, wrote: > Hi all, > > I was looking into the document again and came to think that > maybe we need a way to signal from AAA to HA that the HA > needs to be changed. This would be useful in conjunction with > the HA switch functionality (RFC 5142). > > Cheers, > Jouni > > _______________________________________________ > 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 dime-bounces@ietf.org Mon Apr 28 02:21:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E11AE3A6DDD; Mon, 28 Apr 2008 02:21:59 -0700 (PDT) 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 46B813A6CD7 for ; Mon, 28 Apr 2008 02:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 wxbUFNn2pTab for ; Mon, 28 Apr 2008 02:21:58 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF9F3A6BC4 for ; Mon, 28 Apr 2008 02:21:58 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns1.nict.go.jp with ESMTP id m3S9IGtn019884 for ; Mon, 28 Apr 2008 18:18:16 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m3S9IGev003795 for ; Mon, 28 Apr 2008 18:18:16 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m3S9IFVU003792 for ; Mon, 28 Apr 2008 18:18:15 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id C2D0043B7 for ; Mon, 28 Apr 2008 18:18:15 +0900 (JST) Received: from [133.243.146.189] (5gou2f-dhcp29.nict.go.jp [133.243.146.189]) by mail1.nict.go.jp (Postfix) with ESMTP id A42DA4398 for ; Mon, 28 Apr 2008 18:18:15 +0900 (JST) Message-ID: <4815963B.70009@nict.go.jp> Date: Mon, 28 Apr 2008 18:17:47 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.95.6 OpenPGP: id=33D9F61D Subject: [Dime] Diameter API draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, I am starting an implementation of Diameter API in a library. I have a couple of question about the draft-ietf-dime-diameter-api-06 [1] document. - There are some editorial issues with this document (one example: in the ToC 3.1.6 and 3.1.7 have the same label). The document is claimed to be sent to IESG in [2]. Does it mean that it will no more be updated? - Is there any plan to update the API with regards to rfc3588bis (new datatypes, etc...)? Thank you! Sebastien. [1] http://tools.ietf.org/html/draft-ietf-dime-diameter-api-06 [2] http://www.shingou.info/twiki/bin/view/Dime/DimeStatusUpdate -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 30 05:17:11 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9693A6E5C; Wed, 30 Apr 2008 05:17:11 -0700 (PDT) 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 531173A6DDE; Wed, 30 Apr 2008 05:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 5qHWhMStPTWQ; Wed, 30 Apr 2008 05:16:59 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id EDDDB3A6B38; Wed, 30 Apr 2008 05:16:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="scan'208";a="124263396" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 30 Apr 2008 08:16:44 -0400 X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="scan'208";a="195364523" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Apr 2008 08:16:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 14:16:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Volunteers for the Renewed AAA Doctors Team Thread-Index: AciqvAw+fUiUSEHARXWZa6ivRsDqxQ== From: "Romascanu, Dan (Dan)" To: , Cc: aaa-doctors@ietf.org, Ron Bonica , ops-area@ietf.org Subject: [Dime] Call for Volunteers for the Renewed AAA Doctors Team 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org In discussions with the RADEXT and DIME chairs we decided to refresh the membership of the AAA-Doctors team and to re-emphasize the goals of this team as follows: - Review IETF documents at IETF Last Call or IESG review phases on AAA related issues - Provide advice to IANA on queries related to definition and allocation of parameters related to the AAA protocols - Advice the Area Directors and the Working Groups in the area on issues related to the AAA architecture or protocols We ran a few weeks ago a poll through the current AAA-Doctors list members asking those who are interested to continue to be active or just watch the list to provide affirmative feedback. Based on the answers we received we believe that we should enroll a few new active members on the list. Those of you who are interested to participate in this team by providing reviews of the IETF documents and advice on AAA issues from time to time please let us know. Thanks and Regards, Ron and Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime