From Internet-Drafts@ietf.org Sun Apr 3 22:45:35 2011 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 304AB3A6917; Sun, 3 Apr 2011 22:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qT4Q0jwCTnew; Sun, 3 Apr 2011 22:45:25 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766B93A67EF; Sun, 3 Apr 2011 22:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110404054502.28503.75967.idtracker@localhost> Date: Sun, 03 Apr 2011 22:45:02 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-local-keytran-09.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, 04 Apr 2011 05:45:35 -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 Attribute-Value Pairs for Cryptographic Key Transport Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-local-keytran-09.txt Pages : 8 Date : 2011-04-03 Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-local-keytran-09.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-local-keytran-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-03224446.I-D@ietf.org> --NextPart-- From fbrockne@cisco.com Mon Apr 4 06:23:46 2011 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 25ADC3A69EF for ; Mon, 4 Apr 2011 06:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 7bkYnM1dcXyc for ; Mon, 4 Apr 2011 06:23:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id E91313A69BA for ; Mon, 4 Apr 2011 06:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=1950; q=dns/txt; s=iport; t=1301923522; x=1303133122; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=6iOXA8e+cElc9c8tFyKCncS/3p0H2j/8GwMVhz2Nj8Y=; b=JTOF5zKhWRN6PEpQ1L592NAXKxLs5OWaQWtA3nWIq+JEvOD7v6Q8CH+o MtXQ4rutPVnNp8pBAcvYUMVMBbcQZZP9wNw0GA7qfONhgTefinL3bqwaI TEeqaeTqptYj7gJyNuLgJOP9DDryur0uKZSQJTHlk0E+yxDVM8lr4eSE+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikGAArGmU2Q/khMgWdsb2JhbACYW40EFAEBFiYlpDabOoVrBJEE X-IronPort-AV: E=Sophos;i="4.63,297,1299456000"; d="scan'208";a="24358594" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 04 Apr 2011 13:25:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34DPKoP031958 for ; Mon, 4 Apr 2011 13:25:20 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 15:25:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2011 15:25:19 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: call for consent - naming the entities in draft-ietf-dime-nat-control Thread-Index: Acvyy74GzNfU7GgaQmm4QqbCD5apgg== From: "Frank Brockners (fbrockne)" To: X-OriginalArrivalTime: 04 Apr 2011 13:25:20.0857 (UTC) FILETIME=[BF192490:01CBF2CB] Subject: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control 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, 04 Apr 2011 13:23:46 -0000 Following a comment and recommendation from the Gen-ART review, the WG discussed the topic of naming the Diameter entities in draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions happened at IETF 77): The outcome of the discussion was the following recommended approach (hope that I captured things the right way, otherwise, please chime in): * draft-ietf-dime-nat-control should use the generic term "Diameter peer" when referring to the two interacting Diameter entities (i.e. we'd neither create new names for the Diameter entities in DNCA, nor would we name them client and server). * for those cases, where procedures/actions of the two peers need to be differentiated, one would use the description of the function of the peer in question, i.e. "NAT Controller" and "NAT".=20 Although we reached consensus in the WG meeting in Prague, the decision would need re-confirmation from the list. Appreciate your support, so that we can get this issue off the table. Thanks, Frank Some additional background on the above recommendation:=20 Quick summary of the reasoning expressed during the WG meeting: * DNCA is not a typical client-server application, but represents an exchange between two Diameter protocol peers; hence "client" and "server" nomenclature does not really apply to this application. The descriptions for "server" and "client" roles in RFC 3588, section 1.1 could be misleading when applied to non client-server protocols or non pure AAA-protocols. * The DNCA can be implemented per the current I-D without designating devices as "client" or "server". * If DNCA would be implemented within an architecture defined by a different SDO, the names of the two Diameter protocol peers would be named corresponding to the peering elements within the overall architecture, i.e. naming from DNCA isn't likely to be leveraged, hence naming should be as generic as possible. From tom111.taylor@bell.net Mon Apr 4 13:28:36 2011 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 6F91728C0EE for ; Mon, 4 Apr 2011 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] 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 BCPUfb4lG+On for ; Mon, 4 Apr 2011 13:28:35 -0700 (PDT) Received: from blu0-omc3-s34.blu0.hotmail.com (blu0-omc3-s34.blu0.hotmail.com [65.55.116.109]) by core3.amsl.com (Postfix) with ESMTP id 9E1D428C0ED for ; Mon, 4 Apr 2011 13:28:35 -0700 (PDT) Received: from BLU0-SMTP86 ([65.55.116.74]) by blu0-omc3-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 13:30:17 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP86.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 13:30:17 -0700 Date: Mon, 4 Apr 2011 16:30:18 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2011 20:30:18.0032 (UTC) FILETIME=[1C994B00:01CBF307] Subject: [Dime] Proposed changes to draft-ietf-dime-realm-based-redirection (1) 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, 04 Apr 2011 20:28:36 -0000 As reported at the meeting, this draft drew comments from Glen Zorn, Sebastien Decugis, and Avi Lior during WGLC. This note provides the proposed text changes to resolve the first two sets of comments. Avi's comment seemed to require direction from the list. However, prompted by existing text in Section 2.4 of RFC 3588, I have concluded that he is right. I present my argument and proposed changes in a separate note. Glen Zorn 02/08/2010 (ET) ========================= Looks fine to me; the only thing that I might add would be a more direct pointer to the "normal discovery procedures" mentioned in Section 3.1.2. Proposed new text: ... SHOULD attempt to reroute the request to the indicated realm using normal discovery procedures (Section 5.2 of RFC 3588) to ^^^^^^^^^^^^^^^^^^^^^^^^^ find an appropriate destination host. Sebastien Decugis 06/08/2010 (ET) ================================= 1) "(3.1.1) second list item (editorial): "Furthermore, the redirect agent MUST a Redirect-Realm AVP ^^^ missing word?" Proposed new text: Add the word"insert" following "MUST". 2) (3.1.1) What if the the other peer advertised the Relay application? Should the redirect agent consider that it supports the Redirect-Realm application? Proposed new text: Beginning of the first bullet: o If the peer from which the request was received did not advertise the Relay application or ^^^^^^^^^^^^^^^^^^^^^^^^ an application incorporating the realm-based routing capability in the CER/CEA exchange, ... Beginning of the second bullet: o Otherwise, if the Relay application or ^^^^^^^^^^^^^^^^^^^^^^^^ an application supporting the use of realm-based redirection was negotiated with the peer, ... 3) (3.1.1) "the message MUST include the Error- Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP," IIUC this is an impossible situation, since the Redirect Agent did not forward the Request. I believe this text could be removed for clarity. Proposed new text: Delete the second-last sentence of the second bullet. The deleted text reads: To prevent confusion at Diameter nodes receiving the answer message, the message MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP, in conformity with Section 7.1 of [RFC3588]. 4) (3.1.2) What if the original request contains a Destination-Host AVP? In that case, should a UNABLE_TO_DELIVER error be returned? There is probably no point in sending to the alternate realm with a Destination-Host in the previous realm, right? Unless maybe if the Destination-Realm of the request message does not match the Origin-Realm of the Redirect indication (change of broker for example). Any opinion? Proposed new text: Insert the following new text as the new first bullet of *3.1.1*: o If the original request contains a Destination-Host AVP, the the redirecting agent MUST return an error message with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 5) (3.2) This section does not give the value of the M flag for the new AVP. By the semantics of the application, I believe the M flag should be set, right? Proposed new text: Modify the last sentence of the first paragraph of section 3.2 to read as follows (new text indicated): The M flag for the Redirect-Realm AVP MUST be set, and the V ^^^^^^ ^^^^^^^^^^^^^^^^ flag MUST NOT be set. Many thanks to Sebastien in particular for his careful review. Tom Taylor From tom111.taylor@bell.net Mon Apr 4 19:05:11 2011 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 635463A6821 for ; Mon, 4 Apr 2011 19:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] 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 Tbsqsqi9Xqrd for ; Mon, 4 Apr 2011 19:05:10 -0700 (PDT) Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com [65.55.116.88]) by core3.amsl.com (Postfix) with ESMTP id 56CA63A6840 for ; Mon, 4 Apr 2011 19:05:10 -0700 (PDT) Received: from BLU0-SMTP51 ([65.55.116.72]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 19:06:53 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP51.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 19:06:52 -0700 Date: Mon, 4 Apr 2011 22:06:53 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2011 02:06:52.0653 (UTC) FILETIME=[2187E9D0:01CBF336] Subject: [Dime] Proposed changes to draft-ietf-dime-realm-based-redirection (2) 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, 05 Apr 2011 02:05:11 -0000 Avi Lior had the following comment, received 11/08/2010 (ET). By the way, my charts at the meeting said the comments were received last October. I don't know what strange process caused me to transpose year and month, but I apologize for the misdirection. Hi, I have reviewed draft-ietf-dime-realm-based-redirect-03 document -- or I should say i started but I had to stop because there are serious fundamental issues with this draft. I should start with the fact that i think the problem statement raised by the draft is valid. Also, I think that Diameter base 3588 should have supported Realm based redirection as well as host based redirection. Actually Realm-based redirection are probably more useful. However, the problem I am having is that the draft is changing the semantics of a Redirect Agent as defined by base and I dont think that we should be allowed to do that. I get that the draft got around backwards capability issue surrounding the new AVPs be introduced by asserting that only new applications will support the attributes. But in order to deliver this feature in 3588 the behavior of the Redirect Agent had to change. This new redirect agent has to differentiate between applications that do support realm base redirection vs non-realmbased redirection. This is new base behavior and thus should be done in Diameter V2 There is an alternative - which i thought was the approach taken when i started to read the draft and that is: -let the Application itself perform the redirection. To use the example provided, if the operator does not want to host the application anymore, it can let the Application respond back with the realm and/host redirection attributes. As I mentioned in my previous note, I now agree with Avi. The conversion comes about through a chance reading of the following paragraph in Section 2.4 of RFC 3588: Relay and redirect agents MUST advertise the Relay Application Identifier, while all other Diameter nodes MUST advertise locally supported applications. The receiver of a Capabilities Exchange message advertising Relay service MUST assume that the sender supports all current and future applications. I am worried that, by specifying new behaviour for conforming redirect agents, we are setting a precedent that could lead to trouble if it is followed. Since the normal application negotiation process is short-circuited in the case of nodes offering the Relay service, the forwarding agent becomes unable to predict the behaviour of Relay nodes. Without careful Working Group scrutiny, a specification involving the Relay service could end up breaking something. This is brittle. It is safer to place such behaviour at the application level, as Avi suggests. Based on that, the basic change required in the realm-based-redirection draft is to change "relay agent" to "proxy" wherever it occurs. Naturally, other details are also affected. Here is the list of detailed changes that are required. Abstract: Delete the first sentence and the word "However" at the beginning of the next sentence. Introduction, first paragraph, fourth sentence: - Replace "redirect server" by "service", so that the sentence reads: ... the original operator maintains a service to indicate the alternative destination Section 2: - Change to read as follows: Because realm-based redirection is not part of base Diameter behaviour, support for realm-based redirection has to be provided at the application level by a Diameter proxy. Designers of new applications wishing to include support for realm-based redirection can incorporate the mechanism specified here by reference to this document. Section 3.1.1: - Change the title to: "Behaviour at the Redirecting Proxy" - Replace the two paragraphs preceding the bullets with the following text: If a Diameter proxy that supports realm-based redirection receives a request for an application that includes realm-based redirection, and the proxy has been configured to provide redirection for the destination realm of the request, then: [Bullets follow, including the new one proposed in my previous message] - Change all instances of "redirect agent" in the bullets to "redirecting proxy". - Change the final bullet (in which redirection is performed) to read as follows. The first sentence is unchanged but is included for context. o Otherwise, if an application supporting the use of realm-based redirection was negotiated with the peer, the redirect agent MUST set the Result-Code AVP to DIAMETER_REALM_REDIRECT_INDICATION rather than DIAMETER_REDIRECT_INDICATION. Furthermore, the redirect agent MUST include a Redirect-Realm AVP containing the realm with which it has been configured for the purpose of realm-based redirection for this application in its answer message. The redirecting proxy MUST maintain the Hop-by-Hop Identifier in the message header, so that the agent from which it received the request can retrieve that request from its pending message queue (see Section 5.3 of RFC 3588). QUESTION: should the redirected message have the 'E' bit set? Tom Taylor From shwethab@cisco.com Tue Apr 5 21:28:30 2011 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 657953A6849 for ; Tue, 5 Apr 2011 21:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 YvU8uXy9QwGv for ; Tue, 5 Apr 2011 21:28:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 06C4D3A6826 for ; Tue, 5 Apr 2011 21:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shwethab@cisco.com; l=2407; q=dns/txt; s=iport; t=1302064213; x=1303273813; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=62U4CgPC8/L59zlVyqWnTaxpebbRupT1ddaGE/3ir6o=; b=XnfeSUVXsn5gnxN9OrgouMTn79XHmQhjQwdpwOzBQMy8p/p1nUm8O+vq zToRMTa8gAqU7FswgAMwGyBm5YafrQF634AAIz3Jw92dya90D+L7sPFYX 5upi+jJqL6FQAYAzWIvWPYxRAOpOm504XscY2Myq4BBQf+w5MeNRTT2Nr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEEACDsm02Q/khNgWdsb2JhbAClcgIUAQEWJiWIeZw3nCmFbASFTIdug2iFYA X-IronPort-AV: E=Sophos;i="4.63,308,1299456000"; d="scan'208";a="82341654" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 06 Apr 2011 04:29:55 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p364TqDj012535 for ; Wed, 6 Apr 2011 04:29:55 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 09:59:54 +0530 Received: from 173.39.64.79 ([173.39.64.79]) by XMB-BGL-417.cisco.com ([72.163.129.213]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Apr 2011 04:29:54 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 06 Apr 2011 10:00:19 +0530 From: Shwetha To: "Frank Brockners (fbrockne)" , Message-ID: Thread-Topic: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control Thread-Index: Acvyy74GzNfU7GgaQmm4QqbCD5apggBR5eyB In-Reply-To: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Apr 2011 04:29:54.0544 (UTC) FILETIME=[47264F00:01CBF413] Subject: Re: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control 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, 06 Apr 2011 04:28:30 -0000 I support the below proposal of referring to DNCA entities as "Diameter peer" and explicitly use "NAT Controller" and "NAT" when required. Thanks, Shwetha On 4/4/11 6:55 PM, "Frank Brockners (fbrockne)" wrote: > > Following a comment and recommendation from the Gen-ART review, the WG > discussed the topic of naming the Diameter entities in > draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions > happened at IETF 77): > > The outcome of the discussion was the following recommended approach > (hope that I captured things the right way, otherwise, please chime in): > > * draft-ietf-dime-nat-control should use the generic term "Diameter > peer" when referring to the two interacting Diameter entities (i.e. we'd > neither create new names for the Diameter entities in DNCA, nor would we > name them client and server). > * for those cases, where procedures/actions of the two peers need to be > differentiated, one would use the description of the function of the > peer in question, i.e. "NAT Controller" and "NAT". > > Although we reached consensus in the WG meeting in Prague, the decision > would need re-confirmation from the list. > > Appreciate your support, so that we can get this issue off the table. > > Thanks, Frank > > > > Some additional background on the above recommendation: > Quick summary of the reasoning expressed during the WG meeting: > * DNCA is not a typical client-server application, but represents an > exchange between two Diameter protocol peers; hence "client" and > "server" nomenclature does not really apply to this application. The > descriptions for "server" and "client" roles in RFC 3588, section 1.1 > could be misleading when applied to non client-server protocols or non > pure AAA-protocols. > * The DNCA can be implemented per the current I-D without designating > devices as "client" or "server". > * If DNCA would be implemented within an architecture defined by a > different SDO, the names of the two Diameter protocol peers would be > named corresponding to the peering elements within the overall > architecture, i.e. naming from DNCA isn't likely to be leveraged, hence > naming should be as generic as possible. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Wed Apr 6 08:47:58 2011 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 8350528C14D for ; Wed, 6 Apr 2011 08:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Wlsyy7a17KR5 for ; Wed, 6 Apr 2011 08:47:57 -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 699A328C0F6 for ; Wed, 6 Apr 2011 08:47:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgHAFMtcU2HCzI1/2dsb2JhbACYaY18dKR5ApkWhWEEkAw X-IronPort-AV: E=Sophos;i="4.63,311,1299474000"; d="scan'208";a="240431766" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Apr 2011 11:49:39 -0400 X-IronPort-AV: E=Sophos;i="4.63,311,1299474000"; d="scan'208";a="635847720" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Apr 2011 11:49:38 -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: Wed, 6 Apr 2011 17:49:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-extended-naptr-06 Thread-Index: Acv0cjsx7xhWJ1CfSeibSR3SnRxXTg== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD review of draft-ietf-dime-extended-naptr-06 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, 06 Apr 2011 15:47:58 -0000 Hi,=20 I performed the AD review of draft-ietf-dime-extended-naptr-06. The document is in good shape and I plan to send it to IETF Last Call in the next day.=20 I have one minor comment and one question. These should be resolved together with other IETF LC comments:=20 1. The clarity of the text could be improved if a number of acronyms would be extended at the first occurrence: NAPTR, NAI, CER/CEA (and I may have missed a few) 2. idnits warns:=20 -- Obsolete informational reference (is this intentional?): RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) I think that this is OK, but please check again that I am right.=20 Thanks and Regards, Dan=20 From lionel.morand@orange-ftgroup.com Wed Apr 6 10:05:18 2011 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 161573A68A9 for ; Wed, 6 Apr 2011 10:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 9eWf+j3GXbNQ for ; Wed, 6 Apr 2011 10:05:17 -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 E110F3A6841 for ; Wed, 6 Apr 2011 10:05:16 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AAE718C000F; Wed, 6 Apr 2011 19:07:32 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id A0DC38B8001; Wed, 6 Apr 2011 19:07:32 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 19:07:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2011 19:06:58 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control Thread-Index: Acvyy74GzNfU7GgaQmm4QqbCD5apggBR5eyBABo9L+A= References: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> From: To: , , X-OriginalArrivalTime: 06 Apr 2011 17:07:00.0239 (UTC) FILETIME=[0AF949F0:01CBF47D] Subject: Re: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control 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, 06 Apr 2011 17:05:18 -0000 Hi Frank, Just to confirm that your summary is correct according the consensus = reached during the meeting. I hope that other Dime guys will provide their views on this trivial = point that should no longer block the publication of the draft IMHO. BR, Lionel=20 -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Shwetha Envoy=E9=A0: mercredi 6 avril 2011 06:30 =C0=A0: Frank Brockners (fbrockne); dime@ietf.org Objet=A0: Re: [Dime] call for consent - naming the entities in = draft-ietf-dime-nat-control I support the below proposal of referring to DNCA entities as "Diameter peer" and explicitly use "NAT Controller" and "NAT" when required. Thanks, Shwetha On 4/4/11 6:55 PM, "Frank Brockners (fbrockne)" = wrote: >=20 > Following a comment and recommendation from the Gen-ART review, the WG > discussed the topic of naming the Diameter entities in > draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions > happened at IETF 77): >=20 > The outcome of the discussion was the following recommended approach > (hope that I captured things the right way, otherwise, please chime = in): >=20 > * draft-ietf-dime-nat-control should use the generic term "Diameter > peer" when referring to the two interacting Diameter entities (i.e. = we'd > neither create new names for the Diameter entities in DNCA, nor would = we > name them client and server). > * for those cases, where procedures/actions of the two peers need to = be > differentiated, one would use the description of the function of the > peer in question, i.e. "NAT Controller" and "NAT". >=20 > Although we reached consensus in the WG meeting in Prague, the = decision > would need re-confirmation from the list. >=20 > Appreciate your support, so that we can get this issue off the table. >=20 > Thanks, Frank >=20 >=20 >=20 > Some additional background on the above recommendation: > Quick summary of the reasoning expressed during the WG meeting: > * DNCA is not a typical client-server application, but represents an > exchange between two Diameter protocol peers; hence "client" and > "server" nomenclature does not really apply to this application. The > descriptions for "server" and "client" roles in RFC 3588, section 1.1 > could be misleading when applied to non client-server protocols or non > pure AAA-protocols. > * The DNCA can be implemented per the current I-D without designating > devices as "client" or "server". > * If DNCA would be implemented within an architecture defined by a > different SDO, the names of the two Diameter protocol peers would be > named corresponding to the peering elements within the overall > architecture, i.e. naming from DNCA isn't likely to be leveraged, = hence > naming should be as generic as possible. > _______________________________________________ > 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 iesg-secretary@ietf.org Wed Apr 6 10:34:54 2011 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 8131B28C0EF; Wed, 6 Apr 2011 10:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UU+b7Dlne0mk; Wed, 6 Apr 2011 10:34:53 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8C63A6957; Wed, 6 Apr 2011 10:34:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.15 Message-ID: <20110406173453.31558.63429.idtracker@localhost> Date: Wed, 06 Apr 2011 10:34:53 -0700 Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter S-NAPTR Usage) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:34:54 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter S-NAPTR Usage' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ No IPR declarations have been submitted directly on this I-D. From tom111.taylor@bell.net Wed Apr 6 14:02:23 2011 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 5D8D63A67C3 for ; Wed, 6 Apr 2011 14:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.508 X-Spam-Level: X-Spam-Status: No, score=-101.508 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] 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 ljIIWfGJfjZO for ; Wed, 6 Apr 2011 14:02:22 -0700 (PDT) Received: from blu0-omc3-s25.blu0.hotmail.com (blu0-omc3-s25.blu0.hotmail.com [65.55.116.100]) by core3.amsl.com (Postfix) with ESMTP id 58F693A67C2 for ; Wed, 6 Apr 2011 14:02:22 -0700 (PDT) Received: from BLU0-SMTP58 ([65.55.116.74]) by blu0-omc3-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 14:04:06 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP58.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 14:04:05 -0700 Date: Wed, 6 Apr 2011 17:04:06 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Frank Brockners (fbrockne)" References: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2011 21:04:05.0644 (UTC) FILETIME=[29F9D4C0:01CBF49E] Cc: dime@ietf.org Subject: Re: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control 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, 06 Apr 2011 21:02:23 -0000 I agree. On 04/04/2011 9:25 AM, Frank Brockners (fbrockne) wrote: > > Following a comment and recommendation from the Gen-ART review, the WG > discussed the topic of naming the Diameter entities in > draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions > happened at IETF 77): > > The outcome of the discussion was the following recommended approach > (hope that I captured things the right way, otherwise, please chime in): > > * draft-ietf-dime-nat-control should use the generic term "Diameter > peer" when referring to the two interacting Diameter entities (i.e. we'd > neither create new names for the Diameter entities in DNCA, nor would we > name them client and server). > * for those cases, where procedures/actions of the two peers need to be > differentiated, one would use the description of the function of the > peer in question, i.e. "NAT Controller" and "NAT". > > Although we reached consensus in the WG meeting in Prague, the decision > would need re-confirmation from the list. > > Appreciate your support, so that we can get this issue off the table. > > Thanks, Frank > > > > Some additional background on the above recommendation: > Quick summary of the reasoning expressed during the WG meeting: > * DNCA is not a typical client-server application, but represents an > exchange between two Diameter protocol peers; hence "client" and > "server" nomenclature does not really apply to this application. The > descriptions for "server" and "client" roles in RFC 3588, section 1.1 > could be misleading when applied to non client-server protocols or non > pure AAA-protocols. > * The DNCA can be implemented per the current I-D without designating > devices as "client" or "server". > * If DNCA would be implemented within an architecture defined by a > different SDO, the names of the two Diameter protocol peers would be > named corresponding to the peering elements within the overall > architecture, i.e. naming from DNCA isn't likely to be leveraged, hence > naming should be as generic as possible. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From mark@azu.ca Wed Apr 6 15:50:24 2011 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 68E8C3A67EE for ; Wed, 6 Apr 2011 15:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 dODcc8nfAugH for ; Wed, 6 Apr 2011 15:50:23 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 391EB3A67EB for ; Wed, 6 Apr 2011 15:50:22 -0700 (PDT) Received: by qwc23 with SMTP id 23so1429780qwc.31 for ; Wed, 06 Apr 2011 15:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.51.214 with SMTP id e22mr131881qcg.156.1302130326057; Wed, 06 Apr 2011 15:52:06 -0700 (PDT) Received: by 10.229.95.72 with HTTP; Wed, 6 Apr 2011 15:52:06 -0700 (PDT) In-Reply-To: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> References: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> Date: Wed, 6 Apr 2011 18:52:06 -0400 Message-ID: From: Mark Jones To: "Frank Brockners (fbrockne)" Content-Type: text/plain; charset=ISO-8859-1 Cc: dime@ietf.org Subject: Re: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control 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, 06 Apr 2011 22:50:24 -0000 Hi Frank, I agree with defining the "NAT" and "NAT Controller" roles and using these terms in the procedures. I also agree with using "Diameter peer" in text where the role is irrelevant. Regards Mark On Mon, Apr 4, 2011 at 9:25 AM, Frank Brockners (fbrockne) wrote: > > Following a comment and recommendation from the Gen-ART review, the WG > discussed the topic of naming the Diameter entities in > draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions > happened at IETF 77): > > The outcome of the discussion was the following recommended approach > (hope that I captured things the right way, otherwise, please chime in): > > * draft-ietf-dime-nat-control should use the generic term "Diameter > peer" when referring to the two interacting Diameter entities (i.e. we'd > neither create new names for the Diameter entities in DNCA, nor would we > name them client and server). > * for those cases, where procedures/actions of the two peers need to be > differentiated, one would use the description of the function of the > peer in question, i.e. "NAT Controller" and "NAT". > > Although we reached consensus in the WG meeting in Prague, the decision > would need re-confirmation from the list. > > Appreciate your support, so that we can get this issue off the table. > > Thanks, Frank > > > > Some additional background on the above recommendation: > Quick summary of the reasoning expressed during the WG meeting: > * DNCA is not a typical client-server application, but represents an > exchange between two Diameter protocol peers; hence "client" and > "server" nomenclature does not really apply to this application. The > descriptions for "server" and "client" roles in RFC 3588, section 1.1 > could be misleading when applied to non client-server protocols or non > pure AAA-protocols. > * The DNCA can be implemented per the current I-D without designating > devices as "client" or "server". > * If DNCA would be implemented within an architecture defined by a > different SDO, the names of the two Diameter protocol peers would be > named corresponding to the peering elements within the overall > architecture, i.e. naming from DNCA isn't likely to be leveraged, hence > naming should be as generic as possible. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From avi@bridgewatersystems.com Wed Apr 6 18:59:57 2011 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 9B95F3A683D for ; Wed, 6 Apr 2011 18:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 6HxgGsay9jTM for ; Wed, 6 Apr 2011 18:59:56 -0700 (PDT) Received: from mail37.messagelabs.com (mail37.messagelabs.com [216.82.241.83]) by core3.amsl.com (Postfix) with ESMTP id 35B143A67A8 for ; Wed, 6 Apr 2011 18:59:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-10.tower-37.messagelabs.com!1302141699!89404548!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 19451 invoked from network); 7 Apr 2011 02:01:40 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-10.tower-37.messagelabs.com with RC4-SHA encrypted SMTP; 7 Apr 2011 02:01:40 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Wed, 6 Apr 2011 22:01:39 -0400 From: Avi Lior To: "Frank Brockners (fbrockne)" , "dime@ietf.org" Date: Wed, 6 Apr 2011 22:01:38 -0400 Thread-Topic: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control Thread-Index: Acv0x7rcpuLQWpjYQPWWaVjXJI8M0w== Message-ID: In-Reply-To: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control 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, 07 Apr 2011 01:59:57 -0000 I agree with the terminology usage when there are no specific server/client roles. After all, Diameter is a peer-to-peer protocol - we tend to forget that. -- Avi Lior --Bridgewater Systems On 04-04-11 22:25 , "Frank Brockners (fbrockne)" wrote: > >Following a comment and recommendation from the Gen-ART review, the WG >discussed the topic of naming the Diameter entities in >draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions >happened at IETF 77): > >The outcome of the discussion was the following recommended approach >(hope that I captured things the right way, otherwise, please chime in): > >* draft-ietf-dime-nat-control should use the generic term "Diameter >peer" when referring to the two interacting Diameter entities (i.e. we'd >neither create new names for the Diameter entities in DNCA, nor would we >name them client and server). >* for those cases, where procedures/actions of the two peers need to be >differentiated, one would use the description of the function of the >peer in question, i.e. "NAT Controller" and "NAT". > >Although we reached consensus in the WG meeting in Prague, the decision >would need re-confirmation from the list. > >Appreciate your support, so that we can get this issue off the table. > >Thanks, Frank > > > >Some additional background on the above recommendation: >Quick summary of the reasoning expressed during the WG meeting: >* DNCA is not a typical client-server application, but represents an >exchange between two Diameter protocol peers; hence "client" and >"server" nomenclature does not really apply to this application. The >descriptions for "server" and "client" roles in RFC 3588, section 1.1 >could be misleading when applied to non client-server protocols or non >pure AAA-protocols. >* The DNCA can be implemented per the current I-D without designating >devices as "client" or "server". >* If DNCA would be implemented within an architecture defined by a >different SDO, the names of the two Diameter protocol peers would be >named corresponding to the peering elements within the overall >architecture, i.e. naming from DNCA isn't likely to be leveraged, hence >naming should be as generic as possible. >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime From sunseawq@huawei.com Wed Apr 6 20:30:39 2011 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 BE4BA28C0EE for ; Wed, 6 Apr 2011 20:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 bvK8kDOeyp0R for ; Wed, 6 Apr 2011 20:30:38 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 37F3128C102 for ; Wed, 6 Apr 2011 20:30:38 -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 <0LJ900GMQJ3W3W@szxga04-in.huawei.com> for dime@ietf.org; Thu, 07 Apr 2011 11:31:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ900C9YJ3W3T@szxga04-in.huawei.com> for dime@ietf.org; Thu, 07 Apr 2011 11:31:08 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJ900MZ0J3VFG@szxml06-in.huawei.com> for dime@ietf.org; Thu, 07 Apr 2011 11:31:08 +0800 (CST) Date: Thu, 07 Apr 2011 11:31:06 +0800 From: Qin Wu To: Avi Lior , "Frank Brockners (fbrockne)" , dime@ietf.org Message-id: <02ec01cbf4d4$3b233bc0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control 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, 07 Apr 2011 03:30:39 -0000 +1 NAT controller should be defined in this document. ----- Original Message ----- From: "Avi Lior" To: "Frank Brockners (fbrockne)" ; Sent: Thursday, April 07, 2011 10:01 AM Subject: Re: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control >I agree with the terminology usage when there are no specific > server/client roles. > > After all, Diameter is a peer-to-peer protocol - we tend to forget that. > > -- Avi Lior > --Bridgewater Systems > > > On 04-04-11 22:25 , "Frank Brockners (fbrockne)" > wrote: > >> >>Following a comment and recommendation from the Gen-ART review, the WG >>discussed the topic of naming the Diameter entities in >>draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions >>happened at IETF 77): >> >>The outcome of the discussion was the following recommended approach >>(hope that I captured things the right way, otherwise, please chime in): >> >>* draft-ietf-dime-nat-control should use the generic term "Diameter >>peer" when referring to the two interacting Diameter entities (i.e. we'd >>neither create new names for the Diameter entities in DNCA, nor would we >>name them client and server). >>* for those cases, where procedures/actions of the two peers need to be >>differentiated, one would use the description of the function of the >>peer in question, i.e. "NAT Controller" and "NAT". >> >>Although we reached consensus in the WG meeting in Prague, the decision >>would need re-confirmation from the list. >> >>Appreciate your support, so that we can get this issue off the table. >> >>Thanks, Frank >> >> >> >>Some additional background on the above recommendation: >>Quick summary of the reasoning expressed during the WG meeting: >>* DNCA is not a typical client-server application, but represents an >>exchange between two Diameter protocol peers; hence "client" and >>"server" nomenclature does not really apply to this application. The >>descriptions for "server" and "client" roles in RFC 3588, section 1.1 >>could be misleading when applied to non client-server protocols or non >>pure AAA-protocols. >>* The DNCA can be implemented per the current I-D without designating >>devices as "client" or "server". >>* If DNCA would be implemented within an architecture defined by a >>different SDO, the names of the two Diameter protocol peers would be >>named corresponding to the peering elements within the overall >>architecture, i.e. naming from DNCA isn't likely to be leveraged, hence >>naming should be as generic as possible. >>_______________________________________________ >>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 jouni.nospam@gmail.com Wed Apr 6 23:52:09 2011 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 AFEC73A6814 for ; Wed, 6 Apr 2011 23:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fl7NyYdtYXv9 for ; Wed, 6 Apr 2011 23:52:08 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E2BAD3A67F3 for ; Wed, 6 Apr 2011 23:52:07 -0700 (PDT) Received: by bwz13 with SMTP id 13so1992090bwz.31 for ; Wed, 06 Apr 2011 23:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=8lbfQ6D4rnxaALpgoi3/afWjd1gPF2QMa1BrvTVCaDg=; b=ETFl7KlIviseF4nLlrCaxOb8HewpBojDpGk9vDCqKTJhq7kpDYQB0OI5RLUFgdzZS/ /xVzWh2HHTcpy5F0MLjJaPP57Z2/J1hwTZM+XWvd7qAlGyPF81GTujopA+UPRxdtbeyP LRkafve3vD/YoRnOsXRVYqk5GQkxtwovWAIXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=GoGPzb3w4Cp++85Y2e0Le2yMbheTQkMickrEJUkf6c3psm3NuvcZZk9P3Ce0uLeInE YRHycI4d+RUW05uJAeie6qUucUESWy1+cCbOhDmSXV/UEi8G8z4hkNhJq+g03BofcFI/ MxoCwBFdHbZDIhzs6/5yYeCJqBYLpq0GYo/L4= Received: by 10.204.81.224 with SMTP id y32mr396591bkk.152.1302159231620; Wed, 06 Apr 2011 23:53:51 -0700 (PDT) Received: from [10.255.129.20] ([192.100.123.77]) by mx.google.com with ESMTPS id c11sm853772bkc.2.2011.04.06.23.53.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 23:53:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 7 Apr 2011 09:53:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6214EF5B-0199-4665-933B-48EFFC367701@gmail.com> References: To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1082) Cc: dime@ietf.org Subject: Re: [Dime] AD review of draft-ietf-dime-extended-naptr-06 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, 07 Apr 2011 06:52:09 -0000 Hi Dan, Thanks for the review. On Apr 6, 2011, at 6:49 PM, Romascanu, Dan (Dan) wrote: >=20 >=20 > Hi,=20 >=20 > I performed the AD review of draft-ietf-dime-extended-naptr-06. The > document is in good shape and I plan to send it to IETF Last Call in = the > next day.=20 >=20 > I have one minor comment and one question. These should be resolved > together with other IETF LC comments:=20 >=20 > 1. The clarity of the text could be improved if a number of acronyms > would be extended at the first occurrence: NAPTR, NAI, CER/CEA (and I > may have missed a few) Ok. We'll take care of this. >=20 > 2. idnits warns:=20 >=20 > -- Obsolete informational reference (is this intentional?): RFC 2915 > (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) >=20 > I think that this is OK, but please check again that I am right.=20 We kept the reference to RFC2915, even if it is obsolete now, as that is = what RFC3588 references to. However, I think it could be ok to give a = reference to the most recent NAPTR RFC3403. - Jouni >=20 > Thanks and Regards, >=20 > Dan=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Wed Apr 6 23:54:11 2011 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 B3BEF3A681B for ; Wed, 6 Apr 2011 23:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 8Zz-8M4C5YZ5 for ; Wed, 6 Apr 2011 23:54:10 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8B95F3A67F3 for ; Wed, 6 Apr 2011 23:54:10 -0700 (PDT) Received: by bwz13 with SMTP id 13so1993126bwz.31 for ; Wed, 06 Apr 2011 23:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=QwIUoyn3VfsDMgbGY+PEdXaMwXVv1+i9AwCrYvL7ANU=; b=O8zs0Oq8WJ/rEy9DOUrtikhkhs6NXBYWYWtainmWQOnobagyWcnDn2vEeQfs8q2VF8 aHxRFWp6ZRblswSsb2H5lbdadJJlBMjvguAqkFkeTPqXNQCscoru73L2hb7v4EpaM4Bg 018nu3hvcNWmskUYn/2Q2EXcBt7/9V3vyDISY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=h5Kz/sD4FQRawyLxMplb680NGSv9L4+JjaUxITl65EhJKE158ahXX5m4mKdQzhHkS0 xJHvXh5pke2JiT0PgM9NDH+TOz2CTNIJtIiCtti5U3TPExayPhe32X4SDK1+INWYZbYi LLXXo3MnJk519+IoO4q1uQU3GzW3LJjqqOyZc= Received: by 10.204.165.193 with SMTP id j1mr435168bky.11.1302159353811; Wed, 06 Apr 2011 23:55:53 -0700 (PDT) Received: from [10.255.129.20] ([192.100.123.77]) by mx.google.com with ESMTPS id w3sm854435bkt.5.2011.04.06.23.55.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 23:55:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> Date: Thu, 7 Apr 2011 09:55:44 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> To: Frank Brockners (fbrockne) X-Mailer: Apple Mail (2.1082) Cc: dime@ietf.org Subject: Re: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control 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, 07 Apr 2011 06:54:11 -0000 Looks good to me. - Jouni On Apr 4, 2011, at 4:25 PM, Frank Brockners (fbrockne) wrote: > > Following a comment and recommendation from the Gen-ART review, the WG > discussed the topic of naming the Diameter entities in > draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions > happened at IETF 77): > > The outcome of the discussion was the following recommended approach > (hope that I captured things the right way, otherwise, please chime in): > > * draft-ietf-dime-nat-control should use the generic term "Diameter > peer" when referring to the two interacting Diameter entities (i.e. we'd > neither create new names for the Diameter entities in DNCA, nor would we > name them client and server). > * for those cases, where procedures/actions of the two peers need to be > differentiated, one would use the description of the function of the > peer in question, i.e. "NAT Controller" and "NAT". > > Although we reached consensus in the WG meeting in Prague, the decision > would need re-confirmation from the list. > > Appreciate your support, so that we can get this issue off the table. > > Thanks, Frank > > > > Some additional background on the above recommendation: > Quick summary of the reasoning expressed during the WG meeting: > * DNCA is not a typical client-server application, but represents an > exchange between two Diameter protocol peers; hence "client" and > "server" nomenclature does not really apply to this application. The > descriptions for "server" and "client" roles in RFC 3588, section 1.1 > could be misleading when applied to non client-server protocols or non > pure AAA-protocols. > * The DNCA can be implemented per the current I-D without designating > devices as "client" or "server". > * If DNCA would be implemented within an architecture defined by a > different SDO, the names of the two Diameter protocol peers would be > named corresponding to the peering elements within the overall > architecture, i.e. naming from DNCA isn't likely to be leveraged, hence > naming should be as generic as possible. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@freediameter.net Thu Apr 7 00:12:44 2011 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 7707828C0EE for ; Thu, 7 Apr 2011 00:12:44 -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 2YW6WiWP5WPU for ; Thu, 7 Apr 2011 00:12:43 -0700 (PDT) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id AE5943A69EE for ; Thu, 7 Apr 2011 00:12:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id D40312C09B for ; Thu, 7 Apr 2011 09:12:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWjFlca23lRw for ; Thu, 7 Apr 2011 09:12:22 +0200 (CEST) Received: from [192.168.111.11] (p1192-ipbf1208hodogaya.kanagawa.ocn.ne.jp [122.24.172.192]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 368252C09A for ; Thu, 7 Apr 2011 09:12:21 +0200 (CEST) Message-ID: <4D9D644B.70409@freediameter.net> Date: Thu, 07 Apr 2011 16:14:19 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Proposed changes to draft-ietf-dime-realm-based-redirection (2) 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, 07 Apr 2011 07:12:44 -0000 Hi Tom, all, > I should start with the fact that i think the problem statement raised > by the draft is valid. Also, I think that Diameter base 3588 should > have supported Realm based redirection as well as host based > redirection. Actually Realm-based redirection are probably more useful. I strongly agree with this. > However, the problem I am having is that the draft is changing the > semantics of a Redirect Agent as defined by base and I dont think that > we should be allowed to do that. I must confess I have difficulties seeing what the problem is in this case; either the redirect agent would support this feature, or it would not. Both cases end up in being handled correctly, I think. > This is new base behavior and thus should be done in Diameter V2 Agreed also. > There is an alternative - which i thought was the approach taken when > i started to read the draft and that is: > > -let the Application itself perform the redirection. To use the > example provided, if the operator does not want to host the > application anymore, it can let the Application respond back with the > realm and/host redirection attributes. I agree this solves the issue of the Redirect Agent being "aware" of this new mechanism. However, it seems to me that the feature should be kept transversal to the applications, i.e. that the peer that handles these realm redirect should not need any knowledge of the application(s). > I am worried that, by specifying new behaviour for conforming redirect > agents, we are setting a precedent that could lead to trouble if it is > followed. Since the normal application negotiation process is > short-circuited in the case of nodes offering the Relay service, the > forwarding agent becomes unable to predict the behaviour of Relay > nodes. Without careful Working Group scrutiny, a specification > involving the Relay service could end up breaking something. This is > brittle. It is safer to place such behaviour at the application level, > as Avi suggests. Another approach would be for example to include an AVP in the CER/CEA exchange to signal that Realm-based redirect is supported by a relay. But I still believe that there is no real problem if the relay agent does not support the realm-based redirection... > QUESTION: should the redirected message have the 'E' bit set? If the features becomes simply part of the "normal" application flow, and realm-based redirect is handled by proxies of this application, I think the E bit should be cleared, since "standard" based protocol agents will not have to deal differently with these answer messages in that case. Best regards, Sebastien. From gwz@net-zen.net Thu Apr 7 01:40:34 2011 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 BBEF43A69FA for ; Thu, 7 Apr 2011 01:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 u8gvgq5K+eNw for ; Thu, 7 Apr 2011 01:40:33 -0700 (PDT) Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id 47C153A69F9 for ; Thu, 7 Apr 2011 01:40:33 -0700 (PDT) Received: (qmail 6651 invoked from network); 7 Apr 2011 08:17:05 -0000 Received: from unknown (124.120.144.183) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 07 Apr 2011 08:17:05 -0000 Message-ID: <4D9D78E2.3040809@net-zen.net> Date: Thu, 07 Apr 2011 15:42:10 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: jouni korhonen References: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control 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, 07 Apr 2011 08:40:35 -0000 On 4/7/2011 1:55 PM, jouni korhonen wrote: > Looks good to me. Ditto. > > - Jouni > > On Apr 4, 2011, at 4:25 PM, Frank Brockners (fbrockne) wrote: > >> >> Following a comment and recommendation from the Gen-ART review, the WG >> discussed the topic of naming the Diameter entities in >> draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions >> happened at IETF 77): >> >> The outcome of the discussion was the following recommended approach >> (hope that I captured things the right way, otherwise, please chime in): >> >> * draft-ietf-dime-nat-control should use the generic term "Diameter >> peer" when referring to the two interacting Diameter entities (i.e. we'd >> neither create new names for the Diameter entities in DNCA, nor would we >> name them client and server). >> * for those cases, where procedures/actions of the two peers need to be >> differentiated, one would use the description of the function of the >> peer in question, i.e. "NAT Controller" and "NAT". >> >> Although we reached consensus in the WG meeting in Prague, the decision >> would need re-confirmation from the list. >> >> Appreciate your support, so that we can get this issue off the table. >> >> Thanks, Frank >> >> >> >> Some additional background on the above recommendation: >> Quick summary of the reasoning expressed during the WG meeting: >> * DNCA is not a typical client-server application, but represents an >> exchange between two Diameter protocol peers; hence "client" and >> "server" nomenclature does not really apply to this application. The >> descriptions for "server" and "client" roles in RFC 3588, section 1.1 >> could be misleading when applied to non client-server protocols or non >> pure AAA-protocols. >> * The DNCA can be implemented per the current I-D without designating >> devices as "client" or "server". >> * If DNCA would be implemented within an architecture defined by a >> different SDO, the names of the two Diameter protocol peers would be >> named corresponding to the peering elements within the overall >> architecture, i.e. naming from DNCA isn't likely to be leveraged, hence >> naming should be as generic as possible. >> _______________________________________________ >> 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 gwz@net-zen.net Sat Apr 9 20:23:45 2011 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 025903A6834 for ; Sat, 9 Apr 2011 20:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, USER_IN_WHITELIST=-100] 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 fwfJlnrGsGt0 for ; Sat, 9 Apr 2011 20:23:44 -0700 (PDT) Received: from smtpauth12.prod.mesa1.secureserver.net (smtpauth12.prod.mesa1.secureserver.net [64.202.165.35]) by core3.amsl.com (Postfix) with SMTP id 3AED73A6824 for ; Sat, 9 Apr 2011 20:23:43 -0700 (PDT) Received: (qmail 28044 invoked from network); 10 Apr 2011 03:25:30 -0000 Received: from unknown (124.122.190.86) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 10 Apr 2011 03:25:29 -0000 Message-ID: <4DA12323.9090504@net-zen.net> Date: Sun, 10 Apr 2011 10:25:23 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------030802090600060508060103" Subject: [Dime] typo in draft-ietf-dime-rfc3588bis-26.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: Sun, 10 Apr 2011 03:23:45 -0000 This is a multi-part message in MIME format. --------------030802090600060508060103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The third bullet in Section 1.1.3 says "The support for the End-to-End Security framework (E2ESequence AVP and 'P'-bit in the AVP header) has also been deprecated." s/E2ESequence/E2E-Sequence/ --------------030802090600060508060103 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------030802090600060508060103-- From jouni.nospam@gmail.com Sun Apr 10 06:58:27 2011 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 BA36E28C0DD for ; Sun, 10 Apr 2011 06:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 azkCxdyxb173 for ; Sun, 10 Apr 2011 06:58:26 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 846B528C0D6 for ; Sun, 10 Apr 2011 06:58:26 -0700 (PDT) Received: by fxm15 with SMTP id 15so3590963fxm.31 for ; Sun, 10 Apr 2011 07:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=aO6U4sY/xIMtjgMM4/TIykUqgoUSZY5/kP7JIiILWfQ=; b=ZGnJXn4JPPUNk5XwnW71EY3vo24eBTssPgHx4cW0VbNfIxTh2d13N0w35U9yf52L65 lWdjt/QJPWZSUNxzEHTpWjLibqXxXZbXc0gcladHbjCkWrRA3y7D2iK2gaqw8obtVpix prMwUzU1R4+h/wrlsnSCUViIGwV/IARoxth0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=IpAv9AeJ35lg3+EP2FKtTS7deZsndmLiesehVxXUHWuO+WtqOWVkMEuZmncVnqTBwk iSDO/JIhznniOWrK5CVdy+AO78/Bysx7sHUyikf9U30HQq4cSSS9nBSG2tSqLGnrqrrt 0t1mosSx5H0Ch4mjjoU+2cprP3EpgwsRoTmQY= Received: by 10.223.7.9 with SMTP id b9mr1836691fab.89.1302444010631; Sun, 10 Apr 2011 07:00:10 -0700 (PDT) Received: from [192.168.0.103] (dsl-roibrasgw1-fe55de00-189.dhcp.inet.fi [80.222.85.189]) by mx.google.com with ESMTPS id p16sm1354725fax.21.2011.04.10.07.00.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2011 07:00:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4DA12323.9090504@net-zen.net> Date: Sun, 10 Apr 2011 17:00:01 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <4DA12323.9090504@net-zen.net> To: Glen Zorn X-Mailer: Apple Mail (2.1082) Cc: dime@ietf.org Subject: Re: [Dime] typo in draft-ietf-dime-rfc3588bis-26.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: Sun, 10 Apr 2011 13:58:27 -0000 Thanks. Will take care of that. - Jouni On Apr 10, 2011, at 6:25 AM, Glen Zorn wrote: > The third bullet in Section 1.1.3 says "The support for the End-to-End > Security framework (E2ESequence AVP and 'P'-bit in the AVP header) has > also been deprecated." s/E2ESequence/E2E-Sequence/ > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Sun Apr 10 08:34:48 2011 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 D5F5E3A683C for ; Sun, 10 Apr 2011 08:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 iNIJCu9CzBxo for ; Sun, 10 Apr 2011 08:34:47 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 711793A67B2 for ; Sun, 10 Apr 2011 08:34:47 -0700 (PDT) Received: by fxm15 with SMTP id 15so3620112fxm.31 for ; Sun, 10 Apr 2011 08:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=alayXFe8Sa7ozBcEmu11f7i8w+Qa6hI5Wi086ke/Ph4=; b=WuA9KMvu9qU5bfvXNb4YnqBCqezaq287IegPNdfFdqhOO3Oi/Gu8WpKQhhqKDuzOfq Kpb5rYBYVnJw4zJvmxAz9Px6VMMAF8nNbVfDwjEaalLgkB2kOkItoaUS4M0U9n80R2I+ se4TFPx/N351UVKDpL4tsaGp1rZNog3qcUvac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=WLq16GXHZlQM3c1IyLFOP7MTCLS77Kts9M5bFh0ttI9CqgJQNsfOIV/n9F1WKmBZXa 0MFOHM5hCcnMtVG7byErTs/F15zb0STlxjUTsTiF82ZSfOI6UPxZBYn/bko8Y8kQs66v gqH8OpejJU98YuR+dJoiIHqS7UmObK8jLRNTk= Received: by 10.223.68.193 with SMTP id w1mr1917495fai.42.1302449793741; Sun, 10 Apr 2011 08:36:33 -0700 (PDT) Received: from [192.168.0.103] (dsl-roibrasgw1-fe55de00-189.dhcp.inet.fi [80.222.85.189]) by mx.google.com with ESMTPS id n2sm1375530fam.4.2011.04.10.08.36.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2011 08:36:32 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Apr 2011 18:36:26 +0300 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Dime] Use of Origin-Host 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: Sun, 10 Apr 2011 15:34:49 -0000 Hi, As discussed briefly during Prague Dime meeting, here is background = about the changing Origin-Host. One interpretation of RFC3588(bis) is that the DiameterIdentity in the = Origin-Host AVP received in a CER/CEA must equal to the DiameterIdentity = in Origin-Host AVP for every request message the same Diameter node = originates over the same transport connection. This is not explicit in = RFC3588(bis). RFC3588 Section 4.3 says a Diameter node can have multiple = DiameterIdentities but a single identity should be selected when the = Diameter node starts. Note the 'should' here, which is not RFC2119 = language 'SHOULD' and even if it were it is not a 'MUST' or 'SHALL=92. = Because a Diameter node has really no other way to learn the = DiameterIdentity of its peer, it uses the Origin-Host AVP received in = the CER/CEA message as stated in Section 5.6.1. What we have observed in the field is that some Diameter peers change = their identity spontaneously. This would not be an issue if the peer = were a proxy or a relay. However, there are peers that are 1) directly = connected and 2) change their DiameterIdentity in the Origin-Host to = something else what they claimed during CER/CEA exchange. Regarding 1) = the requests with changed identity are not proxied/relayed i.e. they do = not include any routing AVPs and especially no Route-Record AVP. This is = clearly a violation of RC3588(bis). Usually this still happens to work = out as the answer follows hop-by-hop identifiers rather than Origin-Host = & Origin-Realm. However, problems arise when a peer that originally = received a request with changed DiameterIdentity sends a request (like = ASR or alike) later on using the "cached identity" from the previous = message exchange (and there is no authorization state maintained). Now = the changed identity cannot be found from the peer table. One could fall = back to realm based routing and get the message delivered but still this = not "as it should be based on RFC3588" and may also lead to unwanted = routing paths. Should we make Section 4.3 text explicit: =93If a Diameter node can be = identified by several FQDNs, a single FQDN MUST be picked at startup, = and used as the only DiameterIdentity for that node, whatever the = connection it is sent on.=94 ??!=20 - Jouni= From jouni.nospam@gmail.com Sun Apr 10 08:43:38 2011 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 953D83A69E0 for ; Sun, 10 Apr 2011 08:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 ZPu93TuekSEF for ; Sun, 10 Apr 2011 08:43:37 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 27F463A683C for ; Sun, 10 Apr 2011 08:43:37 -0700 (PDT) Received: by fxm15 with SMTP id 15so3622400fxm.31 for ; Sun, 10 Apr 2011 08:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=Bkoz362U58ebxKgmNTOki8A3R7QB3tfGIDpszPEbBV8=; b=fcoOgptxmqR3iOqb+mqSJh968V9tT7+eBjxfskLUl6GRjYNQ0XIPxA7cCgqNvbDn76 gOVlo18AVTVgZL11w5BFNz2VXxyVuUORJj+1AH7Zlmhyej8wMsXvN1GBfNqZ6s9DRIev r5gP88xwpy14zeJyvn9Uk59Q0ZQ4vbZqfnhUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=Vqnkl9KVRZCGTjfruVMDy9aSnXamv9/HiNwJLL0ytS5OVIxmVDdpy9Ik5UOqOpWmng FGQ9t1HnDTk+ok6md9w+LfEWwee/QjNbeYMZ95mEcHYHkmPqZPTNpVsL0hkUjQKsuwrA gf3zXlLovku/MGUo3BWsZZMcHXPqhXIrKf/ro= Received: by 10.223.125.66 with SMTP id x2mr1793708far.51.1302450323115; Sun, 10 Apr 2011 08:45:23 -0700 (PDT) Received: from [192.168.0.103] (dsl-roibrasgw1-fe55de00-189.dhcp.inet.fi [80.222.85.189]) by mx.google.com with ESMTPS id e17sm1375659fak.24.2011.04.10.08.45.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2011 08:45:22 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Apr 2011 18:45:14 +0300 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: Jouni Korhonen Subject: [Dime] DIME draft meeting notes 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: Sun, 10 Apr 2011 15:43:38 -0000 Folks, Draft meeting notes from Prague. Big thank to Tom for taking notes! If = you have any corrections to propose, please post them to the list. If = nothing is heard by 15th April, I'll upload these minutes into web. - Jouni ------ Note Well presented verbally. Agenda : accepted. Status =3D=3D=3D=3D=3D=3D Jouni presenting. 3588bis -- Victor Fajardo has no time to maintain. Jouni is taking it on = for the moment. Need new editor for MIBs -- if no action, will drop. Lionel: Glen Zorn and Dan have been discussing. No comments. RFC3588bis Update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jouni Korhonen AVP flags: Mark Jones proposed that we add the text "sender MUST set to = 0, receiver MUST ignore". Agreed in principle. Will not address matter = of application-defined flags, since nothing is broken. Jouni will = propose text. No action on Grouped flag. Application can define one if needed. Result Codes: Jouni proposes to keep 3588bis aligned, retain 5016, put = some note to explain difference from 3... SCTP data chunk protocol identifier: will reserve a non-zero value to = make debugging analysis easier. Glen Zorn: some misalignment between the updated IANA section and the = references to it in the body of the text. Jouni will propose text to the list. Diameter NAT Control =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Frank Brockners Review of Genart review comments. Entity naming issue. Glen Zorn: Diameter really being used as peer to peer protocol in this = application. Use the term "peer". Mark Jones agrees. Roles are defined by the application. Lionel: agrees. Frank: how to distinguish the peers -- what terms? Mark Jones: NAT, NAT controller. Glen Zorn: labels don't matter, just make message flow clear at any = point in time. Frank: lack of "client" and "server" bothers some people. Lionel: not a big problem. Just be clear that this is using a new = architecture for Diameter. Glen: DIME shouldn't be overly concerned with preconceptions of external = reviewers. Tom Taylor: can use the terms "requesting peer" and "responding peer" if = discussing at an abstract level, otherwise use the concrete terms "NAT", = "Nat Controller". Further discussion -- Frank worried because some people were so = concerned with terminology. Dan Romanascu: confirm on list. Genart reviewer is effectively one = member of the Working Group. Lionel: Frank to propose terminology on list, explaining the new = Diameter architecture on the list. Further discussion, but effectively that was the conclusion. Note: some = thought to fact to fact that this sets a precedent for the architecture. Realm-Based Redirect =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Reviewed list comments. Most can be dealt with easily -- present proposed text changes to list. = On issue of changes to base behaviour of redirect agent, present issue = to list for resolution. 4005bis =3D=3D=3D=3D=3D=3D=3D No activity. A review has been posted by Mark Jones. Diameter General Purpose Session =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=3D=3D=3D Marco Liebsch Returning proposal (presented in IETF78, IETF79). Some 3GPP related activity on hold pending Dime acceptance. Basic idea: be able to run sessions applying to groups of users. Various coding proposals. Comments received. Proposal: split into two drafts to cover the two ideas: Diameter group = sessions (shared session ID), encoding for bulk sessions (reusable for = other session types) Glen Zorn: not an extension to the base protocol. Concerned that = changing semantics will lead to interoperability problems. Non-AAA: not = in charter scope. Lionel: let's first guage interest. Jouni: play with session, clobber applications. On the other hand, could = have advantages. Mark Jones: generally useful, doesn't need justification by other SDOs, = useful, supports. Dan Romascanu: yes, could be concerned about change in semantics. = Broader question is whether it is in scope of Diameter. Does need = charter change or new WG -- not AAA. Frank Brockners: question for clarification -- did he understand = correctly that the bulk encoding would be reusable for other other = applications? Marco: not usable by current applications, but could be = used by new ones. Dan: understands Marco's interest, but this is definitely beyond the = scope of Dime as currently constituted. Could work through 3GPP liaison = channels to set work in motion. Jouni: could conceivably broaden charter. Dan: would like to see charter proposal, then get a view of consensus in = this room and on the list. Mark Jones: other SDOs also have an interest in bulk signalling. Doesn't = want to push too hard without seeing others' interest. Glen Zorn: inclination would be to call a BOF. Also noted that it is = possible to split meeting time between interest groups. Frank Brockners: can be useful. Getting different solutions now -- = standardization would be nice. Gave examples of TISPAN, 3GPP.\ Dan: would like to see charter proposal. Make clear that this extends = the existing scope, make sure charter is not open-ended. Need usual = assurance of availability of people to do the work. Could be extension = of Dime or new WG. Glen: noted how two of the new AVT spinoffs met back-to-back in the same = room. Lionel summed up resolution as above Other Business =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jouni Origin-Host and a Diameter node with multiple DiameterIdentity values. Base issue. Problem is that a host can contain multiple Diameter nodes, = each of which can be identified by multiple FQDNs. Sec. 4.3 of 3588 says = a Diameter node should (small letters) use a single identity. Sec. 6.3 = says that an Origin-Host value is unique within the host. Jouni proposes = text in 4.3 to ensure that a Diameter node always uses the same = Origin-Host value for the life of the transport connection. Tom Taylor argued an interpretation of 6.3 that made it irrelevant to = the question. 4.3 should be addressed on its own merits. Jouni clarified this is a problem when peers are directly connected and = the request with the changed identity was not proxied. Could be a result = of some kind of load balancer activity that does not implement Diameter = protocol properly. Lionel Load balancing issue. Mark Jones suggested we had to pull in the vendors = of load balancers to participate in DIME. From lionel.morand@orange-ftgroup.com Tue Apr 19 04:36:29 2011 Return-Path: X-Original-To: dime@ietfc.amsl.com Delivered-To: dime@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B4DE1E06E0 for ; Tue, 19 Apr 2011 04:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zlSDAlahzBa for ; Tue, 19 Apr 2011 04:36:29 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfc.amsl.com (Postfix) with ESMTP id CFE71E068E for ; Tue, 19 Apr 2011 04:36:28 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6889D858020; Tue, 19 Apr 2011 13:42:52 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 609A0858016; Tue, 19 Apr 2011 13:42:52 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 13:36:27 +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: Tue, 19 Apr 2011 13:36:26 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] call for consent - naming the entities indraft-ietf-dime-nat-control Thread-Index: Acv08OyaOic/k2+rQT6cZAGpcSvvWgJlE/ww References: <0D212BD466921646B58854FB79092CEC0511E5E0@XMB-AMS-106.cisco.com> From: To: , X-OriginalArrivalTime: 19 Apr 2011 11:36:27.0990 (UTC) FILETIME=[0566FF60:01CBFE86] Cc: dime@ietf.org Subject: Re: [Dime] call for consent - naming the entities indraft-ietf-dime-nat-control X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 11:36:29 -0000 Any other view? At the end of this week, I think that we can consider that the consensus = reached during the meeting is confirmed. It is not necessary to postpone = further the RFC publication process of this draft. Lionel =20 -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de jouni korhonen Envoy=E9=A0: jeudi 7 avril 2011 08:56 =C0=A0: Frank Brockners (fbrockne) Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] call for consent - naming the entities = indraft-ietf-dime-nat-control Looks good to me. - Jouni On Apr 4, 2011, at 4:25 PM, Frank Brockners (fbrockne) wrote: >=20 > Following a comment and recommendation from the Gen-ART review, the WG > discussed the topic of naming the Diameter entities in > draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions > happened at IETF 77): >=20 > The outcome of the discussion was the following recommended approach > (hope that I captured things the right way, otherwise, please chime = in): >=20 > * draft-ietf-dime-nat-control should use the generic term "Diameter > peer" when referring to the two interacting Diameter entities (i.e. = we'd > neither create new names for the Diameter entities in DNCA, nor would = we > name them client and server). > * for those cases, where procedures/actions of the two peers need to = be > differentiated, one would use the description of the function of the > peer in question, i.e. "NAT Controller" and "NAT".=20 >=20 > Although we reached consensus in the WG meeting in Prague, the = decision > would need re-confirmation from the list. >=20 > Appreciate your support, so that we can get this issue off the table. >=20 > Thanks, Frank >=20 >=20 >=20 > Some additional background on the above recommendation:=20 > Quick summary of the reasoning expressed during the WG meeting: > * DNCA is not a typical client-server application, but represents an > exchange between two Diameter protocol peers; hence "client" and > "server" nomenclature does not really apply to this application. The > descriptions for "server" and "client" roles in RFC 3588, section 1.1 > could be misleading when applied to non client-server protocols or non > pure AAA-protocols. > * The DNCA can be implemented per the current I-D without designating > devices as "client" or "server". > * If DNCA would be implemented within an architecture defined by a > different SDO, the names of the two Diameter protocol peers would be > named corresponding to the peering elements within the overall > architecture, i.e. naming from DNCA isn't likely to be leveraged, = hence > naming should be as generic as possible. > _______________________________________________ > 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 mudit22@gmail.com Wed Apr 20 23:02:41 2011 Return-Path: X-Original-To: dime@ietfc.amsl.com Delivered-To: dime@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 230CBE07F9 for ; Wed, 20 Apr 2011 23:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 928Dgzu1QQB3 for ; Wed, 20 Apr 2011 23:02:40 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfc.amsl.com (Postfix) with ESMTP id 34D5DE07F5 for ; Wed, 20 Apr 2011 23:02:40 -0700 (PDT) Received: by pvh1 with SMTP id 1so943939pvh.31 for ; Wed, 20 Apr 2011 23:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=MhnDcxZcM+/AwzIRKUf7AnHDFoRWSnhZt4rF0/YzNsI=; b=EEbmXWJVE20uwxBoUD2s7+JdN6yFfAUhyHJ2wJV27MHiCRuiGHexqGRAbC5QION+AN 8utOaqrKVK0iXDRwmnQ2eQX34eZ/TAoEmLsgzhNYVy0eSz5IZ+dv9AbvKMPJvKKQsDbx v/5HMaOkZ1k/dy7XwNBzmzt1gu9VrFIOby6u0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LyOHkuPgoT1FkkxQZ+vnYTMr/U3H0biiRGMd7+4gCETkssWJcVuJyDz9Og9mpwQ3tH 3C49q0WMhrAvjCGU5vAOqSK//gQbO0v/yNaT9dpcujyAqt5MEEO+6o76SSjgexLe6qXp YDp843YRiHeCGjAKeJopdyrTWgDtpc3ETs7Ok= MIME-Version: 1.0 Received: by 10.142.171.16 with SMTP id t16mr3310032wfe.105.1303365404733; Wed, 20 Apr 2011 22:56:44 -0700 (PDT) Received: by 10.142.141.15 with HTTP; Wed, 20 Apr 2011 22:56:44 -0700 (PDT) Date: Thu, 21 Apr 2011 11:26:44 +0530 Message-ID: From: Mudit Gupta To: dime@ietf.org Content-Type: multipart/alternative; boundary=000e0cd20d76f666a304a1676756 Subject: [Dime] election lost X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 06:03:39 -0000 --000e0cd20d76f666a304a1676756 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear All I have a query regarding result code =93election lost=94. In what case the = CEA will come with result code =93election lost=94 and how it should be treated= . Best regards, Mudit --000e0cd20d76f666a304a1676756 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Dear All

=A0

I have a query regarding result code =93election lost=94. In w= hat case the CEA will come with result code =93election lost=94 and how it = should be treated.

=A0

Best regards,

Mudit

=A0

--000e0cd20d76f666a304a1676756-- From tom111.taylor@bell.net Thu Apr 21 06:58:34 2011 Return-Path: X-Original-To: dime@ietfc.amsl.com Delivered-To: dime@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 03E67E0762 for ; Thu, 21 Apr 2011 06:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.396 X-Spam-Level: X-Spam-Status: No, score=-101.396 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn1ch9nBTvG9 for ; Thu, 21 Apr 2011 06:58:33 -0700 (PDT) Received: from blu0-omc3-s36.blu0.hotmail.com (blu0-omc3-s36.blu0.hotmail.com [65.55.116.111]) by ietfc.amsl.com (Postfix) with ESMTP id 4531FE00BE for ; Thu, 21 Apr 2011 06:58:33 -0700 (PDT) Received: from BLU0-SMTP59 ([65.55.116.74]) by blu0-omc3-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 06:58:32 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP59.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 06:58:31 -0700 Date: Thu, 21 Apr 2011 09:58:20 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2011 13:58:32.0052 (UTC) FILETIME=[32F72340:01CC002C] Subject: Re: [Dime] Proposed changes to draft-ietf-dime-realm-based-redirection (1) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 13:58:34 -0000 I will implement these changes and submit the updated document. On 04/04/2011 4:30 PM, Tom Taylor wrote: > As reported at the meeting, this draft drew comments from Glen Zorn, > Sebastien Decugis, and Avi Lior during WGLC. This note provides the > proposed text changes to resolve the first two sets of comments. Avi's > comment seemed to require direction from the list. However, prompted by > existing text in Section 2.4 of RFC 3588, I have concluded that he is > right. I present my argument and proposed changes in a separate note. > > Glen Zorn 02/08/2010 (ET) > ========================= > > Looks fine to me; the only thing that I might add would be a more direct > pointer to the "normal discovery procedures" mentioned in Section 3.1.2. > > Proposed new text: > > ... SHOULD attempt to reroute the request to the indicated realm > using normal discovery procedures (Section 5.2 of RFC 3588) to > ^^^^^^^^^^^^^^^^^^^^^^^^^ > find an appropriate destination host. > > Sebastien Decugis 06/08/2010 (ET) > ================================= > > 1) "(3.1.1) second list item (editorial): > > "Furthermore, the redirect agent MUST a Redirect-Realm AVP > ^^^ > missing word?" > > Proposed new text: > > Add the word"insert" following "MUST". > > > 2) (3.1.1) What if the the other peer advertised the Relay application? > Should the redirect agent consider that it supports > the Redirect-Realm application? > > Proposed new text: > > Beginning of the first bullet: > > o If the peer from which the request was received did not > advertise the Relay application or > ^^^^^^^^^^^^^^^^^^^^^^^^ > an application incorporating the realm-based routing > capability in the CER/CEA exchange, ... > > Beginning of the second bullet: > > o Otherwise, if the Relay application or > ^^^^^^^^^^^^^^^^^^^^^^^^ > an application supporting the use of realm-based > redirection was negotiated with the peer, ... > > > 3) (3.1.1) "the message MUST include the Error- > Reporting-Host AVP if the host setting the Result-Code AVP is > different from the identity encoded in the Origin-Host AVP," > IIUC this is an impossible situation, since the Redirect Agent did not > forward the Request. > I believe this text could be removed for clarity. > > Proposed new text: > > Delete the second-last sentence of the second bullet. The deleted > text reads: > > To prevent confusion at Diameter nodes > receiving the answer message, the message MUST include the > Error-Reporting-Host AVP if the host setting the Result-Code > AVP is different from the identity encoded in the Origin-Host > AVP, in conformity with Section 7.1 of [RFC3588]. > > > 4) (3.1.2) What if the original request contains a Destination-Host AVP? > In that case, should a UNABLE_TO_DELIVER error be returned? > There is probably no point in sending to the alternate realm with a > Destination-Host in the previous realm, right? > Unless maybe if the Destination-Realm of the request message does not > match the Origin-Realm of the Redirect indication > (change of broker for example). Any opinion? > > Proposed new text: > > Insert the following new text as the new first bullet of *3.1.1*: > > o If the original request contains a Destination-Host AVP, the > the redirecting agent MUST return an error message with the > Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. > > > 5) (3.2) This section does not give the value of the M flag for the > new AVP. By the semantics of the application, I believe the M flag > should be set, right? > > Proposed new text: > > Modify the last sentence of the first paragraph of section 3.2 > to read as follows (new text indicated): > > The M flag for the Redirect-Realm AVP MUST be set, and the V > ^^^^^^ ^^^^^^^^^^^^^^^^ > flag MUST NOT be set. > > > Many thanks to Sebastien in particular for his careful review. > > Tom Taylor > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From tom111.taylor@bell.net Thu Apr 21 07:00:21 2011 Return-Path: X-Original-To: dime@ietfc.amsl.com Delivered-To: dime@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4414EE0689 for ; Thu, 21 Apr 2011 07:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.417 X-Spam-Level: X-Spam-Status: No, score=-101.417 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4D+pwCXE7Iu for ; Thu, 21 Apr 2011 07:00:20 -0700 (PDT) Received: from blu0-omc3-s23.blu0.hotmail.com (blu0-omc3-s23.blu0.hotmail.com [65.55.116.98]) by ietfc.amsl.com (Postfix) with ESMTP id 64FC0E00BE for ; Thu, 21 Apr 2011 07:00:20 -0700 (PDT) Received: from BLU0-SMTP21 ([65.55.116.74]) by blu0-omc3-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 07:00:20 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP21.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 07:00:19 -0700 Date: Thu, 21 Apr 2011 10:00:19 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2011 14:00:19.0838 (UTC) FILETIME=[7335F9E0:01CC002C] Subject: Re: [Dime] Proposed changes to draft-ietf-dime-realm-based-redirection (2) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 14:00:21 -0000 Avi was the only one who had this concern (I don't really count). Chairs, can you confirm a consensus that we can leave it up to the Redirect Agent to do the redirection? And should I prepare text to implement this in 3588bis? On 04/04/2011 10:06 PM, Tom Taylor wrote: > Avi Lior had the following comment, received 11/08/2010 (ET). By the > way, my charts at the meeting said the comments were received last > October. I don't know what strange process caused me to transpose year > and month, but I apologize for the misdirection. > > > > Hi, > > I have reviewed draft-ietf-dime-realm-based-redirect-03 document -- or I > should say i started but I had to stop because there are serious > fundamental issues with this draft. > > I should start with the fact that i think the problem statement raised > by the draft is valid. Also, I think that Diameter base 3588 should have > supported Realm based redirection as well as host based redirection. > Actually Realm-based redirection are probably more useful. > > However, the problem I am having is that the draft is changing the > semantics of a Redirect Agent as defined by base and I dont think that > we should be allowed to do that. > > I get that the draft got around backwards capability issue surrounding > the new AVPs be introduced by asserting that only new applications will > support the attributes. > > But in order to deliver this feature in 3588 the behavior of the > Redirect Agent had to change. > > This new redirect agent has to differentiate between applications that > do support realm base redirection vs non-realmbased redirection. > > This is new base behavior and thus should be done in Diameter V2 > > There is an alternative - which i thought was the approach taken when i > started to read the draft and that is: > > -let the Application itself perform the redirection. To use the example > provided, if the operator does not want to host the application anymore, > it can let the Application respond back with the realm and/host > redirection attributes. > > > > As I mentioned in my previous note, I now agree with Avi. The conversion > comes about through a chance reading of the following paragraph in > Section 2.4 of RFC 3588: > > Relay and redirect agents MUST advertise the Relay Application > Identifier, while all other Diameter nodes MUST advertise locally > supported applications. The receiver of a Capabilities Exchange > message advertising Relay service MUST assume that the sender > supports all current and future applications. > > I am worried that, by specifying new behaviour for conforming redirect > agents, we are setting a precedent that could lead to trouble if it is > followed. Since the normal application negotiation process is > short-circuited in the case of nodes offering the Relay service, the > forwarding agent becomes unable to predict the behaviour of Relay nodes. > Without careful Working Group scrutiny, a specification involving the > Relay service could end up breaking something. This is brittle. It is > safer to place such behaviour at the application level, as Avi suggests. > > Based on that, the basic change required in the realm-based-redirection > draft is to change "relay agent" to "proxy" wherever it occurs. > Naturally, other details are also affected. Here is the list of detailed > changes that are required. > > Abstract: > > Delete the first sentence and the word "However" at the beginning of > the next sentence. > > Introduction, first paragraph, fourth sentence: > - Replace "redirect server" by "service", so that the sentence reads: > > ... the original operator maintains a service to > indicate the alternative destination > > Section 2: > - Change to read as follows: > > Because realm-based redirection is not part of base Diameter > behaviour, support for realm-based redirection has to be > provided at the application level by a Diameter proxy. > Designers of new applications wishing to include support > for realm-based redirection can incorporate the mechanism > specified here by reference to this document. > > Section 3.1.1: > - Change the title to: "Behaviour at the Redirecting Proxy" > > - Replace the two paragraphs preceding the bullets with the > following text: > > If a Diameter proxy that supports realm-based redirection > receives a request for an application that includes > realm-based redirection, and the proxy has been configured > to provide redirection for the destination realm of the > request, then: > > [Bullets follow, including the new one proposed in my > previous message] > > - Change all instances of "redirect agent" in the bullets > to "redirecting proxy". > > - Change the final bullet (in which redirection is performed) > to read as follows. The first sentence is unchanged but is > included for context. > > o Otherwise, if an application supporting the use of realm-based > redirection was negotiated with the peer, the redirect agent MUST > set the Result-Code AVP to DIAMETER_REALM_REDIRECT_INDICATION > rather than DIAMETER_REDIRECT_INDICATION. Furthermore, the > redirect agent MUST include a Redirect-Realm AVP containing the > realm with which it has been configured for the purpose of > realm-based redirection for this application in its answer > message. The redirecting proxy MUST maintain the Hop-by-Hop > Identifier in the message header, so that the agent from > which it received the request can retrieve that request from > its pending message queue (see Section 5.3 of RFC 3588). > > QUESTION: should the redirected message have the 'E' bit set? > > Tom Taylor > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From gwz@net-zen.net Sat Apr 23 05:18:33 2011 Return-Path: X-Original-To: dime@ietfc.amsl.com Delivered-To: dime@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 94A1CE0688 for ; Sat, 23 Apr 2011 05:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AKmM1A95pWG for ; Sat, 23 Apr 2011 05:18:33 -0700 (PDT) Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) by ietfc.amsl.com (Postfix) with SMTP id CDD27E0661 for ; Sat, 23 Apr 2011 05:18:32 -0700 (PDT) Received: (qmail 12886 invoked from network); 23 Apr 2011 12:18:31 -0000 Received: from unknown (110.168.121.228) by p3plsmtpa06-10.prod.phx3.secureserver.net (173.201.192.111) with ESMTP; 23 Apr 2011 12:18:31 -0000 Message-ID: <4DB2C395.8030608@net-zen.net> Date: Sat, 23 Apr 2011 19:18:29 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dime-chairs@tools.ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------090607070607050606080808" Cc: dime@ietf.org, draft-ietf-dime-rfc4005bis@tools.ietf.org Subject: [Dime] Mail regarding draft-ietf-dime-rfc4005bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 23 Apr 2011 12:18:33 -0000 This is a multi-part message in MIME format. --------------090607070607050606080808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think that this draft is ready for WGLC. --------------090607070607050606080808 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------090607070607050606080808-- From jouni.nospam@gmail.com Sat Apr 23 15:51:41 2011 Return-Path: X-Original-To: dime@ietfc.amsl.com Delivered-To: dime@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E7A44E0613 for ; Sat, 23 Apr 2011 15:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q94RHKyg3El7 for ; Sat, 23 Apr 2011 15:51:41 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id 4A3F2E0611 for ; Sat, 23 Apr 2011 15:51:41 -0700 (PDT) Received: by ewy19 with SMTP id 19so558501ewy.31 for ; Sat, 23 Apr 2011 15:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=gcBzbVlCo91SmqkyTDOU4Zu7FTpj9jitR9b/GxxnjaU=; b=ru46Dbs/qLzKN/S81iunxaUGBIYBexw8xL2aEZIC3Mv3D/i2z7dUG2YPOQPpKo29wc hnItprQFH4VprRTVX6DoFtpPvSC4PYPE59MhncY/CB/xJYR8iAW4/dhNhuDWGIw8+Euw FMbYHMhXw3msGbrp6n5HFSMl3JuMiGLdp16PU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=a5rJ2itOvmsm5PnOT5llRubPvWlqY4h5F4DV+foU77dUQIcwC6BLJxi2NqdCcKNLOw 3u3TzdziBPanTRCyWytGk62zwUjlTucCCUdcobtufWIvh8c+8GWjNYWPzpXN8GGGr9Ai 0bs8kRPQYYdgfMrUEHpCiZ3tbsci8lXl2bOg4= Received: by 10.14.122.81 with SMTP id s57mr915927eeh.195.1303599098453; Sat, 23 Apr 2011 15:51:38 -0700 (PDT) Received: from a88-112-141-112.elisa-laajakaista.fi (a88-112-141-112.elisa-laajakaista.fi [88.112.141.112]) by mx.google.com with ESMTPS id s50sm1580218eeh.15.2011.04.23.15.51.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Apr 2011 15:51:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4DB2C395.8030608@net-zen.net> Date: Sun, 24 Apr 2011 01:51:32 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <4DB2C395.8030608@net-zen.net> To: Glen Zorn X-Mailer: Apple Mail (2.1082) Cc: dime@ietf.org, dime-chairs@tools.ietf.org, draft-ietf-dime-rfc4005bis@tools.ietf.org Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc4005bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 23 Apr 2011 22:51:42 -0000 Have you already addresses those four issue tracker tickets Mark raised? - Jouni On Apr 23, 2011, at 3:18 PM, Glen Zorn wrote: > I think that this draft is ready for WGLC. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Sat Apr 23 22:49:53 2011 Return-Path: X-Original-To: dime@ietfc.amsl.com Delivered-To: dime@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54ED2E073D for ; Sat, 23 Apr 2011 22:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PECk0vOIy1E for ; Sat, 23 Apr 2011 22:49:52 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by ietfc.amsl.com (Postfix) with SMTP id 66774E06A0 for ; Sat, 23 Apr 2011 22:49:52 -0700 (PDT) Received: (qmail 26796 invoked from network); 24 Apr 2011 05:49:51 -0000 Received: from unknown (110.168.121.228) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 24 Apr 2011 05:49:50 -0000 Message-ID: <4DB3B9FA.4070608@net-zen.net> Date: Sun, 24 Apr 2011 12:49:46 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: jouni korhonen References: <4DB2C395.8030608@net-zen.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------040001070502060708020009" Cc: dime@ietf.org, dime-chairs@tools.ietf.org, draft-ietf-dime-rfc4005bis@tools.ietf.org Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc4005bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 05:49:53 -0000 This is a multi-part message in MIME format. --------------040001070502060708020009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/24/2011 5:51 AM, jouni korhonen wrote: > > Have you already addresses those four issue tracker tickets Mark raised? I believe that I responded, but maybe not. In any case, it's not up to me how the issues are to be addressed (since it is WG document). I can, however, comment (perhaps redundantly) upon them and will in following threads. > > - Jouni > > > On Apr 23, 2011, at 3:18 PM, Glen Zorn wrote: > >> I think that this draft is ready for WGLC. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > > --------------040001070502060708020009 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------040001070502060708020009-- From Mudit.Gupta@ccpu.com Wed Apr 20 22:53:54 2011 Return-Path: X-Original-To: dime@ietfc.amsl.com Delivered-To: dime@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C2B04E0765 for ; Wed, 20 Apr 2011 22:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xTHxTL97Xxg for ; Wed, 20 Apr 2011 22:53:54 -0700 (PDT) Received: from sd-smtp.ccpu.com (sd-smtp.ccpu.com [65.44.201.8]) by ietfc.amsl.com (Postfix) with ESMTP id D6561E0660 for ; Wed, 20 Apr 2011 22:53:53 -0700 (PDT) Received: from sd-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 9CD3762013D for ; Wed, 20 Apr 2011 22:53:48 -0700 (PDT) Received: from INMAIL.ccpu.com (inmail.ccpu.com [172.25.0.64]) by sd-smtp.ccpu.com (Postfix) with ESMTP id 576F5620036 for ; Wed, 20 Apr 2011 22:53:47 -0700 (PDT) Received: from INEXCHANGE.ccpu.com ([fe80::b509:6cad:a066:8e97]) by INMAIL.ccpu.com ([::1]) with mapi; Thu, 21 Apr 2011 11:23:50 +0530 From: Mudit Gupta To: "dime@ietf.org" Date: Thu, 21 Apr 2011 11:23:47 +0530 Thread-Topic: Election Lost Thread-Index: Acv/6Hsed2f0urcMSDaU47vck5bDUA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Ag0M Azno BoQu BuQ7 CkDO EDXo FENL FilL Fst4 IM0P JOy/ KFSP Kwvi LUUs Ljus LoIG; 1; ZABpAG0AZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {329959E5-FA53-4911-9FDA-51925C6C2DE0}; bQB1AGQAaQB0AC4AZwB1AHAAdABhAEAAYwBjAHAAdQAuAGMAbwBtAA==; Thu, 21 Apr 2011 05:53:47 GMT;RQBsAGUAYwB0AGkAbwBuACAATABvAHMAdAA= x-cr-puzzleid: {329959E5-FA53-4911-9FDA-51925C6C2DE0} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BCDADD7BFE51844DA81E33EB574279F20DC9AB8A0AINEXCHANGEccp_" MIME-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3216-6.5.0.1024-18086.003 X-TM-AS-Result: No--14.334-5.0-31-1 X-imss-scan-details: No--14.334-5.0-31-1 X-TM-AS-User-Approved-Sender: No X-Mailman-Approved-At: Mon, 25 Apr 2011 06:24:13 -0700 Subject: [Dime] Election Lost X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 05:53:54 -0000 --_000_BCDADD7BFE51844DA81E33EB574279F20DC9AB8A0AINEXCHANGEccp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All I have a query regarding result code "election lost". In what case the CEA = will come with result code "election lost" and how it should be treated. Best regards, Mudit --_000_BCDADD7BFE51844DA81E33EB574279F20DC9AB8A0AINEXCHANGEccp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All

 

I have a query regarding result code “election l= ost”. In what case the CEA will come with result code “election lost”= and how it should be treated.

 

Best regards,

Mudit

--_000_BCDADD7BFE51844DA81E33EB574279F20DC9AB8A0AINEXCHANGEccp_-- From gwz@net-zen.net Thu Apr 28 22:46:09 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39501E0740 for ; Thu, 28 Apr 2011 22:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv05h1-vCwtv for ; Thu, 28 Apr 2011 22:46:08 -0700 (PDT) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by ietfa.amsl.com (Postfix) with SMTP id 42562E065F for ; Thu, 28 Apr 2011 22:46:08 -0700 (PDT) Received: (qmail 3179 invoked from network); 29 Apr 2011 05:46:07 -0000 Received: from unknown (115.87.81.29) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 29 Apr 2011 05:46:06 -0000 Message-ID: <4DBA5097.8070205@net-zen.net> Date: Fri, 29 Apr 2011 12:45:59 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------000704090006000908040803" Subject: [Dime] rfc 4005 - issue #16 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2011 05:46:09 -0000 This is a multi-part message in MIME format. --------------000704090006000908040803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ticket #16 says: > Section 3.9. Accounting-Request (ACR) Command > > "Either the Acct-Application-Id AVP or the Vendor-Specific- > Application-Id AVP MUST be present." > > Mark Jones> I understand that the Acct-Application-Id is required for > backwards compatibility (it is still redundant since the same app id is > in the command header) The Acct-Application-Id is redundant if it is assumed that the Diameter header is available at every step in server processing, but there are processing models in which the network headers are stripped after the initial packet validation and the contents of the Diameter message (sans header) are forwarded to other processing elements; in this case, the Acct-Application-Id may be needed for internal message routing. For example, in a split accounting service different modules might process accounting messages for different applications; the presence of the Acct-Application-Id as an AVP in the body of the message allows this without the overhead of carrying the Diameter header (most of which is irrelevant in this usage) along for the ride. > I > but don't see why Vendor-Specific-Application-Id > would ever need be present. The same comment applies to Section 3.10. My understanding is that the accounting messages in RFC 4005 were designed with re-usability in mind, possibly including reuse by vendor-specific apps. --------------000704090006000908040803 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------000704090006000908040803-- From trac+dime@trac.tools.ietf.org Thu Apr 28 23:47:58 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F95BE0678 for ; Thu, 28 Apr 2011 23:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xjPBDGdvSk7 for ; Thu, 28 Apr 2011 23:47:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A07BAE065F for ; Thu, 28 Apr 2011 23:47:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFhUT-0004Fj-VJ; Thu, 28 Apr 2011 23:47:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gwz@net-zen.net X-Trac-Project: dime Date: Fri, 29 Apr 2011 06:47:49 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/dime/trac/ticket/20 Message-ID: <057.0ca7cc0abc305c0fa4d3c5ae33d14fe6@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gwz@net-zen.net, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 29 Apr 2011 02:13:00 -0700 Cc: dime@ietf.org Subject: [Dime] [dime] #20: no accounting model specified X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 06:47:58 -0000 #20: no accounting model specified RFC 3588bis says in Section 9.3 that Applications have the option of using one or both of the following accounting application extension models: Split Accounting Service The accounting message will carry the Application Id of the Diameter base accounting application (see Section 2.4). Accounting messages maybe routed to Diameter nodes other than the corresponding Diameter application. These nodes might be centralized accounting servers that provide accounting service for multiple different Diameter applications. These nodes MUST advertise the Diameter base accounting Application Id during capabilities exchange. Coupled Accounting Service The accounting messages will carry the Application Id of the application that is using it. The application itself will process the received accounting records or forward them to an accounting server. There is no accounting application advertisement required during capabilities exchange and the accounting messages will be routed the same as any of the other application messages. However, RFC 4005 uses neither of these models, specifying that Diameter applications conforming to this specification MUST advertise support by including the value of one (1) in the Auth-Application-Id of the Capabilities-Exchange-Request (CER), AA-Request (AAR), and AA- Answer (AAA) messages. All other messages use the Base application id value [I-D.ietf-dime-rfc3588bis]. This seems incorrect. -- --------------------------------+------------------------------------------- Reporter: gwz@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: rfc4005bis | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: dime From trac+dime@trac.tools.ietf.org Fri Apr 29 00:29:30 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1C4E06B4 for ; Fri, 29 Apr 2011 00:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKRsosuxc2za for ; Fri, 29 Apr 2011 00:29:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A00EAE064B for ; Fri, 29 Apr 2011 00:29:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFi8i-0003LL-Fl; Fri, 29 Apr 2011 00:29:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gwz@net-zen.net X-Trac-Project: dime Date: Fri, 29 Apr 2011 07:29:24 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/dime/trac/ticket/21 Message-ID: <057.183c15a66cdfb38d9d333c1e501a2367@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gwz@net-zen.net, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 29 Apr 2011 02:13:00 -0700 Cc: dime@ietf.org Subject: [Dime] [dime] #21: typo X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 07:29:30 -0000 #21: typo in section 1.1, s/exchang/exchange -- --------------------------------+------------------------------------------- Reporter: gwz@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: Component: rfc3588bis | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: dime From stefan.winter@restena.lu Fri Apr 29 04:48:44 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3905AE071D for ; Fri, 29 Apr 2011 04:48: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZstpm+bPXLq for ; Fri, 29 Apr 2011 04:48:39 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 779A6E0758 for ; Fri, 29 Apr 2011 04:48:37 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 6C9BF10691 for ; Fri, 29 Apr 2011 13:48:35 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 60ABE10582 for ; Fri, 29 Apr 2011 13:48:35 +0200 (CEST) Message-ID: <4DBAA59D.2030405@restena.lu> Date: Fri, 29 Apr 2011 13:48:45 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: dime@ietf.org References: <4DBA5097.8070205@net-zen.net> In-Reply-To: <4DBA5097.8070205@net-zen.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig98CD84F3F0E67614EB26D3FC" X-Virus-Scanned: ClamAV Subject: Re: [Dime] rfc 4005 - issue #16 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2011 11:48:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig98CD84F3F0E67614EB26D3FC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > The Acct-Application-Id is redundant if it is assumed that the Diameter= > header is available at every step in server processing, but there are > processing models in which the network headers are stripped after the > initial packet validation and the contents of the Diameter message (san= s > header) are forwarded to other processing elements; in this case, [...]= [...] it is the implementation's very own problem if it can't maintain state properly. That's how I would have finished this sentence. A protocol's job is to make sure that information can be transmitted from source to destination. I don't see it as a protocol's job to make sure the information is transmitted redundantly, just to support some implementations that are programmed so that they forget aspects of the transmission. Requiring the redundancy in the protocol means that *every* implementation has extra work, just to enable *some* implementations to be lazy/badly programmed. I don't really fancy that. > the > Acct-Application-Id may be needed for internal message routing. For > example, in a split accounting service different modules might process > accounting messages for different applications; the presence of the > Acct-Application-Id as an AVP in the body of the message allows this > without the overhead of carrying the Diameter header (most of which is > irrelevant in this usage) along for the ride. *shrug* some of the info in the Diameter header is apparently of use. How is "throwing it all away, and then demand protocol redundancy because you've thrown away too much" a good approach? Greetings, Stefan Winter >> I >> but don't see why Vendor-Specific-Application-Id >> would ever need be present. The same comment applies to Section 3.10. > My understanding is that the accounting messages in RFC 4005 were > designed with re-usability in mind, possibly including reuse by > vendor-specific apps. > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig98CD84F3F0E67614EB26D3FC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk26paEACgkQ+jm90f8eFWah2wCeMQEXnR1eoW+qKjUoDtTI40O5 5ioAn1uqJQUVKqHIc7jUOxN9xl+O2Jb7 =Aqkl -----END PGP SIGNATURE----- --------------enig98CD84F3F0E67614EB26D3FC-- From gwz@net-zen.net Fri Apr 29 23:04:09 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DF3E065B for ; Fri, 29 Apr 2011 23:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z5hxt5yH-i0 for ; Fri, 29 Apr 2011 23:04:08 -0700 (PDT) Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by ietfa.amsl.com (Postfix) with SMTP id BCF3BE0655 for ; Fri, 29 Apr 2011 23:04:08 -0700 (PDT) Received: (qmail 16074 invoked from network); 30 Apr 2011 06:04:08 -0000 Received: from unknown (124.120.109.17) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 30 Apr 2011 06:04:07 -0000 Message-ID: <4DBBA651.8060504@net-zen.net> Date: Sat, 30 Apr 2011 13:04:01 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stefan Winter References: <4DBA5097.8070205@net-zen.net> <4DBAA59D.2030405@restena.lu> In-Reply-To: <4DBAA59D.2030405@restena.lu> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------000806070309070708080807" Cc: dime@ietf.org Subject: Re: [Dime] rfc 4005 - issue #16 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2011 06:04:09 -0000 This is a multi-part message in MIME format. --------------000806070309070708080807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/29/2011 6:48 PM, Stefan Winter wrote: > Hi, > >> The Acct-Application-Id is redundant if it is assumed that the Diameter >> header is available at every step in server processing, but there are >> processing models in which the network headers are stripped after the >> initial packet validation and the contents of the Diameter message (sans >> header) are forwarded to other processing elements; in this case, [...] > [...] it is the implementation's very own problem if it can't maintain > state properly. > > That's how I would have finished this sentence. A protocol's job is to > make sure that information can be transmitted from source to > destination. I don't see it as a protocol's job to make sure the > information is transmitted redundantly, just to support some > implementations that are programmed so that they forget aspects of the > transmission. > > Requiring the redundancy in the protocol means that *every* > implementation has extra work, just to enable *some* implementations to > be lazy/badly programmed. I don't really fancy that. > >> the >> Acct-Application-Id may be needed for internal message routing. For >> example, in a split accounting service different modules might process >> accounting messages for different applications; the presence of the >> Acct-Application-Id as an AVP in the body of the message allows this >> without the overhead of carrying the Diameter header (most of which is >> irrelevant in this usage) along for the ride. > > *shrug* some of the info in the Diameter header is apparently of use. > How is "throwing it all away, and then demand protocol redundancy > because you've thrown away too much" a good approach? At one point in time there was this concept called "layering" that was quite popular. I guess it must be obsolete. > > Greetings, > > Stefan Winter > >>> I >>> but don't see why Vendor-Specific-Application-Id >>> would ever need be present. The same comment applies to Section 3.10. >> My understanding is that the accounting messages in RFC 4005 were >> designed with re-usability in mind, possibly including reuse by >> vendor-specific apps. >> >> >> >> >> >> >> >> _______________________________________________ >> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNu6ZRAAoJEG4XtfZZU7Rf0+oIALadVBHtpJdmWBmTdeBndlhN pbKatz89t2kENGfcuCWYwrHySYZ4ZRuCGPtUN2y2nPrn4E2Nbdv0BdZCp3H+vst8 VQFF0HmfDNSjMsgZD1h7PkRkPjiFz6slmSOWlZnF/+qeuMDCwf5f1Yjxaf4NZdFA 41VjTpaIPG11bJ1N9o7ppVHHjCDyT+wzfWqNwXVE9X3rEkFwpPHvh5z/mh2kz+cS vk3wsktbmnBLIOQFmf239j+mbfcMG9AQ2XlONIVuZcHIGEFYwxHEpKEvnLap/dSK MVFN7t2iG+wIHiD0dCi09kk0VGvUl5lmngMV8KXoyWhZG8oga1KOBV7xtP5ly+U= =HQVK -----END PGP SIGNATURE----- --------------000806070309070708080807 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------000806070309070708080807-- From gwz@net-zen.net Sat Apr 30 02:58:15 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8AE06CA for ; Sat, 30 Apr 2011 02:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLL-y0aApaRx for ; Sat, 30 Apr 2011 02:58:14 -0700 (PDT) Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by ietfa.amsl.com (Postfix) with SMTP id C68C9E068B for ; Sat, 30 Apr 2011 02:58:14 -0700 (PDT) Received: (qmail 4438 invoked from network); 30 Apr 2011 09:37:42 -0000 Received: from unknown (124.120.109.17) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 30 Apr 2011 09:37:42 -0000 Message-ID: <4DBBDD2F.3070705@net-zen.net> Date: Sat, 30 Apr 2011 16:58:07 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------090503000405050508070504" Subject: [Dime] Issue #17 on RFC4005bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2011 09:58:15 -0000 This is a multi-part message in MIME format. --------------090503000405050508070504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The ticket says: > Section 4.1.1. QoSFilterRule > > "The QosFilterRule? format is derived from the OctetString? AVP Base > Format. It uses the ASCII charset." > > Mark Jones> RFC5777 defines Diameter AVPs that represent QoS and IP > filter rules and even includes a NASREQ example. I'd like to see the > ASCII-based variants deprecated but even if that idea doesn't fly, This is up to the WG, I think. > I think it would be useful to mention RFC5777 here as offering an > alternative. This is fine with me; care to contribute some text? --------------090503000405050508070504 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------090503000405050508070504-- From gwz@net-zen.net Sat Apr 30 03:22:06 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E39E06E4 for ; Sat, 30 Apr 2011 03:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+uw8Io7CP8I for ; Sat, 30 Apr 2011 03:22:05 -0700 (PDT) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by ietfa.amsl.com (Postfix) with SMTP id C75AAE06CA for ; Sat, 30 Apr 2011 03:22:05 -0700 (PDT) Received: (qmail 7020 invoked from network); 30 Apr 2011 10:22:05 -0000 Received: from unknown (124.120.109.17) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 30 Apr 2011 10:22:04 -0000 Message-ID: <4DBBE2C7.4090105@net-zen.net> Date: Sat, 30 Apr 2011 17:21:59 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------050404020708000200000606" Subject: [Dime] Issue #18 re: RFC 4005 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2011 10:22:06 -0000 This is a multi-part message in MIME format. --------------050404020708000200000606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The ticket says: > Section 4.2.5. Called-Station-Id AVP > > "It SHOULD only be present in authentication and/or authorization > requests." > > Mark Jones> Why is this recommendation here? I have no idea, either. This seems like a question the Chairs should pose the WG, since the text in question was inherited from RFC 4005. > This AVP is commonly > used in RADIUS accounting requests. Same comment for Calling- > Station-Id AVP in Section 4.2.6. --------------050404020708000200000606 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------050404020708000200000606-- From gwz@net-zen.net Sat Apr 30 03:34:48 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F417E068B for ; Sat, 30 Apr 2011 03:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cORxCbg9jOlj for ; Sat, 30 Apr 2011 03:34:47 -0700 (PDT) Received: from p3plsmtpa01-04.prod.phx3.secureserver.net (p3plsmtpa01-04.prod.phx3.secureserver.net [72.167.82.84]) by ietfa.amsl.com (Postfix) with SMTP id 41C39E0684 for ; Sat, 30 Apr 2011 03:34:47 -0700 (PDT) Received: (qmail 2211 invoked from network); 30 Apr 2011 10:34:46 -0000 Received: from unknown (124.120.109.17) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 30 Apr 2011 10:34:45 -0000 Message-ID: <4DBBE5BF.2010400@net-zen.net> Date: Sat, 30 Apr 2011 17:34:39 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------060405050201050702060600" Subject: [Dime] RFC 4005bis, Issue #19 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2011 10:34:48 -0000 This is a multi-part message in MIME format. --------------060405050201050702060600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The ticket says: > Section 4.5.8. Tunnel-Assignment-Id AVP > > Mark Jones> s/should/SHOULD/g Mark Jones> Last paragraph appears to > be missing normative statements in the first two sentences. Was this > intentional? I have no idea, but I doubt it. Since this appears to be a purely editorial change, I think that I can just go ahead & make it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNu+W/AAoJEG4XtfZZU7RfEFMIAMKaAE3X0kxq24fGonYnBXUU fMAUWUO9zq237gO9/ExFNTNv8qAi4YjuitmNvrJRRtzSQR7TZyc8Hsb9lN1ivHIN YrK9v39MWCAGORScWuzfYAu5Ovr4sDyuph/XBxg2nh8MGyyiKc2Gdw45h5fmV2K5 Db787mKhLwYSAxyjpFV8rDqJIcXQNtD3pOXbvHUtjbfJ9FkLkGoXr0KjzF/WwzHw q2viJgR1W73s4mB+BhkEMJHTJf0B9UCZgS+GbK8Rm9sKHl/5+HnZot7lkVy34TUD rafaeSITCXiGERw3mUjl6bCUQ68AVrCvdZ1YiQcts5wky53IZqCA3tiw9DPLQfo= =UmfV -----END PGP SIGNATURE----- --------------060405050201050702060600 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------060405050201050702060600--