From nobody Tue Apr 1 03:32:23 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A601A0988 for ; Tue, 1 Apr 2014 03:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M-okGhgRRqt for ; Tue, 1 Apr 2014 03:32:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A0F371A802C for ; Tue, 1 Apr 2014 03:32:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:35343 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WUvzL-0002oJ-GQ; Tue, 01 Apr 2014 12:32:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Tue, 01 Apr 2014 10:32:15 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/63 Message-ID: <064.8b98719c3d80dc6597df7e7453a13774@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kZzHWWf4VF7Fs2UZW0NP7aKY9WQ Cc: dime@ietf.org Subject: [Dime] [dime] #63 (draft-docdt-dime-ovli): test X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Apr 2014 10:32:21 -0000 #63: test ignore -- ------------------------------------+------------------------------------ Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: ------------------------------------+------------------------------------ Ticket URL: dime From nobody Tue Apr 1 03:57:15 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D581A82E2; Tue, 1 Apr 2014 03:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrxwjY2zy2P0; Tue, 1 Apr 2014 03:57:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 138981A8035; Tue, 1 Apr 2014 03:57:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 632857FC399; Tue, 1 Apr 2014 03:57:08 -0700 (PDT) To: bclaise@cisco.com, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com From: RFC Errata System Message-Id: <20140401105709.632857FC399@rfc-editor.org> Date: Tue, 1 Apr 2014 03:57:08 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/u_g3IrQlvtn5iS-yM0DgZlSgzsY Cc: dime@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Errata Verified] RFC6733 (3942) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 10:57:15 -0000 The following errata report has been verified for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=3942 -------------------------------------- Status: Verified Type: Technical Reported by: Benoit Claise Date Reported: 2014-04-01 Verified by: Benoit Claise (IESG) Section: 8 Original Text ------------- When a Diameter server authorizes a user to implement network resources for a finite amount of time, and it is willing to extend the authorization via a future request, it MUST add the Authorization- Lifetime AVP to the answer message. Corrected Text -------------- When a Diameter server authorizes a user to implement network resources for a finite amount of time, and it is willing to extend the authorization via a future request, it MUST add the Authorization-Lifetime AVP to the answer message. Notes ----- Authorization-Lifetime was mispelled -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Apr 1 04:03:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075951A86EA for ; Tue, 1 Apr 2014 03:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCE4IJIrCVV8 for ; Tue, 1 Apr 2014 03:53:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 2D45C1A86E6 for ; Tue, 1 Apr 2014 03:53:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 471087FC3A9; Tue, 1 Apr 2014 03:52:58 -0700 (PDT) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com From: RFC Errata System Message-Id: <20140401105258.471087FC3A9@rfc-editor.org> Date: Tue, 1 Apr 2014 03:52:58 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PHRf06RmR_5vztSFWUWalHNS1_I X-Mailman-Approved-At: Tue, 01 Apr 2014 04:03:15 -0700 Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Technical Errata Reported] RFC6733 (3942) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 10:53:05 -0000 The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=3942 -------------------------------------- Type: Technical Reported by: Benoit Claise Section: 8 Original Text ------------- When a Diameter server authorizes a user to implement network resources for a finite amount of time, and it is willing to extend the authorization via a future request, it MUST add the Authorization- Lifetime AVP to the answer message. Corrected Text -------------- When a Diameter server authorizes a user to implement network resources for a finite amount of time, and it is willing to extend the authorization via a future request, it MUST add the Authorization-Lifetime AVP to the answer message. Notes ----- Authorization-Lifetime was mispelled Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Apr 1 05:13:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252B71A0697 for ; Tue, 1 Apr 2014 05:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I_T1Zb1VxOM for ; Tue, 1 Apr 2014 05:13:16 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 28AAA1A067F for ; Tue, 1 Apr 2014 05:13:16 -0700 (PDT) Received: from [85.114.53.34] (port=18136 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WUxYy-00064W-O7 for dime@ietf.org; Tue, 01 Apr 2014 05:13:09 -0700 Message-ID: <533AAD53.8080402@usdonovans.com> Date: Tue, 01 Apr 2014 14:13:07 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5cN-Q-P_ox0sJI5IsVfwUElTEAk Subject: [Dime] Section 6 - Transport Considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 12:13:18 -0000 All, Now that we have -02 out it is time to start working on -03. My first proposal is to remove section 6. It discusses something that is not part of the DOIC solution and might or might not be added in a future extension. I suggest moving the first paragraph of section 6 to Appendix A as a potential issue for future specifications. Regards, Steve From nobody Wed Apr 2 02:04:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6DC1A017A for ; Wed, 2 Apr 2014 02:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNEenn-yo-fZ for ; Wed, 2 Apr 2014 02:04:17 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4B31A0178 for ; Wed, 2 Apr 2014 02:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28167; q=dns/txt; s=iport; t=1396429453; x=1397639053; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=rAiQK3evDIlb2uQfdsOWktjc0/eSe8gkgoGpgQ44zZs=; b=AyKq388d/kgORuQ2nUDY88g0cf2+IR6A+0CvH9/5d08heN8ceDmWzGHM dU/UwuTfS9cTT2BGwxP95d17zX2P9I/lJisOOj+fHg3lh5X8ZHAkTDeUY j+ooEYZVyrTdt8knhQoSaDfQTMoI173DvwqMJG1Ia5D5vOw2e+j+YFTDn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoGAM3RO1OtJssU/2dsb2JhbABZgwY7iT2yDIh0gRsWdIImAQEEGk0RARAsFgEOCQMCAQIBRQYNAQcBARCHZQ3QDheJRoQ9CWQHhDgEhWCSdoEzhRyLaoMyO4Es X-IronPort-AV: E=Sophos;i="4.97,778,1389744000"; d="scan'208,217";a="8685362" Received: from aer-core-3.cisco.com ([173.38.203.20]) by aer-iport-3.cisco.com with ESMTP; 02 Apr 2014 09:04:11 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3293ogN011607; Wed, 2 Apr 2014 09:03:50 GMT Message-ID: <533BD276.7000401@cisco.com> Date: Wed, 02 Apr 2014 11:03:50 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "draft-ietf-dime-app-design-guide.all@tools.ietf.org" References: <52D9030B.3010402@cisco.com> In-Reply-To: <52D9030B.3010402@cisco.com> X-Forwarded-Message-Id: <52D9030B.3010402@cisco.com> Content-Type: multipart/alternative; boundary="------------090601000503020208070903" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/egBbGbCd49CQvP18VsgXlyGdCLc Cc: dime mailing list Subject: [Dime] AD review draft-ietf-dime-app-design-guide X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 09:04:21 -0000 This is a multi-part message in MIME format. --------------090601000503020208070903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Sorry for dropping the ball on this one. If any of the points was already discussed/addressed by the WG, feel free to let me know. - When I read the document, it looked to me as a BCP. BCP definition from RFC 2026: 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. Interestingly, the charter mentions: May 2012, Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document If you go to BCP, don't forget to update the abstract, and the writeup. Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013) Example: OLD: Diameter protocol designers are then strongly advised to carefully consider NEW: Diameter protocol designers SHOULD NOT consider OLD: Instead of using an Enumerated AVP for a Boolean flag, protocol designers are again encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which the data field would be defined as NEW: Instead of using an Enumerated AVP for a Boolean flag, protocol designers SHOULD use AVPs of type Unsigned32 or Unsigned64 AVP in which the data field would be defined as Finally, with a BCP, RFC 6733 could be a normative reference, which I believe it should. - Editorial Please don't use "we" in RFCs - Section 3 Major Extension: Enhancing an application that requires the definition of a new Diameter application. Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new AVP with the M-bit set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. Do you want to mention that Major Extension have backward compatibility issue, as opposed to the minor one? - Editorial Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new AVP with the M-bit set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. NEW: Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new mandatory AVP set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. Justification: * Minor extension speaks about "optional" * The M-bit is explained in 4.3.1 - Section 3 I see Minor Extension versus Major Extension, and I tried to match the following classifications to Minor or Major 1. Addition of new functionality to an existing Diameter application without defining a new application. 2. Addition of new functionality to an existing Diameter application that requires the definition of a new application. 3. The definition of an entirely new Diameter application to offer functionality not supported by existing applications. 4. The definition of a new generic functionality that can be reused across different applications. 2 and 3 are Major For 1, I thought about Minor, but the following sentence "or the definition of a new AVP with the M-bit set to be carried in an existing command." in the Major paragraph confuses me. I guess that 4 is Major, but it's not mentioned. Can you please better explain the mapping between the 4 categories and Minor/Major extensions Alternatively, or maybe on top of that, explain which of 4.X and 5.X are Minor/Major extensions would be beneficial. - Section 3 I don't understand what your message is with: We would also like to remind that the definition of a new Diameter application and the definition of a new command should be something to avoid as much as possible. In the past, there has been some reluctance to define new commands and new applications. With the modified extensibility rules provided by [RFC6733 ], registering new commands and new applications does not lead to additional overhead for the specification author in terms of standardization process. Registering new functionality (new commands, new AVPs, new applications, etc.) with IANA remains important to avoid namespace collisions, which will likely lead to deployment problems. "should be something to avoid as much as possible", is this valid today? Because the next sentence speaks about the past, then the next sentence seems like it's fixed now with 6733. - Editorial: With the modified extensibility rules provided by [RFC6733 ], registering new commands and new applications does not lead to additional overhead for the specification author in terms of standardization process. Registering new functionality (new commands, new AVPs, new applications, etc.) "etc.": What does it refer to? new AVP value is the only one I can think of. Worth removing "etc." and specifying the full list? - Application and command Major Extension: Enhancing an application that requires the definition of anew Diameter application. Typical examples would be the creation of anew command for providing functionality not supported by existing applications or the definition of a new AVP with the M-bit set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. 4.1 . Adding a New Command Adding a new command is considered as a major extension and requires a new Diameter application to be defined. I'm not clear on the application/command boundary. Why do we need a new application for a new command? Why can't I add a command to an existing application? There are commands that are for all applications/independent of the application, no? CER/CEA (Capabilities-Exchange-Request) This contradicts: Before adding or_importing_a command, application designers should consider the following ... This also appears to contradict, in section 6 Generic Diameter extensions are AVPs, commands or applications that are designed_to support other Diameter applications_. My issue comes from the fact that there are no "application" and "command" definitions. Draft says: 2 . Terminology This document reuses the terminology defined in [RFC6733] However, RFC 6733 terminology doesn't contain the application and command definitions. Talking to Jouni, I now understand that a command is always specified within the context of an application. This should be clarified. Also, from section 5.2: As a general recommendation, commands should not be defined from scratch. It is instead recommend to re-use an existing command offering similar functionality and use it as a starting point. Based on my latest understanding (a command is always specified within the context of an application), the only justification for the above text is code reuse, right. Please mention it. - Editorial Adding a new command is considered as a major extension and requires a new Diameter application to be defined. Adding a new command to an application means ... A new command addition is always to an application, right? If yes, why do you make the distinction between the sentences above - Application version? An exception might be if the intent of the deletion is to create a newer version of the same application that is somehow simpler than the previous version. ... o Would the new AVP be used to differentiate between old and new versions of the same application whereby the two versions are not backward compatible? Readers might be understanding that diameter applications having a version field. This is not the case. Please rephrase. Also, mention that a new version of an application is a new application. I guess it needs to be mentioned in 7.d - Section 4.3.2 For the reader convenience, I would mention the convention behind { AVP } and [ AVP ], or at least give a reference. - Section 5.3 OLD: Some existing specifications do not adhere to this rule for historical reasons. However, this guidance should be followed to avoid routing problems. NEW: Some existing specifications do not adhere to this rule for historical reasons. However, this guidance should be followed for new applications to avoid routing problems. In the same section, why "In general" in the next sentence? It contradicts with "must use" In general, when a new application has been allocated with a new Application Id and it also reuses existing commands with or without modifications, it must use the newly allocated Application Id in the header and in all relevant Application Id AVPs (Auth-Application-Id or Acct-Application-Id) present in the commands message body. - Editorial, section 5.5 OLD: Based on these considerations, protocol designers should carefully appraise whether the application currently defined relies on it's own session management concept or whether NEW: Based on these considerations, protocol designers should carefully appraise whether the application currently defined relies on its own session management concept or whether - Editorial in section 5.7 OLD: Destination- Realm NEW: Destination-Realm - The section 5.8 should mention RFC4005bis - Section 5.9 Applications that do not understand these AVPs can discard them upon receipt. Generic comment: Each time there is a sentence like this one above, we should mention RFC 6733 as the reference. This document is not an extension/deviation to RFC 6733. - Do you have a good reason to add a reference to a work-in-progress that didn't progress since 2001? [I-D.calhoun-diameter-res-mgmt] Calhoun, P., "Diameter Resource Management Extensions", draft-calhoun-diameter-res-mgmt-08.txt (work in progress), March 2001. - Editorial (section 6) I can't parse the following sentence: Backward Compatibility: With the design of generic extensions an protocol designer has to consider with potential concerns about how existing applications deal with the new extension they do not understand. - Contributors: If Victor and Hannes are authors, then they shouldn't be in the contributors list. Btw, I don't see an affiliation for Victor in the document header. I believe the common practice is to write down "consultant" Did the WG ever considered the following questions: - Any naming convention for new applications? - When it is not a good idea to define diameter applications? Let me make something up: to push syslog message Regards, Benoit --------------090601000503020208070903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear authors,

Sorry for dropping the ball on this one.
If any of the points was already discussed/addressed by the WG, feel free to let me know.


- When I read the document, it looked to me as a BCP.
BCP definition from RFC 2026:
5.  BEST CURRENT PRACTICE (BCP) RFCs

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.
Interestingly, the charter mentions:
May 2012, Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document

If you go to BCP, don't forget to update the abstract, and the writeup.
Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013)
Example:
OLD:
Diameter
protocol designers are then strongly advised to carefully consider
NEW:
   Diameter
   protocol designers SHOULD NOT consider
OLD:
   Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers are again
   encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which
   the data field would be defined as

NEW:
   Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers SHOULD 
   use AVPs of type Unsigned32 or Unsigned64 AVP in which
   the data field would be defined as
Finally, with a BCP, RFC 6733 could be a normative reference, which I believe it should.


- Editorial
Please don't use "we" in RFCs

-
Section 3
  Major Extension:  Enhancing an application that requires the
      definition of a new Diameter application.

      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new AVP with the M-bit set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.
Do you want to mention that Major Extension have backward compatibility issue, as opposed to the minor one?

- Editorial
      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new AVP with the M-bit set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.
NEW:
      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new mandatory AVP set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.
Justification:
	* Minor extension speaks about "optional"
	* The M-bit is explained in 4.3.1

- Section 3
I see Minor Extension versus Major Extension, and I tried to match the following classifications to Minor or Major
   1.  Addition of new functionality to an existing Diameter application
       without defining a new application.

   2.  Addition of new functionality to an existing Diameter application
       that requires the definition of a new application.

   3.  The definition of an entirely new Diameter application to offer
       functionality not supported by existing applications.

   4.  The definition of a new generic functionality that can be reused
       across different applications.
2 and 3 are Major
For 1, I thought about Minor, but the following sentence "or the definition of a new AVP with the M-bit set to be carried in an existing command." in the Major paragraph confuses me.
I guess that 4 is Major, but it's not mentioned.
Can you please better explain the mapping between the 4 categories and Minor/Major extensions
Alternatively, or maybe on top of that, explain which of 4.X and 5.X are Minor/Major extensions would be beneficial.

- Section 3
I don't understand what your message is with:
   We would also like to remind that the definition of a new Diameter
   application and the definition of a new command should be something
   to avoid as much as possible.  In the past, there has been some
   reluctance to define new commands and new applications.  With the
   modified extensibility rules provided by [RFC6733], registering new
   commands and new applications does not lead to additional overhead
   for the specification author in terms of standardization process.
   Registering new functionality (new commands, new AVPs, new
   applications, etc.) with IANA remains important to avoid namespace
   collisions, which will likely lead to deployment problems.
"should be something to avoid as much as possible", is this valid today?
Because the next sentence speaks about the past, then the next sentence seems like it's fixed now with 6733.

- Editorial:
   With the
   modified extensibility rules provided by [RFC6733], registering new
   commands and new applications does not lead to additional overhead
   for the specification author in terms of standardization process.
   Registering new functionality (new commands, new AVPs, new
   applications, etc.)
"etc.": What does it refer to? new AVP value is the only one I can think of.
Worth removing "etc." and specifying the full list?


- Application and command

   Major Extension:  Enhancing an application that requires the
      definition of a new Diameter application.

      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new AVP with the M-bit set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.
4.1.  Adding a New Command
   Adding a new command is considered as a major extension and requires
   a new Diameter application to be defined.
I'm not clear on the application/command boundary.
Why do we need a new application for a new command?
Why can't I add a command to an existing application?
There are commands that are for all applications/independent of the application, no?
    CER/CEA (Capabilities-Exchange-Request)
This contradicts:
   Before adding or importing a command, application designers
   should consider the following ...

This also appears to contradict, in section 6
   Generic Diameter extensions are AVPs, commands or applications that
   are designed to support other Diameter applications.
My issue comes from the fact that there are no "application" and "command" definitions.
Draft says:
2.  Terminology
   This document reuses the terminology defined in [RFC6733]
However, RFC 6733 terminology doesn't contain the application and command definitions.
Talking to Jouni, I now understand that a command is always specified within the context of an application.
This should be clarified.

Also, from section 5.2:
   As a general recommendation, commands should not be defined from
   scratch.  It is instead recommend to re-use an existing command
   offering similar functionality and use it as a starting point.
Based on my latest understanding (a command is always specified within the context of an application), the only justification for the above text is code reuse, right. Please mention it.

- Editorial
   Adding a new command is considered as a major extension and requires
   a new Diameter application to be defined.  Adding a new command to an
   application means ...
A new command addition is always to an application, right?
If yes, why do you make the distinction between the sentences above

- Application version?
An exception might be if the
   intent of the deletion is to create a newer version of the same
   application that is somehow simpler than the previous version.
        ...

   o  Would the new AVP be used to differentiate between old and new
      versions of the same application whereby the two versions are not
      backward compatible?
Readers might be understanding that diameter applications having a version field.
This is not the case. Please rephrase.
Also, mention that a new version of an application is a new application.
I guess it needs to be mentioned in 7.d


- Section 4.3.2
For the reader convenience, I would mention the convention behind { AVP } and [ AVP ], or at least give a reference.

- Section 5.3
OLD:
   Some existing
   specifications do not adhere to this rule for historical reasons.
   However, this guidance should be followed to avoid routing problems.

NEW:
   Some existing
   specifications do not adhere to this rule for historical reasons.
   However, this guidance should be followed for new applications to avoid routing problems.

In the same section, why "In general" in the next sentence? It contradicts with "must use"
In general, when a new application has been allocated with a new
   Application Id and it also reuses existing commands with or without
   modifications, it must use the newly allocated Application Id in the
   header and in all relevant Application Id AVPs (Auth-Application-Id
   or Acct-Application-Id) present in the commands message body.

- Editorial, section 5.5
OLD: 
   Based on these considerations, protocol designers should carefully
   appraise whether the application currently defined relies on it's own
   session management concept or whether 

NEW:
   Based on these considerations, protocol designers should carefully
   appraise whether the application currently defined relies on its own
   session management concept or whether

- Editorial in section 5.7
OLD:
Destination- Realm

NEW:
Destination-Realm


- The section 5.8 should mention RFC4005bis

- Section 5.9
 Applications that do not understand these AVPs can discard
   them upon receipt.
Generic comment: Each time there is a sentence like this one above, we should mention RFC 6733 as the reference.
This document is not an extension/deviation to RFC 6733.

- Do you have a good reason to add a reference to a work-in-progress that didn't progress since 2001?
   [I-D.calhoun-diameter-res-mgmt]
              Calhoun, P., "Diameter Resource Management Extensions",
              draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
              March 2001.

- Editorial (section 6)
I can't parse the following sentence:
 Backward Compatibility:

      With the design of generic extensions an protocol designer has to
      consider with potential concerns about how existing applications
      deal with the new extension they do not understand.

- Contributors:
If Victor and Hannes are authors, then they shouldn't be in the contributors list.
Btw, I don't see an affiliation for Victor in the document header. I believe the common practice is to write down "consultant"

Did the WG ever considered the following questions:
- Any naming convention for new applications?
- When it is not a good idea to define diameter applications? Let me make something up: to push syslog message

Regards, Benoit











--------------090601000503020208070903-- From nobody Wed Apr 2 02:32:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91FE1A0194 for ; Wed, 2 Apr 2014 02:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayzOlS37fvwP for ; Wed, 2 Apr 2014 02:32:17 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id CA9431A017A for ; Wed, 2 Apr 2014 02:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=82012; q=dns/txt; s=iport; t=1396431128; x=1397640728; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=cDEmnIqFZG5OIqvjFdLEq3ee+S/61M7l6mtLgIZCeuk=; b=mBx6A8SEOAUYGwKZgmerXId533z/79AkqMLT+dNHptuKtgryuWvnBulB 6e2JOWm0wyJofV2wNf+uF0iaDKewzfGUejwGJD5UaoVcO8gue2FucKvQU 5IIA1eFszIvyVgWnDo25uCgo6yn7N3ozY/AQ0eqFKY+iJ83nvbnNJp3dy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEGACzYO1OtJssH/2dsb2JhbABZgkJEO1GIbLNLhzWBGxZ0giUBAQEEAQEBFwESQQYFDAQLEQQBAQEJFwEGBw8CEAYfCQgGAQwBBQIBAQUSA4dHAxEIBcgsDYdFF4lGgxCBOBEBCyMiBgEGhDIElmmBbYEzhRyGHoVMgzI7gSwJFwQ X-IronPort-AV: E=Sophos; i="4.97,779,1389744000"; d="scan'208,217"; a="12777652" Received: from aer-core-2.cisco.com ([173.38.203.7]) by aer-iport-2.cisco.com with ESMTP; 02 Apr 2014 09:32:04 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s329W15p026138; Wed, 2 Apr 2014 09:32:02 GMT Message-ID: <533BD911.804@cisco.com> Date: Wed, 02 Apr 2014 11:32:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "Shishufeng (Susan)" , Steve Donovan , Jouni Korhonen References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------030004010803090108050708" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_iMqCALPVHdyPodt-gVn8nWINC8 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 09:32:30 -0000 This is a multi-part message in MIME format. --------------030004010803090108050708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, On consensus, here is a good link: http://www.ietf.org/tao.html#getting.things.done Note that the WG chairs are the ones who must be evaluating the consensus, even rough. Regards, Benoit > > Hi Susan, > > I do care about comments from other but we need to move on. > > My decision is based on the following: from a technical point of view, > there is no issue if we define this AVP as required. From a protocol > aspect, it is cleaner as a report ALWAYS applies to a given type. > Default value was considered as sub-optimal by Jouni, Ben, Steve, > Maria Cruz (who has triggered this issue) and myself. > > Now, about the process, a 100% is not required to move forward. As it > is not possible to get consensus on this issue, I use my prerogative > to pick one solution, the one that seems to be the best solution at > this stage, to be able to close the discussion at this stage and > produce the draft that we need. > > After, it is always possible to challenge again the content of the > draft if there is still concern. > > Benoit, the Area Director, is copied. It is not a putsch. Just > administrative way agreed within IETF to be able to move forward a WG > draft, which is the ultimate goal of everyone I think. > > Regards, > > Lionel. > > *De :*Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com] > *Envoyé :* mercredi 26 mars 2014 08:06 > *À :* Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni > Korhonen > *Cc :* dime@ietf.org > *Objet :* RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP > > Hello Lionel, > > Further clarification: > > I don't agree with this, not ok to everyone as you said. > > Best Regards, > > Susan > > *From:*Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com] > *Sent:* Wednesday, March 26, 2014 2:56 PM > *To:* lionel.morand@orange.com; Steve Donovan; Jouni Korhonen > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP > > Hello Lionel, > > I don't understand it. > > Please clarify if you care about other people's comments. > > Best Regards, > > Susan > > *From:*lionel.morand@orange.com > [mailto:lionel.morand@orange.com] > *Sent:* Wednesday, March 26, 2014 2:44 PM > *To:* Steve Donovan; Jouni Korhonen; Shishufeng (Susan) > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP > > As chair and temporary doc shepherd, > > Please stop this thread for now. > > As mandatory/required is ok for everyone (even if useless in certain case), let use it for now. > > Lionel > > > "Shishufeng (Susan)" > a écrit : > > > Hello Steve, > > Thanks for clarifying the IETF procedure. I'm not familiar with it, > while I know the draft is mainly for 3GPP use, that's why we 3GPP > delegates are deeply involved in this specific discussion. If most of > 3GPP people think it is not so needed I couldn't understand why it > shall be mandatory. > > From technical point of view, in the case realm based report type is > not needed, nothing wrong without this AVP, and even better and cleaner. > > And you ever said you have preference but ok with either way forward, > i.e., make it mandatory or optional. Then let's move on with the draft > as it is on this point, if you agree. > > Best Regards, > > Susan > > *From:*Steve Donovan [mailto:srdonovan@usdonovans.com] > *Sent:* Tuesday, March 25, 2014 8:39 PM > *To:* Shishufeng (Susan); Jouni Korhonen > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP > > Susan, > > We have not been following a process of determining consensus based on > a majority of companies expressing a preference. It is also the case > that, in the IETF, companies do not contribute, individuals contribute. > > In addition, if we did take a "vote" on this one, I'm not sure which > side would actually have a majority. > > We might need to change our process to speed things up, but right now > we have been striving for true consensus where everyone agrees. Note > that this doesn't mean everyone agrees with the technical reasoning > behind the decision. There have been many cases where agreement is > reached because it was more important to get something finished then > to win a technical argument. > > If we can't start moving a little faster then we will likely need to > change to rough consensus, where the measure is that most everyone > agrees. However, in the IETF, even this is not a voting process. If > things are close to 50-50 in opinions then the correct process is to > continue to discuss the technical merits of each alternative until > rough consensus is reached. > > Regards, > > Steve > > On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote: > > Hi Steve, > > As I know, majority companies expressed preference to keep the AVP > as optional and keep the texts as they are. You have preference to > have it explicitly but ok with either way. That's how I assumed we > reached consensus. > > Best Regards, > > Susan > > *From:*Steve Donovan [mailto:srdonovan@usdonovans.com] > *Sent:* Monday, March 24, 2014 8:26 PM > *To:* Shishufeng (Susan); Jouni Korhonen > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP > > Susan, > > We are in the middle of the discussion and have not yet reached > consensus. > > I agree with Jouni on making it explicit. Either way, we should > try to make a decision quickly. > > Steve > > On 3/23/14 10:59 PM, Shishufeng (Susan) wrote: > > Hello Jouni, > > > > I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft. > > > > Best Regards, > > Susan > > > > > > -----Original Message----- > > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] > > Sent: Saturday, March 22, 2014 10:38 AM > > To: Steve Donovan > > Cc:dime@ietf.org > > Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP > > > > > > Lets have it explicit then. Use '<' and '>' to make the position fixed. > > > > - Jouni > > > > On Mar 19, 2014, at 1:29 AM, Steve Donovan wrote: > > > > I'm ok with either direction but generally lean toward being explicit. > > > > Do we have other opinions? > > > > Steve > > On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote: > > Hello, > > I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft. > > This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports. > > If there is consensus on this, I will go with this. > > Best regards > > /MCruz > > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > > Sent: martes, 18 de marzo de 2014 17:47 > > To:dime@ietf.org > > Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP > > > > All, > > > > Do we have consensus that the OC-Report-Type AVP is required? > > > > If so then one change would be as indicated in the syntax definition proposed by Lionel. We would also remove wording on the default value. > > > > Jouni, > > > > How do we indicate a fixed position for an AVP? > > > > I presonally don't see this as critical but we can add this requirement if there is consensus. > > > > Regards, > > > > Steve > > > > On 2/28/14 10:27 AM, Jouni Korhonen wrote: > > > > Hi, > > > > How having the AVP could be less error prone if it has a default > > value and the receiver knows exactly how to proceed when the AVP is > > not present? > > > > If a node does not include it when it should, the implementation is > > broken. Wouldn't a broken node be able to put wrong report type into > > the AVP even if the AVP is mandatory? > > > > Anyway, if it is my statement keeping issue #54 still open, consider > > it resolved from my side. I am OK making the OC-Report-Type AVP as > > required/mandatory AVP. Should we also consider it having a fixed > > position just after the OC-Sequence-Number AVP as well since it is > > going to in every OC-OLR? > > > > - Jouni > > > > > > > > On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome wrote: > > > > > > Hello all, > > > > I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong. > > > > I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior. > > > > Best regards > > /MCruz > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell > > Sent: viernes, 14 de febrero de 2014 23:13 > > To: Jouni Korhonen > > Cc:dime@ietf.org > > Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP > > > > I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors. > > > > On Feb 13, 2014, at 6:05 AM, Jouni Korhonen wrote: > > > > > > Agree that it is a small optimization, which I put there because at > > the beginning there seemed to be a lot of worry on every extra AVP > > ;-) > > > > I prefer having the AVP optional but with a default value just like > > it is now. We have the same for the reduction percentage and the > > validity time as well. > > > > - Jouni > > > > On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" wrote: > > > > Hi Mcruz > > > > The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. > > We may have deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization. > > > > Best regards > > > > JJacques > > > > > > > > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de > > lionel.morand@orange.com Envoyé : mercredi 12 février 2014 15:46 À : > > dime@ietf.org ;maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] > > [dime] #54: OC-Report-Type as mandatory AVP > > > > Hi Maria Cruz, > > > > I'm assuming that you mean "required" instead of "mandatory", right? > > > > So instead of: > > > > OC-OLR ::= < AVP Header: TBD2 > > > < OC-Sequence-Number > > > [ OC-Report-Type ] > > [ OC-Reduction-Percentage ] > > [ OC-Validity-Duration ] > > * [ AVP ] > > > > You would prefer: > > > > OC-OLR ::= < AVP Header: TBD2 > > > < OC-Sequence-Number > > > { OC-Report-Type } > > [ OC-Reduction-Percentage ] > > [ OC-Validity-Duration ] > > * [ AVP ] > > > > And I'm fine with this proposal. > > > > Cheers, > > > > Lionel > > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue > > tracker Envoyé : mercredi 12 février 2014 15:26 À : > > maria.cruz.bartolome@ericsson.com Cc :dime@ietf.org Objet : [Dime] > > [dime] #54: OC-Report-Type as mandatory AVP > > > > #54: OC-Report-Type as mandatory AVP > > > > Now in chapter 4.6: > > > > The default value of the OC-Report-Type AVP is 0 (i.e. the host > > report). > > > > This AVP is always required, right? Then, I think it is more precise that we define this AVP as mandatory. > > > > -- > > -----------------------------------------------+--------------------- > > -----------------------------------------------+--- > > -----------------------------------------------+--- > > Reporter:maria.cruz.bartolome@ericsson.com | Owner: MCruz > > Type: defect | Bartolomé > > Priority: major | Status: new > > Component: draft-docdt-dime-ovli | Milestone: > > Severity: Active WG Document | Version: 1.0 > > | Keywords: > > -----------------------------------------------+--------------------- > > -----------------------------------------------+--- > > -----------------------------------------------+--- > > > > Ticket URL: > > dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _____________________________________________________________________ > > ____________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------030004010803090108050708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

On consensus, here is a good link: http://www.ietf.org/tao.html#getting.things.done
Note that the WG chairs are the ones who must be evaluating the consensus, even rough.

Regards, Benoit

Hi Susan,

 

I do care about comments from other but we need to move on.

 

My decision is based on the following: from a technical point of view, there is no issue if we define this AVP as required. From a protocol aspect, it is cleaner as a report ALWAYS applies to a given type. Default value was considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggered this issue) and myself.

 

Now, about the process, a 100% is not required to move forward. As it is not possible to get consensus on this issue, I use my prerogative to pick one solution, the one that seems to be the best solution at this stage, to be able to close the discussion at this stage and produce the draft that we need.

 

After, it is always possible to challenge again the content of the draft if there is still concern.

 

Benoit, the Area Director, is copied. It is not a putsch. Just administrative way agreed within IETF to be able to move forward a WG draft, which is the ultimate goal of everyone I think.

 

Regards,

 

Lionel.

 

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoyé : mercredi 26 mars 2014 08:06
À : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

 

Hello Lionel,

 

Further clarification:

 

I don’t agree with this, not ok to everyone as you said.

 

Best Regards,

Susan

 

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

 

Hello Lionel,

 

I don’t understand it.

 

Please clarify if you care about other people’s comments.

 

Best Regards,

Susan

 

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

 

As chair and temporary doc shepherd,
 
Please stop this thread for now.
 
As mandatory/required is ok for everyone (even if useless in certain case), let use it for now.
 
Lionel 
 
 
"Shishufeng (Susan)" <susan.shishufeng@huawei.com> a écrit :
 

Hello Steve,

 

Thanks for clarifying the IETF procedure. I’m not familiar with it, while I know the draft is mainly for 3GPP use, that’s why we 3GPP delegates are deeply involved in this specific discussion. If most of 3GPP people think it is not so needed I couldn’t understand why it shall be mandatory.

 

From technical point of view, in the case realm based report type is not needed, nothing wrong without this AVP, and even better and cleaner.

 

And you ever said you have preference but ok with either way forward, i.e., make it mandatory or optional. Then let’s move on with the draft as it is on this point, if you agree.

 

Best Regards,

Susan

 

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

 

Susan,

We have not been following a process of determining consensus based on a majority of companies expressing a preference.  It is also the case that, in the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side would actually have a majority.

We might need to change our process to speed things up, but right now we have been striving for true consensus where everyone agrees.  Note that this doesn't mean everyone agrees with the technical reasoning behind the decision.  There have been many cases where agreement is reached because it was more important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change to rough consensus, where the measure is that most everyone agrees.  However, in the IETF, even this is not a voting process.  If things are close to 50-50 in opinions then the correct process is to continue to discuss the technical merits of each alternative until rough consensus is reached.

Regards,

Steve

On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:

Hi Steve,

 

As I know, majority companies expressed preference to keep the AVP as optional and keep the texts as they are. You have preference to have it explicitly but ok with either way. That’s how I assumed we reached consensus.

 

Best Regards,

Susan

 

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

 

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to make a decision quickly.

Steve

On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,
 
I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft. 
 
Best Regards,
Susan
 
 
-----Original Message-----
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Saturday, March 22, 2014 10:38 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
 
 
Lets have it explicit then. Use '<' and '>' to make the position fixed.
 
- Jouni
 
On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
 
I'm ok with either direction but generally lean toward being explicit.
 
Do we have other opinions?  
 
Steve
On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:
Hello,
I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft.
This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports.
If there is consensus on this, I will go with this.
Best regards
/MCruz
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 18 de marzo de 2014 17:47
To: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
 
All,
 
Do we have consensus that the OC-Report-Type AVP is required?
 
If so then one change would be as indicated in the syntax definition proposed by Lionel.  We would also remove wording on the default value.
 
Jouni,
 
How do we indicate a fixed position for an AVP?  
 
I presonally don't see this as critical but we can add this requirement if there is consensus.
 
Regards,
 
Steve
 
On 2/28/14 10:27 AM, Jouni Korhonen wrote:
 
Hi,
 
How having the AVP could be less error prone if it has a default 
value and the receiver knows exactly how to proceed when the AVP is 
not present?
 
If a node does not include it when it should, the implementation is 
broken. Wouldn't a broken node be able to put wrong report type into 
the AVP even if the AVP is mandatory?
 
Anyway, if it is my statement keeping issue #54 still open, consider 
it resolved from my side. I am OK making the OC-Report-Type AVP as 
required/mandatory AVP. Should we also consider it having a fixed 
position just after the OC-Sequence-Number AVP as well since it is 
going to in every OC-OLR?
 
- Jouni
 
 
 
On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:
 
 
Hello all,
 
I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.
 
I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.
 
Best regards
/MCruz
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: viernes, 14 de febrero de 2014 23:13
To: Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
 
I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.
 
On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
 
 
Agree that it is a small optimization, which I put there because at 
the beginning there seemed to be a lot of worry on every extra AVP 
;-)
 
I prefer having the AVP optional but with a default value just like 
it is now. We have the same for the reduction percentage and the 
validity time as well.
 
- Jouni
 
On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:
 
Hi Mcruz
 
The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 
We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.
 
Best regards
 
JJacques
 
 
 
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de 
lionel.morand@orange.com Envoyé : mercredi 12 février 2014 15:46 À :
dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] 
[dime] #54: OC-Report-Type as mandatory AVP
 
Hi Maria Cruz,
 
I'm assuming that you mean "required" instead of "mandatory", right?
 
So instead of:
 
OC-OLR ::= < AVP Header: TBD2 >
           < OC-Sequence-Number >
           [ OC-Report-Type ]
           [ OC-Reduction-Percentage ]
           [ OC-Validity-Duration ]
         * [ AVP ]
 
You would prefer:
 
OC-OLR ::= < AVP Header: TBD2 >
           < OC-Sequence-Number >
           { OC-Report-Type }
           [ OC-Reduction-Percentage ]
           [ OC-Validity-Duration ]
         * [ AVP ]
 
And I'm fine with this proposal.
 
Cheers,
 
Lionel
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 
tracker Envoyé : mercredi 12 février 2014 15:26 À :
maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 
[dime] #54: OC-Report-Type as mandatory AVP
 
#54: OC-Report-Type as mandatory AVP
 
Now in chapter 4.6:
 
 The default value of the OC-Report-Type AVP is 0 (i.e. the host  
report).
 
This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.
 
--
-----------------------------------------------+---------------------
-----------------------------------------------+---
-----------------------------------------------+---
Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
  Type:  defect                             |  Bartolomé
Priority:  major                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
Severity:  Active WG Document                 |    Version:  1.0
                                            |   Keywords:
-----------------------------------------------+---------------------
-----------------------------------------------+---
-----------------------------------------------+---
 
Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54>
dime <http://tools.ietf.org/wg/dime/>
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
_____________________________________________________________________
____________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
 
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
 
 

 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------030004010803090108050708-- From nobody Wed Apr 2 06:26:14 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E54A1A01CB for ; Wed, 2 Apr 2014 06:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnaFoptqgCkm for ; Wed, 2 Apr 2014 06:26:09 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 480C11A01D5 for ; Wed, 2 Apr 2014 06:26:01 -0700 (PDT) Received: from [85.114.54.3] (port=16572 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WVLAs-0002cm-BT for dime@ietf.org; Wed, 02 Apr 2014 06:25:57 -0700 Message-ID: <533C0FDC.1080705@usdonovans.com> Date: Wed, 02 Apr 2014 15:25:48 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dime@ietf.org References: <53304336.20006@usdonovans.com> In-Reply-To: <53304336.20006@usdonovans.com> Content-Type: multipart/alternative; boundary="------------010202010509070307050405" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uI9M8v1MQFxCx_-PwMX-bNxp3Nk Subject: Re: [Dime] Issue #27 - Result code sent when agent throttles message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 13:26:13 -0000 This is a multi-part message in MIME format. --------------010202010509070307050405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, Do we have any thoughts on the options outlined below? Regards, Steve On 3/24/14, 3:37 PM, Steve Donovan wrote: > All, > > We don't have a clean solution for this as existing error result codes > do not get the desired behavior of the reacting node not retrying the > request on another path, if available. > > The proposal has been made that we propose an extension to 6733 to > introduce a new result code. This would be something like: > > DIAMETER_REQUEST_THROTTLED 3011 > > A request was received by an agent and the agent determined that > the request needed to be throttled due to an existing overload > condition. The client SHOULD NOT attempt to retry the request and > the client SHOULD NOT attempt to sent the request to an > an alternate peer. > > My assumption is that this extension would be included in the the > CER/CEA exchange so an agent would know if it is supported. A client > that supports this extension is referred to as a 6733+ client below. > A client that doesn't is referred to as a 6733 client. > > With this extension we have two options for wording to be put into the > DOIC specification. > > 1) Indicate that a DOIC agent that throttles a request MUST send a > 3011 error response for all clients, 6733 and 6733+. This would > depend on default processing in clients for result codes that the > client does not understand. This default processing is not defined in > 6733 (at least I didn't find it). The closest I could find was the > following. If an unrecognized result code was interpreted as the > answer message containing an error then throttling a request would > result in the session being terminated. > In the case where the answer message itself contains errors, any > related session SHOULD be terminated by sending an STR or ASR > message. The Termination-Cause AVP in the STR MAY be filled with the > appropriate value to indicate the cause of the error. An application > MAY also send an application-specific request instead of an STR or > ASR message to signal the error in the case where no state is > maintained or to allow for some form of error recovery with the > corresponding Diameter entity. > RFC 6733 - Diameter Base Protocol 2) Indicate that a DOIC agent that > throttles a request MUST send a 3011 response to 6733+ clients. For > 6733 clients the agent MUST send DIAMETER_TOO_BUSY 3002. This is not > perfect as 3002 says the client should try to send to an alternative > peer, but it is as close as we can get. > > Neither of these solutions are perfect and would come with the strong > recommendation that Diameter nodes that support DOIC should also > support the above extension. > > I propose number 1 as it at least does result in reduction of traffic > sent toward the overloaded server. > > Regards, > > Steve > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------010202010509070307050405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

Do we have any thoughts on the options outlined below?

Regards,

Steve

On 3/24/14, 3:37 PM, Steve Donovan wrote:
All,

We don't have a clean solution for this as existing error result codes do not get the desired behavior of the reacting node not retrying the request on another path, if available.

The proposal has been made that we propose an extension to 6733 to introduce a new result code.  This would be something like:

   DIAMETER_REQUEST_THROTTLED  3011

    A request was received by an agent and the agent determined that the request needed to be throttled due to an existing overload
    condition.  The client SHOULD NOT attempt to retry the request and the client SHOULD NOT attempt to sent the request to an
    an alternate peer.

My assumption is that this extension would be included in the the CER/CEA exchange so an agent would know if it is supported.  A client that supports this extension is referred to as a 6733+ client below.  A client that doesn't is referred to as a 6733 client.

With this extension we have two options for wording to be put into the DOIC specification.

1) Indicate that a DOIC agent that throttles a request MUST send a 3011 error response for all clients, 6733 and 6733+.  This would depend on default processing in clients for result codes that the client does not understand.  This default processing is not defined in 6733 (at least I didn't find it).  The closest I could find was the following.  If an unrecognized result code was interpreted as the answer message containing an error then throttling a request would result in the session being terminated.  
In the case where the answer message itself contains errors, any
   related session SHOULD be terminated by sending an STR or ASR
   message.  The Termination-Cause AVP in the STR MAY be filled with the
   appropriate value to indicate the cause of the error.  An application
   MAY also send an application-specific request instead of an STR or
   ASR message to signal the error in the case where no state is
   maintained or to allow for some form of error recovery with the
   corresponding Diameter entity.
RFC 6733 - Diameter Base Protocol 2) Indicate that a DOIC agent that throttles a request MUST send a 3011 response to 6733+ clients.  For 6733 clients the agent MUST send DIAMETER_TOO_BUSY 3002.  This is not perfect as 3002 says the client should try to send to an alternative peer, but it is as close as we can get.

Neither of these solutions are perfect and would come with the strong recommendation that Diameter nodes that support DOIC should also support the above extension.

I propose number 1 as it at least does result in reduction of traffic sent toward the overloaded server.

Regards,

Steve





 

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

--------------010202010509070307050405-- From nobody Wed Apr 2 21:21:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7906A1A0045; Wed, 2 Apr 2014 21:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNqSTINTHe7u; Wed, 2 Apr 2014 21:21:12 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 400431A002D; Wed, 2 Apr 2014 21:21:08 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id 10so871315lbg.7 for ; Wed, 02 Apr 2014 21:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=2rzHWdmt747YHOBZ1QQItUsskKspBfHGmW35osdUnP4=; b=E2ACP9fCcwkzTdJHPH+55+oQMEM9nz8KSFxcrEXkRL4Jvy9tUpPSLeEZ2g8tkU/lBv +qZuln7+X4pgjYtnQUfOsPgn7nWrv5w12xuy8NYSPGdG+5K+758M14u23Ru3dlxDtj0r +cLU1FhzwQrh0xy/mBW7rwo3TaU89aGPQIpwG3M3pDPhkDTGwqzCGAx4tkky3Lv8JAnv sKKc1doWdy9RHg6q7nIgKeaz0Iiz6Ln4DUUMUKepvtmHslGyNgoy80zed1gj9QTViGul VnShtUq/EgkSLDiUXcmX6XHIXom+ioaHLA3lX3yFO1A3dFK588xSYHP32W84doCcKqzx +0fA== X-Received: by 10.152.6.2 with SMTP id w2mr2763439law.28.1396498863559; Wed, 02 Apr 2014 21:21:03 -0700 (PDT) Received: from [10.222.31.190] ([82.203.205.227]) by mx.google.com with ESMTPSA id oy7sm2696729lbb.16.2014.04.02.21.21.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 21:21:02 -0700 (PDT) Message-ID: <533CE1AD.3010407@gmail.com> Date: Thu, 03 Apr 2014 07:21:01 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dime@ietf.org, dime-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IzAtUyvutFce33Pzk3BMxtwKcFk Subject: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Apr 2014 04:21:17 -0000 Folks, As discussed and agreed (and now verified with our AD), this email starts a two week adoption call for draft-bertz-dime-congestion-flow-attributes-02 as a Dime WG document. Express your support or opposition on the mailing list. The call ends 17th April. Jouni & Lionel From nobody Fri Apr 4 12:26:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2501A04C5 for ; Fri, 4 Apr 2014 12:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GQKjEXxnAAL for ; Fri, 4 Apr 2014 12:25:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1398A1A04BA for ; Fri, 4 Apr 2014 12:25:55 -0700 (PDT) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s34JPnrO030930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Apr 2014 14:25:50 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <533C0FDC.1080705@usdonovans.com> Date: Fri, 4 Apr 2014 14:25:49 -0500 X-Mao-Original-Outgoing-Id: 418332349.128267-f9c2d7cbea49005855fd71f95c08870e Content-Transfer-Encoding: quoted-printable Message-Id: <98602E4A-500A-436B-B559-568ECE61933A@nostrum.com> References: <53304336.20006@usdonovans.com> <533C0FDC.1080705@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1VWD8xftrXdN5xYNC4z7_3gplys Cc: dime@ietf.org Subject: Re: [Dime] Issue #27 - Result code sent when agent throttles message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 19:26:00 -0000 On Apr 2, 2014, at 8:25 AM, Steve Donovan = wrote: > All, >=20 > Do we have any thoughts on the options outlined below? >=20 > Regards, >=20 > Steve >=20 > On 3/24/14, 3:37 PM, Steve Donovan wrote: >> All, >>=20 >> We don't have a clean solution for this as existing error result = codes do not get the desired behavior of the reacting node not retrying = the request on another path, if available. >>=20 >> The proposal has been made that we propose an extension to 6733 to = introduce a new result code. This would be something like: >>=20 >> DIAMETER_REQUEST_THROTTLED 3011 >>=20 >> A request was received by an agent and the agent determined that = the request needed to be throttled due to an existing overload=20 >> condition. The client SHOULD NOT attempt to retry the request = and the client SHOULD NOT attempt to sent the request to an >> an alternate peer. Why SHOULD NOTs and not MUST NOTs? OTOH, I'm not sure the proscription against sending to alternate peers = is generally applicable. There may be cases where you want the = downstream node to resend to an alternate peer. E.g some agent overload = scenarios. Maybe we need two separate codes? (Or maybe TOO_BUSY is = enough for the other case?) >>=20 >> My assumption is that this extension would be included in the the = CER/CEA exchange so an agent would know if it is supported. A client = that supports this extension is referred to as a 6733+ client below. A = client that doesn't is referred to as a 6733 client. >>=20 >> With this extension we have two options for wording to be put into = the DOIC specification. >>=20 >> 1) Indicate that a DOIC agent that throttles a request MUST send a = 3011 error response for all clients, 6733 and 6733+. This would depend = on default processing in clients for result codes that the client does = not understand. This default processing is not defined in 6733 (at = least I didn't find it). The closest I could find was the following. = If an unrecognized result code was interpreted as the answer message = containing an error then throttling a request would result in the = session being terminated. =20 I could have sworn that I read that for unknown errors in a known class, = the error should be treated as the base for the class. But I can't find = that anywhere. >> =20 >> In the case where the answer message itself contains errors, any >> related session SHOULD be terminated by sending an STR or ASR >> message. The Termination-Cause AVP in the STR MAY be filled with = the >> appropriate value to indicate the cause of the error. An = application >> MAY also send an application-specific request instead of an STR or >> ASR message to signal the error in the case where no state is >> maintained or to allow for some form of error recovery with the >> corresponding Diameter entity. >>=20 Would that guidance still make since if one or both peers in question = are agents? >> 2) Indicate that a DOIC agent that throttles a request MUST send a = 3011 response to 6733+ clients. For 6733 clients the agent MUST send = DIAMETER_TOO_BUSY 3002. This is not perfect as 3002 says the client = should try to send to an alternative peer, but it is as close as we can = get. >>=20 I am skeptical of requiring different behavior depending on whether the = client supports 6733bis. That would require a version number change, or = some other way to signal 6733bis support. If we were to go that route, = it might make more sense to make the new code part of DOIC. >> Neither of these solutions are perfect and would come with the strong = recommendation that Diameter nodes that support DOIC should also support = the above extension. So the real reason for separating this from DOIC is some sense that = nodes might support the new code when they otherwise don't support DOIC. = Do we expect that to really happen? >>=20 >> I propose number 1 as it at least does result in reduction of traffic = sent toward the overloaded server. >>=20 >> Regards, >>=20 >> Steve >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Fri Apr 4 13:14:28 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F284C1A0452; Fri, 4 Apr 2014 13:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk1G00acGyFd; Fri, 4 Apr 2014 13:14:21 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 209B71A0238; Fri, 4 Apr 2014 13:14:20 -0700 (PDT) Received: from mail91-am1-R.bigfish.com (10.3.201.232) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.22; Fri, 4 Apr 2014 20:14:12 +0000 Received: from mail91-am1 (localhost [127.0.0.1]) by mail91-am1-R.bigfish.com (Postfix) with ESMTP id 46B5210027E; Fri, 4 Apr 2014 20:14:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.25; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(z579ehz9371I9f17R542Izz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzdchz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25f6h2605h262fh268bh26d3h9a9j1155h) Received-SPF: pass (mail91-am1: domain of sprint.com designates 144.230.168.25 as permitted sender) client-ip=144.230.168.25; envelope-from=Brent.Hirschman@sprint.com; helo=plsasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail91-am1 (localhost.localdomain [127.0.0.1]) by mail91-am1 (MessageSwitch) id 1396642449190730_10607; Fri, 4 Apr 2014 20:14:09 +0000 (UTC) Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.228]) by mail91-am1.bigfish.com (Postfix) with ESMTP id 2095344006B; Fri, 4 Apr 2014 20:14:09 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 4 Apr 2014 20:14:09 +0000 Received: from PLSWEH03.ad.sprint.com (plsweh03.corp.sprint.com [144.226.242.132]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s34KEBom011413 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Apr 2014 15:14:11 -0500 Received: from PREWE13M04.ad.sprint.com (144.226.128.23) by PLSWEH03.ad.sprint.com (144.226.242.132) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Apr 2014 15:13:55 -0500 Received: from PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) by PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) with Microsoft SMTP Server (TLS) id 15.0.775.38; Fri, 4 Apr 2014 16:13:53 -0400 Received: from PREWE13M04.ad.sprint.com ([fe80::6848:f832:11d7:eaca]) by PREWE13M04.ad.sprint.com ([fe80::6848:f832:11d7:eaca%15]) with mapi id 15.00.0775.031; Fri, 4 Apr 2014 16:13:53 -0400 From: "Hirschman, Brent B [CTO]" To: Jouni Korhonen , "dime@ietf.org" , "dime-chairs@ietf.org" Thread-Topic: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 Thread-Index: AQHPTvQ5/uUBcsaoOEejK/uxUyjVzZsB5n3A Date: Fri, 4 Apr 2014 20:13:53 +0000 Message-ID: <69f544d6b08b400bbd3fd8c4e14aab87@PREWE13M04.ad.sprint.com> References: <533CE1AD.3010407@gmail.com> In-Reply-To: <533CE1AD.3010407@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GHmom6TYW1I9nhI4xC8cczNjMbA Subject: Re: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 20:14:26 -0000 As an author of this draft, I am in support of this document becoming a wor= king group document. There are three main reasons for promoting it to this= status: 1. These were overlooked items in the creation of RFC5777. In discuss= ions with Avi Lior, one of the authors of that document, he agreed that it = was an oversight not to include it originally. 2. The concept of adding flow and packet AVPs as part of reports is si= mple. This type of reporting is very similar to byte count reporting alrea= dy done in Diameter reporting. 3. Reporting based upon ECN filters can be used not only for managing= real-time congestion at a node in a network, but can also be used for long= er term network planning such as adding capacity or additional nodes to the= network. The authors would appreciate your support in progressing this draft quickly= through the approval process. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Wednesday, April 02, 2014 11:21 PM To: dime@ietf.org; dime-chairs@ietf.org Subject: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attribut= es-02 Folks, As discussed and agreed (and now verified with our AD), this email starts a= two week adoption call for draft-bertz-dime-congestion-flow-attributes-02 as a Dime WG document. Express your support or opposition on the mailing list. The call ends 17th = April. Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Apr 7 06:21:25 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7BE1A070C for ; Mon, 7 Apr 2014 06:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHQkqn9jXTTd for ; Mon, 7 Apr 2014 06:21:19 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 929A21A0709 for ; Mon, 7 Apr 2014 06:21:19 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55011 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WX9Ty-0002mg-AY for dime@ietf.org; Mon, 07 Apr 2014 06:21:10 -0700 Message-ID: <5342A63E.4030004@usdonovans.com> Date: Mon, 07 Apr 2014 08:21:02 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dime@ietf.org References: <533CE1AD.3010407@gmail.com> <69f544d6b08b400bbd3fd8c4e14aab87@PREWE13M04.ad.sprint.com> In-Reply-To: <69f544d6b08b400bbd3fd8c4e14aab87@PREWE13M04.ad.sprint.com> Content-Type: multipart/alternative; boundary="------------050305030205050705050006" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Knoj-CLyDB1xJMyIbPVR0r8WDMs Subject: Re: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 13:21:23 -0000 This is a multi-part message in MIME format. --------------050305030205050705050006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I support adoption of this work item. Steve On 4/4/14 3:13 PM, Hirschman, Brent B [CTO] wrote: > As an author of this draft, I am in support of this document becoming a working group document. There are three main reasons for promoting it to this status: > 1. These were overlooked items in the creation of RFC5777. In discussions with Avi Lior, one of the authors of that document, he agreed that it was an oversight not to include it originally. > 2. The concept of adding flow and packet AVPs as part of reports is simple. This type of reporting is very similar to byte count reporting already done in Diameter reporting. > 3. Reporting based upon ECN filters can be used not only for managing real-time congestion at a node in a network, but can also be used for longer term network planning such as adding capacity or additional nodes to the network. > > The authors would appreciate your support in progressing this draft quickly through the approval process. > > Brent Hirschman > Tech Dev Strategist III > Sprint Corporation > 6220 Sprint Parkway > Overland Park, KS 66251 > Office - 913-762-6736 > Mobile - 913-593-6221 > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Wednesday, April 02, 2014 11:21 PM > To: dime@ietf.org; dime-chairs@ietf.org > Subject: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 > > Folks, > > As discussed and agreed (and now verified with our AD), this email starts a two week adoption call for > draft-bertz-dime-congestion-flow-attributes-02 as a Dime WG document. > Express your support or opposition on the mailing list. The call ends 17th April. > > Jouni & Lionel > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------050305030205050705050006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I support adoption of this work item.

Steve
On 4/4/14 3:13 PM, Hirschman, Brent B [CTO] wrote:
As an author of this draft, I am in support of this document becoming a working group document.  There are three main reasons for promoting it to this status:
1.      These were overlooked items in the creation of RFC5777.  In discussions with Avi Lior, one of the authors of that document, he agreed that it was an oversight not to include it originally.
2.      The concept of adding flow and packet AVPs as part of reports is simple.  This type of reporting is very similar to byte count reporting already done in Diameter reporting.
3.      Reporting  based upon ECN filters can be used not only for managing real-time congestion at a node in a network, but can also be used for longer term network planning such as adding capacity or additional nodes to the network.

The authors would appreciate your support in progressing this draft quickly through the approval process.

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office - 913-762-6736
Mobile - 913-593-6221

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Wednesday, April 02, 2014 11:21 PM
To: dime@ietf.org; dime-chairs@ietf.org
Subject: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02

Folks,

As discussed and agreed (and now verified with our AD), this email starts a two week adoption call for
draft-bertz-dime-congestion-flow-attributes-02 as a Dime WG document.
Express your support or opposition on the mailing list. The call ends 17th April.

Jouni & Lionel

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


________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

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

--------------050305030205050705050006-- From nobody Mon Apr 7 06:41:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832821A0159 for ; Mon, 7 Apr 2014 06:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSvSNb--NwZO for ; Mon, 7 Apr 2014 06:40:58 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id E21501A0411 for ; Mon, 7 Apr 2014 06:40:56 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53048 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WX9my-0007nS-UR for dime@ietf.org; Mon, 07 Apr 2014 06:40:50 -0700 Message-ID: <5342AAD9.9030803@usdonovans.com> Date: Mon, 07 Apr 2014 14:40:41 +0100 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------010100050102000701020908" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4qtzOwcN-vcOeS0CJRRrBM4xrYM Subject: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 13:41:02 -0000 This is a multi-part message in MIME format. --------------010100050102000701020908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I believe that the current definition of the host report needs to be enhanced. The following is what is currently in the -02 draft: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment. This does not address the case where there is no agent between the reacting and reporting nodes. In other words, the reacting node has a direct connection to the reporting node. In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP. I propose that the second paragraph be changed to the following: "The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR. This is the value of the Origin-Host AVP in the message that carried the OLR. There are two cases where the reacting node will know that the request will be routed to the overloaded node. The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR. The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node." Regards, Steve --------------010100050102000701020908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

I believe that the current definition of the host report needs to be enhanced.

The following is what is currently in the -02 draft:

   0  A host report.  The overload treatment should apply to requests
      for which all of the following conditions are true:

      The Destination-Host AVP is present in the request and its value
      matches the value of the Origin-Host AVP of the received message
      that contained the OC-OLR AVP.

      The value of the Destination-Realm AVP in the request matches the
      value of the Origin-Realm AVP of the received message that
      contained the OC-OLR AVP.

      The value of the Application-ID in the Diameter Header of the
      request matches the value of the Application-ID of the Diameter
      Header of the received message that contained the OC-OLR AVP.

The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment.

This does not address the case where there is no agent between the reacting and reporting nodes.  In other words, the reacting node has a direct connection to the reporting node.  In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP.

I propose that the second paragraph be changed to the following:

"The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR.  This is the value of the Origin-Host AVP in the message that carried the OLR.  There are two cases where the reacting node will know that the request will be routed to the overloaded node.  The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR.  The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node."

Regards,

Steve
--------------010100050102000701020908-- From nobody Mon Apr 7 06:57:04 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19AB1A072C for ; Mon, 7 Apr 2014 06:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.812 X-Spam-Level: X-Spam-Status: No, score=0.812 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8kSwxky-ZUu for ; Mon, 7 Apr 2014 06:56:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 555DB1A070E for ; Mon, 7 Apr 2014 06:56:55 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0BE6622C33C; Mon, 7 Apr 2014 15:56:49 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DF14D2380DD; Mon, 7 Apr 2014 15:56:48 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 7 Apr 2014 15:56:48 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 Thread-Index: AQHPUEJ5s8zi20oaj0GL7WO4o9GuuJsGBmUAgAArHJA= Date: Mon, 7 Apr 2014 13:56:48 +0000 Message-ID: <29201_1396879008_5342AEA0_29201_1082_1_6B7134B31289DC4FAF731D844122B36E548BB6@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <533CE1AD.3010407@gmail.com> <69f544d6b08b400bbd3fd8c4e14aab87@PREWE13M04.ad.sprint.com> <5342A63E.4030004@usdonovans.com> In-Reply-To: <5342A63E.4030004@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E548BB6PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/P8euY2cZol99-djbwNvxRqitRVw Subject: Re: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 13:57:02 -0000 --_000_6B7134B31289DC4FAF731D844122B36E548BB6PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As individual, I support this new work item. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 7 avril 2014 15:21 =C0 : dime@ietf.org Objet : Re: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attri= butes-02 I support adoption of this work item. Steve On 4/4/14 3:13 PM, Hirschman, Brent B [CTO] wrote: As an author of this draft, I am in support of this document becoming a wor= king group document. There are three main reasons for promoting it to this= status: 1. These were overlooked items in the creation of RFC5777. In discuss= ions with Avi Lior, one of the authors of that document, he agreed that it = was an oversight not to include it originally. 2. The concept of adding flow and packet AVPs as part of reports is si= mple. This type of reporting is very similar to byte count reporting alrea= dy done in Diameter reporting. 3. Reporting based upon ECN filters can be used not only for managing= real-time congestion at a node in a network, but can also be used for long= er term network planning such as adding capacity or additional nodes to the= network. The authors would appreciate your support in progressing this draft quickly= through the approval process. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Wednesday, April 02, 2014 11:21 PM To: dime@ietf.org; dime-chairs@ietf.org Subject: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attribut= es-02 Folks, As discussed and agreed (and now verified with our AD), this email starts a= two week adoption call for draft-bertz-dime-congestion-flow-attributes-02 as a Dime WG document. Express your support or opposition on the mailing list. The call ends 17th = April. Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E548BB6PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

As individ= ual, I support this new work item.

 = ;

Regards,

 = ;

Lionel

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 7 avril 2014 15:21
=C0 : dime@ietf.org
Objet : Re: [Dime] Adoption call for draft-bertz-dime-congestio= n-flow-attributes-02

 

I support adoption of= this work item.

Steve

On 4/4/14 3:13 PM, Hirschman, Brent B [CTO] wrote:

As an author of this draft, I am in support of this document becoming =
a working group document.  There are three main reasons for promoting =
it to this status:
1.      These were overlooked items in the cr=
eation of RFC5777.  In discussions with Avi Lior, one of the authors o=
f that document, he agreed that it was an oversight not to include it origi=
nally.
2.      The concept of adding flow and packet=
 AVPs as part of reports is simple.  This type of reporting is very si=
milar to byte count reporting already done in Diameter reporting.
3.      Reporting  based upon ECN filter=
s can be used not only for managing real-time congestion at a node in a net=
work, but can also be used for longer term network planning such as adding =
capacity or additional nodes to the network.
 
The authors would appreciate your support in progressing this draft qu=
ickly through the approval process.
 
Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office - 913-762-6736
Mobile - 913-593-6221
 
-----Original Message-----
From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen
Sent: Wednesday, April 02, 2014 11:21 PM
To: dime@ietf.org; dime-chairs@ietf.org
Subject: [Dime] Adoption call for draft-bertz-dime-congestion-flow-att=
ributes-02
 
Folks,
 
As discussed and agreed (and now verified with our AD), this email sta=
rts a two week adoption call for
draft-bertz-dime-congestion-flow-attributes-02 as a Dime WG document.<=
o:p>
Express your support or opposition on the mailing list. The call ends =
17th April.
 
Jouni & Lionel
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime
 
 
________________________________
 
This e-mail may contain Sprint proprietary information intended for th=
e sole use of the recipient(s). Any use by others is prohibited. If you are=
 not the intended recipient, please contact the sender and delete all copie=
s of the message.
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime
 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E548BB6PEXCVZYM13corpora_-- From nobody Mon Apr 7 07:09:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9580A1A0431 for ; Mon, 7 Apr 2014 07:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlh-TA8NQIJk for ; Mon, 7 Apr 2014 07:08:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7951A0794 for ; Mon, 7 Apr 2014 07:08:43 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 19EF81902B5; Mon, 7 Apr 2014 16:08:37 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id F2D8FC8140; Mon, 7 Apr 2014 16:08:36 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 7 Apr 2014 16:07:31 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Definition of host report Thread-Index: AQHPUmcES0lyEHVLxUK4BUr9Vd1zDJsGLomw Date: Mon, 7 Apr 2014 14:07:31 +0000 Message-ID: <28937_1396879717_5342B165_28937_9147_1_6B7134B31289DC4FAF731D844122B36E548C2D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5342AAD9.9030803@usdonovans.com> In-Reply-To: <5342AAD9.9030803@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.7.133016 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gT_e-op5_OJ4KcpIUnDM5oX9ILU Subject: Re: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 14:08:54 -0000 Hi Steve, As defined today, the originator of a Host-based report is the node identif= ied by the Origin-host in the answer. I don't understand what is wrong with= the existing definition in the draft. Please see below. Regards, Lionel De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: lundi 7 avril 2014 15:41 =C0=A0: dime@ietf.org Objet=A0: [Dime] Definition of host report All, I believe that the current definition of the host report needs to be enhanc= ed. The following is what is currently in the -02 draft: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. The second paragraph says that only requests that contain a Destination-Hos= t AVP can be used for overload treatment. This does not address the case where there is no agent between the reacting= and reporting nodes.=A0 [LM] I think you mean: this does ONLY address, right? In other words, the reacting node has a direct connection to the reporting = node.=A0 In this case the reacting node should include all messages that wo= uld be sent to the reporting node, including those that do not contain a De= stination-Host AVP and those that the reacting node would sent to the repor= ting node through normal route selection for requests that do not contain a= Destination-Host AVP. [LM] I'm not sure to understand the reasoning above. Why should a reacting = node include request with no Dest-Host AVP? I propose that the second paragraph be changed to the following: "The reacting node knows that the request will be routed to the overloaded = Diameter node identified by the Diameter ID in the OLR.=A0 This is the valu= e of the Origin-Host AVP in the message that carried the OLR.=A0 There are = two cases where the reacting node will know that the request will be routed= to the overloaded node.=A0 The first is the request contains a Destination= -Host AVP that matches the Diameter ID contained in the OLR.=A0 The second = is when the reacting node selects a route that is a direct connection to th= e overloaded Diameter node." [LM] this is not needed if the Origin-host in the answer is enough to ident= ify which node is overloaded, that is the current assumption in the draft. Regards, Steve ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Apr 7 10:30:10 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEB11A01E0 for ; Mon, 7 Apr 2014 10:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAz_VQzrbGEF for ; Mon, 7 Apr 2014 10:30:05 -0700 (PDT) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by ietfa.amsl.com (Postfix) with ESMTP id D4F551A07BE for ; Mon, 7 Apr 2014 10:30:04 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id v15so723582bkz.33 for ; Mon, 07 Apr 2014 10:29:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NOC7OlXhFx13Ky7OiXng7eAwg9tAVxKDKWyyG6hfOUM=; b=iVP836NfA+xgSH5qlRDES8cJMYQVMIFTny0R2ZeDtlRz8D3lh1d7GOhphU7CVIvdMA 5jVMb9z151/QfqpjgMMyzW3RuWw7jRTikGwGrdmJE3ze52Xl0mEPejINIwStKneGBmUO VsEtfwm3YTY1B85g1IWXo45aCRRU+QYhW8O0CwoeeenJfp9pEx3+tWdHXjHt2P4PWTIe Q1Z4Af2CLA30n0ulJ6JiW5tZe1JDmx5xp5Srfao5iixAC6+oPk9Mx80d7Yx3Mqrd5Ygt 7QSlzWqncenkLZ1vwxLX0xkpwQ47GFUFCvo7XAUXqXQXyLHKwV+z4RGqnw9M2ZQU9I2U ppeQ== X-Gm-Message-State: ALoCoQlTNHoVPDdKYm4mzlnqYvVTCoTB5X4o8OLGRuFiFy1Wtpcg+UJW+ObNvBCUdaCNYybQOx5P X-Received: by 10.204.59.70 with SMTP id k6mr1531078bkh.52.1396891798168; Mon, 07 Apr 2014 10:29:58 -0700 (PDT) Received: from Avis-MacBook-Air.local (CPE5c5948c48b53-CM602ad089cf9c.cpe.net.cable.rogers.com. [99.224.54.118]) by mx.google.com with ESMTPSA id xj2sm17828771bkb.15.2014.04.07.10.29.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 10:29:56 -0700 (PDT) Message-ID: <5342E090.8050003@lior.org> Date: Mon, 07 Apr 2014 13:29:52 -0400 From: Avi Lior User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: "dime@ietf.org" , "dime-chairs@ietf.org" References: <533CE1AD.3010407@gmail.com> <69f544d6b08b400bbd3fd8c4e14aab87@PREWE13M04.ad.sprint.com> In-Reply-To: <69f544d6b08b400bbd3fd8c4e14aab87@PREWE13M04.ad.sprint.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ch7cozCZJu6hPV93-Ut_3OL-ISY Subject: Re: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 17:30:09 -0000 Hi, As an individual I support this document. I have reviewed the work (it extends a previous RFC i have authored), and I think there is a need for this in certain networks. Avi. Hirschman, Brent B [CTO] wrote: > As an author of this draft, I am in support of this document becoming a working group document. There are three main reasons for promoting it to this status: > 1. These were overlooked items in the creation of RFC5777. In discussions with Avi Lior, one of the authors of that document, he agreed that it was an oversight not to include it originally. > 2. The concept of adding flow and packet AVPs as part of reports is simple. This type of reporting is very similar to byte count reporting already done in Diameter reporting. > 3. Reporting based upon ECN filters can be used not only for managing real-time congestion at a node in a network, but can also be used for longer term network planning such as adding capacity or additional nodes to the network. > > The authors would appreciate your support in progressing this draft quickly through the approval process. > > Brent Hirschman > Tech Dev Strategist III > Sprint Corporation > 6220 Sprint Parkway > Overland Park, KS 66251 > Office - 913-762-6736 > Mobile - 913-593-6221 > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Wednesday, April 02, 2014 11:21 PM > To: dime@ietf.org; dime-chairs@ietf.org > Subject: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 > > Folks, > > As discussed and agreed (and now verified with our AD), this email starts a two week adoption call for > draft-bertz-dime-congestion-flow-attributes-02 as a Dime WG document. > Express your support or opposition on the mailing list. The call ends 17th April. > > Jouni & Lionel > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -- Avi Lior ====== h: +1.613.831.9031 m: +1.613.355.7112 From nobody Mon Apr 7 10:58:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186421A0161 for ; Mon, 7 Apr 2014 10:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqrhUVXxDU6B for ; Mon, 7 Apr 2014 10:58:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9C1A04AF for ; Mon, 7 Apr 2014 10:58:48 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A2DE526417A; Mon, 7 Apr 2014 19:58:41 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8996F27C1B3; Mon, 7 Apr 2014 19:58:41 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 7 Apr 2014 19:58:41 +0200 From: To: Benoit Claise , "draft-ietf-dime-app-design-guide.all@tools.ietf.org" Thread-Topic: Diameter Guidelines as BCP? (was: AD review draft-ietf-dime-app-design-guide) Thread-Index: AQHPTlKK04bn8aLKgkqsyndd0aygjpsGeLuQ Date: Mon, 7 Apr 2014 17:58:40 +0000 Message-ID: <24395_1396893521_5342E751_24395_4614_1_6B7134B31289DC4FAF731D844122B36E54AE2F@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> In-Reply-To: <533BD276.7000401@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E54AE2FPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.7.63014 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/o-HExvNc70RWX9zy3yYp5chF1NU Cc: dime mailing list Subject: [Dime] Diameter Guidelines as BCP? (was: AD review draft-ietf-dime-app-design-guide) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 17:58:54 -0000 --_000_6B7134B31289DC4FAF731D844122B36E54AE2FPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Benoit, Defining this document as BCP makes sense. Any other feedback from the working group before modifying the objective of= this document? Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Benoit Claise Envoy=E9 : mercredi 2 avril 2014 11:04 =C0 : draft-ietf-dime-app-design-guide.all@tools.ietf.org Cc : dime mailing list Objet : [Dime] AD review draft-ietf-dime-app-design-guide Dear authors, Sorry for dropping the ball on this one. If any of the points was already discussed/addressed by the WG, feel free t= o let me know. - When I read the document, it looked to me as a BCP. BCP definition from RFC 2026: 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. Interestingly, the charter mentions: May 2012, Submit 'Diameter Application Design Guidelines' to the IESG for c= onsideration as a BCP document If you go to BCP, don't forget to update the abstract, and the writeup. Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013) Example: OLD: Diameter protocol designers are then strongly advised to carefully consider NEW: Diameter protocol designers SHOULD NOT consider OLD: Instead of using an Enumerated AVP for a Boolean flag, protocol designers are again encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which the data field would be defined as NEW: Instead of using an Enumerated AVP for a Boolean flag, protocol designers SHOULD use AVPs of type Unsigned32 or Unsigned64 AVP in which the data field would be defined as Finally, with a BCP, RFC 6733 could be a normative reference, which I belie= ve it should. - Editorial Please don't use "we" in RFCs - Section 3 Major Extension: Enhancing an application that requires the definition of a new Diameter application. Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new AVP with the M-bit set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. Do you want to mention that Major Extension have backward compatibility iss= ue, as opposed to the minor one? - Editorial Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new AVP with the M-bit set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. NEW: Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new mandatory AVP set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. Justification: * Minor extension speaks about "optional" * The M-bit is explained in 4.3.1 - Section 3 I see Minor Extension versus Major Extension, and I tried to match the foll= owing classifications to Minor or Major 1. Addition of new functionality to an existing Diameter application without defining a new application. 2. Addition of new functionality to an existing Diameter application that requires the definition of a new application. 3. The definition of an entirely new Diameter application to offer functionality not supported by existing applications. 4. The definition of a new generic functionality that can be reused across different applications. 2 and 3 are Major For 1, I thought about Minor, but the following sentence "or the definition= of a new AVP with the M-bit set to be carried in an existing command." in = the Major paragraph confuses me. I guess that 4 is Major, but it's not mentioned. Can you please better explain the mapping between the 4 categories and Mino= r/Major extensions Alternatively, or maybe on top of that, explain which of 4.X and 5.X are Mi= nor/Major extensions would be beneficial. - Section 3 I don't understand what your message is with: We would also like to remind that the definition of a new Diameter application and the definition of a new command should be something to avoid as much as possible. In the past, there has been some reluctance to define new commands and new applications. With the modified extensibility rules provided by [RFC6733], registering new commands and new applications does not lead to additional overhead for the specification author in terms of standardization process. Registering new functionality (new commands, new AVPs, new applications, etc.) with IANA remains important to avoid namespace collisions, which will likely lead to deployment problems. "should be something to avoid as much as possible", is this valid today? Because the next sentence speaks about the past, then the next sentence see= ms like it's fixed now with 6733. - Editorial: With the modified extensibility rules provided by [RFC6733], registering new commands and new applications does not lead to additional overhead for the specification author in terms of standardization process. Registering new functionality (new commands, new AVPs, new applications, etc.) "etc.": What does it refer to? new AVP value is the only one I can think of. Worth removing "etc." and specifying the full list? - Application and command Major Extension: Enhancing an application that requires the definition of a new Diameter application. Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new AVP with the M-bit set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. 4.1. Adding a New Command Adding a new command is considered as a major extension and requires a new Diameter application to be defined. I'm not clear on the application/command boundary. Why do we need a new application for a new command? Why can't I add a command to an existing application? There are commands that are for all applications/independent of the applica= tion, no? CER/CEA (Capabilities-Exchange-Request) This contradicts: Before adding or importing a command, application designers should consider the following ... This also appears to contradict, in section 6 Generic Diameter extensions are AVPs, commands or applications that are designed to support other Diameter applications. My issue comes from the fact that there are no "application" and "command" = definitions. Draft says: 2= . Terminology This document reuses the terminology defined in [RFC6733] However, RFC 6733 terminology doesn't contain the application and command d= efinitions. Talking to Jouni, I now understand that a command is always specified withi= n the context of an application. This should be clarified. Also, from section 5.2: As a general recommendation, commands should not be defined from scratch. It is instead recommend to re-use an existing command offering similar functionality and use it as a starting point. Based on my latest understanding (a command is always specified within the = context of an application), the only justification for the above text is co= de reuse, right. Please mention it. - Editorial Adding a new command is considered as a major extension and requires a new Diameter application to be defined. Adding a new command to an application means ... A new command addition is always to an application, right? If yes, why do you make the distinction between the sentences above - Application version? An exception might be if the intent of the deletion is to create a newer version of the same application that is somehow simpler than the previous version. ... o Would the new AVP be used to differentiate between old and new versions of the same application whereby the two versions are not backward compatible? Readers might be understanding that diameter applications having a version = field. This is not the case. Please rephrase. Also, mention that a new version of an application is a new application. I guess it needs to be mentioned in 7.d - Section 4.3.2 For the reader convenience, I would mention the convention behind { AVP } a= nd [ AVP ], or at least give a reference. - Section 5.3 OLD: Some existing specifications do not adhere to this rule for historical reasons. However, this guidance should be followed to avoid routing problems. NEW: Some existing specifications do not adhere to this rule for historical reasons. However, this guidance should be followed for new applications to avoid = routing problems. In the same section, why "In general" in the next sentence? It contradicts = with "must use" In general, when a new application has been allocated with a new Application Id and it also reuses existing commands with or without modifications, it must use the newly allocated Application Id in the header and in all relevant Application Id AVPs (Auth-Application-Id or Acct-Application-Id) present in the commands message body. - Editorial, section 5.5 OLD: Based on these considerations, protocol designers should carefully appraise whether the application currently defined relies on it's own session management concept or whether NEW: Based on these considerations, protocol designers should carefully appraise whether the application currently defined relies on its own session management concept or whether - Editorial in section 5.7 OLD: Destination- Realm NEW: Destination-Realm - The section 5.8 should mention RFC4005bis - Section 5.9 Applications that do not understand these AVPs can discard them upon receipt. Generic comment: Each time there is a sentence like this one above, we shou= ld mention RFC 6733 as the reference. This document is not an extension/deviation to RFC 6733. - Do you have a good reason to add a reference to a work-in-progress that d= idn't progress since 2001? [I-D.calhoun-diameter-res-mgmt] Calhoun, P., "Diameter Resource Management Extensions", draft-calhoun-diameter-res-mgmt-08.txt (work in progress), March 2001. - Editorial (section 6) I can't parse the following sentence: Backward Compatibility: With the design of generic extensions an protocol designer has to consider with potential concerns about how existing applications deal with the new extension they do not understand. - Contributors: If Victor and Hannes are authors, then they shouldn't be in the contributor= s list. Btw, I don't see an affiliation for Victor in the document header. I believ= e the common practice is to write down "consultant" Did the WG ever considered the following questions: - Any naming convention for new applications? - When it is not a good idea to define diameter applications? Let me make s= omething up: to push syslog message Regards, Benoit ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E54AE2FPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Benoit,

 <= /p>

Defining t= his document as BCP makes sense.

Any other = feedback from the working group before modifying the objective of this docu= ment?

 = ;

Regards,

 = ;

Lionel

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Benoit Claise
Envoy=E9 : mercredi 2 avril 2014 11:04
=C0 : draft-ietf-dime-app-design-guide.all@tools.ietf.org
Cc : dime mailing list
Objet : [Dime] AD review draft-ietf-dime-app-design-guide<= /o:p>

 

Dear authors,

Sorry for dropping the ball on this one.
If any of the points was already discussed/addressed by the WG, feel free t= o let me know.



- When I read the document, it looked to me as a BCP.

BCP definition from RFC 2026:

5.  BEST CURRENT PRACTICE (BCP) RFCs
 
   The BCP subseries of the RFC series is designed to be a w=
ay to
   standardize practices and the results of community delibe=
rations.

Interestingly, the charter mentions:

May 2012, Submit 'Diameter Application Design Guidel= ines' to the IESG for consideration as a BCP document


If you go to BCP, don't forget to update the abstract, and the writeup.
Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013)
Example:
OLD:

Diameter
protocol designers are then strongly advised to carefully consider

NEW:

   Diameter
   protocol designers SHOULD NOT consider
 

OLD:

   Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers =
are again
   encouraged to use AVPs of type Unsigned32 or Unsigned64 A=
VP in which
   the data field would be defined as


NEW:

   Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers =
SHOULD 
   use AVPs of type Unsigned32 or Unsigned64 AVP in whi=
ch
   the data field would be defined as

Finally, with a BCP, RFC 6733 could be a normative r= eference, which I believe it should.


- Editorial
Please don't use "we" in RFCs

-
Section 3

  Major Extension:  Enhancing an application that requires t=
he
      definition of a new Diameter applicatio=
n.
 
      Typical examples would be the creation =
of a new command for
      providing functionality not supported b=
y existing applications or
      the definition of a new AVP with the M-=
bit set to be carried in an
      existing command.  For such extens=
ion, a significant specification
      effort is required and a careful approa=
ch is recommended.

Do you want to mention that Major Extension have bac= kward compatibility issue, as opposed to the minor one?

- Editorial

      Typical examples would be the creation =
of a new command for
      providing functionality not supported b=
y existing applications or
      the definition of a new AVP with the M-=
bit set to be carried in an
      existing command.  For such extens=
ion, a significant specification
      effort is required and a careful approa=
ch is recommended.

NEW:

      Typical examples would be the creation =
of a new command for
      providing functionality not supported b=
y existing applications or
      the definition of a new mandatory AVP s=
et to be carried in an
      existing command.  For such extens=
ion, a significant specification
      effort is required and a careful approa=
ch is recommended.

Justification:

        * Minor extension speaks ab=
out "optional"
        * The M-bit is explained in=
 4.3.1
 


- Section 3
I see Minor Extension versus Major Extension, and I tried to match the foll= owing classifications to Minor or Major

   1.  Addition of new functionality to an existing Dia=
meter application
       without defining a new applicatio=
n.
 
   2.  Addition of new functionality to an existing Dia=
meter application
       that requires the definition of a=
 new application.
 
   3.  The definition of an entirely new Diameter appli=
cation to offer
       functionality not supported by ex=
isting applications.
 
   4.  The definition of a new generic functionality th=
at can be reused
       across different applications.

2 and 3 are Major
For 1, I thought about Minor, but the following sentence "or the defin= ition of a new AVP with the M-bit set to be carried in an existing command.= " in the Major paragraph confuses me.
I guess that 4 is Major, but it's not mentioned.
Can you please better explain the mapping between the 4 categories and Mino= r/Major extensions
Alternatively, or maybe on top of that, explain which of 4.X and 5.X are Mi= nor/Major extensions would be beneficial.

- Section 3
I don't understand what your message is with:

   We would also like to remind that the definition of a new=
 Diameter
   application and the definition of a new command should be=
 something
   to avoid as much as possible.  In the past, there ha=
s been some
   reluctance to define new commands and new applications.&n=
bsp; With the
   modified extensibility rules provided by ["should be something to avoid as much as possib=
le", is this valid today?

Because the next sentence speaks about the past, then the next sentence see=
ms like it's fixed now with 6733.




- Editorial:


   With the


   modified extensibility rules provided by ["etc.": Wha=
t does it refer to? new AVP value is the only one I can think of.

Worth removing "etc." and specifying the full list?





- Application and command


   Major Extension:  Enhancing an application that requ=
ires the


      definition of a new Diameter application.


 


      Typical examples would be the creation =
of a new command for


      providing functionality not supported b=
y existing applications or


      the definition of a new AVP with the M-=
bit set to be carried in an


      existing command.  For such extens=
ion, a significant specification


      effort is required and a careful approa=
ch is recommended.


4.1.  Adding a New Command


   Adding a new command is considered as a major extension a=
nd requires


   a new Diameter application to be defined.


I'm not clear on the application/command boundary.
Why do we need a new application for a new command?

Why can't I add a command to an existing application?

There are commands that are for all applications/independent of the applica=
tion, no?

    CER/CEA (Capabilities-Exchange-Request)

This contradicts:


   Before adding or importing a command, application =
designers


   should consider the following ...


 


This also appears to contradict, in section 6


   Generic Diameter extensions are AVPs, commands or applica=
tions that


   are designed to support other Diameter applications.


 


My issue comes from the fact that there are no "=
;application" and "command" definitions.

Draft says:


2.  Terminology


   This document reuses the terminology defined in [RFC6733]


However, RFC 6733 terminology doesn't contain the ap=
plication and command definitions.

Talking to Jouni, I now understand that a command is always specified withi=
n the context of an application.

This should be clarified.



Also, from section 5.2:


   As a general recommendation, commands should not be defin=
ed from


   scratch.  It is instead recommend to re-use an exist=
ing command


   offering similar functionality and use it as a starting p=
oint.


Based on my latest understanding (a command is alway=
s specified within the context of an application), the only justification f=
or the above text is code reuse, right. Please mention it.



- Editorial


   Adding a new command is considered as a major extension a=
nd requires


   a new Diameter application to be defined.  Adding a =
new command to an


   application means ...


A new command addition is always to an application, =
right?

If yes, why do you make the distinction between the sentences above



- Application version?


An exception might be if the


   intent of the deletion is to create a newer version of th=
e same


   application that is somehow simpler than the previous ver=
sion.


   &nb=
sp;    ...


   o  Would the new AVP be used to differentiate betwee=
n old and new


      versions of the same application whereb=
y the two versions are not


      backward compatible?


Readers might be understanding that diameter applica=
tions having a version field.

This is not the case. Please rephrase.

Also, mention that a new version of an application is a new application.

I guess it needs to be mentioned in 7.d





- Section 4.3.2

For the reader convenience, I would mention the convention behind { AVP } a=
nd [ AVP ], or at least give a reference.



- Section 5.3

OLD:


   Some existing


   specifications do not adhere to this rule for historical =
reasons.


   However, this guidance should be followed to avoid routin=
g problems.


 


NEW:


   Some existing


   specifications do not adhere to this rule for historical =
reasons.


   However, this guidance should be followed for new applica=
tions to avoid routing problems.




In the same section, why "In general" in the next sentence? It co=
ntradicts with "must use"


In general, when a new application has been allocated with a new<=
/o:p>


   Application Id and it also reuses existing commands with =
or without


   modifications, it must use the newly allocated Applicatio=
n Id in the


   header and in all relevant Application Id AVPs (Auth-Appl=
ication-Id


   or Acct-Application-Id) present in the commands message b=
ody.




- Editorial, section 5.5


OLD: 


   Based on these considerations, protocol designers sh=
ould carefully


   appraise whether the application currently defined relies=
 on it's own


   session management concept or whether 


 


NEW:


   Based on these considerations, protocol designers should =
carefully


   appraise whether the application currently defined relies=
 on its own


   session management concept or whether 




- Editorial in section 5.7

OLD:


Destination- Realm


 


NEW:


Destination-Realm






- The section 5.8 should mention RFC4005bis



- Section 5.9


 Applications that do not understand these AVPs can discard=



   them upon receipt. 


Generic comment: Each time there is a sentence like =
this one above, we should mention RFC 6733 as the reference.

This document is not an extension/deviation to RFC 6733.



- Do you have a good reason to add a reference to a work-in-progress that d=
idn't progress since 2001?


   [I-D.calhoun-diameter-res-mgmt]


           &nbs=
p;  Calhoun, P., "Diameter Resource Management Extensions",<=
o:p>


           &nbs=
p;  draft-calhoun-diameter-res-mgmt-08.txt (work in progress),<=
o:p>


           &nbs=
p;  March 2001.




- Editorial (section 6)

I can't parse the following sentence:


 Backward Compatibility:


 


      With the design of generic extensions a=
n protocol designer has to


      consider with potential concerns about =
how existing applications


      deal with the new extension they do not=
 understand. 




- Contributors:

If Victor and Hannes are authors, then they shouldn't be in the contributor=
s list.

Btw, I don't see an affiliation for Victor in the document header. I believ=
e the common practice is to write down "consultant"



Did the WG ever considered the following questions:

- Any naming convention for new applications?

- When it is not a good idea to define diameter applications? Let me make s=
omething up: to push syslog message



Regards, Benoit


 







 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E54AE2FPEXCVZYM13corpora_-- From nobody Mon Apr 7 14:29:59 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4521A02D2 for ; Mon, 7 Apr 2014 14:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J3xVYYBZNvX for ; Mon, 7 Apr 2014 14:29:52 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF91A02CD for ; Mon, 7 Apr 2014 14:29:52 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57511 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WXH6q-0002B3-Id; Mon, 07 Apr 2014 14:29:45 -0700 Message-ID: <534318C7.1060502@usdonovans.com> Date: Mon, 07 Apr 2014 16:29:43 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <5342AAD9.9030803@usdonovans.com> <28937_1396879717_5342B165_28937_9147_1_6B7134B31289DC4FAF731D844122B36E548C2D@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <28937_1396879717_5342B165_28937_9147_1_6B7134B31289DC4FAF731D844122B36E548C2D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------080903000002030701060706" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/njrlm8jqqK7Prn1TjnuO7nxZfq0 Subject: Re: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 21:29:57 -0000 This is a multi-part message in MIME format. --------------080903000002030701060706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lionel, Please see inline. Steve On 4/7/14 9:07 AM, lionel.morand@orange.com wrote: > Hi Steve, > > As defined today, the originator of a Host-based report is the node identified by the Origin-host in the answer. I don't understand what is wrong with the existing definition in the draft. > > Please see below. > > Regards, > > Lionel > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoyé : lundi 7 avril 2014 15:41 > À : dime@ietf.org > Objet : [Dime] Definition of host report > > All, > > I believe that the current definition of the host report needs to be enhanced. > > The following is what is currently in the -02 draft: > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > > The value of the Destination-Realm AVP in the request matches the > value of the Origin-Realm AVP of the received message that > contained the OC-OLR AVP. > > The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > > The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment. > > This does not address the case where there is no agent between the reacting and reporting nodes. > [LM] I think you mean: this does ONLY address, right? SRD> No, I mean the case where a client is connected directly to a set of servers. One of the servers becomes overloaded and sends a host report. The server is telling clients to reduce the traffic sent to it by x%. The client selects a route for the request. Any request that would be routed to the connection to the server should be a candidate for overload treatment. If this is not the case then how do you protect a server for an application that has 100% realm routed requests? > > In other words, the reacting node has a direct connection to the reporting node. In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP. > [LM] I'm not sure to understand the reasoning above. Why should a reacting node include request with no Dest-Host AVP? SRD> Because there is nothing else in the network that can manage that traffic. > > I propose that the second paragraph be changed to the following: > > "The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR. This is the value of the Origin-Host AVP in the message that carried the OLR. There are two cases where the reacting node will know that the request will be routed to the overloaded node. The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR. The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node." > [LM] this is not needed if the Origin-host in the answer is enough to identify which node is overloaded, that is the current assumption in the draft. > > Regards, > > Steve > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > --------------080903000002030701060706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lionel,

Please see inline.

Steve
On 4/7/14 9:07 AM, lionel.morand@orange.com wrote:
Hi Steve,

As defined today, the originator of a Host-based report is the node identified by the Origin-host in the answer. I don't understand what is wrong with the existing definition in the draft.

Please see below.

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 7 avril 2014 15:41
À : dime@ietf.org
Objet : [Dime] Definition of host report

All,

I believe that the current definition of the host report needs to be enhanced.

The following is what is currently in the -02 draft:
   0  A host report.  The overload treatment should apply to requests
      for which all of the following conditions are true:

      The Destination-Host AVP is present in the request and its value
      matches the value of the Origin-Host AVP of the received message
      that contained the OC-OLR AVP.

      The value of the Destination-Realm AVP in the request matches the
      value of the Origin-Realm AVP of the received message that
      contained the OC-OLR AVP.

      The value of the Application-ID in the Diameter Header of the
      request matches the value of the Application-ID of the Diameter
      Header of the received message that contained the OC-OLR AVP.

The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment.

This does not address the case where there is no agent between the reacting and reporting nodes. 
[LM] I think you mean: this does ONLY address, right?
SRD> No, I mean the case where a client is connected directly to a set of servers.  One of the servers becomes overloaded and sends a host report.  The server is telling clients to reduce the traffic sent to it by x%.  The client selects a route for the request.  Any request that would be routed to the connection to the server should be a candidate for overload treatment.  If this is not the case then how do you protect a server for an application that has 100% realm routed requests?

In other words, the reacting node has a direct connection to the reporting node.  In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP.
[LM] I'm not sure to understand the reasoning above. Why should a reacting node include request with no Dest-Host AVP?
SRD> Because there is nothing else in the network that can manage that traffic.

I propose that the second paragraph be changed to the following:

"The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR.  This is the value of the Origin-Host AVP in the message that carried the OLR.  There are two cases where the reacting node will know that the request will be routed to the overloaded node.  The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR.  The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node."
[LM] this is not needed if the Origin-host in the answer is enough to identify which node is overloaded, that is the current assumption in the draft.

Regards,

Steve

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------080903000002030701060706-- From nobody Tue Apr 8 00:38:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330DB1A0168 for ; Tue, 8 Apr 2014 00:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_YDEn9LCCia for ; Tue, 8 Apr 2014 00:38:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id F3F651A0143 for ; Tue, 8 Apr 2014 00:38:19 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s387cDPP014755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Apr 2014 07:38:13 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s387cCNw002429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 09:38:12 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 8 Apr 2014 09:38:12 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.65]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 09:38:12 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Definition of host report Thread-Index: AQHPUmcExmbK8hK+6kuc9JeDZTxITZsHUAcg Date: Tue, 8 Apr 2014 07:38:12 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3@DEMUMBX014.nsn-intra.net> References: <5342AAD9.9030803@usdonovans.com> In-Reply-To: <5342AAD9.9030803@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3DEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 13422 X-purgate-ID: 151667::1396942693-00001564-43654412/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/clocF2X-knMoV_tMeXQmu2qJP3k Subject: Re: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 07:38:25 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3DEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, I tend to agree. However, wouldn't this mean that also the current definition of realm repor= t (which actually is RRR) needs to be enhanced? e.g. replace The Destination-Host AVP is absent in the request. with something like "The reacting node does not know to which Diameter Host the request will be= routed." I was also wondering if there may be cases where a) the reacting node selects the host, detects that it has a direct connect= ion to that host and therefore does not include the Destination-Host AVP in= the request. The selected host, however, when receiving the Destination-Ho= st-less request decides to forward the request to another host. Or b) the reacting node does not select a host and therefore does not include = a Destination-Host AVP, but sends the request to the next hop, which happen= s to be a Host that decides to handle the request. Are those cases valid and covered? Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Monday, April 07, 2014 3:41 PM To: dime@ietf.org Subject: [Dime] Definition of host report All, I believe that the current definition of the host report needs to be enhanc= ed. The following is what is currently in the -02 draft: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. The second paragraph says that only requests that contain a Destination-Hos= t AVP can be used for overload treatment. This does not address the case where there is no agent between the reacting= and reporting nodes. In other words, the reacting node has a direct conne= ction to the reporting node. In this case the reacting node should include= all messages that would be sent to the reporting node, including those tha= t do not contain a Destination-Host AVP and those that the reacting node wo= uld sent to the reporting node through normal route selection for requests = that do not contain a Destination-Host AVP. I propose that the second paragraph be changed to the following: "The reacting node knows that the request will be routed to the overloaded = Diameter node identified by the Diameter ID in the OLR. This is the value = of the Origin-Host AVP in the message that carried the OLR. There are two = cases where the reacting node will know that the request will be routed to = the overloaded node. The first is the request contains a Destination-Host = AVP that matches the Diameter ID contained in the OLR. The second is when = the reacting node selects a route that is a direct connection to the overlo= aded Diameter node." Regards, Steve --_000_5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3DEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,

I tend to = agree.

However, w= ouldn’t this mean that also the current definition of realm report (w= hich actually is RRR) needs to be enhanced?

 = ;

e.g. repla= ce

The Destination-Host AVP is absent in the r= equest.<= /p>

 = ;

with somet= hing like

"The reacting node does no= t know to which Diameter Host the request will be routed.” 

 

I was also wondering if there m= ay be cases where

a) the reacting node selects th= e host, detects that it has a direct connection to that host and therefore = does not include the Destination-Host AVP in the request. The selected host= , however, when receiving the Destination-Host-less request decides to forward the request to another host. Or

b) the reacting node does not s= elect a host and therefore does not include a Destination-Host AVP, but sen= ds the request to the next hop, which happens to be a Host that decides to = handle the request.

 

 

Are those cases valid and cover= ed?

 

Ulrich

 

 = ;

 = ;

 = ;

 = ;

From:= DiME [mailto:dime-b= ounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, April 07, 2014 3:41 PM
To: dime@ietf.org
Subject: [Dime] Definition of host report

 

All,

I believe that the current definition of the host report needs to be enhanc= ed.

The following is what is currently in the -02 draft:

   0  A host report.  The overload treatment shoul=
d apply to requests
      for which all of the following conditio=
ns are true:
 
      The Destination-Host AVP is present in =
the request and its value
      matches the value of the Origin-Host AV=
P of the received message
      that contained the OC-OLR AVP.
 
      The value of the Destination-Realm AVP =
in the request matches the
      value of the Origin-Realm AVP of the re=
ceived message that
      contained the OC-OLR AVP.

 


      The value of the Application-ID in the =
Diameter Header of the


      request matches the value of the Applic=
ation-ID of the Diameter


      Header of the received message that con=
tained the OC-OLR AVP.




The second paragraph says that only requests that contain a Destination-Hos=
t AVP can be used for overload treatment.



This does not address the case where there is no agent between the reacting=
 and reporting nodes.  In other words, the reacting node has a direct =
connection to the reporting node.  In this case the reacting node shou=
ld include all messages that would be sent
 to the reporting node, including those that do not contain a Destination-H=
ost AVP and those that the reacting node would sent to the reporting node t=
hrough normal route selection for requests that do not contain a Destinatio=
n-Host AVP.



I propose that the second paragraph be changed to the following:



"The reacting node knows that the request will be routed to the overlo=
aded Diameter node identified by the Diameter ID in the OLR.  This is =
the value of the Origin-Host AVP in the message that carried the OLR. =
 There are two cases where the reacting node will
 know that the request will be routed to the overloaded node.  The fir=
st is the request contains a Destination-Host AVP that matches the Diameter=
 ID contained in the OLR.  The second is when the reacting node select=
s a route that is a direct connection to the
 overloaded Diameter node."



Regards,



Steve
--_000_5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3DEMUMBX014nsnin_-- From nobody Tue Apr 8 05:21:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9221A0387 for ; Tue, 8 Apr 2014 05:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqUzUnJHvi2W for ; Tue, 8 Apr 2014 05:20:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id A6D7E1A0228 for ; Tue, 8 Apr 2014 05:20:36 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id AAAC83742EC; Tue, 8 Apr 2014 14:20:35 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 911081800A0; Tue, 8 Apr 2014 14:20:35 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 8 Apr 2014 14:20:35 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Definition of host report Thread-Index: AQHPUqiD40GtsuX80E2Kxe3h4DRr4JsHZV8g Date: Tue, 8 Apr 2014 12:20:34 +0000 Message-ID: <7558_1396959635_5343E993_7558_7400_1_6B7134B31289DC4FAF731D844122B36E54C514@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5342AAD9.9030803@usdonovans.com> <28937_1396879717_5342B165_28937_9147_1_6B7134B31289DC4FAF731D844122B36E548C2D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <534318C7.1060502@usdonovans.com> In-Reply-To: <534318C7.1060502@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.8.91220 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/HdDC9UExfrIcyCkF9IDl9n_HV4A Subject: Re: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 12:20:43 -0000 Hi Steve, I understand your point now. Thank you for the clarification. However, I don't think that it leads necessarily to the need for a Diameter= Id in the OLR. The clarification could be that, in case of direct connection between clien= ts and servers, the Host report type applies also to the peer connection fo= r which the peer id is equal to the origin-host in the answer containing th= e OLR. Such binding is required and the Diameter Id in the OLR will not pro= vide added-value compared to the origin-host of the answer. Regards,=20 Lionel De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: lundi 7 avril 2014 23:30 =C0=A0: MORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: Re: [Dime] Definition of host report Lionel, Please see inline. Steve On 4/7/14 9:07 AM, lionel.morand@orange.com wrote: Hi Steve, As defined today, the originator of a Host-based report is the node identif= ied by the Origin-host in the answer. I don't understand what is wrong with= the existing definition in the draft. Please see below. Regards, Lionel De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: lundi 7 avril 2014 15:41 =C0=A0: dime@ietf.org Objet=A0: [Dime] Definition of host report All, I believe that the current definition of the host report needs to be enhanc= ed. The following is what is currently in the -02 draft: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. The second paragraph says that only requests that contain a Destination-Hos= t AVP can be used for overload treatment. This does not address the case where there is no agent between the reacting= and reporting nodes.=A0 [LM] I think you mean: this does ONLY address, right? SRD> No, I mean the case where a client is connected directly to a set of s= ervers.=A0 One of the servers becomes overloaded and sends a host report.= =A0 The server is telling clients to reduce the traffic sent to it by x%.= =A0 The client selects a route for the request.=A0 Any request that would b= e routed to the connection to the server should be a candidate for overload= treatment.=A0 If this is not the case then how do you protect a server for= an application that has 100% realm routed requests? In other words, the reacting node has a direct connection to the reporting = node.=A0 In this case the reacting node should include all messages that wo= uld be sent to the reporting node, including those that do not contain a De= stination-Host AVP and those that the reacting node would sent to the repor= ting node through normal route selection for requests that do not contain a= Destination-Host AVP. [LM] I'm not sure to understand the reasoning above. Why should a reacting = node include request with no Dest-Host AVP? SRD> Because there is nothing else in the network that can manage that traf= fic. I propose that the second paragraph be changed to the following: "The reacting node knows that the request will be routed to the overloaded = Diameter node identified by the Diameter ID in the OLR.=A0 This is the valu= e of the Origin-Host AVP in the message that carried the OLR.=A0 There are = two cases where the reacting node will know that the request will be routed= to the overloaded node.=A0 The first is the request contains a Destination= -Host AVP that matches the Diameter ID contained in the OLR.=A0 The second = is when the reacting node selects a route that is a direct connection to th= e overloaded Diameter node." [LM] this is not needed if the Origin-host in the answer is enough to ident= ify which node is overloaded, that is the current assumption in the draft. Regards, Steve ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Apr 8 06:07:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9C71A03B1 for ; Tue, 8 Apr 2014 06:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CArrx7RUVFtF for ; Tue, 8 Apr 2014 06:07:02 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4131A03B3 for ; Tue, 8 Apr 2014 06:07:01 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59512 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WXVjs-00053a-T4; Tue, 08 Apr 2014 06:07:00 -0700 Message-ID: <5343F470.50808@usdonovans.com> Date: Tue, 08 Apr 2014 08:06:56 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <5342AAD9.9030803@usdonovans.com> <28937_1396879717_5342B165_28937_9147_1_6B7134B31289DC4FAF731D844122B36E548C2D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <534318C7.1060502@usdonovans.com> <7558_1396959635_5343E993_7558_7400_1_6B7134B31289DC4FAF731D844122B36E54C514@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <7558_1396959635_5343E993_7558_7400_1_6B7134B31289DC4FAF731D844122B36E54C514@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------060807070905040308010104" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xwQKicTOYwyoEHHf1GEUBOnpigU Subject: Re: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 13:07:06 -0000 This is a multi-part message in MIME format. --------------060807070905040308010104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lionel, I'm not proposing adding an AVP to the overload report. I should have said the Diameter ID in the overload control state. I agree completely that the Diameter ID comes from the Origin-Host AVP in the answer message containing the OLR. Regards, Steve On 4/8/14 7:20 AM, lionel.morand@orange.com wrote: > Hi Steve, > > I understand your point now. Thank you for the clarification. > > However, I don't think that it leads necessarily to the need for a Diameter Id in the OLR. > > The clarification could be that, in case of direct connection between clients and servers, the Host report type applies also to the peer connection for which the peer id is equal to the origin-host in the answer containing the OLR. Such binding is required and the Diameter Id in the OLR will not provide added-value compared to the origin-host of the answer. > > Regards, > > Lionel > > > De : Steve Donovan [mailto:srdonovan@usdonovans.com] > Envoyé : lundi 7 avril 2014 23:30 > À : MORAND Lionel IMT/OLN; dime@ietf.org > Objet : Re: [Dime] Definition of host report > > Lionel, > > Please see inline. > > Steve > On 4/7/14 9:07 AM, lionel.morand@orange.com wrote: > Hi Steve, > > As defined today, the originator of a Host-based report is the node identified by the Origin-host in the answer. I don't understand what is wrong with the existing definition in the draft. > > Please see below. > > Regards, > > Lionel > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoyé : lundi 7 avril 2014 15:41 > À : dime@ietf.org > Objet : [Dime] Definition of host report > > All, > > I believe that the current definition of the host report needs to be enhanced. > > The following is what is currently in the -02 draft: > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > > The value of the Destination-Realm AVP in the request matches the > value of the Origin-Realm AVP of the received message that > contained the OC-OLR AVP. > > The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > > The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment. > > This does not address the case where there is no agent between the reacting and reporting nodes. > [LM] I think you mean: this does ONLY address, right? > SRD> No, I mean the case where a client is connected directly to a set of servers. One of the servers becomes overloaded and sends a host report. The server is telling clients to reduce the traffic sent to it by x%. The client selects a route for the request. Any request that would be routed to the connection to the server should be a candidate for overload treatment. If this is not the case then how do you protect a server for an application that has 100% realm routed requests? > > In other words, the reacting node has a direct connection to the reporting node. In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP. > [LM] I'm not sure to understand the reasoning above. Why should a reacting node include request with no Dest-Host AVP? > SRD> Because there is nothing else in the network that can manage that traffic. > > > > I propose that the second paragraph be changed to the following: > > "The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR. This is the value of the Origin-Host AVP in the message that carried the OLR. There are two cases where the reacting node will know that the request will be routed to the overloaded node. The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR. The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node." > [LM] this is not needed if the Origin-host in the answer is enough to identify which node is overloaded, that is the current assumption in the draft. > > Regards, > > Steve > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > --------------060807070905040308010104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lionel,

I'm not proposing adding an AVP to the overload report.  I should have said the Diameter ID in the overload control state.  I agree completely that the Diameter ID comes from the Origin-Host AVP in the answer message containing the OLR.

Regards,

Steve
On 4/8/14 7:20 AM, lionel.morand@orange.com wrote:
Hi Steve,

I understand your point now. Thank you for the clarification.

However, I don't think that it leads necessarily to the need for a Diameter Id in the OLR.

The clarification could be that, in case of direct connection between clients and servers, the Host report type applies also to the peer connection for which the peer id is equal to the origin-host in the answer containing the OLR. Such binding is required and the Diameter Id in the OLR will not provide added-value compared to the origin-host of the answer.

Regards, 

Lionel


De : Steve Donovan [mailto:srdonovan@usdonovans.com] 
Envoyé : lundi 7 avril 2014 23:30
À : MORAND Lionel IMT/OLN; dime@ietf.org
Objet : Re: [Dime] Definition of host report

Lionel,

Please see inline.

Steve
On 4/7/14 9:07 AM, lionel.morand@orange.com wrote:
Hi Steve,

As defined today, the originator of a Host-based report is the node identified by the Origin-host in the answer. I don't understand what is wrong with the existing definition in the draft.

Please see below.

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 7 avril 2014 15:41
À : dime@ietf.org
Objet : [Dime] Definition of host report

All,

I believe that the current definition of the host report needs to be enhanced.

The following is what is currently in the -02 draft:
   0  A host report.  The overload treatment should apply to requests
      for which all of the following conditions are true:

      The Destination-Host AVP is present in the request and its value
      matches the value of the Origin-Host AVP of the received message
      that contained the OC-OLR AVP.

      The value of the Destination-Realm AVP in the request matches the
      value of the Origin-Realm AVP of the received message that
      contained the OC-OLR AVP.

      The value of the Application-ID in the Diameter Header of the
      request matches the value of the Application-ID of the Diameter
      Header of the received message that contained the OC-OLR AVP.

The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment.

This does not address the case where there is no agent between the reacting and reporting nodes. 
[LM] I think you mean: this does ONLY address, right?
SRD> No, I mean the case where a client is connected directly to a set of servers.  One of the servers becomes overloaded and sends a host report.  The server is telling clients to reduce the traffic sent to it by x%.  The client selects a route for the request.  Any request that would be routed to the connection to the server should be a candidate for overload treatment.  If this is not the case then how do you protect a server for an application that has 100% realm routed requests?

In other words, the reacting node has a direct connection to the reporting node.  In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP.
[LM] I'm not sure to understand the reasoning above. Why should a reacting node include request with no Dest-Host AVP?
SRD> Because there is nothing else in the network that can manage that traffic.



I propose that the second paragraph be changed to the following:

"The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR.  This is the value of the Origin-Host AVP in the message that carried the OLR.  There are two cases where the reacting node will know that the request will be routed to the overloaded node.  The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR.  The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node."
[LM] this is not needed if the Origin-host in the answer is enough to identify which node is overloaded, that is the current assumption in the draft.

Regards,

Steve

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.




_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------060807070905040308010104-- From nobody Tue Apr 8 06:23:35 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52771A03C4 for ; Tue, 8 Apr 2014 06:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cKtjCTkWmIn for ; Tue, 8 Apr 2014 06:23:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id CC9151A0379 for ; Tue, 8 Apr 2014 06:23:26 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id C8A7F3B41F0; Tue, 8 Apr 2014 15:23:25 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id ABAACC807F; Tue, 8 Apr 2014 15:23:25 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 8 Apr 2014 15:23:25 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Definition of host report Thread-Index: AQHPUytwZFDFsRdQF02SAbAlZFyGjJsHsYJg Date: Tue, 8 Apr 2014 13:23:24 +0000 Message-ID: <29259_1396963405_5343F84D_29259_1241_1_6B7134B31289DC4FAF731D844122B36E54C7C3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5342AAD9.9030803@usdonovans.com> <28937_1396879717_5342B165_28937_9147_1_6B7134B31289DC4FAF731D844122B36E548C2D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <534318C7.1060502@usdonovans.com> <7558_1396959635_5343E993_7558_7400_1_6B7134B31289DC4FAF731D844122B36E54C514@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5343F470.50808@usdonovans.com> In-Reply-To: <5343F470.50808@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E54C7C3PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xFiAYLLLFhUSRgUTFomvPAu9xu8 Subject: Re: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 13:23:32 -0000 --_000_6B7134B31289DC4FAF731D844122B36E54C7C3PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I see my mistake. I was confused by "the overloaded Diameter node identifie= d by the Diameter ID in the OLR" Therefore, I agree with the proposed change. In order to keep the existing = text, do you think that the following wording would be clear enough: Either the Destination-Host AVP is present in the request and its val= ue matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP; Either the Destination-Host is not pre= sent in the request but the value of peer identity associated with the con= nection used to send the request matches the value of the Origin-Host AVP of = the received message that contained the OC-OLR AVP. Regards, Lionel De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi 8 avril 2014 15:07 =C0 : MORAND Lionel IMT/OLN; dime@ietf.org Objet : Re: [Dime] Definition of host report Lionel, I'm not proposing adding an AVP to the overload report. I should have said= the Diameter ID in the overload control state. I agree completely that th= e Diameter ID comes from the Origin-Host AVP in the answer message containi= ng the OLR. Regards, Steve On 4/8/14 7:20 AM, lionel.morand@orange.com wrote: Hi Steve, I understand your point now. Thank you for the clarification. However, I don't think that it leads necessarily to the need for a Diameter= Id in the OLR. The clarification could be that, in case of direct connection between clien= ts and servers, the Host report type applies also to the peer connection fo= r which the peer id is equal to the origin-host in the answer containing th= e OLR. Such binding is required and the Diameter Id in the OLR will not pro= vide added-value compared to the origin-host of the answer. Regards, Lionel De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : lundi 7 avril 2014 23:30 =C0 : MORAND Lionel IMT/OLN; dime@ietf.org Objet : Re: [Dime] Definition of host report Lionel, Please see inline. Steve On 4/7/14 9:07 AM, lionel.morand@orange.com wrote: Hi Steve, As defined today, the originator of a Host-based report is the node identif= ied by the Origin-host in the answer. I don't understand what is wrong with= the existing definition in the draft. Please see below. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 7 avril 2014 15:41 =C0 : dime@ietf.org Objet : [Dime] Definition of host report All, I believe that the current definition of the host report needs to be enhanc= ed. The following is what is currently in the -02 draft: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. The second paragraph says that only requests that contain a Destination-Hos= t AVP can be used for overload treatment. This does not address the case where there is no agent between the reacting= and reporting nodes. [LM] I think you mean: this does ONLY address, right? SRD> No, I mean the case where a client is connected directly to a set of s= ervers. One of the servers becomes overloaded and sends a host report. Th= e server is telling clients to reduce the traffic sent to it by x%. The cl= ient selects a route for the request. Any request that would be routed to = the connection to the server should be a candidate for overload treatment. = If this is not the case then how do you protect a server for an applicatio= n that has 100% realm routed requests? In other words, the reacting node has a direct connection to the reporting = node. In this case the reacting node should include all messages that woul= d be sent to the reporting node, including those that do not contain a Dest= ination-Host AVP and those that the reacting node would sent to the reporti= ng node through normal route selection for requests that do not contain a D= estination-Host AVP. [LM] I'm not sure to understand the reasoning above. Why should a reacting = node include request with no Dest-Host AVP? SRD> Because there is nothing else in the network that can manage that traf= fic. I propose that the second paragraph be changed to the following: "The reacting node knows that the request will be routed to the overloaded = Diameter node identified by the Diameter ID in the OLR. This is the value = of the Origin-Host AVP in the message that carried the OLR. There are two = cases where the reacting node will know that the request will be routed to = the overloaded node. The first is the request contains a Destination-Host = AVP that matches the Diameter ID contained in the OLR. The second is when = the reacting node selects a route that is a direct connection to the overlo= aded Diameter node." [LM] this is not needed if the Origin-host in the answer is enough to ident= ify which node is overloaded, that is the current assumption in the draft. Regards, Steve ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E54C7C3PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I see my m= istake. I was confused by "the overloaded = Diameter node identified by the Diameter ID in the OLR"

Therefore,= I agree with the proposed change. In order to keep the existing text, do y= ou think that the following wording would be clear enough:

 = ;

      Either the Destina=
tion-Host AVP is present in the request and its value

      matches the value =
of the Origin-Host AVP of the received message


      that contained the=
 OC-OLR AVP; Either the Destination-Host is not present

      in the request but=
 the value of peer identity associated with the connection


      used to send the r=
equest matches the value of the Origin-Host AVP of the

      received message t=
hat contained the OC-OLR AVP. 


 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 Steve Donovan [mailto:srdonovan@usdonovans.co=
m]


Envoy=E9 : mardi 8 avril 2014 15:07

=C0 : MORAND Lionel IMT/OLN; dime@ietf.org

Objet : Re: [Dime] Definition of host report<=
/p>





 


Lionel,



I'm not proposing adding an AVP to the overload report.  I should have=
 said the Diameter ID in the overload control state.  I agree complete=
ly that the Diameter ID comes from the Origin-Host AVP in the answer messag=
e containing the OLR.



Regards,



Steve




On 4/8/14 7:20 AM, 
lionel.morand@orange.com wrote:






Hi Steve,


 


I understand your point now. Thank you for the clarification.


 


However, I don't think that it leads necessarily to the need for a Dia=
meter Id in the OLR.


 


The clarification could be that, in case of direct connection between =
clients and servers, the Host report type applies also to the peer connecti=
on for which the peer id is equal to the origin-host in the answer containi=
ng the OLR. Such binding is required and the Diameter Id in the OLR will no=
t provide added-value compared to the origin-host of the answer.=



 


Regards, 


 


Lionel


 


 


De : Steve Donovan [m=
ailto:srdonovan@usdonovans.com] 


Envoy=E9 : lundi 7 avril 2014 23:30


=C0 : MORAND Lionel IMT/OLN; dim=
e@ietf.org


Objet : Re: [Dime] Definition of host report


 


Lionel,


 


Please see inline.


 


Steve


On 4/7/14 9:07 AM, lionel.=
morand@orange.com wrote:


Hi Steve,


 


As defined today, the originator of a Host-based report is the node id=
entified by the Origin-host in the answer. I don't understand what is wrong=
 with the existing definition in the draft.


 


Please see below.


 


Regards,


 


Lionel


 


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Steve Donovan


Envoy=E9 : lundi 7 avril 2014 15:41


=C0 : dime@ietf.org


Objet : [Dime] Definition of host report


 


All,


 


I believe that the current definition of the host report needs to be e=
nhanced.


 


The following is what is currently in the -02 draft:


   0  A host report.  The overload treatment shoul=
d apply to requests


      for which all of the following conditio=
ns are true:


 


      The Destination-Host AVP is present in =
the request and its value


      matches the value of the Origin-Host AV=
P of the received message


      that contained the OC-OLR AVP.


 


      The value of the Destination-Realm AVP =
in the request matches the


      value of the Origin-Realm AVP of the re=
ceived message that


      contained the OC-OLR AVP.

 


      The value of the Application-ID in the =
Diameter Header of the


      request matches the value of the Applic=
ation-ID of the Diameter


      Header of the received message that con=
tained the OC-OLR AVP.


 


The second paragraph says that only requests that contain a Destinatio=
n-Host AVP can be used for overload treatment.


 


This does not address the case where there is no agent between the rea=
cting and reporting nodes. 


[LM] I think you mean: this does ONLY address, right?


SRD> No, I mean the case where a client is connected directly to a =
set of servers.  One of the servers becomes overloaded and sends a hos=
t report.  The server is telling clients to reduce the traffic sent to=
 it by x%.  The client selects a route for the request.  Any requ=
est that would be routed to the connection to the server should be a candid=
ate for overload treatment.  If this is not the case then how do you p=
rotect a server for an application that has 100% realm routed requests?


 


In other words, the reacting node has a direct connection to the repor=
ting node.  In this case the reacting node should include all messages=
 that would be sent to the reporting node, including those that do not cont=
ain a Destination-Host AVP and those that the reacting node would sent to t=
he reporting node through normal route selection for requests that do not c=
ontain a Destination-Host AVP.


[LM] I'm not sure to understand the reasoning above. Why should a reac=
ting node include request with no Dest-Host AVP?


SRD> Because there is nothing else in the network that can manage t=
hat traffic.


 


 


 


I propose that the second paragraph be changed to the following:<=
/o:p>


 


"The reacting node knows that the request will be routed to the o=
verloaded Diameter node identified by the Diameter ID in the OLR.  Thi=
s is the value of the Origin-Host AVP in the message that carried the OLR.&=
nbsp; There are two cases where the reacting node will know that the reques=
t will be routed to the overloaded node.  The first is the request con=
tains a Destination-Host AVP that matches the Diameter ID contained in the =
OLR.  The second is when the reacting node selects a route that is a d=
irect connection to the overloaded Diameter node."


[LM] this is not needed if the Origin-host in the answer is enough to =
identify which node is overloaded, that is the current assumption in the dr=
aft.


 


Regards,


 


Steve


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


 


 


 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


 


 




 


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E54C7C3PEXCVZYM13corpora_-- From nobody Tue Apr 8 08:34:35 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2515B1A03C1 for ; Tue, 8 Apr 2014 08:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkAx9TJZklpM for ; Tue, 8 Apr 2014 08:34:32 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 207301A01C9 for ; Tue, 8 Apr 2014 08:34:32 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60367 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WXY2b-0005eX-MO; Tue, 08 Apr 2014 08:34:30 -0700 Message-ID: <53441701.1070502@usdonovans.com> Date: Tue, 08 Apr 2014 10:34:25 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <5342AAD9.9030803@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------000003040109010708070001" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/K3uHXmogM3AGOALzEjFnJ5HFLLc Subject: Re: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 15:34:34 -0000 This is a multi-part message in MIME format. --------------000003040109010708070001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich, Please see inline. Steve On 4/8/14 2:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > > Steve, > > I tend to agree. > > However, wouldn't this mean that also the current definition of realm > report (which actually is RRR) needs to be enhanced? > > > > e.g. replace > > The Destination-Host AVP is absent in the request. > > > > with something like > > "The reacting node does not know to which Diameter Host the request > will be routed." > SRD> How about "The reacting node does not know to which Diameter Host within the Realm the request will be routed." > > > > I was also wondering if there may be cases where > > a) the reacting node selects the host, detects that it has a direct > connection to that host and therefore does not include the > Destination-Host AVP in the request. The selected host, however, when > receiving the Destination-Host-less request decides to forward the > request to another host. Or > SRD> Why would the receiving host decide to forward the request? If it does, it's either an agent or there is some new application layer behavior that the reacting node can't predict. > > b) the reacting node does not select a host and therefore does not > include a Destination-Host AVP, but sends the request to the next hop, > which happens to be a Host that decides to handle the request. > SRD> But the reacting node will know if the next hop matches an active overload report based on the ID of the host on the other end of the connection used. This is the case I'm addressing with my proposal. > > > > > > Are those cases valid and covered? > > > > Ulrich > > > > > > > > > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve > Donovan > *Sent:* Monday, April 07, 2014 3:41 PM > *To:* dime@ietf.org > *Subject:* [Dime] Definition of host report > > > > All, > > I believe that the current definition of the host report needs to be > enhanced. > > The following is what is currently in the -02 draft: > > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > > The value of the Destination-Realm AVP in the request matches the > value of the Origin-Realm AVP of the received message that > contained the OC-OLR AVP. > > The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > > > The second paragraph says that only requests that contain a > Destination-Host AVP can be used for overload treatment. > > This does not address the case where there is no agent between the > reacting and reporting nodes. In other words, the reacting node has a > direct connection to the reporting node. In this case the reacting > node should include all messages that would be sent to the reporting > node, including those that do not contain a Destination-Host AVP and > those that the reacting node would sent to the reporting node through > normal route selection for requests that do not contain a > Destination-Host AVP. > > I propose that the second paragraph be changed to the following: > > "The reacting node knows that the request will be routed to the > overloaded Diameter node identified by the Diameter ID in the OLR. > This is the value of the Origin-Host AVP in the message that carried > the OLR. There are two cases where the reacting node will know that > the request will be routed to the overloaded node. The first is the > request contains a Destination-Host AVP that matches the Diameter ID > contained in the OLR. The second is when the reacting node selects a > route that is a direct connection to the overloaded Diameter node." > > Regards, > > Steve > --------------000003040109010708070001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich,

Please see inline.

Steve
On 4/8/14 2:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Steve,

I tend to agree.

However, wouldn’t this mean that also the current definition of realm report (which actually is RRR) needs to be enhanced?

 

e.g. replace

The Destination-Host AVP is absent in the request.

 

with something like

"The reacting node does not know to which Diameter Host the request will be routed.” 

SRD> How about "The reacting node does not know to which Diameter Host within the Realm the request will be routed."

 

I was also wondering if there may be cases where

a) the reacting node selects the host, detects that it has a direct connection to that host and therefore does not include the Destination-Host AVP in the request. The selected host, however, when receiving the Destination-Host-less request decides to forward the request to another host. Or

SRD> Why would the receiving host decide to forward the request?  If it does, it's either an agent or there is some new application layer behavior that the reacting node can't predict.

b) the reacting node does not select a host and therefore does not include a Destination-Host AVP, but sends the request to the next hop, which happens to be a Host that decides to handle the request.

SRD> But the reacting node will know if the next hop matches an active overload report based on the ID of the host on the other end of the connection used.  This is the case I'm addressing with my proposal. 

 

 

Are those cases valid and covered?

 

Ulrich

 

 

 

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, April 07, 2014 3:41 PM
To: dime@ietf.org
Subject: [Dime] Definition of host report

 

All,

I believe that the current definition of the host report needs to be enhanced.

The following is what is currently in the -02 draft:

   0  A host report.  The overload treatment should apply to requests
      for which all of the following conditions are true:
 
      The Destination-Host AVP is present in the request and its value
      matches the value of the Origin-Host AVP of the received message
      that contained the OC-OLR AVP.
 
      The value of the Destination-Realm AVP in the request matches the
      value of the Origin-Realm AVP of the received message that
      contained the OC-OLR AVP.
 
      The value of the Application-ID in the Diameter Header of the
      request matches the value of the Application-ID of the Diameter
      Header of the received message that contained the OC-OLR AVP.


The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment.

This does not address the case where there is no agent between the reacting and reporting nodes.  In other words, the reacting node has a direct connection to the reporting node.  In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP.

I propose that the second paragraph be changed to the following:

"The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR.  This is the value of the Origin-Host AVP in the message that carried the OLR.  There are two cases where the reacting node will know that the request will be routed to the overloaded node.  The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR.  The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node."

Regards,

Steve


--------------000003040109010708070001-- From nobody Tue Apr 8 08:38:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002691A042D for ; Tue, 8 Apr 2014 08:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zvprZbbybh8 for ; Tue, 8 Apr 2014 08:38:24 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id A0CBE1A042E for ; Tue, 8 Apr 2014 08:38:24 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60375 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WXY6L-00025F-VS; Tue, 08 Apr 2014 08:38:23 -0700 Message-ID: <534417E9.3030302@usdonovans.com> Date: Tue, 08 Apr 2014 10:38:17 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <5342AAD9.9030803@usdonovans.com> <28937_1396879717_5342B165_28937_9147_1_6B7134B31289DC4FAF731D844122B36E548C2D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <534318C7.1060502@usdonovans.com> <7558_1396959635_5343E993_7558_7400_1_6B7134B31289DC4FAF731D844122B36E54C514@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5343F470.50808@usdonovans.com> <29259_1396963405_5343F84D_29259_1241_1_6B7134B31289DC4FAF731D844122B36E54C7C3@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <29259_1396963405_5343F84D_29259_1241_1_6B7134B31289DC4FAF731D844122B36E54C7C3@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------060409060200030909030204" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BHgKkhd1yCgnZmw-K3OIwnoXpoo Subject: Re: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 15:38:30 -0000 This is a multi-part message in MIME format. --------------060409060200030909030204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lionel, The second Either would need to be "Or". I'm generally ok with your wording. I was attempting to get to wording that referred to the overload control state and not the message that carried the OC-OLR AVP. I just didn't do a good job of it. We can go with your wording for now but I might take another attempt to have it refer to the OCS instead. Steve On 4/8/14 8:23 AM, lionel.morand@orange.com wrote: > > I see my mistake. I was confused by "the overloaded Diameter node > identified by the Diameter ID in the OLR" > > Therefore, I agree with the proposed change. In order to keep the > existing text, do you think that the following wording would be clear > enough: > > > > Either the Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP; Either the Destination-Host is not present > in the request but the value of peer identity associated with the connection > used to send the request matches the value of the Origin-Host AVP of the > received message that contained the OC-OLR AVP. > > > > Regards, > > > > Lionel > > > > *De :*Steve Donovan [mailto:srdonovan@usdonovans.com] > *Envoyé :* mardi 8 avril 2014 15:07 > *À :* MORAND Lionel IMT/OLN; dime@ietf.org > *Objet :* Re: [Dime] Definition of host report > > > > Lionel, > > I'm not proposing adding an AVP to the overload report. I should have > said the Diameter ID in the overload control state. I agree > completely that the Diameter ID comes from the Origin-Host AVP in the > answer message containing the OLR. > > Regards, > > Steve > > On 4/8/14 7:20 AM, lionel.morand@orange.com > wrote: > > Hi Steve, > > > > I understand your point now. Thank you for the clarification. > > > > However, I don't think that it leads necessarily to the need for a Diameter Id in the OLR. > > > > The clarification could be that, in case of direct connection between clients and servers, the Host report type applies also to the peer connection for which the peer id is equal to the origin-host in the answer containing the OLR. Such binding is required and the Diameter Id in the OLR will not provide added-value compared to the origin-host of the answer. > > > > Regards, > > > > Lionel > > > > > > De : Steve Donovan [mailto:srdonovan@usdonovans.com] > > Envoyé : lundi 7 avril 2014 23:30 > > À : MORAND Lionel IMT/OLN; dime@ietf.org > > Objet : Re: [Dime] Definition of host report > > > > Lionel, > > > > Please see inline. > > > > Steve > > On 4/7/14 9:07 AM, lionel.morand@orange.com wrote: > > Hi Steve, > > > > As defined today, the originator of a Host-based report is the node identified by the Origin-host in the answer. I don't understand what is wrong with the existing definition in the draft. > > > > Please see below. > > > > Regards, > > > > Lionel > > > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > > Envoyé : lundi 7 avril 2014 15:41 > > À : dime@ietf.org > > Objet : [Dime] Definition of host report > > > > All, > > > > I believe that the current definition of the host report needs to be enhanced. > > > > The following is what is currently in the -02 draft: > > 0 A host report. The overload treatment should apply to requests > > for which all of the following conditions are true: > > > > The Destination-Host AVP is present in the request and its value > > matches the value of the Origin-Host AVP of the received message > > that contained the OC-OLR AVP. > > > > The value of the Destination-Realm AVP in the request matches the > > value of the Origin-Realm AVP of the received message that > > contained the OC-OLR AVP. > > > > The value of the Application-ID in the Diameter Header of the > > request matches the value of the Application-ID of the Diameter > > Header of the received message that contained the OC-OLR AVP. > > > > The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment. > > > > This does not address the case where there is no agent between the reacting and reporting nodes. > > [LM] I think you mean: this does ONLY address, right? > > SRD> No, I mean the case where a client is connected directly to a set of servers. One of the servers becomes overloaded and sends a host report. The server is telling clients to reduce the traffic sent to it by x%. The client selects a route for the request. Any request that would be routed to the connection to the server should be a candidate for overload treatment. If this is not the case then how do you protect a server for an application that has 100% realm routed requests? > > > > In other words, the reacting node has a direct connection to the reporting node. In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP. > > [LM] I'm not sure to understand the reasoning above. Why should a reacting node include request with no Dest-Host AVP? > > SRD> Because there is nothing else in the network that can manage that traffic. > > > > > > > > I propose that the second paragraph be changed to the following: > > > > "The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR. This is the value of the Origin-Host AVP in the message that carried the OLR. There are two cases where the reacting node will know that the request will be routed to the overloaded node. The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR. The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node." > > [LM] this is not needed if the Origin-host in the answer is enough to identify which node is overloaded, that is the current assumption in the draft. > > > > Regards, > > > > Steve > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > > Thank you. > > > > > > > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > > Thank you. > > > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------060409060200030909030204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lionel,

The second Either would need to be "Or".

I'm generally ok with your wording.  I was attempting to get to wording that referred to the overload control state and not the message that carried the OC-OLR AVP.  I just didn't do a good job of it. 

We can go with your wording for now but I might take another attempt to have it refer to the OCS instead.

Steve
On 4/8/14 8:23 AM, lionel.morand@orange.com wrote:

I see my mistake. I was confused by "the overloaded Diameter node identified by the Diameter ID in the OLR"

Therefore, I agree with the proposed change. In order to keep the existing text, do you think that the following wording would be clear enough:

 

      Either the Destination-Host AVP is present in the request and its value
      matches the value of the Origin-Host AVP of the received message
      that contained the OC-OLR AVP; Either the Destination-Host is not present
      in the request but the value of peer identity associated with the connection
      used to send the request matches the value of the Origin-Host AVP of the
      received message that contained the OC-OLR AVP.

 

Regards,

 

Lionel

 

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoyé : mardi 8 avril 2014 15:07
À : MORAND Lionel IMT/OLN; dime@ietf.org
Objet : Re: [Dime] Definition of host report

 

Lionel,

I'm not proposing adding an AVP to the overload report.  I should have said the Diameter ID in the overload control state.  I agree completely that the Diameter ID comes from the Origin-Host AVP in the answer message containing the OLR.

Regards,

Steve

On 4/8/14 7:20 AM, lionel.morand@orange.com wrote:

Hi Steve,
 
I understand your point now. Thank you for the clarification.
 
However, I don't think that it leads necessarily to the need for a Diameter Id in the OLR.
 
The clarification could be that, in case of direct connection between clients and servers, the Host report type applies also to the peer connection for which the peer id is equal to the origin-host in the answer containing the OLR. Such binding is required and the Diameter Id in the OLR will not provide added-value compared to the origin-host of the answer.
 
Regards, 
 
Lionel
 
 
De : Steve Donovan [mailto:srdonovan@usdonovans.com] 
Envoyé : lundi 7 avril 2014 23:30
À : MORAND Lionel IMT/OLN; dime@ietf.org
Objet : Re: [Dime] Definition of host report
 
Lionel,
 
Please see inline.
 
Steve
On 4/7/14 9:07 AM, lionel.morand@orange.com wrote:
Hi Steve,
 
As defined today, the originator of a Host-based report is the node identified by the Origin-host in the answer. I don't understand what is wrong with the existing definition in the draft.
 
Please see below.
 
Regards,
 
Lionel
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 7 avril 2014 15:41
À : dime@ietf.org
Objet : [Dime] Definition of host report
 
All,
 
I believe that the current definition of the host report needs to be enhanced.
 
The following is what is currently in the -02 draft:
   0  A host report.  The overload treatment should apply to requests
      for which all of the following conditions are true:
 
      The Destination-Host AVP is present in the request and its value
      matches the value of the Origin-Host AVP of the received message
      that contained the OC-OLR AVP.
 
      The value of the Destination-Realm AVP in the request matches the
      value of the Origin-Realm AVP of the received message that
      contained the OC-OLR AVP.
 
      The value of the Application-ID in the Diameter Header of the
      request matches the value of the Application-ID of the Diameter
      Header of the received message that contained the OC-OLR AVP.
 
The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment.
 
This does not address the case where there is no agent between the reacting and reporting nodes. 
[LM] I think you mean: this does ONLY address, right?
SRD> No, I mean the case where a client is connected directly to a set of servers.  One of the servers becomes overloaded and sends a host report.  The server is telling clients to reduce the traffic sent to it by x%.  The client selects a route for the request.  Any request that would be routed to the connection to the server should be a candidate for overload treatment.  If this is not the case then how do you protect a server for an application that has 100% realm routed requests?
 
In other words, the reacting node has a direct connection to the reporting node.  In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP.
[LM] I'm not sure to understand the reasoning above. Why should a reacting node include request with no Dest-Host AVP?
SRD> Because there is nothing else in the network that can manage that traffic.
 
 
 
I propose that the second paragraph be changed to the following:
 
"The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR.  This is the value of the Origin-Host AVP in the message that carried the OLR.  There are two cases where the reacting node will know that the request will be routed to the overloaded node.  The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR.  The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node."
[LM] this is not needed if the Origin-host in the answer is enough to identify which node is overloaded, that is the current assumption in the draft.
 
Regards,
 
Steve
 
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
 
 
 
 
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
 
 

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------060409060200030909030204-- From nobody Tue Apr 8 10:04:25 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FAD1A048A for ; Tue, 8 Apr 2014 10:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVTMmBP_QbQD for ; Tue, 8 Apr 2014 10:04:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id A740C1A0489 for ; Tue, 8 Apr 2014 10:04:07 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id DD72C1B8342; Tue, 8 Apr 2014 19:04:06 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id BB64E18006C; Tue, 8 Apr 2014 19:04:06 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 8 Apr 2014 19:04:06 +0200 From: To: Benoit Claise , "draft-ietf-dime-app-design-guide.all@tools.ietf.org" Thread-Topic: [Dime] AD review draft-ietf-dime-app-design-guide Thread-Index: AQHPTlKK04bn8aLKgkqsyndd0aygjpsHsEvg Date: Tue, 8 Apr 2014 17:04:05 +0000 Message-ID: <22885_1396976646_53442C06_22885_3037_1_6B7134B31289DC4FAF731D844122B36E54D5C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> In-Reply-To: <533BD276.7000401@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E54D5C4PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.8.91220 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PH64unILe4bk-T5PgBS_tKRORqI Cc: dime mailing list Subject: Re: [Dime] AD review draft-ietf-dime-app-design-guide X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 17:04:20 -0000 --_000_6B7134B31289DC4FAF731D844122B36E54D5C4PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Benoit, Thank you for the deep review. Please find my feedback below. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Benoit Claise Envoy=E9 : mercredi 2 avril 2014 11:04 =C0 : draft-ietf-dime-app-design-guide.all@tools.ietf.org Cc : dime mailing list Objet : [Dime] AD review draft-ietf-dime-app-design-guide Dear authors, Sorry for dropping the ball on this one. If any of the points was already discussed/addressed by the WG, feel free t= o let me know. - When I read the document, it looked to me as a BCP. BCP definition from RFC 2026: 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. Interestingly, the charter mentions: May 2012, Submit 'Diameter Application Design Guidelines' to the IESG for c= onsideration as a BCP document [LM] discussed in another email thread. If you go to BCP, don't forget to update the abstract, and the writeup. Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013) Example: OLD: Diameter protocol designers are then strongly advised to carefully consider NEW: Diameter protocol designers SHOULD NOT consider OLD: Instead of using an Enumerated AVP for a Boolean flag, protocol designers are again encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which the data field would be defined as NEW: Instead of using an Enumerated AVP for a Boolean flag, protocol designers SHOULD use AVPs of type Unsigned32 or Unsigned64 AVP in which the data field would be defined as Finally, with a BCP, RFC 6733 could be a normative reference, which I belie= ve it should. - Editorial Please don't use "we" in RFCs [LM] Should I say "I"? :) - Section 3 Major Extension: Enhancing an application that requires the definition of a new Diameter application. Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new AVP with the M-bit set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. Do you want to mention that Major Extension have backward compatibility iss= ue, as opposed to the minor one? [LM] Yes. I'm assuming that you would prefer to say it explicitly. - Editorial Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new AVP with the M-bit set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. NEW: Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new mandatory AVP set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. Justification: * Minor extension speaks about "optional" * The M-bit is explained in 4.3.1 [LM] I would say that "mandatory" and "M-bit" set are the same and you need= to refer to RFC6733 to understand the meaning anyway. But I would be prefe= r to keep "M-bit set" to avoid the common ambiguity with "required AVP" tha= t indicates the mandatory presence of an AVP. I can add an explicit referen= ce to section 4.1. of RFC6733. - Section 3 I see Minor Extension versus Major Extension, and I tried to match the foll= owing classifications to Minor or Major 1. Addition of new functionality to an existing Diameter application without defining a new application. 2. Addition of new functionality to an existing Diameter application that requires the definition of a new application. 3. The definition of an entirely new Diameter application to offer functionality not supported by existing applications. 4. The definition of a new generic functionality that can be reused across different applications. 2 and 3 are Major [LM] right For 1, I thought about Minor, but the following sentence "or the definition= of a new AVP with the M-bit set to be carried in an existing command." in = the Major paragraph confuses me. [LM] (1) is "Minor" as no new application is required. If the new functiona= lity would have been supported by an AVP with the M-bit set, it would have = caused the creation of a new application (cf. section 4.3.1: "A mandatory A= VP cannot be added to an existing command without defining a new Diameter a= pplication" I guess that 4 is Major, but it's not mentioned. [LM] can be both as described in section 6. Can you please better explain the mapping between the 4 categories and Mino= r/Major extensions [LM] the whole document is about clarifying these points. Each point is fur= ther described in the section 4, 5 and 6. Alternatively, or maybe on top of that, explain which of 4.X and 5.X are Mi= nor/Major extensions would be beneficial. [LM] I will try to clarify when required by highlighting "Minor/Major" - Section 3 I don't understand what your message is with: We would also like to remind that the definition of a new Diameter application and the definition of a new command should be something to avoid as much as possible. In the past, there has been some reluctance to define new commands and new applications. With the modified extensibility rules provided by [RFC6733], registering new commands and new applications does not lead to additional overhead for the specification author in terms of standardization process. Registering new functionality (new commands, new AVPs, new applications, etc.) with IANA remains important to avoid namespace collisions, which will likely lead to deployment problems. "should be something to avoid as much as possible", is this valid today? Because the next sentence speaks about the past, then the next sentence see= ms like it's fixed now with 6733. [LM] Some inconsistency due to the modification of the IANA allocation moda= lities. I propose to: - remove the first sentence. - Clarify that "in the past" refers to RFC3588 - Remove the last sentence as it is somehow clarify in the section= 7. - Add a sentence that the general guideline "try to reuse as much = as possible" still applies. - Editorial: With the modified extensibility rules provided by [RFC6733], registering new commands and new applications does not lead to additional overhead for the specification author in terms of standardization process. Registering new functionality (new commands, new AVPs, new applications, etc.) "etc.": What does it refer to? new AVP value is the only one I can think of. Worth removing "etc." and specifying the full list? [LM] removed. - Application and command Major Extension: Enhancing an application that requires the definition of a new Diameter application. Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new AVP with the M-bit set to be carried in an existing command. For such extension, a significant specification effort is required and a careful approach is recommended. 4.1. Adding a New Command Adding a new command is considered as a major extension and requires a new Diameter application to be defined. I'm not clear on the application/command boundary. Why do we need a new application for a new command? [LM] using an unknown command in an existing application will cause a proto= col error as per the RFC 6733. DIAMETER_COMMAND_UNSUPPORTED 3001 This error code is used when a Diameter entity receives a message with a Command Code that it does not support. Therefore non-supporting nodes will never be able to process the request. Why can't I add a command to an existing application? There are commands that are for all applications/independent of the applica= tion, no? CER/CEA (Capabilities-Exchange-Request) [LM] CER/CEA are part of an application, the application "0" i.e. the base = protocol. The requirement is that all diameter peers support AT LEAST the b= ase protocol application. This contradicts: Before adding or importing a command, application designers should consider the following ... [LM] here, we are in the section "Adding a new command to an existing appli= cation" and it is clearly said that it is a major extension that will cause= the creation of a new application. This also appears to contradict, in section 6 Generic Diameter extensions are AVPs, commands or applications that are designed to support other Diameter applications. [LM] not so. Any new application can reuse an existing command. For instanc= e, Session Termination commands are reused in every session-related applica= tions. My issue comes from the fact that there are no "application" and "command" = definitions. Draft says: 2= . Terminology This document reuses the terminology defined in [RFC6733] However, RFC 6733 terminology doesn't contain the application and command d= efinitions. Talking to Jouni, I now understand that a command is always specified withi= n the context of an application. This should be clarified. [LM] ok Also, from section 5.2: As a general recommendation, commands should not be defined from scratch. It is instead recommend to re-use an existing command offering similar functionality and use it as a starting point. Based on my latest understanding (a command is always specified within the = context of an application), the only justification for the above text is co= de reuse, right. Please mention it. [LM] it refers to the text in the section 3. It will reduce the time to finalize specification writing, and it will lead to a smaller implementation effort as well as reduce the need for testing. In general, it is clever to avoid duplicate effort when possible. Will be clarified. - Editorial Adding a new command is considered as a major extension and requires a new Diameter application to be defined. Adding a new command to an application means ... A new command addition is always to an application, right? If yes, why do you make the distinction between the sentences above [LM] It is about adding a command to an EXISTING application. The first sen= tence will say "Adding a new command to an existing application is consider= ed" and "to an application" will be removed from the second sentence. - Application version? An exception might be if the intent of the deletion is to create a newer version of the same application that is somehow simpler than the previous version. ... o Would the new AVP be used to differentiate between old and new versions of the same application whereby the two versions are not backward compatible? Readers might be understanding that diameter applications having a version = field. This is not the case. Please rephrase. [LM] I think we can speak about new version of the specification and varian= t of the application Also, mention that a new version of an application is a new application. I guess it needs to be mentioned in 7.d [LM] OK for the clarification but not in 7.d as this section is only about = interaction with IANA. - Section 4.3.2 For the reader convenience, I would mention the convention behind { AVP } a= nd [ AVP ], or at least give a reference. [LM] I would clarify that "a required AVP (an AVP indicated as {AVP} in the= command CCF)" and "an optional AVP (an AVP indicated as [AVP] in the comma= nd CCF)" - Section 5.3 OLD: Some existing specifications do not adhere to this rule for historical reasons. However, this guidance should be followed to avoid routing problems. NEW: Some existing specifications do not adhere to this rule for historical reasons. However, this guidance should be followed for new applications to avoid = routing problems. [LM] ok In the same section, why "In general" in the next sentence? It contradicts = with "must use" In general, when a new application has been allocated with a new Application Id and it also reuses existing commands with or without modifications, it must use the newly allocated Application Id in the header and in all relevant Application Id AVPs (Auth-Application-Id or Acct-Application-Id) present in the commands message body. [LM] "In general" must be removed and "must use" will be "should use". - Editorial, section 5.5 OLD: Based on these considerations, protocol designers should carefully appraise whether the application currently defined relies on it's own session management concept or whether NEW: Based on these considerations, protocol designers should carefully appraise whether the application currently defined relies on its own session management concept or whether [LM] ok - Editorial in section 5.7 OLD: Destination- Realm NEW: Destination-Realm [LM] ok - The section 5.8 should mention RFC4005bis [LM] already covered by a previous comment :) - Section 5.9 Applications that do not understand these AVPs can discard them upon receipt. Generic comment: Each time there is a sentence like this one above, we shou= ld mention RFC 6733 as the reference. This document is not an extension/deviation to RFC 6733. [LM] ok - Do you have a good reason to add a reference to a work-in-progress that d= idn't progress since 2001? [I-D.calhoun-diameter-res-mgmt] Calhoun, P., "Diameter Resource Management Extensions", draft-calhoun-diameter-res-mgmt-08.txt (work in progress), March 2001. [LM] I think that it was as illustration of general-purpose extension based= on new commands. Other existing examples are only based on introduction of= new AVP. But I agree that it is weird to make reference to expired drafts = :) I would rather refer to Realm-Based Redirection (RFC 7075) and Diameter= Priority AVP (RFC6735) - Editorial (section 6) I can't parse the following sentence: Backward Compatibility: With the design of generic extensions an protocol designer has to consider with potential concerns about how existing applications deal with the new extension they do not understand. [LM] what about: When defining generic extensions designed to be supported by existing Diameter applications, protocol designers have to consider the potential impacts of the introduction of the new extension on the beh= avior of node that would not be yet upgraded to support/understand this new= extension. - Contributors: If Victor and Hannes are authors, then they shouldn't be in the contributor= s list. [LM] this list gives the members of the design team, not the contributors. Btw, I don't see an affiliation for Victor in the document header. I believ= e the common practice is to write down "consultant" [LM] I will try to contact him to see what he would like to see indicated a= s affiliation. Did the WG ever considered the following questions: - Any naming convention for new applications? [LM] no convention so far. - When it is not a good idea to define diameter applications? Let me make s= omething up: to push syslog message [LM] let me two days and I will define a nice application for that :) I can= not see real key criteria to formally say "defining a Diameter application = for that purpose is a bad idea". If your example was for "to reinvent the w= heel", it seems that this is only a criterion for WG chairs and Ads, but no= t anymore for the industry. Regards, Benoit ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E54D5C4PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Benoit,=

 = ;

Thank you = for the deep review.

Please fin= d my feedback below.

 = ;

Regards,

 = ;

Lionel

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Benoit Claise
Envoy=E9 : mercredi 2 avril 2014 11:04
=C0 : draft-ietf-dime-app-design-guide.all@tools.ietf.org
Cc : dime mailing list
Objet : [Dime] AD review draft-ietf-dime-app-design-guide<= /o:p>

 

Dear authors,

Sorry for dropping the ball on this one.
If any of the points was already discussed/addressed by the WG, feel free t= o let me know.



- When I read the document, it looked to me as a BCP.

BCP definition from RFC 2026:

5.  BEST CURRENT PRACTICE (BCP) RFCs
 
   The BCP subseries of the RFC series is designed to be a w=
ay to
   standardize practices and the results of community delibe=
rations.

Interestingly, the charter mentions:

May 2012, Submit 'Diameter Application Design Guidel= ines' to the IESG for consideration as a BCP document

[LM]= discussed in another email thread.


If you go to BCP, don't forget to update the abstract, and the writeup.
Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013)
Example:
OLD:

Diameter
protocol designers are then strongly advised to carefully consider

NEW:

   Diameter
   protocol designers SHOULD NOT consider
 

OLD:

   Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers =
are again
   encouraged to use AVPs of type Unsigned32 or Unsigned64 A=
VP in which
   the data field would be defined as


NEW:

   Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers =
SHOULD 
   use AVPs of type Unsigned32 or Unsigned64 AVP in whi=
ch
   the data field would be defined as

Finally, with a BCP, RFC 6733 could be a normative r= eference, which I believe it should.


- Editorial
Please don't use "we" in RFCs<= /o:p>

[LM]= Should I say "I"? J



-
Section 3

  Major Extension:  Enhancing an application that requires t=
he
      definition of a new Diameter applicatio=
n.
 
      Typical examples would be the creation =
of a new command for
      providing functionality not supported b=
y existing applications or
      the definition of a new AVP with the M-=
bit set to be carried in an
      existing command.  For such extens=
ion, a significant specification
      effort is required and a careful approa=
ch is recommended.

Do you want to mention that Major Extension have bac= kward compatibility issue, as opposed to the minor one?

[LM]= Yes. I'm assuming that you would prefer to say it explicitly.



- Editorial

      Typical examples would be the creation =
of a new command for
      providing functionality not supported b=
y existing applications or
      the definition of a new AVP with the M-=
bit set to be carried in an
      existing command.  For such extens=
ion, a significant specification
      effort is required and a careful approa=
ch is recommended.

NEW:

      Typical examples would be the creation =
of a new command for
      providing functionality not supported b=
y existing applications or
      the definition of a new mandatory AVP s=
et to be carried in an
      existing command.  For such extens=
ion, a significant specification
      effort is required and a careful approa=
ch is recommended.

Justification:

        * Minor extension speaks ab=
out "optional"
        * The M-bit is explained in=
 4.3.1
[LM] I would say that =
"mandatory" and "M-bit" set are the same and you need t=
o refer to RFC6733 to understand the meaning anyway. But I would be prefer =
to keep "M-bit set" to avoid the common ambiguity with "requ=
ired AVP" that indicates the mandatory presence of an AVP. I can add a=
n explicit reference to section 4.1. of RFC6733.


- Section 3
I see Minor Extension versus Major Extension, and I tried to match the foll= owing classifications to Minor or Major

   1.  Addition of new func=
tionality to an existing Diameter application
       without defining a new applicatio=
n.
 
   2.  Addition of new functionality to an existing Dia=
meter application
       that requires the definition of a=
 new application.
 
   3.  The definition of an entirely new Diameter appli=
cation to offer
       functionality not supported by ex=
isting applications.
 
   4.  The definition of a new generic functionality th=
at can be reused
       across different applications.

2 and 3 are Major=

[LM] right


For 1, I thought about Minor, but the following sentence "or the defin= ition of a new AVP with the M-bit set to be carried in an existing command.= " in the Major paragraph confuses me.

[LM] (1) is "Mino=
r" as no new application is required. If the new functionality would h=
ave been supported by an AVP with the M-bit set, it would have caused the c=
reation of a new application (cf. section 4.3.1: "A mandatory AVP cannot be added to an existing command with=
out defining a new Diameter application"


I guess that 4 is Major, but it's not mentioned.

[LM]= can be both as described in section 6.


Can you please better explain the mapping between the 4 categories and Mino= r/Major extensions=

[LM]= the whole document is about clarifying these points. Each point is further= described in the section 4, 5 and 6.


Alternatively, or maybe on top of that, explain which of 4.X and 5.X are Mi= nor/Major extensions would be beneficial.

[LM]= I will try to clarify when required by highlighting "Minor/Major"= ;



- Section 3
I don't understand what your message is with:

   We would also like to remind =
that the definition of a new Diameter
   application and the definition of a new command should be=
 something
   to avoid as much as possible.  In the past, there ha=
s been some
   reluctance to define new commands and new applications.&n=
bsp; With the
   modified extensibility rules provided by ["should be something to avoid as much as possib=
le", is this valid today?

Because the next sentence speaks about the past, then the next sentence see=
ms like it's fixed now with 6733.<=
/span>


[LM]=
 Some inconsistency due to the modification of the IANA allocation modaliti=
es. I propose to:


-         
 remove the first sentence.


-         
Clarify that "in the past" refers to=
 RFC3588


-         
Remove the last sentence as it is somehow clar=
ify in the section 7.


-         
Add a sentence that the general guideline &quo=
t;try to reuse as much as possible" still applies.


 




- Editorial:


   With the


   modified extensibility rules provided by ["etc.": Wha=
t does it refer to? new AVP value is the only one I can think of.

Worth removing "etc." and specifying the full list?


[LM] removed.





- Application and command


   Major Extension:  Enhanc=
ing an application that requires the


      definition of a new Diameter application.


 


      Typical examples would be the creation =
of a new command for


      providing functionality not supported b=
y existing applications or


      the definition of a new AVP with the M-=
bit set to be carried in an


      existing command.  For such extens=
ion, a significant specification


      effort is required and a careful approa=
ch is recommended.


4.1.  Adding a New Command


   Adding a new command is considered as a major extension a=
nd requires


   a new Diameter application to be defined.


I'm not clear on the application/command boundary.
Why do we need a new application for a new command?


[LM]=
 using an unknown command in an existing application will cause a protocol =
error as per the RFC 6733.


   DIAMETER_COMM=
AND_UNSUPPORTED 3001


 

    &n=
bsp; This error code is used when a Diameter entity receives a message=



    &n=
bsp; with a Command Code that it does not support.


Ther=
efore non-supporting nodes will never be able to process the request.<=
/o:p>




Why can't I add a command to an existing application?

There are commands that are for all applications/independent of the =
application, no?

    CER/CEA (Capabilities-Exchange-Request)


[LM]=
 CER/CEA are part of an application, the application "0" i.e. the=
 base protocol. The requirement is that all diameter peers support AT
 LEAST the base protocol application.




This contradicts:


   Before adding or importing=
 a command, application designers


   should consider the following ...


[LM] here, we are in t=
he section "Adding a new command to an existing application" and =
it is clearly said that it is a major extension that will cause the creatio=
n of a new application.


 


This also appears to contradict, in section 6


   Generic Diameter extensions are AVPs, commands or applica=
tions that


   are designed to support other Diameter applications.


[LM] not so. Any new a=
pplication can reuse an existing command. For instance, Session Termination=
 commands are reused in every session-related applications.<=
span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo=
t;,"sans-serif";color:#1F497D">


 


My issue comes from the fact that there are no "=
;application" and "command" definitions.

Draft says:


2.  Terminology


   This document reuses the terminology defined in [RFC6733]


However, RFC 6733 terminology doesn't contain the ap=
plication and command definitions.

Talking to Jouni, I now understand that a command is always specified withi=
n the context of an application.

This should be clarified.

[LM] ok<=
/span>






Also, from section 5.2:


   As a general recommendation, commands should not be defin=
ed from


   scratch.  It is instead recommend to re-use an exist=
ing command


   offering similar functionality and use it as a starting p=
oint.


Based on my latest understanding (a command is alway=
s specified within the context of an application), the only justification f=
or the above text is code reuse, right. Please mention it.


[LM]=
 it refers to the text in the section 3.


   It will reduc=
e the time to finalize


   specification=
 writing, and it will lead to a smaller implementation


   effort as wel=
l as reduce the need for testing.  In general, it is=



   clever to avo=
id duplicate effort when possible.


Will=
 be clarified.






- Editorial


   Adding a new command is consi=
dered as a major extension and requires


   a new Diameter application to be defined.  Adding a =
new command to an


   application means ...


A new command addition is always to an application, =
right?

If yes, why do you make the distinction between the sentences above


[LM]=
 It is about adding a command to an EXISTING application. The first sentenc=
e will say "Adding a new
 command to an existing application is considered" and "to an application" will =
be removed from the second sentence.






- Application version?


An exception might be if the


   intent of the deletion is to create a newer version of th=
e same


   application that is somehow simpler than the previous ver=
sion.


   &nb=
sp;    ...


   o  Would the new AVP be used to differentiate betwee=
n old and new


      versions of the same application whereb=
y the two versions are not


      backward compatible?


Readers might be understanding that diameter applica=
tions having a version field.

This is not the case. Please rephrase.


[LM]=
 I think we can speak about new version of the specification and variant of=
 the application




Also, mention that a new version of an application is a new application.

I guess it needs to be mentioned in 7.d


[LM]=
 OK for the clarification but not in 7.d as this section is only about inte=
raction with IANA.



- Section 4.3.2

For the reader convenience, I would mention the convention behind { AVP } a=
nd [ AVP ], or at least give a reference.


[LM] I would clarify t=
hat "a =
required AVP (an AVP indicated as {AVP} in the command CCF)" and "an optional AVP (an AVP indicat=
ed as [AVP] in the command CCF)"






- Section 5.3

OLD:


   Some existing


   specifications do not adhere to this rule for historical =
reasons.


   However, this guidance should be followed to avoid routin=
g problems.


 


NEW:


   Some existing


   specifications do not adhere to this rule for historical =
reasons.


   However, this guidance should be followed for new applica=
tions to avoid routing problems.


[LM] ok




In the same section, why "In general" in the next sentence? It co=
ntradicts with "must use"


In general, when a new application has been allocated with a new<=
/o:p>


   Application Id and it also reuses existing commands with =
or without


   modifications, it must use the newly allocated Applicatio=
n Id in the


   header and in all relevant Application Id AVPs (Auth-Appl=
ication-Id


   or Acct-Application-Id) present in the commands message b=
ody.


[LM]  "In ge=
neral" must be removed and "must use" will be "should u=
se". 




- Editorial, section 5.5


OLD: 


   Based on these considerations, protocol designers sh=
ould carefully


   appraise whether the application currently defined relies=
 on it's own


   session management concept or whether 


 


NEW:


   Based on these considerations, protocol designers should =
carefully


   appraise whether the application currently defined relies=
 on its own


   session management concept or whether 


[LM] ok




- Editorial in section 5.7

OLD:


Destination- Realm


 


NEW:


Destination-Realm


[LM] ok






- The section 5.8 should mention RFC4005bis


[LM]=
 already covered by a previous comment
J






- Section 5.9


 Applications that do not understand these AVPs can discard=



   them upon receipt. 


Generic comment: Each time there is a sentence like =
this one above, we should mention RFC 6733 as the reference.

This document is not an extension/deviation to RFC 6733.


[LM] ok<=
/span>






- Do you have a good reason to add a reference to a work-in-progress that d=
idn't progress since 2001?


   [I-D.calhoun-diam=
eter-res-mgmt]


           &nbs=
p;  Calhoun, P., "Diameter Resource Management Extensions",<=
o:p>


           &nbs=
p;  draft-calhoun-diameter-res-mgmt-08.txt (work in progress),<=
o:p>


           &nbs=
p;  March 2001.


[LM] I think that it w=
as as illustration of general-purpose extension based on new commands. Othe=
r existing examples are only based on introduction of new AVP. But I agree =
that it is weird to make reference to expired drafts <=
span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:Wingdings;color:#=
1F497D">J &n=
bsp;I would rather refer to Realm-Based Redirection (RFC 7075) and Diameter=
 Priority AVP (RFC6735)




- Editorial (section 6)

I can't parse the following sentence:


 Backward Compatibility:


 


      With the design of generic extensions a=
n protocol designer has to


      consider with potential concerns about =
how existing applications


      deal with the new extension they do not=
 understand. 


[LM] what about:


 


   &nbs=
p;  When defining generic extensions desig=
ned to be supported by existing


      Diameter applicati=
ons, protocol design=
ers have to consider the 


   &nbs=
p;  potential impacts of the introduction of the new extension on=
 the behavior 


   &nbs=
p;  of node that would not be yet upgraded to support/understand =
this new extension.


 

=


- Contributors:

If Victor and Hannes are authors, then they shouldn't be in the contributor=
s list.


[LM] this list gives the members of the design t=
eam, not the contributors.


=


Btw, I don't see an affiliation for Victor in the document header. I=
 believe the common practice is to write down "consultant"


[LM] I will try to contact him to see what he wo=
uld like to see indicated as affiliation.


=




Did the WG ever considered the following questions:

- Any naming convention for new applications?


[LM] no convention so far.=



=


- When it is not a good idea to define diameter applications? Let me=
 make something up: to push syslog message


[LM] let me two days and I will define a nice ap=
plication for that
J I cannot see real key criteria to formally
 say "defining a Diameter application for that purpose is a bad idea&q=
uot;. If your example was for "to reinvent the wheel", it seems t=
hat this is only a criterion for WG chairs and Ads, but not anymore for the=
 industry.



=




Regards, Benoit


=
 

=





 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E54D5C4PEXCVZYM13corpora_-- From nobody Wed Apr 9 05:03:58 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001581A0227 for ; Wed, 9 Apr 2014 05:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8qD14dElGaG for ; Wed, 9 Apr 2014 05:03:54 -0700 (PDT) Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) by ietfa.amsl.com (Postfix) with ESMTP id 719A21A0223 for ; Wed, 9 Apr 2014 05:03:54 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id na10so2223770bkb.18 for ; Wed, 09 Apr 2014 05:03:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=7frtf44KMRC4MNznOpAs6ha+hklqGxGm321Ud0t0jz4=; b=d7NorI+ekFl/o5TG1PhSLbckeWfWtllZiLUm/Mw4/QZiHbIo/A9kCAUfN/wEUdulgy vU3DJE85AOhlm/SVfo2fJzSmDUdFqqiYUI9s9VOlM39cu5KqiM3N7QseSBhuoMdARNfX nC6SlI5Vso6u9pjN/wVWMUHotCF2R7YX4a6pEnH1w+hUd92wi9MVZ41Bh6p6XMOjd6fy ujIuYsE2znhaClYj05htT2CQe5s40slZLvbC2oArw9zt8+6iq1CzfFRBWhi7XiTPCick ysnn4bMzOVLSYZVq0wWcNYabNo4Q7GVDQR+BhIfCtWhpUC7pO1E9FJVbmW0U2kBc9FOY vMUg== X-Gm-Message-State: ALoCoQkEqv8WzuRJ5Iw4Yfbyb2qtfVx+ISMXxUXgSf1hgl/ZDkHmHebLjYzbnaFS7nv7M5AwvXEK X-Received: by 10.204.247.134 with SMTP id mc6mr86327bkb.69.1397045033177; Wed, 09 Apr 2014 05:03:53 -0700 (PDT) Received: from Avis-MacBook-Air.local (CPE5c5948c48b53-CM602ad089cf9c.cpe.net.cable.rogers.com. [99.224.54.118]) by mx.google.com with ESMTPSA id ci7sm1932015bkc.0.2014.04.09.05.03.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 05:03:52 -0700 (PDT) Message-ID: <53453724.9030009@lior.org> Date: Wed, 09 Apr 2014 08:03:48 -0400 From: Avi Lior User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: dime mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/v7TMp7xBjZHyEgtWzNFWQEVsZ0M Subject: [Dime] Questions regarding RFC6924 Diameter Support for ERP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Apr 2014 12:03:56 -0000 Hi folks I was reading 6696 and 6924 (it's been awhile) and I need clarification: 1) It appears that 6924 does not support transportation of DSRK key. Only rRK and rMSK. Is that correct? 2) According to RFC 6696 - section 4.2: RFC 6696: Section 4.2: o The rRK MUST remain on the peer and the server that derived it and MUST NOT be transported to any other entity. So why is 6942 transporting the rRK around? Avi Lior From nobody Wed Apr 9 21:33:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3D81A008B for ; Wed, 9 Apr 2014 21:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.816 X-Spam-Level: * X-Spam-Status: No, score=1.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ-ygiXLpbzD for ; Wed, 9 Apr 2014 21:33:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 92EC41A0425 for ; Wed, 9 Apr 2014 21:33:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCY10282; Thu, 10 Apr 2014 04:33:10 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 05:31:31 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 05:32:48 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 10 Apr 2014 12:32:45 +0800 From: Qin Wu To: Avi Lior , dime mailing list Thread-Topic: [Dime] Questions regarding RFC6924 Diameter Support for ERP Thread-Index: AQHPU+vPu85QOCj5+EC973FcklW1kZsKQmbQ Date: Thu, 10 Apr 2014 04:32:44 +0000 Message-ID: References: <53453724.9030009@lior.org> In-Reply-To: <53453724.9030009@lior.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.114] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6dpxrO0Ig-VnqzOebuAmsWYbY6c Subject: [Dime] =?gb2312?b?tPC4tDogIFF1ZXN0aW9ucyByZWdhcmRpbmcgUkZDNjky?= =?gb2312?b?NCBEaWFtZXRlciBTdXBwb3J0IGZvciBFUlA=?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Apr 2014 04:33:18 -0000 clJLIGlzIGVxdWl2YWxlbnQgdG8gckRTUkssIFNlZSBzZWN0aW9uIDI6DQoiDQpUaGUgcmUtYXV0 aGVudGljYXRpb24gRG9tYWluLVNwZWNpZmljIFJvb3QgS2V5IChyRFNSSykgaXMgYQ0KcmUtYXV0 aGVudGljYXRpb24gUm9vdCBLZXkgKHJSSykgW1JGQzY2OTZdIGRlcml2ZWQgZnJvbSB0aGUgRG9t YWluLQ0KU3BlY2lmaWMgUm9vdCBLZXkgKERTUkspIGluc3RlYWQgb2YgdGhlIEVNU0suDQoiDQoN ClJGQzY5NDIgc3VwcG9ydCB0cmFuc3BvcnRhdGlvbiBvZiByRFNSSy4gV2hlbiBFUiBzZXJ2ZXIg Y2hhbmdlLCBuZXcgckRTUksgbmVlZHMgdG8gYmUgZ2VuZXJhdGVkIGFuZCB0cmFuc3BvcnRlZCB0 byB0aGUgbmV3IEVSIHNlcnZlci4NClRoZSBwZWVyIGluIFJGQzY2OTYgaXMgcmVmZXJyZWQgdG8g RVIgY2xpZW50IG5vdCBEaWFtZXRlciBQZWVyLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS3Tyrz+ 1K28/i0tLS0tDQq3orz+yMs6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddILT6 se0gQXZpIExpb3INCreiy83KsbzkOiAyMDE0xOo01MI5yNUgMjA6MDQNCsrVvP7IyzogZGltZSBt YWlsaW5nIGxpc3QNCtb3zOI6IFtEaW1lXSBRdWVzdGlvbnMgcmVnYXJkaW5nIFJGQzY5MjQgRGlh bWV0ZXIgU3VwcG9ydCBmb3IgRVJQDQoNCkhpIGZvbGtzDQoNCkkgd2FzIHJlYWRpbmcgNjY5NiBh bmQgNjkyNCAoaXQncyBiZWVuIGF3aGlsZSkgIGFuZCBJIG5lZWQgY2xhcmlmaWNhdGlvbjoNCg0K DQoxKSBJdCBhcHBlYXJzIHRoYXQgNjkyNCBkb2VzIG5vdCBzdXBwb3J0IHRyYW5zcG9ydGF0aW9u IG9mIERTUksga2V5LiANCk9ubHkgclJLIGFuZCByTVNLLiAgSXMgdGhhdCBjb3JyZWN0Pw0KDQoy KSBBY2NvcmRpbmcgdG8gUkZDIDY2OTYgLSBzZWN0aW9uIDQuMjoNCg0KUkZDIDY2OTY6IFNlY3Rp b24gNC4yOg0KDQogICAgIG8gIFRoZSByUksgTVVTVCByZW1haW4gb24gdGhlIHBlZXIgYW5kIHRo ZSBzZXJ2ZXIgdGhhdCBkZXJpdmVkIGl0IGFuZCBNVVNUIE5PVCBiZSB0cmFuc3BvcnRlZCB0byBh bnkgb3RoZXIgZW50aXR5Lg0KDQpTbyB3aHkgaXMgNjk0MiB0cmFuc3BvcnRpbmcgdGhlIHJSSyBh cm91bmQ/IA0KDQpBdmkgTGlvcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K From nobody Sat Apr 12 13:56:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0381A023A for ; Sat, 12 Apr 2014 13:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8_9SWny7hgw for ; Sat, 12 Apr 2014 13:56:47 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 56E531A0240 for ; Sat, 12 Apr 2014 13:56:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:40991 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WZ4yj-0006U9-3Y; Sat, 12 Apr 2014 22:56:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Sat, 12 Apr 2014 20:56:45 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/64 Message-ID: <064.dfc0928b64407199101015baf6a75c70@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-xVC61wPSNuxpa4BXMazzkwo8OI Cc: dime@ietf.org Subject: [Dime] [dime] #64 (draft-docdt-dime-ovli): test X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 12 Apr 2014 20:56:49 -0000 #64: test test -- ------------------------------------+------------------------------------ Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: ------------------------------------+------------------------------------ Ticket URL: dime From nobody Mon Apr 14 06:07:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D2F1A0460 for ; Mon, 14 Apr 2014 06:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.072 X-Spam-Level: X-Spam-Status: No, score=-7.072 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZFylnlu-Q9u for ; Mon, 14 Apr 2014 06:07:31 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 36D8E1A0467 for ; Mon, 14 Apr 2014 06:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=84042; q=dns/txt; s=iport; t=1397480845; x=1398690445; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=lpnQam1tg2ZFoSDZIyp1LIvkuBkwcKNQY9ljQ17MTVs=; b=CB2n0vrthj1r+8h/kwajtiKR3QVb53oGRcOq9Vx0nzfnxhbBXz+pNYVu edc8Xe6LWOda5+O89B1BjBwmliKlYR8GSqfYAEUPjYQzRiYiTb3rWDW2S yvpW7RVeT+kZXB8wM4/J+c5zHMtD8cN+ZBn6XIJKr9Bg3J8Hq1MJnhkFO w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAAXdS1OtJssW/2dsb2JhbABZgkJ/iUS6M4E1dIIeBwEBAQMBGgESOgcKAQULCyEWAQEGBwkDAgECATQRBgEMAQUCAQEQhTUHgiQIDcscF4lGhDsJAhEBDiAiBgGEOAEDhWGHH4thgTaFHn2KcoMzO4EsAgcX X-IronPort-AV: E=Sophos; i="4.97,857,1389744000"; d="scan'208,217"; a="13171179" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 14 Apr 2014 13:07:23 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3ED7M1D018531; Mon, 14 Apr 2014 13:07:22 GMT Message-ID: <534BDD8A.7040800@cisco.com> Date: Mon, 14 Apr 2014 15:07:22 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "draft-ietf-dime-app-design-guide.all@tools.ietf.org" References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> <22885_1396976646_53442C06_22885_3037_1_6B7134B31289DC4FAF731D844122B36E54D5C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <22885_1396976646_53442C06_22885_3037_1_6B7134B31289DC4FAF731D844122B36E54D5C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------080500000801010504000004" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kyInrHw2ZHN0N57-NMPpqifV0KU Cc: "Heather Flanagan \(RFC Series Editor\)" , dime mailing list Subject: Re: [Dime] AD review draft-ietf-dime-app-design-guide X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Apr 2014 13:07:38 -0000 This is a multi-part message in MIME format. --------------080500000801010504000004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Lionel, > > Hi Benoit, > > Thank you for the deep review. > > Please find my feedback below. > > Regards, > > Lionel > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Benoit Claise > *Envoyé :* mercredi 2 avril 2014 11:04 > *À :* draft-ietf-dime-app-design-guide.all@tools.ietf.org > *Cc :* dime mailing list > *Objet :* [Dime] AD review draft-ietf-dime-app-design-guide > > Dear authors, > > Sorry for dropping the ball on this one. > If any of the points was already discussed/addressed by the WG, feel > free to let me know. > > > > - When I read the document, it looked to me as a BCP. > > BCP definition from RFC 2026: > > 5. BEST CURRENT PRACTICE (BCP) RFCs > > > > The BCP subseries of the RFC series is designed to be a way to > > standardize practices and the results of community deliberations. > > Interestingly, the charter mentions: > > May 2012, Submit 'Diameter Application Design Guidelines' to the IESG > for consideration as a BCP document > > */[LM] discussed in another email thread./* > > > If you go to BCP, don't forget to update the abstract, and the writeup. > Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013) > Example: > OLD: > > Diameter > protocol designers are then strongly advised to carefully consider > > NEW: > > Diameter > protocol designers SHOULD NOT consider > > > OLD: > > Instead of using > an Enumerated AVP for a Boolean flag, protocol designers are again > encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which > the data field would be defined as > > > NEW: > > Instead of using > an Enumerated AVP for a Boolean flag, protocol designers SHOULD > use AVPs of type Unsigned32 or Unsigned64 AVP in which > the data field would be defined as > > Finally, with a BCP, RFC 6733 could be a normative reference, which I > believe it should. > > > - Editorial > Please don't use "we" in RFCs > > */[LM] Should I say "I"? /**/J/* > [BC] That's one of those rules I received from my previous ADs, and that I've been applying blindly In fact, I can't find it at http://www.rfc-editor.org/rfc-style-guide/rfc-style Copying Heather, who might be able to shed some light. > > *//* > > > > - > Section 3 > > Major Extension: Enhancing an application that requires the > definition of a new Diameter application. > > Typical examples would be the creation of a new command for > providing functionality not supported by existing applications or > the definition of a new AVP with the M-bit set to be carried in an > existing command. For such extension, a significant specification > effort is required and a careful approach is recommended. > > Do you want to mention that Major Extension have backward > compatibility issue, as opposed to the minor one? > > */[LM] Yes. I'm assuming that you would prefer to say it explicitly./* > [BC] Yes. > > *//* > > > > - Editorial > > Typical examples would be the creation of a new command for > providing functionality not supported by existing applications or > the definition of a new AVP with the M-bit set to be carried in an > existing command. For such extension, a significant specification > effort is required and a careful approach is recommended. > > NEW: > > Typical examples would be the creation of a new command for > providing functionality not supported by existing applications or > the definition of a new mandatory AVP set to be carried in an > existing command. For such extension, a significant specification > effort is required and a careful approach is recommended. > > Justification: > > * Minor extension speaks about "optional" > * The M-bit is explained in 4.3.1 > */[LM] I would say that "mandatory" and "M-bit" set are the same and you need to refer to RFC6733 to understand the meaning anyway. But I would be prefer to keep "M-bit set" to avoid the common ambiguity with "required AVP" that indicates the mandatory presence of an AVP. I can add an explicit reference to section 4.1. of RFC6733./* [BC] Ok > > > - Section 3 > I see Minor Extension versus Major Extension, and I tried to match the > following classifications to Minor or Major > > 1. Addition of new functionality to an existing Diameter application > without defining a new application. > > 2. Addition of new functionality to an existing Diameter application > that requires the definition of a new application. > > 3. The definition of an entirely new Diameter application to offer > functionality not supported by existing applications. > > 4. The definition of a new generic functionality that can be reused > across different applications. > > 2 and 3 are Major > > */[LM] right/* > > *//* > > > For 1, I thought about Minor, but the following sentence "or the > definition of a new AVP with the M-bit set to be carried in an > existing command." in the Major paragraph confuses me. > > */[LM] (1) is "Minor" as no new application is required. If the new functionality would have been supported by an AVP with the M-bit set, it would have caused the creation of a new application (cf. section 4.3.1: "/*A mandatory AVP cannot be added to an existing command without defining a new Diameter application*/"/* > > > I guess that 4 is Major, but it's not mentioned. > > */[LM] can be both as described in section 6./* > > > Can you please better explain the mapping between the 4 categories and > Minor/Major extensions > > */[LM] the whole document is about clarifying these points. Each point > is further described in the section 4, 5 and 6. /* > > > Alternatively, or maybe on top of that, explain which of 4.X and 5.X > are Minor/Major extensions would be beneficial. > > */[LM] I will try to clarify when required by highlighting "Minor/Major"/* > [BC] perfect. > > *//* > > > > - Section 3 > I don't understand what your message is with: > > We would also like to remind that the definition of a new Diameter > application and the definition of a new command should be something > to avoid as much as possible. In the past, there has been some > reluctance to define new commands and new applications. With the > modified extensibility rules provided by [RFC6733 ], registering new > commands and new applications does not lead to additional overhead > for the specification author in terms of standardization process. > Registering new functionality (new commands, new AVPs, new > applications, etc.) with IANA remains important to avoid namespace > collisions, which will likely lead to deployment problems. > > "should be something to avoid as much as possible", is this valid today? > Because the next sentence speaks about the past, then the next > sentence seems like it's fixed now with 6733. > > */[LM] Some inconsistency due to the modification of the IANA > allocation modalities. I propose to:/* > > -*/ remove the first sentence./* > > -*/Clarify that "in the past" refers to RFC3588/* > > -*/Remove the last sentence as it is somehow clarify in the section 7./* > > -*/Add a sentence that the general guideline "try to reuse as much as > possible" still applies./* > > *//* > [BC] I'll review the proposed text. > > > - Editorial: > > With the > modified extensibility rules provided by [RFC6733 ], registering new > commands and new applications does not lead to additional overhead > for the specification author in terms of standardization process. > Registering new functionality (new commands, new AVPs, new > applications, etc.) > > "etc.": What does it refer to? new AVP value is the only one I can > think of. > Worth removing "etc." and specifying the full list? > > */[LM] removed./* > > > - Application and command > > Major Extension: Enhancing an application that requires the > definition of anew Diameter application. > > Typical examples would be the creation of anew command for > providing functionality not supported by existing applications or > the definition of a new AVP with the M-bit set to be carried in an > existing command. For such extension, a significant specification > effort is required and a careful approach is recommended. > > > 4.1 > . > Adding a New Command > > Adding a new command is considered as a major extension and requires > a new Diameter application to be defined. > > I'm not clear on the application/command boundary. > Why do we need a new application for a new command? > > */[LM] using an unknown command in an existing application will cause > a protocol error as per the RFC 6733./* > > DIAMETER_COMMAND_UNSUPPORTED 3001 > > This error code is used when a Diameter entity receives a message > > with a Command Code that it does not support. > > */Therefore non-supporting nodes will never be able to process the > request./* > > > Why can't I add a command to an existing application? > There are commands that are for all applications/independent of the > application, no? > CER/CEA (Capabilities-Exchange-Request) > > */[LM] CER/CEA are part of an application, the application "0" i.e. > the base protocol. The requirement is that all diameter peers support > AT LEAST the base protocol application./* > > > This contradicts: > > Before adding or_importing_a command, application designers > should consider the following ... > */[LM] here, we are in the section "Adding a new command to an existing application" and it is clearly said that it is a major extension that will cause the creation of a new application./* > > This also appears to contradict, in section 6 > Generic Diameter extensions are AVPs, commands or applications that > are designed_to support other Diameter applications_. > */[LM] not so. Any new application can reuse an existing command. For instance, Session Termination commands are reused in every session-related applications./* > > > My issue comes from the fact that there are no "application" and > "command" definitions. > Draft says: > > > 2 > . > Terminology > > This document reuses the terminology defined in [RFC6733] > > However, RFC 6733 terminology doesn't contain the application and > command definitions. > Talking to Jouni, I now understand that a command is always specified > within the context of an application. > This should be clarified. > > */[LM] ok/* > > > > Also, from section 5.2: > > As a general recommendation, commands should not be defined from > scratch. It is instead recommend to re-use an existing command > offering similar functionality and use it as a starting point. > > Based on my latest understanding (a command is always specified within > the context of an application), the only justification for the above > text is code reuse, right. Please mention it. > > */[LM] it refers to the text in the section 3./* > > It will reduce the time to finalize > > specification writing, and it will lead to a smaller implementation > > effort as well as reduce the need for testing. In general, it is > > clever to avoid duplicate effort when possible. > > */Will be clarified./* > [BC] thanks. I will review all this command and application text with the new version. > > *//* > > > > - Editorial > > Adding a new command is considered as a major extension and requires > a new Diameter application to be defined. Adding a new command to an > application means ... > > A new command addition is always to an application, right? > If yes, why do you make the distinction between the sentences above > > */[LM] It is about adding a command to an EXISTING application. The > first sentence will say "/*Adding a new command to an existing > application is considered*/" and "to an application" will be removed > from the second sentence./* > > > > - Application version? > > An exception might be if the > intent of the deletion is to create a newer version of the same > application that is somehow simpler than the previous version. > > ... > > o Would the new AVP be used to differentiate between old and new > versions of the same application whereby the two versions are not > backward compatible? > > Readers might be understanding that diameter applications having a > version field. > This is not the case. Please rephrase. > > */[LM] I think we can speak about new version of the specification and > variant of the application/* > > > Also, mention that a new version of an application is a new application. > I guess it needs to be mentioned in 7.d > > */[LM] OK for the clarification but not in 7.d as this section is only > about interaction with IANA./* > [BC] Sure > > > - Section 4.3.2 > For the reader convenience, I would mention the convention behind { > AVP } and [ AVP ], or at least give a reference. > > */[LM] I would clarify that "/*a required AVP (an AVP indicated as {AVP} in the command CCF)*/" and"/*an optional AVP (an AVP indicated as [AVP] in the command CCF)*/"/* > > > > - Section 5.3 > OLD: > > Some existing > specifications do not adhere to this rule for historical reasons. > However, this guidance should be followed to avoid routing problems. > > NEW: > Some existing > specifications do not adhere to this rule for historical reasons. > However, this guidance should be followed for new applications to avoid routing problems. > */[LM] ok/* > > > In the same section, why "In general" in the next sentence? It > contradicts with "must use" > > In general, when a new application has been allocated with a new > Application Id and it also reuses existing commands with or without > modifications, it must use the newly allocated Application Id in the > header and in all relevant Application Id AVPs (Auth-Application-Id > or Acct-Application-Id) present in the commands message body. > */[LM] "In general" must be removed and "must use" will be "should use"./* > > > - Editorial, section 5.5 > > OLD: > Based on these considerations, protocol designers should carefully > appraise whether the application currently defined relies on it's own > session management concept or whether > > NEW: > Based on these considerations, protocol designers should carefully > appraise whether the application currently defined relies on its own > session management concept or whether > */[LM] ok/* > > > - Editorial in section 5.7 > OLD: > > Destination- Realm > > NEW: > Destination-Realm > */[LM] ok/* > > > > - The section 5.8 should mention RFC4005bis > > */[LM] already covered by a previous comment /**/J/**//* > > > > - Section 5.9 > > Applications that do not understand these AVPs can discard > them upon receipt. > > Generic comment: Each time there is a sentence like this one above, we > should mention RFC 6733 as the reference. > This document is not an extension/deviation to RFC 6733. > > */[LM] ok/* > > > > - Do you have a good reason to add a reference to a work-in-progress > that didn't progress since 2001? > > [I-D.calhoun-diameter-res-mgmt] > Calhoun, P., "Diameter Resource Management Extensions", > draft-calhoun-diameter-res-mgmt-08.txt (work in progress), > March 2001. > */[LM] I think that it was as illustration of general-purpose extension based on new commands. Other existing examples are only based on introduction of new AVP. But I agree that it is weird to make reference to expired drafts/**/J/**/ I would rather refer to Realm-Based Redirection (RFC 7075) and Diameter Priority AVP (RFC6735)/* > > > - Editorial (section 6) > I can't parse the following sentence: > > Backward Compatibility: > > With the design of generic extensions an protocol designer has to > consider with potential concerns about how existing applications > deal with the new extension they do not understand. > */[LM] what about:/* > */ /* > When defining generic extensionsdesigned to be supported by existing > Diameter applications, protocol designers have to consider the > potential impacts of the introduction of the new extension on the behavior > of node that would not be yet upgraded to support/understand this new extension. > [BC] Fine > > > - Contributors: > If Victor and Hannes are authors, then they shouldn't be in the > contributors list. > > */[LM] this list gives the members of the design team, not the > contributors./* > [BC] http://www.rfc-editor.org/policy.html#policy.auth When the RFC Editor refers to "contributors", we mean people, other than the authors, who also contributed significantly to the RFC > *//* > > > Btw, I don't see an affiliation for Victor in the document header. I > believe the common practice is to write down "consultant" > > */[LM] I will try to contact him to see what he would like to see > indicated as affiliation./* > > > > Did the WG ever considered the following questions: > - Any naming convention for new applications? > > */[LM] no convention so far./* > [BC] Ok, then. As an example, this was covered for IPFIX IE in RFC 7013 > > *//* > > > - When it is not a good idea to define diameter applications? Let me > make something up: to push syslog message > > */[LM] let me two days and I will define a nice application for that > /**/J/**/I cannot see real key criteria to formally say "defining a > Diameter application for that purpose is a bad idea". If your example > was for "to reinvent the wheel", it seems that this is only a > criterion for WG chairs and Ads, but not anymore for the industry. /* > [BC] Ok, then. I just don't want that, in 6 months from now, the WG comes up with a draft such as draft-shore-icmp-aup-12 , specifically for DIME. Regards, Benoit > > > Regards, Benoit > > > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------080500000801010504000004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Lionel,

Hi Benoit,

 

Thank you for the deep review.

Please find my feedback below.

 

Regards,

 

Lionel

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Benoit Claise
Envoyé : mercredi 2 avril 2014 11:04
À : draft-ietf-dime-app-design-guide.all@tools.ietf.org
Cc : dime mailing list
Objet : [Dime] AD review draft-ietf-dime-app-design-guide

 

Dear authors,

Sorry for dropping the ball on this one.
If any of the points was already discussed/addressed by the WG, feel free to let me know.



- When I read the document, it looked to me as a BCP.

BCP definition from RFC 2026:

5.  BEST CURRENT PRACTICE (BCP) RFCs
 
   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.

Interestingly, the charter mentions:

May 2012, Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document

[LM] discussed in another email thread.


If you go to BCP, don't forget to update the abstract, and the writeup.
Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013)
Example:
OLD:

Diameter
protocol designers are then strongly advised to carefully consider

NEW:

   Diameter
   protocol designers SHOULD NOT consider
 

OLD:

   Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers are again
   encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which
   the data field would be defined as


NEW:

   Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers SHOULD 
   use AVPs of type Unsigned32 or Unsigned64 AVP in which
   the data field would be defined as

Finally, with a BCP, RFC 6733 could be a normative reference, which I believe it should.


- Editorial
Please don't use "we" in RFCs

[LM] Should I say "I"? J

[BC] That's one of those rules I received from my previous ADs, and that I've been applying blindly
In fact, I can't find it at http://www.rfc-editor.org/rfc-style-guide/rfc-style
Copying Heather, who might be able to shed some light.



-
Section 3

  Major Extension:  Enhancing an application that requires the
      definition of a new Diameter application.
 
      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new AVP with the M-bit set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.

Do you want to mention that Major Extension have backward compatibility issue, as opposed to the minor one?

[LM] Yes. I'm assuming that you would prefer to say it explicitly.

[BC] Yes.



- Editorial

      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new AVP with the M-bit set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.

NEW:

      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new mandatory AVP set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.

Justification:

        * Minor extension speaks about "optional"
        * The M-bit is explained in 4.3.1
[LM] I would say that "mandatory" and "M-bit" set are the same and you need to refer to RFC6733 to understand the meaning anyway. But I would be prefer to keep "M-bit set" to avoid the common ambiguity with "required AVP" that indicates the mandatory presence of an AVP. I can add an explicit reference to section 4.1. of RFC6733.
[BC] Ok


- Section 3
I see Minor Extension versus Major Extension, and I tried to match the following classifications to Minor or Major

   1.  Addition of new functionality to an existing Diameter application
       without defining a new application.
 
   2.  Addition of new functionality to an existing Diameter application
       that requires the definition of a new application.
 
   3.  The definition of an entirely new Diameter application to offer
       functionality not supported by existing applications.
 
   4.  The definition of a new generic functionality that can be reused
       across different applications.

2 and 3 are Major

[LM] right



For 1, I thought about Minor, but the following sentence "or the definition of a new AVP with the M-bit set to be carried in an existing command." in the Major paragraph confuses me.

[LM] (1) is "Minor" as no new application is required. If the new functionality would have been supported by an AVP with the M-bit set, it would have caused the creation of a new application (cf. section 4.3.1: "A mandatory AVP cannot be added to an existing command without defining a new Diameter application"


I guess that 4 is Major, but it's not mentioned.

[LM] can be both as described in section 6.


Can you please better explain the mapping between the 4 categories and Minor/Major extensions

[LM] the whole document is about clarifying these points. Each point is further described in the section 4, 5 and 6.


Alternatively, or maybe on top of that, explain which of 4.X and 5.X are Minor/Major extensions would be beneficial.

[LM] I will try to clarify when required by highlighting "Minor/Major"

[BC] perfect.



- Section 3
I don't understand what your message is with:

   We would also like to remind that the definition of a new Diameter
   application and the definition of a new command should be something
   to avoid as much as possible.  In the past, there has been some
   reluctance to define new commands and new applications.  With the
   modified extensibility rules provided by [RFC6733], registering new
   commands and new applications does not lead to additional overhead
   for the specification author in terms of standardization process.
   Registering new functionality (new commands, new AVPs, new
   applications, etc.) with IANA remains important to avoid namespace
   collisions, which will likely lead to deployment problems.

"should be something to avoid as much as possible", is this valid today?
Because the next sentence speaks about the past, then the next sentence seems like it's fixed now with 6733.

[LM] Some inconsistency due to the modification of the IANA allocation modalities. I propose to:

-           remove the first sentence.

-          Clarify that "in the past" refers to RFC3588

-          Remove the last sentence as it is somehow clarify in the section 7.

-          Add a sentence that the general guideline "try to reuse as much as possible" still applies.

 

[BC] I'll review the proposed text.


- Editorial:

   With the
   modified extensibility rules provided by [RFC6733], registering new
   commands and new applications does not lead to additional overhead
   for the specification author in terms of standardization process.
   Registering new functionality (new commands, new AVPs, new
   applications, etc.)

"etc.": What does it refer to? new AVP value is the only one I can think of.
Worth removing "etc." and specifying the full list?

[LM] removed.


- Application and command

   Major Extension:  Enhancing an application that requires the
      definition of a new Diameter application.
 
      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new AVP with the M-bit set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.

4.1.  Adding a New Command

   Adding a new command is considered as a major extension and requires
   a new Diameter application to be defined.

I'm not clear on the application/command boundary.
Why do we need a new application for a new command?

[LM] using an unknown command in an existing application will cause a protocol error as per the RFC 6733.

   DIAMETER_COMMAND_UNSUPPORTED 3001

 

      This error code is used when a Diameter entity receives a message

      with a Command Code that it does not support.

Therefore non-supporting nodes will never be able to process the request.


Why can't I add a command to an existing application?
There are commands that are for all applications/independent of the application, no?
    CER/CEA (Capabilities-Exchange-Request)

[LM] CER/CEA are part of an application, the application "0" i.e. the base protocol. The requirement is that all diameter peers support AT LEAST the base protocol application.


This contradicts:

   Before adding or importing a command, application designers
   should consider the following ...
[LM] here, we are in the section "Adding a new command to an existing application" and it is clearly said that it is a major extension that will cause the creation of a new application.
 
This also appears to contradict, in section 6
   Generic Diameter extensions are AVPs, commands or applications that
   are designed to support other Diameter applications.
[LM] not so. Any new application can reuse an existing command. For instance, Session Termination commands are reused in every session-related applications.
 

My issue comes from the fact that there are no "application" and "command" definitions.
Draft says:

2.  Terminology

   This document reuses the terminology defined in [RFC6733]

However, RFC 6733 terminology doesn't contain the application and command definitions.
Talking to Jouni, I now understand that a command is always specified within the context of an application.
This should be clarified.

[LM] ok



Also, from section 5.2:

   As a general recommendation, commands should not be defined from
   scratch.  It is instead recommend to re-use an existing command
   offering similar functionality and use it as a starting point.

Based on my latest understanding (a command is always specified within the context of an application), the only justification for the above text is code reuse, right. Please mention it.

[LM] it refers to the text in the section 3.

   It will reduce the time to finalize

   specification writing, and it will lead to a smaller implementation

   effort as well as reduce the need for testing.  In general, it is

   clever to avoid duplicate effort when possible.

Will be clarified.

[BC] thanks. I will review all this command and application text with the new version.



- Editorial

   Adding a new command is considered as a major extension and requires
   a new Diameter application to be defined.  Adding a new command to an
   application means ...

A new command addition is always to an application, right?
If yes, why do you make the distinction between the sentences above

[LM] It is about adding a command to an EXISTING application. The first sentence will say "Adding a new command to an existing application is considered" and "to an application" will be removed from the second sentence.



- Application version?

An exception might be if the
   intent of the deletion is to create a newer version of the same
   application that is somehow simpler than the previous version.

        ...

   o  Would the new AVP be used to differentiate between old and new
      versions of the same application whereby the two versions are not
      backward compatible?

Readers might be understanding that diameter applications having a version field.
This is not the case. Please rephrase.

[LM] I think we can speak about new version of the specification and variant of the application


Also, mention that a new version of an application is a new application.
I guess it needs to be mentioned in 7.d

[LM] OK for the clarification but not in 7.d as this section is only about interaction with IANA.

[BC] Sure


- Section 4.3.2
For the reader convenience, I would mention the convention behind { AVP } and [ AVP ], or at least give a reference.

[LM] I would clarify that "a required AVP (an AVP indicated as {AVP} in the command CCF)" and "an optional AVP (an AVP indicated as [AVP] in the command CCF)"



- Section 5.3
OLD:

   Some existing
   specifications do not adhere to this rule for historical reasons.
   However, this guidance should be followed to avoid routing problems.
 
NEW:
   Some existing
   specifications do not adhere to this rule for historical reasons.
   However, this guidance should be followed for new applications to avoid routing problems.
[LM] ok


In the same section, why "In general" in the next sentence? It contradicts with "must use"

In general, when a new application has been allocated with a new
   Application Id and it also reuses existing commands with or without
   modifications, it must use the newly allocated Application Id in the
   header and in all relevant Application Id AVPs (Auth-Application-Id
   or Acct-Application-Id) present in the commands message body.
[LM]  "In general" must be removed and "must use" will be "should use".


- Editorial, section 5.5

OLD: 
   Based on these considerations, protocol designers should carefully
   appraise whether the application currently defined relies on it's own
   session management concept or whether 
 
NEW:
   Based on these considerations, protocol designers should carefully
   appraise whether the application currently defined relies on its own
   session management concept or whether 
[LM] ok


- Editorial in section 5.7
OLD:

Destination- Realm
 
NEW:
Destination-Realm
[LM] ok



- The section 5.8 should mention RFC4005bis

[LM] already covered by a previous comment J



- Section 5.9

 Applications that do not understand these AVPs can discard
   them upon receipt.

Generic comment: Each time there is a sentence like this one above, we should mention RFC 6733 as the reference.
This document is not an extension/deviation to RFC 6733.

[LM] ok



- Do you have a good reason to add a reference to a work-in-progress that didn't progress since 2001?

   [I-D.calhoun-diameter-res-mgmt]
              Calhoun, P., "Diameter Resource Management Extensions",
              draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
              March 2001.
[LM] I think that it was as illustration of general-purpose extension based on new commands. Other existing examples are only based on introduction of new AVP. But I agree that it is weird to make reference to expired drafts J  I would rather refer to Realm-Based Redirection (RFC 7075) and Diameter Priority AVP (RFC6735)


- Editorial (section 6)
I can't parse the following sentence:

 Backward Compatibility:
 
      With the design of generic extensions an protocol designer has to
      consider with potential concerns about how existing applications
      deal with the new extension they do not understand. 
[LM] what about:
 
      When defining generic extensions designed to be supported by existing
      Diameter applications, protocol designers have to consider the 
      potential impacts of the introduction of the new extension on the behavior 
      of node that would not be yet upgraded to support/understand this new extension.
 
[BC] Fine


- Contributors:
If Victor and Hannes are authors, then they shouldn't be in the contributors list.

[LM] this list gives the members of the design team, not the contributors.

[BC]
http://www.rfc-editor.org/policy.html#policy.auth
    When the RFC Editor refers to "contributors", we mean people, other than the authors, who also contributed significantly to the RFC


Btw, I don't see an affiliation for Victor in the document header. I believe the common practice is to write down "consultant"

[LM] I will try to contact him to see what he would like to see indicated as affiliation.



Did the WG ever considered the following questions:
- Any naming convention for new applications?

[LM] no convention so far.

[BC] Ok, then.
As an example, this was covered for IPFIX IE in RFC 7013


- When it is not a good idea to define diameter applications? Let me make something up: to push syslog message

[LM] let me two days and I will define a nice application for that J I cannot see real key criteria to formally say "defining a Diameter application for that purpose is a bad idea". If your example was for "to reinvent the wheel", it seems that this is only a criterion for WG chairs and Ads, but not anymore for the industry.

[BC]  Ok, then.
I just don't want that, in 6 months from now, the WG comes up with a draft such as draft-shore-icmp-aup-12, specifically for DIME.

Regards, Benoit


Regards, Benoit

 







 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------080500000801010504000004-- From nobody Mon Apr 14 06:08:21 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7071A01D4 for ; Mon, 14 Apr 2014 06:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss5bLo6DmXFB for ; Mon, 14 Apr 2014 06:08:05 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id B79C91A048A for ; Mon, 14 Apr 2014 06:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45661; q=dns/txt; s=iport; t=1397480878; x=1398690478; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=0E19PwezjpRv8T4ExedCODZHYKw3slVNT5k8BK2DYKY=; b=gVT3wHzP5pOGWaq/8nI7JiOuiyzbonyI6MqNRfBC4Cv1XOqLaoqH1E8u ep2R3vT/Gi8sdES1cCtOifRhpMcdBICkeSoCUxDb4/YDvVa4WkXN5AkJh s/Xu/4A+vN1nCZerzqFFtE0D/YA5exWyaP+gv8c6HrVR3qRVslhAjEprZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAEAAXdS1OtJssW/2dsb2JhbABZgkJ/iUS6M4E1dIImAQEEGhM6BwoBEAshFgEBBgcJAwIBAgE0EQYBDAEFAgEBEIdoDcscF4lGhDsJAhEBUAYBhDgBA4VhkwCBNoUei2+DMzuBLAkX X-IronPort-AV: E=Sophos; i="4.97,857,1389744000"; d="scan'208,217"; a="17276170" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 14 Apr 2014 13:07:56 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3ED7t2H023825; Mon, 14 Apr 2014 13:07:55 GMT Message-ID: <534BDDAB.1030603@cisco.com> Date: Mon, 14 Apr 2014 15:07:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "draft-ietf-dime-app-design-guide.all@tools.ietf.org" References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> <24395_1396893521_5342E751_24395_4614_1_6B7134B31289DC4FAF731D844122B36E54AE2F@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <24395_1396893521_5342E751_24395_4614_1_6B7134B31289DC4FAF731D844122B36E54AE2F@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------030601020808000105010309" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sk7QiPzvJkAOQ3BCX5wSoSoinUU Cc: dime mailing list Subject: Re: [Dime] Diameter Guidelines as BCP? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Apr 2014 13:08:11 -0000 This is a multi-part message in MIME format. --------------030601020808000105010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Lionel, No feedback after a week. I think it's time to apply this change. Regards, Benoit > > Hi Benoit, > > Defining this document as BCP makes sense. > > Any other feedback from the working group before modifying the > objective of this document? > > Regards, > > Lionel > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Benoit Claise > *Envoyé :* mercredi 2 avril 2014 11:04 > *À :* draft-ietf-dime-app-design-guide.all@tools.ietf.org > *Cc :* dime mailing list > *Objet :* [Dime] AD review draft-ietf-dime-app-design-guide > > Dear authors, > > Sorry for dropping the ball on this one. > If any of the points was already discussed/addressed by the WG, feel > free to let me know. > > > > - When I read the document, it looked to me as a BCP. > > BCP definition from RFC 2026: > > 5. BEST CURRENT PRACTICE (BCP) RFCs > > > > The BCP subseries of the RFC series is designed to be a way to > > standardize practices and the results of community deliberations. > > Interestingly, the charter mentions: > > May 2012, Submit 'Diameter Application Design Guidelines' to the IESG > for consideration as a BCP document > > > If you go to BCP, don't forget to update the abstract, and the writeup. > Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013) > Example: > OLD: > > Diameter > protocol designers are then strongly advised to carefully consider > > NEW: > > Diameter > protocol designers SHOULD NOT consider > > > OLD: > > Instead of using > an Enumerated AVP for a Boolean flag, protocol designers are again > encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which > the data field would be defined as > > > NEW: > > Instead of using > an Enumerated AVP for a Boolean flag, protocol designers SHOULD > use AVPs of type Unsigned32 or Unsigned64 AVP in which > the data field would be defined as > > Finally, with a BCP, RFC 6733 could be a normative reference, which I > believe it should. > > > - Editorial > Please don't use "we" in RFCs > > - > Section 3 > > Major Extension: Enhancing an application that requires the > definition of a new Diameter application. > > Typical examples would be the creation of a new command for > providing functionality not supported by existing applications or > the definition of a new AVP with the M-bit set to be carried in an > existing command. For such extension, a significant specification > effort is required and a careful approach is recommended. > > Do you want to mention that Major Extension have backward > compatibility issue, as opposed to the minor one? > > - Editorial > > Typical examples would be the creation of a new command for > providing functionality not supported by existing applications or > the definition of a new AVP with the M-bit set to be carried in an > existing command. For such extension, a significant specification > effort is required and a careful approach is recommended. > > NEW: > > Typical examples would be the creation of a new command for > providing functionality not supported by existing applications or > the definition of a new mandatory AVP set to be carried in an > existing command. For such extension, a significant specification > effort is required and a careful approach is recommended. > > Justification: > > * Minor extension speaks about "optional" > * The M-bit is explained in 4.3.1 > > > > - Section 3 > I see Minor Extension versus Major Extension, and I tried to match the > following classifications to Minor or Major > > 1. Addition of new functionality to an existing Diameter application > without defining a new application. > > 2. Addition of new functionality to an existing Diameter application > that requires the definition of a new application. > > 3. The definition of an entirely new Diameter application to offer > functionality not supported by existing applications. > > 4. The definition of a new generic functionality that can be reused > across different applications. > > 2 and 3 are Major > For 1, I thought about Minor, but the following sentence "or the > definition of a new AVP with the M-bit set to be carried in an > existing command." in the Major paragraph confuses me. > I guess that 4 is Major, but it's not mentioned. > Can you please better explain the mapping between the 4 categories and > Minor/Major extensions > Alternatively, or maybe on top of that, explain which of 4.X and 5.X > are Minor/Major extensions would be beneficial. > > - Section 3 > I don't understand what your message is with: > > We would also like to remind that the definition of a new Diameter > application and the definition of a new command should be something > to avoid as much as possible. In the past, there has been some > reluctance to define new commands and new applications. With the > modified extensibility rules provided by [RFC6733 ], registering new > commands and new applications does not lead to additional overhead > for the specification author in terms of standardization process. > Registering new functionality (new commands, new AVPs, new > applications, etc.) with IANA remains important to avoid namespace > collisions, which will likely lead to deployment problems. > > "should be something to avoid as much as possible", is this valid today? > Because the next sentence speaks about the past, then the next > sentence seems like it's fixed now with 6733. > > - Editorial: > > With the > modified extensibility rules provided by [RFC6733 ], registering new > commands and new applications does not lead to additional overhead > for the specification author in terms of standardization process. > Registering new functionality (new commands, new AVPs, new > applications, etc.) > > "etc.": What does it refer to? new AVP value is the only one I can > think of. > Worth removing "etc." and specifying the full list? > > > - Application and command > > Major Extension: Enhancing an application that requires the > definition of anew Diameter application. > > Typical examples would be the creation of anew command for > providing functionality not supported by existing applications or > the definition of a new AVP with the M-bit set to be carried in an > existing command. For such extension, a significant specification > effort is required and a careful approach is recommended. > > > 4.1 > . > Adding a New Command > > Adding a new command is considered as a major extension and requires > a new Diameter application to be defined. > > I'm not clear on the application/command boundary. > Why do we need a new application for a new command? > Why can't I add a command to an existing application? > There are commands that are for all applications/independent of the > application, no? > CER/CEA (Capabilities-Exchange-Request) > This contradicts: > > Before adding or_importing_a command, application designers > should consider the following ... > > This also appears to contradict, in section 6 > Generic Diameter extensions are AVPs, commands or applications that > are designed_to support other Diameter applications_. > > > My issue comes from the fact that there are no "application" and > "command" definitions. > Draft says: > > > 2 > . > Terminology > > This document reuses the terminology defined in [RFC6733] > > However, RFC 6733 terminology doesn't contain the application and > command definitions. > Talking to Jouni, I now understand that a command is always specified > within the context of an application. > This should be clarified. > > Also, from section 5.2: > > As a general recommendation, commands should not be defined from > scratch. It is instead recommend to re-use an existing command > offering similar functionality and use it as a starting point. > > Based on my latest understanding (a command is always specified within > the context of an application), the only justification for the above > text is code reuse, right. Please mention it. > > - Editorial > > Adding a new command is considered as a major extension and requires > a new Diameter application to be defined. Adding a new command to an > application means ... > > A new command addition is always to an application, right? > If yes, why do you make the distinction between the sentences above > > - Application version? > > An exception might be if the > intent of the deletion is to create a newer version of the same > application that is somehow simpler than the previous version. > > ... > > o Would the new AVP be used to differentiate between old and new > versions of the same application whereby the two versions are not > backward compatible? > > Readers might be understanding that diameter applications having a > version field. > This is not the case. Please rephrase. > Also, mention that a new version of an application is a new application. > I guess it needs to be mentioned in 7.d > > > - Section 4.3.2 > For the reader convenience, I would mention the convention behind { > AVP } and [ AVP ], or at least give a reference. > > - Section 5.3 > OLD: > > Some existing > specifications do not adhere to this rule for historical reasons. > However, this guidance should be followed to avoid routing problems. > > NEW: > Some existing > specifications do not adhere to this rule for historical reasons. > However, this guidance should be followed for new applications to avoid routing problems. > > > In the same section, why "In general" in the next sentence? It > contradicts with "must use" > > In general, when a new application has been allocated with a new > Application Id and it also reuses existing commands with or without > modifications, it must use the newly allocated Application Id in the > header and in all relevant Application Id AVPs (Auth-Application-Id > or Acct-Application-Id) present in the commands message body. > > > - Editorial, section 5.5 > > OLD: > Based on these considerations, protocol designers should carefully > appraise whether the application currently defined relies on it's own > session management concept or whether > > NEW: > Based on these considerations, protocol designers should carefully > appraise whether the application currently defined relies on its own > session management concept or whether > > > - Editorial in section 5.7 > OLD: > > Destination- Realm > > NEW: > Destination-Realm > > > > - The section 5.8 should mention RFC4005bis > > - Section 5.9 > > Applications that do not understand these AVPs can discard > them upon receipt. > > Generic comment: Each time there is a sentence like this one above, we > should mention RFC 6733 as the reference. > This document is not an extension/deviation to RFC 6733. > > - Do you have a good reason to add a reference to a work-in-progress > that didn't progress since 2001? > > [I-D.calhoun-diameter-res-mgmt] > Calhoun, P., "Diameter Resource Management Extensions", > draft-calhoun-diameter-res-mgmt-08.txt (work in progress), > March 2001. > > > - Editorial (section 6) > I can't parse the following sentence: > > Backward Compatibility: > > With the design of generic extensions an protocol designer has to > consider with potential concerns about how existing applications > deal with the new extension they do not understand. > > > - Contributors: > If Victor and Hannes are authors, then they shouldn't be in the > contributors list. > Btw, I don't see an affiliation for Victor in the document header. I > believe the common practice is to write down "consultant" > > Did the WG ever considered the following questions: > - Any naming convention for new applications? > - When it is not a good idea to define diameter applications? Let me > make something up: to push syslog message > > Regards, Benoit > > > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------030601020808000105010309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Lionel,

No feedback after a week. I think it's time to apply this change.

Regards, Benoit

Hi Benoit,

 

Defining this document as BCP makes sense.

Any other feedback from the working group before modifying the objective of this document?

 

Regards,

 

Lionel

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Benoit Claise
Envoyé : mercredi 2 avril 2014 11:04
À : draft-ietf-dime-app-design-guide.all@tools.ietf.org
Cc : dime mailing list
Objet : [Dime] AD review draft-ietf-dime-app-design-guide

 

Dear authors,

Sorry for dropping the ball on this one.
If any of the points was already discussed/addressed by the WG, feel free to let me know.



- When I read the document, it looked to me as a BCP.

BCP definition from RFC 2026:

5.  BEST CURRENT PRACTICE (BCP) RFCs
 
   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.

Interestingly, the charter mentions:

May 2012, Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document


If you go to BCP, don't forget to update the abstract, and the writeup.
Also, BCPs usually use the RFC2119 keywords (ex: RFC 7013)
Example:
OLD:

Diameter
protocol designers are then strongly advised to carefully consider

NEW:

   Diameter
   protocol designers SHOULD NOT consider
 

OLD:

   Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers are again
   encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which
   the data field would be defined as


NEW:

   Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers SHOULD 
   use AVPs of type Unsigned32 or Unsigned64 AVP in which
   the data field would be defined as

Finally, with a BCP, RFC 6733 could be a normative reference, which I believe it should.


- Editorial
Please don't use "we" in RFCs

-
Section 3

  Major Extension:  Enhancing an application that requires the
      definition of a new Diameter application.
 
      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new AVP with the M-bit set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.

Do you want to mention that Major Extension have backward compatibility issue, as opposed to the minor one?

- Editorial

      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new AVP with the M-bit set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.

NEW:

      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new mandatory AVP set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.

Justification:

        * Minor extension speaks about "optional"
        * The M-bit is explained in 4.3.1
 


- Section 3
I see Minor Extension versus Major Extension, and I tried to match the following classifications to Minor or Major

   1.  Addition of new functionality to an existing Diameter application
       without defining a new application.
 
   2.  Addition of new functionality to an existing Diameter application
       that requires the definition of a new application.
 
   3.  The definition of an entirely new Diameter application to offer
       functionality not supported by existing applications.
 
   4.  The definition of a new generic functionality that can be reused
       across different applications.

2 and 3 are Major
For 1, I thought about Minor, but the following sentence "or the definition of a new AVP with the M-bit set to be carried in an existing command." in the Major paragraph confuses me.
I guess that 4 is Major, but it's not mentioned.
Can you please better explain the mapping between the 4 categories and Minor/Major extensions
Alternatively, or maybe on top of that, explain which of 4.X and 5.X are Minor/Major extensions would be beneficial.

- Section 3
I don't understand what your message is with:

   We would also like to remind that the definition of a new Diameter
   application and the definition of a new command should be something
   to avoid as much as possible.  In the past, there has been some
   reluctance to define new commands and new applications.  With the
   modified extensibility rules provided by [RFC6733], registering new
   commands and new applications does not lead to additional overhead
   for the specification author in terms of standardization process.
   Registering new functionality (new commands, new AVPs, new
   applications, etc.) with IANA remains important to avoid namespace
   collisions, which will likely lead to deployment problems.

"should be something to avoid as much as possible", is this valid today?
Because the next sentence speaks about the past, then the next sentence seems like it's fixed now with 6733.

- Editorial:

   With the
   modified extensibility rules provided by [RFC6733], registering new
   commands and new applications does not lead to additional overhead
   for the specification author in terms of standardization process.
   Registering new functionality (new commands, new AVPs, new
   applications, etc.)

"etc.": What does it refer to? new AVP value is the only one I can think of.
Worth removing "etc." and specifying the full list?


- Application and command

   Major Extension:  Enhancing an application that requires the
      definition of a new Diameter application.
 
      Typical examples would be the creation of a new command for
      providing functionality not supported by existing applications or
      the definition of a new AVP with the M-bit set to be carried in an
      existing command.  For such extension, a significant specification
      effort is required and a careful approach is recommended.

4.1.  Adding a New Command

   Adding a new command is considered as a major extension and requires
   a new Diameter application to be defined.

I'm not clear on the application/command boundary.
Why do we need a new application for a new command?
Why can't I add a command to an existing application?
There are commands that are for all applications/independent of the application, no?
    CER/CEA (Capabilities-Exchange-Request)
This contradicts:

   Before adding or importing a command, application designers
   should consider the following ...
 
This also appears to contradict, in section 6
   Generic Diameter extensions are AVPs, commands or applications that
   are designed to support other Diameter applications.
 

My issue comes from the fact that there are no "application" and "command" definitions.
Draft says:

2.  Terminology

   This document reuses the terminology defined in [RFC6733]

However, RFC 6733 terminology doesn't contain the application and command definitions.
Talking to Jouni, I now understand that a command is always specified within the context of an application.
This should be clarified.

Also, from section 5.2:

   As a general recommendation, commands should not be defined from
   scratch.  It is instead recommend to re-use an existing command
   offering similar functionality and use it as a starting point.

Based on my latest understanding (a command is always specified within the context of an application), the only justification for the above text is code reuse, right. Please mention it.

- Editorial

   Adding a new command is considered as a major extension and requires
   a new Diameter application to be defined.  Adding a new command to an
   application means ...

A new command addition is always to an application, right?
If yes, why do you make the distinction between the sentences above

- Application version?

An exception might be if the
   intent of the deletion is to create a newer version of the same
   application that is somehow simpler than the previous version.

        ...

   o  Would the new AVP be used to differentiate between old and new
      versions of the same application whereby the two versions are not
      backward compatible?

Readers might be understanding that diameter applications having a version field.
This is not the case. Please rephrase.
Also, mention that a new version of an application is a new application.
I guess it needs to be mentioned in 7.d


- Section 4.3.2
For the reader convenience, I would mention the convention behind { AVP } and [ AVP ], or at least give a reference.

- Section 5.3
OLD:

   Some existing
   specifications do not adhere to this rule for historical reasons.
   However, this guidance should be followed to avoid routing problems.
 
NEW:
   Some existing
   specifications do not adhere to this rule for historical reasons.
   However, this guidance should be followed for new applications to avoid routing problems.


In the same section, why "In general" in the next sentence? It contradicts with "must use"

In general, when a new application has been allocated with a new
   Application Id and it also reuses existing commands with or without
   modifications, it must use the newly allocated Application Id in the
   header and in all relevant Application Id AVPs (Auth-Application-Id
   or Acct-Application-Id) present in the commands message body.


- Editorial, section 5.5

OLD: 
   Based on these considerations, protocol designers should carefully
   appraise whether the application currently defined relies on it's own
   session management concept or whether 
 
NEW:
   Based on these considerations, protocol designers should carefully
   appraise whether the application currently defined relies on its own
   session management concept or whether


- Editorial in section 5.7
OLD:

Destination- Realm
 
NEW:
Destination-Realm



- The section 5.8 should mention RFC4005bis

- Section 5.9

 Applications that do not understand these AVPs can discard
   them upon receipt.

Generic comment: Each time there is a sentence like this one above, we should mention RFC 6733 as the reference.
This document is not an extension/deviation to RFC 6733.

- Do you have a good reason to add a reference to a work-in-progress that didn't progress since 2001?

   [I-D.calhoun-diameter-res-mgmt]
              Calhoun, P., "Diameter Resource Management Extensions",
              draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
              March 2001.


- Editorial (section 6)
I can't parse the following sentence:

 Backward Compatibility:
 
      With the design of generic extensions an protocol designer has to
      consider with potential concerns about how existing applications
      deal with the new extension they do not understand.


- Contributors:
If Victor and Hannes are authors, then they shouldn't be in the contributors list.
Btw, I don't see an affiliation for Victor in the document header. I believe the common practice is to write down "consultant"

Did the WG ever considered the following questions:
- Any naming convention for new applications?
- When it is not a good idea to define diameter applications? Let me make something up: to push syslog message

Regards, Benoit

 







 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------030601020808000105010309-- From nobody Mon Apr 14 08:45:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EE71A0479 for ; Mon, 14 Apr 2014 08:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZlv7ghmAky4 for ; Mon, 14 Apr 2014 08:44:54 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 36E991A048A for ; Mon, 14 Apr 2014 08:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4169; q=dns/txt; s=iport; t=1397490290; x=1398699890; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ykpmeAbgg+oyBoMqzkDfDnvVxjJ6/iy8azuVaqmiliw=; b=UbhehLHC3TURBWLCHxhx03WjHKxsCd9g5krwhgRXQp+9AISex2p+5ahp 7oODv3lhYT81uSlil5zJR2NxpifoVm/Xlslxow2Up7QyU4iNIbssubVBp 7EvFzxS5bcZFFxExNLldeCcVJiiN6tBo2y7ysicvHpU8x32x6vWzc6PSM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEACcBTFOtJssW/2dsb2JhbABagkJ/w3mBOnSCJQEBAQR4ARALBBQJFg8JAwIBAgFFBgEMAQcBAYd4Dcs9F45uB4Q4AQOYYYZUi2+DMzs X-IronPort-AV: E=Sophos; i="4.97,857,1389744000"; d="scan'208,217"; a="13238411" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 14 Apr 2014 15:44:48 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3EFimel015599; Mon, 14 Apr 2014 15:44:48 GMT Message-ID: <534C0270.2060503@cisco.com> Date: Mon, 14 Apr 2014 17:44:48 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Heather Flanagan (RFC Series Editor)" , lionel.morand@orange.com, "draft-ietf-dime-app-design-guide.all@tools.ietf.org" References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> <22885_1396976646_53442C06_22885_3037_1_6B7134B31289DC4FAF731D844122B36E54D5C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <534BDD8A.7040800@cisco.com> <534BFDD1.9050608@rfc-editor.org> In-Reply-To: <534BFDD1.9050608@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------010206010005020004090104" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BRBGfaxbo9Ird-UDu-6XiskRrgA Cc: dime mailing list Subject: Re: [Dime] AD review draft-ietf-dime-app-design-guide X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Apr 2014 15:44:58 -0000 This is a multi-part message in MIME format. --------------010206010005020004090104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 14/04/2014 17:25, Heather Flanagan (RFC Series Editor) wrote: > Hello all, > >>> >>> - Editorial >>> Please don't use "we" in RFCs >>> >>> */[LM] Should I say "I"? /**/J/* >>> >> [BC] That's one of those rules I received from my previous ADs, and >> that I've been applying blindly >> In fact, I can't find it at >> http://www.rfc-editor.org/rfc-style-guide/rfc-style >> Copying Heather, who might be able to shed some light. >>> >>> *//* >>> >>> >>> > > I'm not certain where that guidance came from - the RFC Editor does > not have a problem with the use of "we" in an RFC. In fact, using > "we" is rather common, particularly for WG-generated RFCs. Thanks for your guidance. Regards, Benoit --------------010206010005020004090104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 14/04/2014 17:25, Heather Flanagan (RFC Series Editor) wrote:
Hello all,


- Editorial
Please don't use "we" in RFCs

[LM] Should I say "I"? J

[BC] That's one of those rules I received from my previous ADs, and that I've been applying blindly
In fact, I can't find it at http://www.rfc-editor.org/rfc-style-guide/rfc-style
Copying Heather, who might be able to shed some light.




I'm not certain where that guidance came from - the RFC Editor does not have a problem with the use of "we" in an RFC.  In fact, using "we" is rather common, particularly for WG-generated RFCs.

Thanks for your guidance.

Regards, Benoit


--------------010206010005020004090104-- From nobody Mon Apr 14 09:06:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F3C1A0479 for ; Mon, 14 Apr 2014 08:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AxA5N08RoV7 for ; Mon, 14 Apr 2014 08:25:13 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 746161A04BC for ; Mon, 14 Apr 2014 08:25:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 5852E1E12A7; Mon, 14 Apr 2014 08:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg7d-EfdYQiz; Mon, 14 Apr 2014 08:24:43 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (98-125-168-3.dyn.centurytel.net [98.125.168.3]) by c8a.amsl.com (Postfix) with ESMTPSA id C80791E12A4; Mon, 14 Apr 2014 08:24:42 -0700 (PDT) Message-ID: <534BFDD1.9050608@rfc-editor.org> Date: Mon, 14 Apr 2014 08:25:05 -0700 From: "Heather Flanagan (RFC Series Editor)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Benoit Claise , lionel.morand@orange.com, "draft-ietf-dime-app-design-guide.all@tools.ietf.org" References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> <22885_1396976646_53442C06_22885_3037_1_6B7134B31289DC4FAF731D844122B36E54D5C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <534BDD8A.7040800@cisco.com> In-Reply-To: <534BDD8A.7040800@cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------050908030202080205090407" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3wtUY1z5R9kNNlfAat2nwbbF2qk X-Mailman-Approved-At: Mon, 14 Apr 2014 09:06:40 -0700 Cc: dime mailing list Subject: Re: [Dime] AD review draft-ietf-dime-app-design-guide X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Apr 2014 15:25:18 -0000 This is a multi-part message in MIME format. --------------050908030202080205090407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all, >> >> - Editorial >> Please don't use "we" in RFCs >> >> */[LM] Should I say "I"? /**/J/* >> > [BC] That's one of those rules I received from my previous ADs, and > that I've been applying blindly > In fact, I can't find it at > http://www.rfc-editor.org/rfc-style-guide/rfc-style > Copying Heather, who might be able to shed some light. >> >> *//* >> >> >> I'm not certain where that guidance came from - the RFC Editor does not have a problem with the use of "we" in an RFC. In fact, using "we" is rather common, particularly for WG-generated RFCs. -Heather --------------050908030202080205090407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello all,


- Editorial
Please don't use "we" in RFCs

[LM] Should I say "I"? J

[BC] That's one of those rules I received from my previous ADs, and that I've been applying blindly
In fact, I can't find it at http://www.rfc-editor.org/rfc-style-guide/rfc-style
Copying Heather, who might be able to shed some light.




I'm not certain where that guidance came from - the RFC Editor does not have a problem with the use of "we" in an RFC.  In fact, using "we" is rather common, particularly for WG-generated RFCs.

-Heather
--------------050908030202080205090407-- From nobody Mon Apr 14 17:11:44 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBDD1A03EC; Mon, 14 Apr 2014 17:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYoPJVvcY1dU; Mon, 14 Apr 2014 17:11:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id E78661A06E5; Mon, 14 Apr 2014 17:10:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8F09E18000D; Mon, 14 Apr 2014 17:10:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140415001036.8F09E18000D@rfc-editor.org> Date: Mon, 14 Apr 2014 17:10:36 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/v6WmRObfa42bpLR-eH_MQ9X7zPU Cc: drafts-update-ref@iana.org, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 7155 on Diameter Network Access Server Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 00:11:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7155 Title: Diameter Network Access Server Application Author: G. Zorn, Ed. Status: Standards Track Stream: IETF Date: April 2014 Mailbox: glenzorn@gmail.com Pages: 70 Characters: 154559 Obsoletes: RFC4005 I-D Tag: draft-ietf-dime-rfc4005bis-14.txt URL: http://www.rfc-editor.org/rfc/rfc7155.txt This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Apr 14 17:12:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50D61A06C8; Mon, 14 Apr 2014 17:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9EZ7Glk77Dl; Mon, 14 Apr 2014 17:12:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A38D41A045B; Mon, 14 Apr 2014 17:11:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A70AC1801A4; Mon, 14 Apr 2014 17:10:50 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140415001050.A70AC1801A4@rfc-editor.org> Date: Mon, 14 Apr 2014 17:10:50 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AuqU4GXubNoz_r6j6zr__V6wTLs Cc: drafts-update-ref@iana.org, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 7156 on Diameter Support for Proxy Mobile IPv6 Localized Routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 00:12:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7156 Title: Diameter Support for Proxy Mobile IPv6 Localized Routing Author: G. Zorn, Q. Wu, J. Korhonen Status: Standards Track Stream: IETF Date: April 2014 Mailbox: glenzorn@gmail.com, bill.wu@huawei.com, jouni.nospam@gmail.com Pages: 11 Characters: 25657 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-pmip6-lr-18.txt URL: http://www.rfc-editor.org/rfc/rfc7156.txt In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol. This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Apr 14 22:26:56 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C211A0357 for ; Mon, 14 Apr 2014 22:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY6lZdD2gv36 for ; Mon, 14 Apr 2014 22:26:53 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 69B691A074C for ; Mon, 14 Apr 2014 22:26:53 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so6530932lan.12 for ; Mon, 14 Apr 2014 22:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OkbpRBFH1cCBDCUUQrZSx2unbqURuzatHJF6m8PeM24=; b=qO6vurLrFahupAjcXVGYGTlUZPfou2WrNYsBC6z1QO3p8LZhGGCYF3ipXWKHaRBqfX 4+IwWuj0t0fAhjDmjnzcdQGtIPnKmyKlmm/n+902eHvzhtlz4nDh/bJ2xVw5AEvu16Gq LYu9VjBu7R2l0ej2p+y//2lo0xz+v0cgT0bONZJPY9JH/9tR9njLxh8CODFaLpoh0Q6n gMfuqQ0emBb8g4L9UwXVpIrwvv2MZuUSeew9U0TOh0QKs8XVU+1EA5aR6osVfRAKGdv/ aDnF0WiNcPVIbBZ6uS87TSXhqviVmaZbOACd6Ai8Udd+Hd4fkJ9UO0PU9A2T2/uP7PhM KPZQ== X-Received: by 10.152.235.3 with SMTP id ui3mr32772229lac.2.1397539609852; Mon, 14 Apr 2014 22:26:49 -0700 (PDT) Received: from [10.37.155.233] ([77.95.242.69]) by mx.google.com with ESMTPSA id cq4sm17943466lad.5.2014.04.14.22.26.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Apr 2014 22:26:48 -0700 (PDT) Message-ID: <534CC2EB.4030009@gmail.com> Date: Tue, 15 Apr 2014 08:26:03 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dime@ietf.org References: <20140415001036.8F09E18000D@rfc-editor.org> In-Reply-To: <20140415001036.8F09E18000D@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PYqcDpwH4bw_avBdYUvybuLm3w4 Subject: Re: [Dime] RFC 7155 on Diameter Network Access Server Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 05:26:55 -0000 Congrats to the author and everybody who contributed! It took a while but out now. - Jouni & Lionel 4/15/2014 3:10 AM, rfc-editor@rfc-editor.org kirjoitti: > A new Request for Comments is now available in online RFC libraries. > > > RFC 7155 > > Title: Diameter Network Access Server Application > Author: G. Zorn, Ed. > Status: Standards Track > Stream: IETF > Date: April 2014 > Mailbox: glenzorn@gmail.com > Pages: 70 > Characters: 154559 > Obsoletes: RFC4005 > > I-D Tag: draft-ietf-dime-rfc4005bis-14.txt > > URL: http://www.rfc-editor.org/rfc/rfc7155.txt > > This document describes the Diameter protocol application used for > Authentication, Authorization, and Accounting services in the Network > Access Server (NAS) environment; it obsoletes RFC 4005. When > combined with the Diameter Base protocol, Transport Profile, and > Extensible Authentication Protocol specifications, this application > specification satisfies typical network access services requirements. > > This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/search > For downloading RFCs, see http://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > From nobody Mon Apr 14 22:29:44 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52D21A0357 for ; Mon, 14 Apr 2014 22:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuOD2jE2ty5o for ; Mon, 14 Apr 2014 22:29:39 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id BAADC1A0338 for ; Mon, 14 Apr 2014 22:29:38 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id mc6so6328514lab.8 for ; Mon, 14 Apr 2014 22:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=q7J8V/3wQV4HZgiexWVH235H24lDisrK+jCrYqMrMEA=; b=daJ6EEh7uFnJpr01F42/Vtjyje+mjP+EUeDXcl5pg20VjVFm0lrkJ8g3bXyM/r4hlX rFLsr9o+u8Dkwv7XzyACKDm2mJoCg4Ro0WDAXcV7o/I8QaiN02j9mR6l8Fq6Ba2bo8wW Z4RAcL+Pxs5j1KYnUHNFDeusiJWwoMl2i0zVaQ6alJ3JCNvaEO31Qw2bZt515zWbNAaQ aeVlVrCJZMg0bQ4qcGlP2Op/jjmX5yFARueNklaSJt7HtOhrIdk0MoIbkObuSMV7+C8j CFtPpjbUKJXWHqeAP2rtmhnXsr2tREe8i9jD3GSo6wAAEROxDT+fC9SLbadJBTveLsht xUrw== X-Received: by 10.152.116.99 with SMTP id jv3mr32706185lab.19.1397539775393; Mon, 14 Apr 2014 22:29:35 -0700 (PDT) Received: from [10.37.155.233] ([77.95.242.69]) by mx.google.com with ESMTPSA id fa8sm16203308lbc.18.2014.04.14.22.28.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Apr 2014 22:29:34 -0700 (PDT) Message-ID: <534CC376.3070206@gmail.com> Date: Tue, 15 Apr 2014 08:28:22 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dime@ietf.org References: <20140415001050.A70AC1801A4@rfc-editor.org> In-Reply-To: <20140415001050.A70AC1801A4@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kFDBIVA2WwCGYh0GL5PWNV4cI-k Subject: Re: [Dime] RFC 7156 on Diameter Support for Proxy Mobile IPv6 Localized Routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 05:29:43 -0000 Congrats to the authors and everybody that contributed. It definitely took a while but finally shipped. - Jouni & Lionel 4/15/2014 3:10 AM, rfc-editor@rfc-editor.org kirjoitti: > A new Request for Comments is now available in online RFC libraries. > > > RFC 7156 > > Title: Diameter Support for Proxy Mobile > IPv6 Localized Routing > Author: G. Zorn, Q. Wu, J. Korhonen > Status: Standards Track > Stream: IETF > Date: April 2014 > Mailbox: glenzorn@gmail.com, > bill.wu@huawei.com, > jouni.nospam@gmail.com > Pages: 11 > Characters: 25657 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-dime-pmip6-lr-18.txt > > URL: http://www.rfc-editor.org/rfc/rfc7156.txt > > In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the > Mobile Access Gateway (MAG) to which it is attached are typically > tunneled to a Local Mobility Anchor (LMA) for routing. The term > "localized routing" refers to a method by which packets are routed > directly between an MN's MAG and the MAG of its Correspondent Node > (CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, > it may be desirable to control the establishment of localized routing > sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring > that the session be authorized. This document specifies how to > accomplish this using the Diameter protocol. > > This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/search > For downloading RFCs, see http://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > From nobody Tue Apr 15 03:51:17 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C531A0798 for ; Tue, 15 Apr 2014 03:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.816 X-Spam-Level: * X-Spam-Status: No, score=1.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY7XBwFfoQ8m for ; Tue, 15 Apr 2014 03:51:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5CB1A075C for ; Tue, 15 Apr 2014 03:51:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFQ70008; Tue, 15 Apr 2014 10:51:08 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 11:49:17 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 11:50:49 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 18:50:42 +0800 From: Qin Wu To: Avi Lior Thread-Topic: =?gb2312?B?tPC4tDogW0RpbWVdIFF1ZXN0aW9ucyByZWdhcmRpbmcgUkZDNjkyNCBEaWFt?= =?gb2312?Q?eter_Support_for_ERP?= Thread-Index: AQHPU+vPu85QOCj5+EC973FcklW1kZsKQmbQgAISyICABivYsA== Date: Tue, 15 Apr 2014 10:50:42 +0000 Message-ID: References: <53453724.9030009@lior.org> <53484B57.8010404@lior.org> In-Reply-To: <53484B57.8010404@lior.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.114] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BWIRc_ZJxSm4PkUvqKxJKuM0c3E Cc: dime mailing list Subject: [Dime] =?gb2312?b?tPC4tDogtPC4tDogIFF1ZXN0aW9ucyByZWdhcmRpbmcg?= =?gb2312?b?UkZDNjkyNCBEaWFtZXRlciBTdXBwb3J0IGZvciBFUlA=?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 10:51:14 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IEF2aSBMaW9yIFttYWlsdG86YXZpLmlldGZAbGlv ci5vcmddIA0Kt6LLzcqxvOQ6IDIwMTTE6jTUwjEyyNUgNDowNw0KytW8/sjLOiBRaW4gV3UNCrOt y806IGRpbWUgbWFpbGluZyBsaXN0DQrW98ziOiBSZTogtPC4tDogW0RpbWVdIFF1ZXN0aW9ucyBy ZWdhcmRpbmcgUkZDNjkyNCBEaWFtZXRlciBTdXBwb3J0IGZvciBFUlANCg0KSGkgUWluLA0KDQpU aGlzIGlzIHN0aWxsIGNvbmZ1c2luZy4gUmVnYXJkaW5nIHF1ZXNpdG9uIDE6IFRoZSB3YXkgSSB1 bmRlcnN0YW5kIHRoZSBrZXkgaGllcmFyY2h5Og0KDQo2Njk2IGtleSBoaWVyYXJjaHkgZGVyaXZl cyBFUlAgcm9vdCBrZXkgclJLIGZyb20gRFNSSyBhbmQgY2FsbHMgaXMgRFMtclJLIG9yIGZyb20g RU1TSyBhbmQgY2FsbHMgaXQganVzdCByUksuIEFuZCBpbiBnZW5lcmFsIGNhbGwgYXQgdGhlIEVS UCByb290IGtleXMgclJLLg0KDQpEU1JLIGlzIGRlZmluZWQgYnkgUkZDIDUyOTUgYW5kIGlzIG5v dCBFUlAgc3BlY2lmaWMuDQoNCltRaW5dOiBDb3JyZWN0LCBEU1JLIG1heSBoYXZlIG90aGVyIHVz YWdlcy4NCg0KSW4gNjk0MiByUksgY2FuIGJlIHJEU1JLIHdoaWNoIGlzIERTLXJSSyBhcyBkZWZp bmVkIGJ5IDY2OTYgb3IgaXQgY2FuIGJlIHJSSywgdGhlIGtleSBkZXJpdmVkIGRpcmVjdGx5IGZy b20gRU1TSy4NCg0KU28gRFNSSyBpcyBub3QgdGhlIHNhbWUgYXMgckRTUksuIERpZCBJIGdldCB0 aGF0IHJpZ2h0PyANCg0KW1Fpbl06IEkgdGhpbmsgckRTUksgaXMgZGVyaXZlZCBmcm9tIERTUksu DQoNCmFuZCB0aHVzIDY5NDIgZG9lcyBub3QgYXBwZWFyIHRvIG1vdmUgRFNSSy4NCg0KW1Fpbl06 IFJGQzY2OTYgY2FuIG1vdmUgRFNSSyBmcm9tIGhvbWUgRUFQIHNlcnZlciB0byBsb2NhbCBFUiBz ZXJ2ZXIsIHNlZSBmaWd1cmUgMiBvZiBSRkM2Njk2LiBTbyBkb2VzIHJEU1JLLg0KDQpRdWVzdGlv biAyIHN0aWxsIHJlbWFpbiB1bmFuc3dlcmVkLiBhY2NvcmRpbmcgdG8gUkZDIDY2OTYgdGhlIHJS SyAtIHdoZXRoZXIgaXQgaXMgRFMtclJLIG9yIHJSSyBtdXN0IG5vdCBiZSB0cmFuc3BvcnRlZCBm cm9tIHdoZXJlIGl0IGlzIGRlcml2ZWQuIFlldCA2OTQyIHRyYW5zcG9ydHMgaXQgdG8gb3RoZXIg RVJQIGVudGl0aWVzLiBTbyB3aHkgaXMgUkZDDQo2OTQyIHZpb2xhdGluZyA2Njk2Pw0KDQpbUWlu XTogTXkgaW50ZXJwcmV0YXRpb24gdG8geW91ciBxdW90ZWQgdGV4dCBpbiBSRkM2Njk2IGlzIHJS SyBvciByRFNSSyB3aWxsIG5vdCBiZSB0cmFuc3BvcnRlZCBmcm9tIEVSIHNlcnZlciB0byBhdXRo ZW50aWNhdG9yIG9ubHkgck1TSyBnZW5lcmF0ZWQgb3IgZGVyaXZlZCBmcm9tIHJSSyBvciByRFNS SyBhdCB0aGF0IEVSIHNlcnZlciB3aWxsIGJlIHRyYW5zcG9ydGVkIGZyb20gdGhhdCBFUiBzZXJ2 ZXIgdG8gdGhlIEVSIGF1dGhlbnRpY2F0b3IuIA0KDQoNClFpbiBXdSB3cm90ZToNCj4gclJLIGlz IGVxdWl2YWxlbnQgdG8gckRTUkssIFNlZSBzZWN0aW9uIDI6DQo+ICINCj4gVGhlIHJlLWF1dGhl bnRpY2F0aW9uIERvbWFpbi1TcGVjaWZpYyBSb290IEtleSAockRTUkspIGlzIGEgDQo+IHJlLWF1 dGhlbnRpY2F0aW9uIFJvb3QgS2V5IChyUkspIFtSRkM2Njk2XSBkZXJpdmVkIGZyb20gdGhlIERv bWFpbi0gDQo+IFNwZWNpZmljIFJvb3QgS2V5IChEU1JLKSBpbnN0ZWFkIG9mIHRoZSBFTVNLLg0K PiAiDQo+DQo+IFJGQzY5NDIgc3VwcG9ydCB0cmFuc3BvcnRhdGlvbiBvZiByRFNSSy4gV2hlbiBF UiBzZXJ2ZXIgY2hhbmdlLCBuZXcgckRTUksgbmVlZHMgdG8gYmUgZ2VuZXJhdGVkIGFuZCB0cmFu c3BvcnRlZCB0byB0aGUgbmV3IEVSIHNlcnZlci4NCj4gVGhlIHBlZXIgaW4gUkZDNjY5NiBpcyBy ZWZlcnJlZCB0byBFUiBjbGllbnQgbm90IERpYW1ldGVyIFBlZXIuDQo+DQo+IFJlZ2FyZHMhDQo+ IC1RaW4NCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogRGlNRSBbbWFpbHRvOmRpbWUt Ym91bmNlc0BpZXRmLm9yZ10gtPqx7SBBdmkgTGlvcg0KPiC3osvNyrG85DogMjAxNMTqNNTCOcjV IDIwOjA0DQo+IMrVvP7IyzogZGltZSBtYWlsaW5nIGxpc3QNCj4g1vfM4jogW0RpbWVdIFF1ZXN0 aW9ucyByZWdhcmRpbmcgUkZDNjkyNCBEaWFtZXRlciBTdXBwb3J0IGZvciBFUlANCj4NCj4gSGkg Zm9sa3MNCj4NCj4gSSB3YXMgcmVhZGluZyA2Njk2IGFuZCA2OTI0IChpdCdzIGJlZW4gYXdoaWxl KSAgYW5kIEkgbmVlZCBjbGFyaWZpY2F0aW9uOg0KPg0KPg0KPiAxKSBJdCBhcHBlYXJzIHRoYXQg NjkyNCBkb2VzIG5vdCBzdXBwb3J0IHRyYW5zcG9ydGF0aW9uIG9mIERTUksga2V5LiANCj4gT25s eSByUksgYW5kIHJNU0suICBJcyB0aGF0IGNvcnJlY3Q/DQo+DQo+IDIpIEFjY29yZGluZyB0byBS RkMgNjY5NiAtIHNlY3Rpb24gNC4yOg0KPg0KPiBSRkMgNjY5NjogU2VjdGlvbiA0LjI6DQo+DQo+ ICAgICAgbyAgVGhlIHJSSyBNVVNUIHJlbWFpbiBvbiB0aGUgcGVlciBhbmQgdGhlIHNlcnZlciB0 aGF0IGRlcml2ZWQgaXQgYW5kIE1VU1QgTk9UIGJlIHRyYW5zcG9ydGVkIHRvIGFueSBvdGhlciBl bnRpdHkuDQo+DQo+IFNvIHdoeSBpcyA2OTQyIHRyYW5zcG9ydGluZyB0aGUgclJLIGFyb3VuZD8g DQo+DQo+IEF2aSBMaW9yDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IERpTUUgbWFpbGluZyBsaXN0DQo+IERpTUVAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCi0tDQpBdmkgTGlvcg0K PT09PT09DQpoOiArMS42MTMuODMxLjkwMzENCm06ICsxLjYxMy4zNTUuNzExMg0K From nobody Tue Apr 15 08:45:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD241A0742; Tue, 15 Apr 2014 08:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnRRJOUOYtnh; Tue, 15 Apr 2014 08:44:48 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E3D701A04A9; Tue, 15 Apr 2014 08:44:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AD8BB100ADF; Tue, 15 Apr 2014 17:44:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pmgs8jTc9wuR; Tue, 15 Apr 2014 17:44:44 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 7F64A1007F5; Tue, 15 Apr 2014 17:44:29 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.195]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 15 Apr 2014 17:44:29 +0200 From: Marco Liebsch To: Jouni Korhonen , "dime@ietf.org" , "dime-chairs@ietf.org" Thread-Topic: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 Thread-Index: AQHPTvQzhakcd18TJEWk4clwjG0cCpsS5K7Q Date: Tue, 15 Apr 2014 15:44:28 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D69871837@PALLENE.office.hd> References: <533CE1AD.3010407@gmail.com> In-Reply-To: <533CE1AD.3010407@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Bi5rF7baVxQ0-zYMNW_BbYCakaM Subject: Re: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 15:44:54 -0000 I support the adoption of this draft as WG document. marco >-----Original Message----- >From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >Sent: Donnerstag, 3. April 2014 06:21 >To: dime@ietf.org; dime-chairs@ietf.org >Subject: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attribu= tes-02 > >Folks, > >As discussed and agreed (and now verified with our AD), this email starts = a two >week adoption call for >draft-bertz-dime-congestion-flow-attributes-02 as a Dime WG document. >Express your support or opposition on the mailing list. The call ends 17th= April. > >Jouni & Lionel > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime From nobody Tue Apr 15 11:12:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743241A0657; Tue, 15 Apr 2014 11:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFs5ClWoN3H0; Tue, 15 Apr 2014 11:12:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC131A0376; Tue, 15 Apr 2014 11:12:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140415181206.16022.2956.idtracker@ietfa.amsl.com> Date: Tue, 15 Apr 2014 11:12:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/32punJYopE11EQZLMvSHXAbAHuo Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-22.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 18:12:07 -0000 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 Applications Design Guidelines Authors : Lionel Morand Victor Fajardo Hannes Tschofenig Filename : draft-ietf-dime-app-design-guide-22.txt Pages : 26 Date : 2014-04-15 Abstract: The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. It is meant as a guidelines document and therefore as informative in nature. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-app-design-guide-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 15 11:17:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3661B1A068D for ; Tue, 15 Apr 2014 11:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNgOivA_3Ila for ; Tue, 15 Apr 2014 11:17:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 342A01A0699 for ; Tue, 15 Apr 2014 11:17:08 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 7B7AC374598 for ; Tue, 15 Apr 2014 20:17:04 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 5C9C2158052 for ; Tue, 15 Apr 2014 20:17:04 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 15 Apr 2014 20:17:04 +0200 From: To: "dime@ietf.org" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-app-design-guide-22.txt Thread-Index: AQHPWNY3fvGPVJ2dG0Oj2EwF5KuGy5sS+tpQ Date: Tue, 15 Apr 2014 18:17:03 +0000 Message-ID: <24961_1397585824_534D77A0_24961_7486_1_6B7134B31289DC4FAF731D844122B36E55EE10@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20140415181206.16022.2956.idtracker@ietfa.amsl.com> In-Reply-To: <20140415181206.16022.2956.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.15.40019 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GNW-59nILHaQnKh-XKNzXZ_GAwo Subject: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-22.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 18:17:16 -0000 Hi, This version addresses the comments received after the AD review. Except some clarifications, main changes are moving the draft as BCP and, c= onsequently, the use of RFC2119 keywords (MUST/SHOULD, etc.) Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de internet-drafts@ie= tf.org Envoy=E9=A0: mardi 15 avril 2014 20:12 =C0=A0: i-d-announce@ietf.org Cc=A0: dime@ietf.org Objet=A0: [Dime] I-D Action: draft-ietf-dime-app-design-guide-22.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Applications Design Guidelines Authors : Lionel Morand Victor Fajardo Hannes Tschofenig Filename : draft-ietf-dime-app-design-guide-22.txt Pages : 26 Date : 2014-04-15 Abstract: The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. It is meant as a guidelines document and therefore as informative in nature. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Apr 16 22:40:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2BD1A002E for ; Wed, 16 Apr 2014 22:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6zJVeBL0Uoz for ; Wed, 16 Apr 2014 22:40:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B50821A002A for ; Wed, 16 Apr 2014 22:40:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:57031 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf3E-000687-DR; Thu, 17 Apr 2014 07:39:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:39:55 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/64#comment:1 Message-ID: <079.e52d3808cef108eb2961e8451beeca98@trac.tools.ietf.org> References: <064.dfc0928b64407199101015baf6a75c70@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <064.dfc0928b64407199101015baf6a75c70@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ru-TG9BYSeoa08DFub-UScVt16Q Cc: dime@ietf.org Subject: Re: [Dime] [dime] #64 (draft-ietf-dime-ovli): test X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:40:04 -0000 #64: test Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli Comment: Added a new component for the WG draft.. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | ------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:41:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D621A0078 for ; Wed, 16 Apr 2014 22:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4mOk7xOWRt5 for ; Wed, 16 Apr 2014 22:41:13 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 12BCD1A004A for ; Wed, 16 Apr 2014 22:41:13 -0700 (PDT) Received: from localhost ([127.0.0.1]:57089 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf4P-0006dm-BV; Thu, 17 Apr 2014 07:41:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:41:09 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/64#comment:2 Message-ID: <079.ac7f83fbeefe107d63a5bf29f7274b3c@trac.tools.ietf.org> References: <064.dfc0928b64407199101015baf6a75c70@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <064.dfc0928b64407199101015baf6a75c70@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/69lSOs1QmbG2UJ7f-i-xXArX-Yw Cc: dime@ietf.org Subject: Re: [Dime] [dime] #64 (draft-ietf-dime-ovli): test X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:41:14 -0000 #64: test Changes (by jouni.nospam@gmail.com): * status: new => closed * resolution: => fixed Comment: Works. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:43:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCE81A03E2 for ; Wed, 16 Apr 2014 22:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je936taEe6j2 for ; Wed, 16 Apr 2014 22:43:44 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 108F61A002A for ; Wed, 16 Apr 2014 22:43:44 -0700 (PDT) Received: from localhost ([127.0.0.1]:57153 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf6k-0007HW-Tb; Thu, 17 Apr 2014 07:43:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:43:34 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/26#comment:1 Message-ID: <081.7ff27b32cbeb27945d5792091c873ac1@trac.tools.ietf.org> References: <066.2786f2def6b2de11bbdc948e9deec92b@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <066.2786f2def6b2de11bbdc948e9deec92b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qzUDsJYNMv7mtPfVfeHHbJzanOw Cc: dime@ietf.org Subject: Re: [Dime] [dime] #26 (draft-ietf-dime-ovli): Overload Control Endpoints under specified X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:43:48 -0000 #26: Overload Control Endpoints under specified Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Submitted WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:44:15 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3891A0066 for ; Wed, 16 Apr 2014 22:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ORl80mYuv04 for ; Wed, 16 Apr 2014 22:44:06 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8E45B1A0420 for ; Wed, 16 Apr 2014 22:44:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:57184 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf7A-0007TD-SS; Thu, 17 Apr 2014 07:44:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:44:00 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/27#comment:3 Message-ID: <081.5b7f5f522cc45a35ea7c478597172caa@trac.tools.ietf.org> References: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Etiv16h2HNUe8Svg8DOFNzUqgAE Cc: dime@ietf.org Subject: Re: [Dime] [dime] #27 (draft-ietf-dime-ovli): Behavior of agent acting on behalf of Client that does not support DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:44:12 -0000 #27: Behavior of agent acting on behalf of Client that does not support DOIC Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-docdt-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: reopened Priority: critical | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Submitted WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:44:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECF31A0420 for ; Wed, 16 Apr 2014 22:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX9JND5OIMOb for ; Wed, 16 Apr 2014 22:44:27 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 491741A0066 for ; Wed, 16 Apr 2014 22:44:27 -0700 (PDT) Received: from localhost ([127.0.0.1]:57210 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf7S-0007af-AI; Thu, 17 Apr 2014 07:44:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:44:18 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/49#comment:1 Message-ID: <072.61c53446c859920b55d8abab0d0e6061@trac.tools.ietf.org> References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-y6lNErQ7VxEK5Vib4EMi4-7llw Cc: dime@ietf.org Subject: Re: [Dime] [dime] #49 (draft-ietf-dime-ovli): capabilities announcement mechanism needs to be rethought X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:44:29 -0000 #49: capabilities announcement mechanism needs to be rethought Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:44:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7AA1A002A for ; Wed, 16 Apr 2014 22:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf_ABQdJqQZe for ; Wed, 16 Apr 2014 22:44:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BC7B01A042C for ; Wed, 16 Apr 2014 22:44:38 -0700 (PDT) Received: from localhost ([127.0.0.1]:57235 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf7g-0007i5-K3; Thu, 17 Apr 2014 07:44:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:44:32 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/25#comment:1 Message-ID: <081.2eff058269cfa60c1f0a87b3cd8b3e63@trac.tools.ietf.org> References: <066.bb0f61f3d4c3a1f543554c66031a4edd@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <066.bb0f61f3d4c3a1f543554c66031a4edd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IubjGEyuAiXFmbCjJa_e2KlP010 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #25 (draft-ietf-dime-ovli): Section 3.1.5 Diameter Agent Behavior X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:44:44 -0000 #25: Section 3.1.5 Diameter Agent Behavior Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Submitted WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:45:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD161A002A for ; Wed, 16 Apr 2014 22:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F24yjMNsJEDC for ; Wed, 16 Apr 2014 22:44:55 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A21E11A0066 for ; Wed, 16 Apr 2014 22:44:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:57258 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf7z-0007pu-9I; Thu, 17 Apr 2014 07:44:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange-ftgroup.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:44:51 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/35#comment:3 Message-ID: <081.0cd5f430230e7aafb6aa626f495ac3ac@trac.tools.ietf.org> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Je4LPLCDOCl1H_-LPxkEl0BLkQA Cc: dime@ietf.org Subject: Re: [Dime] [dime] #35 (draft-ietf-dime-ovli): additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:44:59 -0000 #35: additional report types are proposed Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:45:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8201A0432 for ; Wed, 16 Apr 2014 22:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-mpstQdMdXU for ; Wed, 16 Apr 2014 22:45:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEC21A002A for ; Wed, 16 Apr 2014 22:45:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:57276 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf8B-0007tW-IY; Thu, 17 Apr 2014 07:45:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:45:03 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/48#comment:1 Message-ID: <072.c44d9c80c4e4c2e71814424aab141a23@trac.tools.ietf.org> References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/S32XALu9lB_lTzEy2s7cS6a7hqw Cc: dime@ietf.org Subject: Re: [Dime] [dime] #48 (draft-ietf-dime-ovli): Setting M-Bit gives wrong semantics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:45:12 -0000 #48: Setting M-Bit gives wrong semantics Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:45:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3115D1A041F for ; Wed, 16 Apr 2014 22:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyAA8bx0I1Tc for ; Wed, 16 Apr 2014 22:45:25 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BD38D1A002A for ; Wed, 16 Apr 2014 22:45:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:57298 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf8T-000840-1V; Thu, 17 Apr 2014 07:45:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:45:21 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/54#comment:1 Message-ID: <090.d7e792c32c2c080a9f3cdce31679ef5d@trac.tools.ietf.org> References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PpcbtNv2gBLzBNoeGI3ZBelLhoQ Cc: dime@ietf.org Subject: Re: [Dime] [dime] #54 (draft-ietf-dime-ovli): OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:45:29 -0000 #54: OC-Report-Type as mandatory AVP Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -----------------------------------------------+--------------------------- Reporter: maria.cruz.bartolome@ericsson.com | Owner: MCruz Type: defect | Bartolomé Priority: major | Status: new Component: draft-ietf-dime-ovli | Milestone: Severity: Active WG Document | Version: 1.0 Keywords: | Resolution: -----------------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:45:49 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2EC1A002A for ; Wed, 16 Apr 2014 22:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRBKudIC-YLQ for ; Wed, 16 Apr 2014 22:45:43 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0B56F1A0434 for ; Wed, 16 Apr 2014 22:45:43 -0700 (PDT) Received: from localhost ([127.0.0.1]:57308 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf8h-00088X-PF; Thu, 17 Apr 2014 07:45:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:45:35 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/55#comment:1 Message-ID: <081.403712b9a8b77f79ebf38e57992d4fef@trac.tools.ietf.org> References: <066.8875fa1c8b7c849ad37eea1864d456e0@trac.tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <066.8875fa1c8b7c849ad37eea1864d456e0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9-E_glfcqzxAeWb-9rNvCxHpuE0 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #55 (draft-ietf-dime-ovli): Lack of overload control for realm overload condition X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:45:47 -0000 #55: Lack of overload control for realm overload condition Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:46:03 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50941A043A for ; Wed, 16 Apr 2014 22:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9V_eRhxKmff for ; Wed, 16 Apr 2014 22:45:57 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 692BC1A002A for ; Wed, 16 Apr 2014 22:45:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:57325 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf8w-0008Gg-6N; Thu, 17 Apr 2014 07:45:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:45:50 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/57#comment:1 Message-ID: <081.09c1d0bec6b847a1e11a34c600ea9531@trac.tools.ietf.org> References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/G1GFlL6ty6l49ViZuif3t71tv0E Cc: dime@ietf.org Subject: Re: [Dime] [dime] #57 (draft-ietf-dime-ovli): Handling of "Realm-Routed" Overload report type X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:46:02 -0000 #57: Handling of "Realm-Routed" Overload report type Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:46:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48511A0441 for ; Wed, 16 Apr 2014 22:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfyDteToqs3Y for ; Wed, 16 Apr 2014 22:46:06 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBCE1A043F for ; Wed, 16 Apr 2014 22:46:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:57346 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf98-0008Ml-LY; Thu, 17 Apr 2014 07:46:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:46:02 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/58#comment:1 Message-ID: <077.7573764256dd75947bc18100160af865@trac.tools.ietf.org> References: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/l5816_2RHXimpy7RwA-DfV_f0L4 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #58 (draft-ietf-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:46:10 -0000 #58: Multiple Reporting Nodes for realm-routed-request type reports Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- ----------------------------------+--------------------------- Reporter: ulrich.wiehe@nsn.com | Owner: Ulrich Wiehe Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | ----------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:46:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853C11A043F for ; Wed, 16 Apr 2014 22:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNt_gN18MVLa for ; Wed, 16 Apr 2014 22:46:24 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 726FF1A043A for ; Wed, 16 Apr 2014 22:46:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:57362 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf9O-0008PQ-2f; Thu, 17 Apr 2014 07:46:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:46:18 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/60#comment:2 Message-ID: <081.ff6858e94e1c7de10a277a802de462cb@trac.tools.ietf.org> References: <066.25846a096050f4de0dae76f80a0a9d46@trac.tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <066.25846a096050f4de0dae76f80a0a9d46@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2xApBkgUIRLH2spILP1YYv2colo Cc: dime@ietf.org Subject: Re: [Dime] [dime] #60 (draft-ietf-dime-ovli): Agent Overload Report Handling considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:46:29 -0000 #60: Agent Overload Report Handling considerations Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:46:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81F91A0441 for ; Wed, 16 Apr 2014 22:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAQ1HBiZ6nju for ; Wed, 16 Apr 2014 22:46:41 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 248AA1A0439 for ; Wed, 16 Apr 2014 22:46:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:57372 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf9c-0008RO-Cn; Thu, 17 Apr 2014 07:46:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:46:32 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/61#comment:2 Message-ID: <081.32b36951341116d13f74c667adc44bee@trac.tools.ietf.org> References: <066.240dbe9c6b177a4db5db4535d22df5f1@trac.tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <066.240dbe9c6b177a4db5db4535d22df5f1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/TW1trDqaTTxrrjY7ZjlwfuVGGDg Cc: dime@ietf.org Subject: Re: [Dime] [dime] #61 (draft-ietf-dime-ovli): Agent Capability Announcement Considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:46:45 -0000 #61: Agent Capability Announcement Considerations Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:46:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DAF1A043A for ; Wed, 16 Apr 2014 22:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxIXw2ULG9IE for ; Wed, 16 Apr 2014 22:46:49 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 604421A0449 for ; Wed, 16 Apr 2014 22:46:49 -0700 (PDT) Received: from localhost ([127.0.0.1]:57395 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf9n-0008Tg-2a; Thu, 17 Apr 2014 07:46:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:46:43 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/62#comment:1 Message-ID: <081.a2ba83fc84ae0e0b9db61e4148a86ddd@trac.tools.ietf.org> References: <066.eba6aa0bd68b42efe99ac62bc852b2b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 62 In-Reply-To: <066.eba6aa0bd68b42efe99ac62bc852b2b5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Y1MjJuozWAV_roV7BpiJd8vZxNE Cc: dime@ietf.org Subject: Re: [Dime] [dime] #62 (draft-ietf-dime-ovli): SEction 3 needs to be made consistent with DIOC solution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:46:52 -0000 #62: SEction 3 needs to be made consistent with DIOC solution Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:46:59 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B3A1A0451 for ; Wed, 16 Apr 2014 22:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZbLoIfXkYjQ for ; Wed, 16 Apr 2014 22:46:57 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 057A41A044B for ; Wed, 16 Apr 2014 22:46:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:57419 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Waf9x-0008WH-9f; Thu, 17 Apr 2014 07:46:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:46:53 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/63#comment:1 Message-ID: <079.1a6919ba00ebfb82a7c9ff970785bd9f@trac.tools.ietf.org> References: <064.8b98719c3d80dc6597df7e7453a13774@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <064.8b98719c3d80dc6597df7e7453a13774@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/O-JXenIERNXOE9D8XNb2Cc8AYCU Cc: dime@ietf.org Subject: Re: [Dime] [dime] #63 (draft-ietf-dime-ovli): test X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:46:58 -0000 #63: test Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | ------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:47:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE4F1A0449 for ; Wed, 16 Apr 2014 22:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qVDa3D8J8wG for ; Wed, 16 Apr 2014 22:47:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E42B51A0439 for ; Wed, 16 Apr 2014 22:47:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:57439 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafA8-0000Aq-6b; Thu, 17 Apr 2014 07:47:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:47:04 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/43#comment:1 Message-ID: <072.9ca99f7ecbfd73b3153ac483ae5f7bb7@trac.tools.ietf.org> References: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aMUnM3w05t_uqccpa2Up8DBhu_w Cc: dime@ietf.org Subject: Re: [Dime] [dime] #43 (draft-ietf-dime-ovli): Overstated guidance on session-ending requests. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:47:12 -0000 #43: Overstated guidance on session-ending requests. Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:48:03 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F1A1A044B for ; Wed, 16 Apr 2014 22:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYQSOWaXS-_d for ; Wed, 16 Apr 2014 22:47:57 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C3FA01A0439 for ; Wed, 16 Apr 2014 22:47:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:57509 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafAq-0001Og-Cd; Thu, 17 Apr 2014 07:47:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:47:48 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/23#comment:1 Message-ID: <081.d5d940e68a7023d908b5825df4199cdd@trac.tools.ietf.org> References: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iwkpSXOeBfcpHnpNqLXk7Y4HovU Cc: dime@ietf.org Subject: Re: [Dime] [dime] #23 (draft-ietf-dime-ovli): DOIC behavior for realm overload X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:48:02 -0000 #23: DOIC behavior for realm overload Changes (by jouni.nospam@gmail.com): * owner: draft-docdt-dime-ovli@tools.ietf.org => draft-ietf-dime- ovli@tools.ietf.org * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: draft-ietf-dime-ovli | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:49:12 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5CF1A0451 for ; Wed, 16 Apr 2014 22:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foC1qFv4vW2m for ; Wed, 16 Apr 2014 22:49:10 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 47CB31A0439 for ; Wed, 16 Apr 2014 22:49:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:57562 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafC6-00045T-HY; Thu, 17 Apr 2014 07:49:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:49:06 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/63#comment:2 Message-ID: <079.23be92417ed26861187ed466c14d73d9@trac.tools.ietf.org> References: <064.8b98719c3d80dc6597df7e7453a13774@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <064.8b98719c3d80dc6597df7e7453a13774@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/szdYio6qrvQTaYU1UnLiB2Uq0LQ Cc: dime@ietf.org Subject: Re: [Dime] [dime] #63 (draft-ietf-dime-ovli): test X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:49:11 -0000 #63: test Changes (by jouni.nospam@gmail.com): * status: new => closed * resolution: => invalid -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: invalid Keywords: | ------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:51:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC621A0470 for ; Wed, 16 Apr 2014 22:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4z_05hWsP4u for ; Wed, 16 Apr 2014 22:51:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BF4131A0459 for ; Wed, 16 Apr 2014 22:50:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:57691 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafDo-00015Q-86; Thu, 17 Apr 2014 07:50:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:50:52 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/40#comment:2 Message-ID: <072.84c31b4b55f1870bb7b49988569236d4@trac.tools.ietf.org> References: <057.01735c3128fb78d15e8c46bffd9dff62@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <057.01735c3128fb78d15e8c46bffd9dff62@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hYggZWjwadqIvM63750qohCyrek Cc: dime@ietf.org Subject: Re: [Dime] [dime] #40 (draft-ietf-dime-ovli): Need defintions for Overload Report and Abatement Algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:51:01 -0000 #40: Need defintions for Overload Report and Abatement Algorithm Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:51:24 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89BA1A0459 for ; Wed, 16 Apr 2014 22:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3HN85_TdmF5 for ; Wed, 16 Apr 2014 22:51:18 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 727BD1A0465 for ; Wed, 16 Apr 2014 22:51:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:57760 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafE8-0002nF-Sq; Thu, 17 Apr 2014 07:51:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:51:12 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/31#comment:2 Message-ID: <081.7830139567981dc759abf2e3452c8c39@trac.tools.ietf.org> References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dH1_o4o0ctYbcZO-kjnu21f-HHI Cc: dime@ietf.org Subject: Re: [Dime] [dime] #31 (draft-ietf-dime-ovli): Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:51:23 -0000 #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:51:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768201A045C for ; Wed, 16 Apr 2014 22:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ss4b_6v7uR92 for ; Wed, 16 Apr 2014 22:51:32 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 18AC11A0459 for ; Wed, 16 Apr 2014 22:51:32 -0700 (PDT) Received: from localhost ([127.0.0.1]:57782 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafEM-0003cB-6V; Thu, 17 Apr 2014 07:51:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:51:26 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/46#comment:3 Message-ID: <072.bbe63791e46a1803c06d3cd783cf936c@trac.tools.ietf.org> References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s_9xTgp8Y4fLFuX1DRwqhO40QXE Cc: dime@ietf.org Subject: Re: [Dime] [dime] #46 (draft-ietf-dime-ovli): Bad normative advice on not letting overload reports expire X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:51:34 -0000 #46: Bad normative advice on not letting overload reports expire Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:51:47 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83CD1A046C for ; Wed, 16 Apr 2014 22:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3qo72SHPzVn for ; Wed, 16 Apr 2014 22:51:44 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6E34E1A0465 for ; Wed, 16 Apr 2014 22:51:44 -0700 (PDT) Received: from localhost ([127.0.0.1]:57827 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafEX-00050X-Mp; Thu, 17 Apr 2014 07:51:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, lionel.morand@orange-ftgroup.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:51:37 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/56#comment:2 Message-ID: <077.dcbc47ddbe515dabb800ac70d1cd0044@trac.tools.ietf.org> References: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, lionel.morand@orange-ftgroup.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zZIKSQF1rJa-koslyMxed7v9fMg Cc: dime@ietf.org Subject: Re: [Dime] [dime] #56 (draft-ietf-dime-ovli): Bad Description of Overload Control State X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:51:46 -0000 #56: Bad Description of Overload Control State Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ulrich.wiehe@nsn.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf- | Version: dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:52:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102971A0471 for ; Wed, 16 Apr 2014 22:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdQGJw314Es6 for ; Wed, 16 Apr 2014 22:51:57 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 95E0B1A0465 for ; Wed, 16 Apr 2014 22:51:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:57844 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafEl-000559-Tp; Thu, 17 Apr 2014 07:51:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:51:51 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/38#comment:2 Message-ID: <072.a940948bb37e5926576323187745b88f@trac.tools.ietf.org> References: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/eBjwbU7C8s6QEq-ROZNqVUUwzUg Cc: dime@ietf.org Subject: Re: [Dime] [dime] #38 (draft-ietf-dime-ovli): Server Farm Definition Issue X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:51:59 -0000 #38: Server Farm Definition Issue Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:52:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907C61A0049 for ; Wed, 16 Apr 2014 22:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rqUhOj-sGgV for ; Wed, 16 Apr 2014 22:52:17 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E17C41A0470 for ; Wed, 16 Apr 2014 22:52:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:57862 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafEz-0005I9-OC; Thu, 17 Apr 2014 07:52:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:52:05 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/42#comment:3 Message-ID: <072.64f3035003684229b4eecb56fa1be7aa@trac.tools.ietf.org> References: <057.ff314df275dab29348f2c0fdfc761219@trac.tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <057.ff314df275dab29348f2c0fdfc761219@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/730hTs-FRf2RgYEdlDZCd1GtnJU Cc: dime@ietf.org Subject: Re: [Dime] [dime] #42 (draft-ietf-dime-ovli): IETF defined example of a stateless application. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:52:19 -0000 #42: IETF defined example of a stateless application. Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: trivial | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:52:37 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F4B1A0470 for ; Wed, 16 Apr 2014 22:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX_fMW5Thf9y for ; Wed, 16 Apr 2014 22:52:33 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A09691A0049 for ; Wed, 16 Apr 2014 22:52:33 -0700 (PDT) Received: from localhost ([127.0.0.1]:57878 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafFL-0005N2-V9; Thu, 17 Apr 2014 07:52:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:52:27 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/44#comment:2 Message-ID: <072.13f8b3c25376079c9fd72328a6d07ca8@trac.tools.ietf.org> References: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GD04YSecq2ofvQFim-mFRwoD1-o Cc: dime@ietf.org Subject: Re: [Dime] [dime] #44 (draft-ietf-dime-ovli): Incorrect sequence number behavior X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:52:35 -0000 #44: Incorrect sequence number behavior Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: trivial | Milestone: Component: draft-ietf- | Version: dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:52:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA651A002F for ; Wed, 16 Apr 2014 22:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN_UKpG3DtpB for ; Wed, 16 Apr 2014 22:52:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 892661A001C for ; Wed, 16 Apr 2014 22:52:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:57893 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafFa-0005Q6-Mw; Thu, 17 Apr 2014 07:52:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:52:42 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/41#comment:2 Message-ID: <072.68e9897f8c0e3051b1783731145fd295@trac.tools.ietf.org> References: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xxqan3Qy0xjpSK0d3jO1QBZqg9Q Cc: dime@ietf.org Subject: Re: [Dime] [dime] #41 (draft-ietf-dime-ovli): Need better overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:52:50 -0000 #41: Need better overview Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:54:43 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0C1A003A for ; Wed, 16 Apr 2014 22:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0Ed3uihzDwF for ; Wed, 16 Apr 2014 22:54:41 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1101A002F for ; Wed, 16 Apr 2014 22:54:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:57959 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafHO-00061Z-04; Thu, 17 Apr 2014 07:54:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:54:33 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/45#comment:2 Message-ID: <072.4b9a089f51c1152ab5da7726e7e78aa8@trac.tools.ietf.org> References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nuGi-6rdd5VJ7vyH94QFMCqeGv4 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #45 (draft-ietf-dime-ovli): Why is a validity duration of 0 disallowed? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:54:42 -0000 #45: Why is a validity duration of 0 disallowed? Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:54:59 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DB01A001C for ; Wed, 16 Apr 2014 22:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1lcXkExqBs2 for ; Wed, 16 Apr 2014 22:54:54 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E760B1A002F for ; Wed, 16 Apr 2014 22:54:53 -0700 (PDT) Received: from localhost ([127.0.0.1]:57968 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafHc-00062f-QQ; Thu, 17 Apr 2014 07:54:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:54:48 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/29#comment:2 Message-ID: <089.a85eacbcc4ed388c912f28beb829f907@trac.tools.ietf.org> References: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/04LhHJ5LwlcEt0MT96qYrhzamBg Cc: dime@ietf.org Subject: Re: [Dime] [dime] #29 (draft-ietf-dime-ovli): OC-Sequence-Number in OC-Supported-Features X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:54:58 -0000 #29: OC-Sequence-Number in OC-Supported-Features Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- ----------------------------------------------+--------------------------- Reporter: lionel.morand@orange-ftgroup.com | Owner: Ulrich Wiehe Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: 2.0 Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:55:10 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF281A001C for ; Wed, 16 Apr 2014 22:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7tZi9aAOZDs for ; Wed, 16 Apr 2014 22:55:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1C01A0045 for ; Wed, 16 Apr 2014 22:55:04 -0700 (PDT) Received: from localhost ([127.0.0.1]:57978 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafHn-00064i-35; Thu, 17 Apr 2014 07:54:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:54:59 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/30#comment:2 Message-ID: <081.aaa95317a28f43758deb26d8c2084769@trac.tools.ietf.org> References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/T4vaDumgnBpNlDCJ20Oe0QTL-98 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #30 (draft-ietf-dime-ovli): OC-Supported-Features AVP in answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:55:08 -0000 #30: OC-Supported-Features AVP in answer messages Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:55:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2DF1A001C for ; Wed, 16 Apr 2014 22:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHDehM13Pm_N for ; Wed, 16 Apr 2014 22:55:14 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AF05B1A0043 for ; Wed, 16 Apr 2014 22:55:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:58005 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafHx-0006Dc-Bc; Thu, 17 Apr 2014 07:55:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:55:09 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/36#comment:2 Message-ID: <090.a68804f47a3a1d7cdc5bdd784ca5a158@trac.tools.ietf.org> References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iszeSbNf431nsYvVgCAWdUeBHpM Cc: dime@ietf.org Subject: Re: [Dime] [dime] #36 (draft-ietf-dime-ovli): OC-Validity-Duration AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:55:19 -0000 #36: OC-Validity-Duration AVP Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -----------------------------------------------+--------------------------- Reporter: maria.cruz.bartolome@ericsson.com | Owner: MCruz Type: enhancement | Bartolomé Priority: major | Status: closed Component: draft-ietf-dime-ovli | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: fixed -----------------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:55:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754D41A0049 for ; Wed, 16 Apr 2014 22:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe5YXFYzxz6p for ; Wed, 16 Apr 2014 22:55:25 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C20BF1A0439 for ; Wed, 16 Apr 2014 22:55:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:58018 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafI8-0006LK-PB; Thu, 17 Apr 2014 07:55:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:55:20 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/34#comment:2 Message-ID: <081.8478b3e81a11372a80941fb5a4fc7967@trac.tools.ietf.org> References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/E5zux111Hw5VMfKRCC3WIJ099BM Cc: dime@ietf.org Subject: Re: [Dime] [dime] #34 (draft-ietf-dime-ovli): Semantics of OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:55:26 -0000 #34: Semantics of OC-Report-Type AVP Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:55:39 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1396E1A0476 for ; Wed, 16 Apr 2014 22:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um1hny2u93dU for ; Wed, 16 Apr 2014 22:55:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C0A9B1A001C for ; Wed, 16 Apr 2014 22:55:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:58026 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafII-0006Pf-RW; Thu, 17 Apr 2014 07:55:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:55:30 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/39#comment:3 Message-ID: <072.b2e2f1d0a8b85881797ad1af7b3e9afb@trac.tools.ietf.org> References: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XnPu_f7GRJ1fZIbQwDmLTLaaxLY Cc: dime@ietf.org Subject: Re: [Dime] [dime] #39 (draft-ietf-dime-ovli): Definition of Diameter Routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:55:38 -0000 #39: Definition of Diameter Routing Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: duplicate Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:55:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE86A1A047B for ; Wed, 16 Apr 2014 22:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gDSDZXsjpci for ; Wed, 16 Apr 2014 22:55:49 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CA7AC1A0484 for ; Wed, 16 Apr 2014 22:55:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:58040 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafIV-0006RM-3R; Thu, 17 Apr 2014 07:55:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:55:43 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/37#comment:3 Message-ID: <072.649e1ef673191aeb1214a79a4e480384@trac.tools.ietf.org> References: <057.3a201a94252d25a27114080765cddc27@trac.tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <057.3a201a94252d25a27114080765cddc27@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_7pokS9LVQ5ALbf3AanPDxhQ9Cg Cc: dime@ietf.org Subject: Re: [Dime] [dime] #37 (draft-ietf-dime-ovli): Inconsistent name and abbreviation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:55:50 -0000 #37: Inconsistent name and abbreviation Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: trivial | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:56:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE9F1A0056 for ; Wed, 16 Apr 2014 22:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki9XZ6-KjbAe for ; Wed, 16 Apr 2014 22:55:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 20F511A001C for ; Wed, 16 Apr 2014 22:55:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:58054 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafIe-0006UO-DG; Thu, 17 Apr 2014 07:55:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:55:52 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/28#comment:2 Message-ID: <081.41242fd4522878114c609c8efa504b7c@trac.tools.ietf.org> References: <066.b908ffa610747388ec343de03f526af3@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <066.b908ffa610747388ec343de03f526af3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2DCE_lJU9gYk50_hk5Jiw-tOEqY Cc: dime@ietf.org Subject: Re: [Dime] [dime] #28 (draft-ietf-dime-ovli): Report type support in capabilities? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:56:04 -0000 #28: Report type support in capabilities? Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-docdt-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:56:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89051A048F for ; Wed, 16 Apr 2014 22:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_MexkafnFMv for ; Wed, 16 Apr 2014 22:56:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B02F91A048E for ; Wed, 16 Apr 2014 22:56:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:58064 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafIr-0006Yi-TX; Thu, 17 Apr 2014 07:56:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:56:05 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/24#comment:3 Message-ID: <081.98b446fdc2bcee34afeb6375dfc8fd78@trac.tools.ietf.org> References: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/loqRiNOgD33PAGeKOXLIoZI8NIM Cc: dime@ietf.org Subject: Re: [Dime] [dime] #24 (draft-ietf-dime-ovli): Terminology and Abbreviations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:56:14 -0000 #24: Terminology and Abbreviations Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-docdt-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:56:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2BE1A0458 for ; Wed, 16 Apr 2014 22:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQRJPb2c7fSm for ; Wed, 16 Apr 2014 22:56:28 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D40341A001C for ; Wed, 16 Apr 2014 22:56:27 -0700 (PDT) Received: from localhost ([127.0.0.1]:58081 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafJ8-0006bx-3c; Thu, 17 Apr 2014 07:56:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:56:22 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/47#comment:3 Message-ID: <072.6cd661e8ec35693e0af3c9f629bdd0b4@trac.tools.ietf.org> References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YoxSg4In0KFKgzU8_9QVFp9dBBc Cc: dime@ietf.org Subject: Re: [Dime] [dime] #47 (draft-ietf-dime-ovli): reduction percentages greater than 100 should be ignored X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:56:30 -0000 #47: reduction percentages greater than 100 should be ignored Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:56:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7735F1A047B for ; Wed, 16 Apr 2014 22:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebW44YIjpDH2 for ; Wed, 16 Apr 2014 22:56:40 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4DB1A001C for ; Wed, 16 Apr 2014 22:56:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:58090 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafJK-0006ci-MT; Thu, 17 Apr 2014 07:56:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:56:34 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/52#comment:3 Message-ID: <090.f4e79f6c8122ecaa26a86ea873c29f85@trac.tools.ietf.org> References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/MLsiSHjhai8eTICPwJcfeB3SBaI Cc: dime@ietf.org Subject: Re: [Dime] [dime] #52 (draft-ietf-dime-ovli): Throttling not needed to be based on previous history X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:56:44 -0000 #52: Throttling not needed to be based on previous history Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -----------------------------------------------+--------------------------- Reporter: maria.cruz.bartolome@ericsson.com | Owner: MCruz Type: defect | Bartolomé Priority: major | Status: closed Component: draft-ietf-dime-ovli | Milestone: Severity: Active WG Document | Version: 1.0 Keywords: | Resolution: fixed -----------------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:56:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161E41A001C for ; Wed, 16 Apr 2014 22:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKToU1gws_ha for ; Wed, 16 Apr 2014 22:56:50 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D848B1A0481 for ; Wed, 16 Apr 2014 22:56:49 -0700 (PDT) Received: from localhost ([127.0.0.1]:58099 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafJV-0006h7-Ob; Thu, 17 Apr 2014 07:56:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:56:45 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/51#comment:3 Message-ID: <090.1ba90c7fcd683b76ca05270a0cf1d4dc@trac.tools.ietf.org> References: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nf2PYhRSX-tAYWEtj9H_fdEpi2c Cc: dime@ietf.org Subject: Re: [Dime] [dime] #51 (draft-ietf-dime-ovli): OC-Supported-Features in requests X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:56:52 -0000 #51: OC-Supported-Features in requests Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -----------------------------------------------+--------------------------- Reporter: maria.cruz.bartolome@ericsson.com | Owner: MCruz Type: defect | Bartolomé Priority: major | Status: closed Component: draft-ietf-dime-ovli | Milestone: Severity: Active WG Document | Version: 1.0 Keywords: | Resolution: fixed -----------------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:57:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60DC1A047B for ; Wed, 16 Apr 2014 22:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzcW6gyCnD2x for ; Wed, 16 Apr 2014 22:57:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 72D1B1A001C for ; Wed, 16 Apr 2014 22:57:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:58110 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafJg-0006kH-Ks; Thu, 17 Apr 2014 07:56:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:56:56 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/50#comment:3 Message-ID: <090.01d296089d20ec418790ba6dfc9f86de@trac.tools.ietf.org> References: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qfRsxaZj_GbLhHu3IRy300paCGk Cc: dime@ietf.org Subject: Re: [Dime] [dime] #50 (draft-ietf-dime-ovli): OC-OLR AVP implicit info X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:57:04 -0000 #50: OC-OLR AVP implicit info Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-docdt-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:57:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE1C1A048C for ; Wed, 16 Apr 2014 22:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uacGER-CWTJD for ; Wed, 16 Apr 2014 22:57:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8B71A001C for ; Wed, 16 Apr 2014 22:57:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:58123 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafJv-0006qu-BP; Thu, 17 Apr 2014 07:57:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange-ftgroup.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:57:11 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/32#comment:4 Message-ID: <081.10ab07ec34c4a3d1d25354111817a8cf@trac.tools.ietf.org> References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IfK-4NG_TYHpvzIT7fz62fku4iA Cc: dime@ietf.org Subject: Re: [Dime] [dime] #32 (draft-ietf-dime-ovli): Sequence-Number Time-Stamp values within OC-OLR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:57:17 -0000 #32: Sequence-Number Time-Stamp values within OC-OLR Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:57:29 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A511A048E for ; Wed, 16 Apr 2014 22:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUoM2G9Hq6vw for ; Wed, 16 Apr 2014 22:57:27 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 183271A001C for ; Wed, 16 Apr 2014 22:57:27 -0700 (PDT) Received: from localhost ([127.0.0.1]:58138 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafK7-0006u7-22; Thu, 17 Apr 2014 07:57:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: maria.cruz.bartolome@ericsson.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:57:23 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/53#comment:2 Message-ID: <090.3e9ef0a4cac4f807fb385578ace94a17@trac.tools.ietf.org> References: <075.7050d926bbf4992a2147612aa862564a@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <075.7050d926bbf4992a2147612aa862564a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/R1KTsZi-fvdNyrJ1lFeiIacrlm0 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #53 (draft-ietf-dime-ovli): 5.5.2 chapter typo? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:57:28 -0000 #53: 5.5.2 chapter typo? Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- -----------------------------------------------+--------------------------- Reporter: maria.cruz.bartolome@ericsson.com | Owner: MCruz Type: defect | Bartolomé Priority: minor | Status: closed Component: draft-ietf-dime-ovli | Milestone: Severity: Active WG Document | Version: 1.0 Keywords: | Resolution: fixed -----------------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 22:57:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9199B1A0484 for ; Wed, 16 Apr 2014 22:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvnHygG7kiTG for ; Wed, 16 Apr 2014 22:57:51 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 602EC1A03F7 for ; Wed, 16 Apr 2014 22:57:51 -0700 (PDT) Received: from localhost ([127.0.0.1]:58159 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafKV-0006yl-LU; Thu, 17 Apr 2014 07:57:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:57:47 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/59#comment:3 Message-ID: <079.32458553134c2816f6a83bda55891e0b@trac.tools.ietf.org> References: <064.bb0da2c00030e1b9c3d10d3561221494@trac.tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <064.bb0da2c00030e1b9c3d10d3561221494@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/C4c_dY5HkAeoHtW56D44U1OXuVE Cc: dime@ietf.org Subject: Re: [Dime] [dime] #59 (draft-ietf-dime-ovli): test X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:57:52 -0000 #59: test Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: enhancement | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: worksforme Keywords: | ------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 16 22:58:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3843C1A03F7 for ; Wed, 16 Apr 2014 22:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgoZJfXhIT6H for ; Wed, 16 Apr 2014 22:58:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F122B1A03AB for ; Wed, 16 Apr 2014 22:58:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:58165 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WafKs-00071S-Uw; Thu, 17 Apr 2014 07:58:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: lionel.morand@orange-ftgroup.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Thu, 17 Apr 2014 05:58:10 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/33#comment:2 Message-ID: <081.8fbd8da1124c902cd9f833e7d8ddc7b2@trac.tools.ietf.org> References: <066.7a9f5ebf154a20a7d05d51b6a5e8f458@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <066.7a9f5ebf154a20a7d05d51b6a5e8f458@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/y8WIRg_ruYIXpnXG5De3qiz_ylw Cc: dime@ietf.org Subject: Re: [Dime] [dime] #33 (draft-ietf-dime-ovli): Overload Mitigation Differentiation per Client X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 05:58:16 -0000 #33: Overload Mitigation Differentiation per Client Changes (by jouni.nospam@gmail.com): * component: draft-docdt-dime-ovli => draft-ietf-dime-ovli -- --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: duplicate Keywords: | --------------------------------------+--------------------------- Ticket URL: dime From nobody Wed Apr 16 23:03:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AFE1A03F7 for ; Wed, 16 Apr 2014 23:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlLuRj6-jVR6 for ; Wed, 16 Apr 2014 23:03:20 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C57B01A03AB for ; Wed, 16 Apr 2014 23:03:19 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so9060983lbd.29 for ; Wed, 16 Apr 2014 23:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=dRf/eX/P91VgvAu5W+yOTo75roMAovzGaoddl9+h1Ys=; b=nDhIr5w+j2VQBJh0QB+JqHd5z3zlJR2hGA8p1USZk7SF4tLbuJCJUs4lvMqmea3Bmc +abmmSAoRN/5xStKpf8ulBoiadM08r1mxXIt6+4dcDExy86L4MN0B8rIcaQdFSkkB6Be i+JLLC+yh3fclKn1to/ZMDXcSrjzBbAJAt4wTNILrDcqPcQ0cCHUUB4HMZxRQ56FZpHF DqeeYV1vcHQ0SNEvm7VsMJjEpKswHGSi59yr7mrXmsW79EUwI76NytbFfXOKP16gB84p lZAtszEeZ1+QPXKGWUn7pjMIm8tR37DsseUhavHdVetNZlUFKt15pPhzNXDpPRQrBg8z jrEw== X-Received: by 10.112.27.133 with SMTP id t5mr5759457lbg.21.1397714595558; Wed, 16 Apr 2014 23:03:15 -0700 (PDT) Received: from [192.168.250.176] ([194.100.71.98]) by mx.google.com with ESMTPSA id a7sm22915967lbc.9.2014.04.16.23.03.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 23:03:14 -0700 (PDT) Message-ID: <534F6E8E.8010305@gmail.com> Date: Thu, 17 Apr 2014 09:02:54 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xIvE9B_Y5_8mXz5Y5CruwqBxGdQ Subject: [Dime] DOIC issue tracker update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 06:03:21 -0000 Folks, As you might have seen, I finally found a way (thanks to Henrik, the tools page developer) to fix the issue tracker ticket assignment.. From now on, when you issue a ticket, use the proper component "draft-ietf-dime-ovli". - Jouni From nobody Thu Apr 17 09:05:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A661A021A; Thu, 17 Apr 2014 09:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVeYtsY8tele; Thu, 17 Apr 2014 09:05:20 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 54FB01A024E; Thu, 17 Apr 2014 09:05:20 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so557355lbd.1 for ; Thu, 17 Apr 2014 09:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y/FbnXZJXtlCO6gjcxcyzCbYTInEM0OepIvlcn67sNg=; b=OvByFiIu5JQLLrPqkYJb1GynuPyxhik+WilXlz3rxg30vvaqB4FrpxSVeQkxACOmid KQEHWgMeDk4aFJWd4bXcfwkgEzL+br1nRxSdfW26HLkplQqO4au4Xuwev+txf9P8EYr3 u3ewoTJ80rMhJnQnqZkcraCIasc2Dagf+I56cPJkY7rYD7ypC0rzRTd2jcQm6uSE10Gu jMkq3TeyuUg60r8OghqluyyQdm0zeZUjXNH6GRn9qdytMEnKnDQkFHK9Y1Llo87e7SBH GvfD09M5svJg2by39+ZIM3GY79Chufix18tV8yzDLXIKXb/rz+Qho9NTAYUh04Xre/Tg kE8w== X-Received: by 10.152.246.43 with SMTP id xt11mr10327995lac.34.1397750715998; Thu, 17 Apr 2014 09:05:15 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:eddb:69dc:33cd:939f? ([2001:1bc8:101:f101:eddb:69dc:33cd:939f]) by mx.google.com with ESMTPSA id k2sm24388175lbm.23.2014.04.17.09.05.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 09:05:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <533CE1AD.3010407@gmail.com> Date: Thu, 17 Apr 2014 19:05:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <533CE1AD.3010407@gmail.com> To: "dime@ietf.org list" , draft-bertz-dime-congestion-flow-attributes@tools.ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YuJB3JLo3C1Xf0iZS9Tcd-9uqOo Cc: dime-chairs@ietf.org Subject: Re: [Dime] Adoption call for draft-bertz-dime-congestion-flow-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 16:05:25 -0000 Folks, We got good support for this document and therefore the WG will adopt = it. @Lyle & Brent go ahead and post = draft-ietf-dime-congestion-flow-attributes-00 version of the document. - Jouni & Lionel On Apr 3, 2014, at 7:21 AM, Jouni Korhonen wrote: > Folks, >=20 > As discussed and agreed (and now verified with our AD), this email = starts a two week adoption call for > draft-bertz-dime-congestion-flow-attributes-02 as a Dime WG document. = Express your support or opposition on the mailing list. The call ends = 17th April. >=20 > Jouni & Lionel From nobody Thu Apr 17 14:56:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C087B1A0045 for ; Thu, 17 Apr 2014 14:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZiILEC1n9K6 for ; Thu, 17 Apr 2014 14:56:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7B81A01CF for ; Thu, 17 Apr 2014 14:56:14 -0700 (PDT) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s3HLu8xC040894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 16:56:10 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <5343F470.50808@usdonovans.com> Date: Thu, 17 Apr 2014 16:56:08 -0500 X-Mao-Original-Outgoing-Id: 419464568.761734-9c90bf3c7859babfaf2c247699c23a29 Content-Transfer-Encoding: quoted-printable Message-Id: <98935E31-5866-4456-BFDF-D02FD2D0BDC6@nostrum.com> References: <5342AAD9.9030803@usdonovans.com> <28937_1396879717_5342B165_28937_9147_1_6B7134B31289DC4FAF731D844122B36E548C2D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <534318C7.1060502@usdonovans.com> <7558_1396959635_5343E993_7558_7400_1_6B7134B31289DC4FAF731D844122B36E54C514@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5343F470.50808@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aPN2JeHF6cxsDWNfoo_Gan7-qWw Cc: "dime@ietf.org" Subject: Re: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 21:56:19 -0000 On Apr 8, 2014, at 8:06 AM, Steve Donovan = wrote: > Lionel, >=20 > I'm not proposing adding an AVP to the overload report. I should have = said the Diameter ID in the overload control state. I agree completely = that the Diameter ID comes from the Origin-Host AVP in the answer = message containing the OLR. There's a potential issue here. Maybe we've discussed this before, but = I've forgotten: What happens if an intervening agent changes the Origin-Host AVP in the = answer? I think we can take our previous discussions ofidentity-mapping = server front end agents as an existence proof of agents that do that = sort of thing. The obvious answer is that any agent that did that sort of thing should = remove the overload report, and perhaps replace it with one of it's own. = But if the proxy does not support DOIC in the first place, it's likely = not to do that. If a host report leaks past an agent that modifies the = Origin-Host, then the reacting node is highly likely to do the Wrong = Thing. >=20 > Regards, >=20 > Steve >=20 > On 4/8/14 7:20 AM, lionel.morand@orange.com wrote: >> Hi Steve, >>=20 >> I understand your point now. Thank you for the clarification. >>=20 >> However, I don't think that it leads necessarily to the need for a = Diameter Id in the OLR. >>=20 >> The clarification could be that, in case of direct connection between = clients and servers, the Host report type applies also to the peer = connection for which the peer id is equal to the origin-host in the = answer containing the OLR. Such binding is required and the Diameter Id = in the OLR will not provide added-value compared to the origin-host of = the answer. From nobody Thu Apr 17 15:14:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A620B1A0130 for ; Thu, 17 Apr 2014 15:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emwEM345ygPq for ; Thu, 17 Apr 2014 15:14:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFDF1A011D for ; Thu, 17 Apr 2014 15:14:35 -0700 (PDT) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s3HMEM5o042360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 17:14:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <4971B712-2F1F-4388-AE76-CB640F8DEB46@gmail.com> Date: Thu, 17 Apr 2014 17:14:22 -0500 X-Mao-Original-Outgoing-Id: 419465662.861579-aac2348fcbdac00aaea459707012b65a Content-Transfer-Encoding: quoted-printable Message-Id: <044DBA57-A76C-4C32-9A8C-0339D4C01FE8@nostrum.com> References: <3B8C74F7-ED9F-45CB-8115-E44E1EF29654@nostrum.com> <532C3D99.30809@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C9869@DEMUMBX014.nsn-intra.net> <4971B712-2F1F-4388-AE76-CB640F8DEB46@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xiuKkooj2dJULFJCMWjUKtGBiqg Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC Overview of Operation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 22:14:37 -0000 Oops, I was cleaning up some old mail, and comment from a while back = that I probably should respond to. Apologies for the tardiness. On Mar 24, 2014, at 7:49 AM, Jouni Korhonen = wrote: >> DOIC endpoints do not generate new messages to carry DOIC related >> information. Rather, they "piggyback" DOIC information over = existing >> Diameter messages by inserting new AVPs into existing Diameter >> requests and responses. >=20 > JiK: This applies to existing applications or new application where > DOIC is just a feature on top of one. Nothing prevents us defining a > DOIC-only application using this spec as the base. This should be > reflected? The entirety of the overview text is intended to describe DOIC as it = currently exists in the draft. If we later create an application to = carry overload reports (perhaps updating DOIC in the process), that = would need its own overview text. =20 From nobody Fri Apr 18 06:37:17 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC78B1A01D4; Fri, 18 Apr 2014 06:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ini5rEMo_h3A; Fri, 18 Apr 2014 06:37:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A823E1A0143; Fri, 18 Apr 2014 06:37:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140418133713.24767.49927.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 06:37:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/etspfPbDNV-O4hQN189Mv7oYVao Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-congestion-flow-attributes-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 13:37:15 -0000 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 Congestion and Filter Attributes Authors : Brent Hirschman Lyle Bertz Filename : draft-ietf-dime-congestion-flow-attributes-00.txt Pages : 7 Date : 2014-04-18 Abstract: This document defines optional ECN and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. RFC 5777 defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions. It does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested. A Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g. packets) is not captured in Accounting applications, leaving administrators without useful information regarding the effectiveness or understanding of the filter definition. These optional attributes are forward and backwards compatible with RFC 5777. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-congestion-flow-attributes-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 18 07:15:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833871A0131 for ; Fri, 18 Apr 2014 07:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLpF78NowIOv for ; Fri, 18 Apr 2014 07:14:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6011A0327 for ; Fri, 18 Apr 2014 07:13:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140418141357.10684.94646.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 07:13:57 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mlLTtwIbderTC0umt0lUFHy9kfo X-Mailman-Approved-At: Fri, 18 Apr 2014 07:15:53 -0700 Subject: [Dime] Milestones changed for dime WG X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 14:14:41 -0000 URL: http://datatracker.ietf.org/wg/dime/charter/ From nobody Fri Apr 18 09:06:25 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665381A0455 for ; Fri, 18 Apr 2014 09:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zJyLXY-AmU9 for ; Fri, 18 Apr 2014 09:06:21 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0531A0451 for ; Fri, 18 Apr 2014 09:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12329; q=dns/txt; s=iport; t=1397837172; x=1399046772; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=RIjQPDaENH/moLbDdimM53Lord/1DtVidH9u4MfKozY=; b=Rj0BZMpwM8Pl/YBfAX1egNWlIf5/sjbz60f0Kb4u5x0KrsL51W7atS2w IN/7D1Leb7jnDWZAYad6Xf2Z9RCeKnIsuyYnLE87Cd/Wwqwo/shkU1Xpc lNQ5DhTsb7hhZAOz01DLoagCKYeC0hcT7RZz3+i3TXfJMD2eidpU5Zfjw 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroEALtMUVOtJssW/2dsb2JhbABagkKKWbsFgTN0giYBAQQtSwEQCyEWDwkDAgECAUUGAQwBBwEBEIgtzR8XjXULEQFQB4Q4AQOYboZYi3eDMzuBNQ X-IronPort-AV: E=Sophos; i="4.97,884,1389744000"; d="scan'208,217"; a="19137948" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 18 Apr 2014 16:06:11 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3IG6BhY017688; Fri, 18 Apr 2014 16:06:11 GMT Message-ID: <53514D73.3090006@cisco.com> Date: Fri, 18 Apr 2014 18:06:11 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "draft-ietf-dime-app-design-guide.all@tools.ietf.org" References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> <22885_1396976646_53442C06_22885_3037_1_6B7134B31289DC4FAF731D844122B36E54D5C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <22885_1396976646_53442C06_22885_3037_1_6B7134B31289DC4FAF731D844122B36E54D5C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------020205050006050807080003" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/b3hkVoAXx6WZGz-fvq37rg7uf2o Cc: dime mailing list Subject: Re: [Dime] AD review draft-ietf-dime-app-design-guide X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 16:06:23 -0000 This is a multi-part message in MIME format. --------------020205050006050807080003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Lionel, Thanks for the new version. See in line > > > > - When I read the document, it looked to me as a BCP. > > BCP definition from RFC 2026: > > 5. BEST CURRENT PRACTICE (BCP) RFCs > > > > The BCP subseries of the RFC series is designed to be a way to > > standardize practices and the results of community deliberations. > > Interestingly, the charter mentions: > > May 2012, Submit 'Diameter Application Design Guidelines' to the IESG > for consideration as a BCP document > > */[LM] discussed in another email thread./* > > > If you go to BCP, don't forget to update the abstract, and the writeup. > Abstract: It is meant as a guidelines document and therefore as informative in nature. I would remove this sentence. Informative and BCP don't go along very well. Jouni, don't forget to update the writeup. > > *//* > > *//**//**//* > > > - Editorial in section 5.7 > OLD: > > Destination- Realm > > NEW: > Destination-Realm > */ > /* Still there. > > > *//**//* > > > > - Section 5.9 > > Applications that do not understand these AVPs can discard > them upon receipt. > > Generic comment: Each time there is a sentence like this one above, we > should mention RFC 6733 as the reference. > This document is not an extension/deviation to RFC 6733. > > */[LM] ok/* > Still there. > > *//* > > *//* Regards, Benoit --------------020205050006050807080003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Lionel,

Thanks for the new version.
See in line



- When I read the document, it looked to me as a BCP.

BCP definition from RFC 2026:

5.  BEST CURRENT PRACTICE (BCP) RFCs
 
   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.

Interestingly, the charter mentions:

May 2012, Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document

[LM] discussed in another email thread.


If you go to BCP, don't forget to update the abstract, and the writeup.

Abstract:
    
   It is meant as a guidelines document and
   therefore as informative in nature.

I would remove this sentence. Informative and BCP don't go along very well.

Jouni, don't forget to update the writeup.


- Editorial in section 5.7
OLD:

Destination- Realm
 
NEW:
Destination-Realm
Still there.




- Section 5.9

 Applications that do not understand these AVPs can discard
   them upon receipt.

Generic comment: Each time there is a sentence like this one above, we should mention RFC 6733 as the reference.
This document is not an extension/deviation to RFC 6733.

[LM] ok

Still there.



Regards, Benoit
--------------020205050006050807080003-- From nobody Fri Apr 18 10:42:02 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285691A03CF for ; Fri, 18 Apr 2014 10:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XzW_pd3C-W8 for ; Fri, 18 Apr 2014 10:41:56 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA8E1A01FE for ; Fri, 18 Apr 2014 10:41:55 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z11so1537130lbi.36 for ; Fri, 18 Apr 2014 10:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SVIKaMUqNL8HOhSq/lDwgMcz/UUXVTp+08f0f+S01fk=; b=wLIE2Dezg5jZLdRvQPkG6oeulsF7jOn7MRUP7p9DH8BFVWRDUo/sma4g8LeqIclu9B vKGmq6tNOy4eiHhLQhLfjszZWFovZ6tX/07dS/SeZLaKBT2VkjAl8mqh712XIw77u4pL q36Q8QuHNyv0A63T0oIWeBljSaOa5Fa7R2zWEDZWgvICoeQisO175gHrDvA0hTz6U9Mi 74r9NBgPClWUmJaGkavWq+l1qdnMx9uB7FAZRrrNNgsc37saa/hSP1iYrPG5y2Q/zxAw Dt4fblOgKWV+XbjZhAbhCuue7gsN0z4cjkfW21n5gLXjO4MWabWJfkm8wgVTzzRMVLD/ xEFQ== X-Received: by 10.152.115.178 with SMTP id jp18mr14725443lab.23.1397842911507; Fri, 18 Apr 2014 10:41:51 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:701e:6163:130a:e2ff? ([2001:1bc8:101:f101:701e:6163:130a:e2ff]) by mx.google.com with ESMTPSA id fa8sm28041949lbc.18.2014.04.18.10.41.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 10:41:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <53514D73.3090006@cisco.com> Date: Fri, 18 Apr 2014 20:41:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <46464E18-BB36-4875-813A-54589C2B1FCB@gmail.com> References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> <22885_1396976646_53442C06_22885_3037_1_6B7134B31289DC4FAF731D844122B36E54D5C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53514D73.3090006@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/CKinkhKIyhD0pXXkuQb8ORIBsno Cc: dime mailing list , "draft-ietf-dime-app-design-guide.all@tools.ietf.org" Subject: Re: [Dime] AD review draft-ietf-dime-app-design-guide X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 17:41:58 -0000 Ok. Will check the write-up. - Jouni On Apr 18, 2014, at 7:06 PM, Benoit Claise wrote: > Hi Lionel, >=20 > Thanks for the new version. > See in line=20 >>=20 >>=20 >> - When I read the document, it looked to me as a BCP. >> BCP definition from RFC 2026: >> 5. BEST CURRENT PRACTICE (BCP) RFCs >> =20 >> The BCP subseries of the RFC series is designed to be a way to >> standardize practices and the results of community deliberations.=20= >> Interestingly, the charter mentions: >> May 2012, Submit 'Diameter Application Design Guidelines' to the IESG = for consideration as a BCP document >> [LM] discussed in another email thread. >>=20 >> If you go to BCP, don't forget to update the abstract, and the = writeup. > Abstract: > =20 > It is meant as a guidelines document and > therefore as informative in nature. >=20 > I would remove this sentence. Informative and BCP don't go along very = well. >=20 > Jouni, don't forget to update the writeup. >=20 >>=20 >>=20 >> - Editorial in section 5.7 >> OLD: >> Destination- Realm >> =20 >> NEW: >> Destination-Realm >>=20 > Still there. >>=20 >>=20 >>=20 >> - Section 5.9 >> Applications that do not understand these AVPs can discard >> them upon receipt.=20 >> Generic comment: Each time there is a sentence like this one above, = we should mention RFC 6733 as the reference. >> This document is not an extension/deviation to RFC 6733. >> [LM] ok > Still there. >>=20 >=20 > Regards, Benoit > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Apr 23 08:03:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA6D1A03E7 for ; Wed, 23 Apr 2014 08:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRdCt6Db4qtj for ; Wed, 23 Apr 2014 08:03:26 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 12DCD1A03DE for ; Wed, 23 Apr 2014 08:03:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:43248 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WcyhV-00038w-Ij; Wed, 23 Apr 2014 17:03:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Wed, 23 Apr 2014 15:03:05 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/65 Message-ID: <066.a99805710f0922547f49ff6eb5d6c0fa@trac.tools.ietf.org> X-Trac-Ticket-ID: 65 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GcSlcoyQBcazKp4ZRkLxZz1T4dM Cc: dime@ietf.org Subject: [Dime] [dime] #65 (draft-ietf-dime-ovli): Definition of messages impacted by host overload report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 23 Apr 2014 15:03:31 -0000 #65: Definition of messages impacted by host overload report The current definition of a host overload needs to be enhanced. The following is what is currently in the -02 draft: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. The second paragraph says that only requests that contain a Destination- Host AVP can be used for overload treatment. This does not address the case where there is no agent between the reacting and reporting nodes. In other words, the reacting node has a direct connection to the reporting node. In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP. I propose that the second paragraph be changed to the following: "The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR. This is the value of the Origin-Host AVP in the message that carried the OLR. There are two cases where the reacting node will know that the request will be routed to the overloaded node. The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR. The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node." -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Apr 23 08:05:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE931A03DA for ; Wed, 23 Apr 2014 08:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YADFHX_7TvGg for ; Wed, 23 Apr 2014 08:05:34 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3FD1A03C2 for ; Wed, 23 Apr 2014 08:05:12 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53576 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WcyjQ-0001Is-Dq; Wed, 23 Apr 2014 08:05:05 -0700 Message-ID: <5357D69F.7040302@usdonovans.com> Date: Wed, 23 Apr 2014 10:05:03 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ben Campbell References: <5342AAD9.9030803@usdonovans.com> <28937_1396879717_5342B165_28937_9147_1_6B7134B31289DC4FAF731D844122B36E548C2D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <534318C7.1060502@usdonovans.com> <7558_1396959635_5343E993_7558_7400_1_6B7134B31289DC4FAF731D844122B36E54C514@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5343F470.50808@usdonovans.com> <98935E31-5866-4456-BFDF-D02FD2D0BDC6@nostrum.com> In-Reply-To: <98935E31-5866-4456-BFDF-D02FD2D0BDC6@nostrum.com> Content-Type: multipart/alternative; boundary="------------030203000400040507030603" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5A_LNSGQYMlKxlhuZUuzQ1tgcpw Cc: "dime@ietf.org" Subject: Re: [Dime] Definition of host report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 15:05:37 -0000 This is a multi-part message in MIME format. --------------030203000400040507030603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ben, I think this is something that needs to be thought through. I suggest entering it in the issue tracker to make sure it gets addressed. Steve On 4/17/14 4:56 PM, Ben Campbell wrote: > On Apr 8, 2014, at 8:06 AM, Steve Donovan wrote: > >> Lionel, >> >> I'm not proposing adding an AVP to the overload report. I should have said the Diameter ID in the overload control state. I agree completely that the Diameter ID comes from the Origin-Host AVP in the answer message containing the OLR. > There's a potential issue here. Maybe we've discussed this before, but I've forgotten: > > What happens if an intervening agent changes the Origin-Host AVP in the answer? I think we can take our previous discussions ofidentity-mapping server front end agents as an existence proof of agents that do that sort of thing. > > The obvious answer is that any agent that did that sort of thing should remove the overload report, and perhaps replace it with one of it's own. But if the proxy does not support DOIC in the first place, it's likely not to do that. If a host report leaks past an agent that modifies the Origin-Host, then the reacting node is highly likely to do the Wrong Thing. > > >> Regards, >> >> Steve >> >> On 4/8/14 7:20 AM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> I understand your point now. Thank you for the clarification. >>> >>> However, I don't think that it leads necessarily to the need for a Diameter Id in the OLR. >>> >>> The clarification could be that, in case of direct connection between clients and servers, the Host report type applies also to the peer connection for which the peer id is equal to the origin-host in the answer containing the OLR. Such binding is required and the Diameter Id in the OLR will not provide added-value compared to the origin-host of the answer. > --------------030203000400040507030603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ben,

I think this is something that needs to be thought through.  I suggest entering it in the issue tracker to make sure it gets addressed.

Steve
On 4/17/14 4:56 PM, Ben Campbell wrote:
On Apr 8, 2014, at 8:06 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


Lionel,

I'm not proposing adding an AVP to the overload report.  I should have said the Diameter ID in the overload control state.  I agree completely that the Diameter ID comes from the Origin-Host AVP in the answer message containing the OLR.

There's a potential issue here. Maybe we've discussed this before, but I've forgotten:

What happens if an intervening agent changes the Origin-Host AVP in the answer? I think we can take our previous discussions ofidentity-mapping server front end agents as an existence proof of agents that do that sort of thing.

The obvious answer is that any agent that did that sort of thing should remove the overload report, and perhaps replace it with one of it's own. But if the proxy does not support DOIC in the first place, it's likely not to do that. If a host report leaks past an agent that modifies the Origin-Host, then the reacting node is highly likely to do the Wrong Thing.



Regards,

Steve

On 4/8/14 7:20 AM, lionel.morand@orange.com wrote:

Hi Steve,

I understand your point now. Thank you for the clarification.

However, I don't think that it leads necessarily to the need for a Diameter Id in the OLR.

The clarification could be that, in case of direct connection between clients and servers, the Host report type applies also to the peer connection for which the peer id is equal to the origin-host in the answer containing the OLR. Such binding is required and the Diameter Id in the OLR will not provide added-value compared to the origin-host of the answer.

--------------030203000400040507030603-- From nobody Wed Apr 23 12:37:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8068B1A049A for ; Wed, 23 Apr 2014 12:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxPWOJ4oWFIg for ; Wed, 23 Apr 2014 12:37:03 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DD3931A0242 for ; Wed, 23 Apr 2014 12:37:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:55074 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Wd2yQ-0000g2-KF; Wed, 23 Apr 2014 21:36:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Wed, 23 Apr 2014 19:36:50 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/66 Message-ID: <057.235f5e0676a095cce4d25acf9f348309@trac.tools.ietf.org> X-Trac-Ticket-ID: 66 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KlgqBTFEYc8akX70EgNvGbOIuEM Cc: dime@ietf.org Subject: [Dime] [dime] #66 (draft-ietf-dime-ovli): Non-Supporting Agent Changing Origin-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 23 Apr 2014 19:37:04 -0000 #66: Non-Supporting Agent Changing Origin-Host What happens if a non-supporting agent rewrites the Origin-Host AVP in a Diameter answer that contains a host report from a server? We know there are agents that do this. But if they do not implement DOIC, they may pass the overload report through to the downstream peer, which might then treat the report as applying to the non-supporting agent rather than the server. This may suggest a need to put the identity of the overloaded server in the report explicitly. For example, we could add a Reporting-Host AVP that contains a Diameter ID. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dime-ovli@tools.ietf.org ben@nostrum.com | Status: new Type: defect | Milestone: Priority: major | Version: 2.0 Component: draft-ietf- | Keywords: dime-ovli | Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Mon Apr 28 03:13:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6D91A04E9 for ; Mon, 28 Apr 2014 03:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbacGRrmcGe0 for ; Mon, 28 Apr 2014 03:11:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6E41A0954 for ; Mon, 28 Apr 2014 03:11:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428101158.25284.69270.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 03:11:58 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Aue9nDCeytNeRFZsL4pDRpEdJcI X-Mailman-Approved-At: Mon, 28 Apr 2014 03:13:35 -0700 Subject: [Dime] Milestones changed for dime WG X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 10:12:00 -0000 Changed milestone "Submit I-D 'Diameter Congestion and Filter Attributes' to the IESG for considerations as a Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/dime/charter/ From nobody Mon Apr 28 11:35:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4B81A6FAC for ; Mon, 28 Apr 2014 11:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvAbAAUlCmqD for ; Mon, 28 Apr 2014 11:35:02 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) by ietfa.amsl.com (Postfix) with ESMTP id CB34F1A04F1 for ; Mon, 28 Apr 2014 11:35:02 -0700 (PDT) Received: from [137.254.4.58] (port=1090 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WeqMi-0007uJ-Bk for dime@ietf.org; Mon, 28 Apr 2014 11:33:21 -0700 Message-ID: <535E9F54.7010607@usdonovans.com> Date: Mon, 28 Apr 2014 13:35:00 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dime@ietf.org References: <066.a99805710f0922547f49ff6eb5d6c0fa@trac.tools.ietf.org> In-Reply-To: <066.a99805710f0922547f49ff6eb5d6c0fa@trac.tools.ietf.org> Content-Type: multipart/alternative; boundary="------------010404080407080009000401" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dqH8Q88J1a4UCKhSlKiAM43m2Cs Subject: Re: [Dime] [dime] #65 (draft-ietf-dime-ovli): Definition of messages impacted by host overload report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 18:35:04 -0000 This is a multi-part message in MIME format. --------------010404080407080009000401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit All, I am planning to update the wording per the following minor adjustment to Lionel's suggested wording for second paragraph of the following. Let me know if there are any objections to closing this issue with the proposed wording. Either the Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP; or the Destination-Host is not present in the request but the value of peer identity associated with the connection used to send the request matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. Regards, Steve On 4/23/14, 10:03 AM, dime issue tracker wrote: > #65: Definition of messages impacted by host overload report > > The current definition of a host overload needs to be enhanced. > > The following is what is currently in the -02 draft: > > 0 A host report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is present in the request and its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > > The value of the Destination-Realm AVP in the request matches the > value of the Origin-Realm AVP of the received message that > contained the OC-OLR AVP. > > The value of the Application-ID in the Diameter Header of the > request matches the value of the Application-ID of the Diameter > Header of the received message that contained the OC-OLR AVP. > > > The second paragraph says that only requests that contain a Destination- > Host AVP can be used for overload treatment. > > This does not address the case where there is no agent between the > reacting and reporting nodes. In other words, the reacting node has a > direct connection to the reporting node. In this case the reacting node > should include all messages that would be sent to the reporting node, > including those that do not contain a Destination-Host AVP and those that > the reacting node would sent to the reporting node through normal route > selection for requests that do not contain a Destination-Host AVP. > > I propose that the second paragraph be changed to the following: > > "The reacting node knows that the request will be routed to the overloaded > Diameter node identified by the Diameter ID in the OLR. This is the value > of the Origin-Host AVP in the message that carried the OLR. There are two > cases where the reacting node will know that the request will be routed to > the overloaded node. The first is the request contains a Destination-Host > AVP that matches the Diameter ID contained in the OLR. The second is when > the reacting node selects a route that is a direct connection to the > overloaded Diameter node." > --------------010404080407080009000401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit All,

I am planning to update the wording per the following minor adjustment to Lionel's suggested wording for second paragraph of the following. 

Let me know if there are any objections to closing this issue with the proposed wording.

      Either the Destination-Host AVP is present in the request and its value
      matches the value of the Origin-Host AVP of the received message
      that contained the OC-OLR AVP; or the Destination-Host is not present
      in the request but the value of peer identity associated with the connection
      used to send the request matches the value of the Origin-Host AVP of the
      received message that contained the OC-OLR AVP.
Regards,

Steve

On 4/23/14, 10:03 AM, dime issue tracker wrote:
#65: Definition of messages impacted by host overload report

 The current definition of a host overload needs to be enhanced.

 The following is what is currently in the -02 draft:

    0  A host report.  The overload treatment should apply to requests
       for which all of the following conditions are true:

       The Destination-Host AVP is present in the request and its value
       matches the value of the Origin-Host AVP of the received message
       that contained the OC-OLR AVP.

       The value of the Destination-Realm AVP in the request matches the
       value of the Origin-Realm AVP of the received message that
       contained the OC-OLR AVP.

       The value of the Application-ID in the Diameter Header of the
       request matches the value of the Application-ID of the Diameter
       Header of the received message that contained the OC-OLR AVP.


 The second paragraph says that only requests that contain a Destination-
 Host AVP can be used for overload treatment.

 This does not address the case where there is no agent between the
 reacting and reporting nodes.  In other words, the reacting node has a
 direct connection to the reporting node.  In this case the reacting node
 should include all messages that would be sent to the reporting node,
 including those that do not contain a Destination-Host AVP and those that
 the reacting node would sent to the reporting node through normal route
 selection for requests that do not contain a Destination-Host AVP.

 I propose that the second paragraph be changed to the following:

 "The reacting node knows that the request will be routed to the overloaded
 Diameter node identified by the Diameter ID in the OLR.  This is the value
 of the Origin-Host AVP in the message that carried the OLR.  There are two
 cases where the reacting node will know that the request will be routed to
 the overloaded node.  The first is the request contains a Destination-Host
 AVP that matches the Diameter ID contained in the OLR.  The second is when
 the reacting node selects a route that is a direct connection to the
 overloaded Diameter node."

--------------010404080407080009000401-- From nobody Mon Apr 28 13:46:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570311A70FD for ; Mon, 28 Apr 2014 13:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcz17VBkzKh6 for ; Mon, 28 Apr 2014 13:46:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F6F1A6FBB for ; Mon, 28 Apr 2014 13:46:53 -0700 (PDT) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s3SKkouu008766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2014 15:46:52 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <535E9F54.7010607@usdonovans.com> Date: Mon, 28 Apr 2014 15:46:50 -0500 X-Mao-Original-Outgoing-Id: 420410810.261898-d7883152c1d07dd317e9721aab5494a8 Content-Transfer-Encoding: quoted-printable Message-Id: References: <066.a99805710f0922547f49ff6eb5d6c0fa@trac.tools.ietf.org> <535E9F54.7010607@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DXGWCDzRKTpEPjhhvjTuuAqXt44 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #65 (draft-ietf-dime-ovli): Definition of messages impacted by host overload report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 20:46:55 -0000 On Apr 28, 2014, at 1:35 PM, Steve Donovan = wrote: > All, >=20 > I am planning to update the wording per the following minor adjustment = to Lionel's suggested wording for second paragraph of the following. =20 >=20 > Let me know if there are any objections to closing this issue with the = proposed wording. >=20 > Either the Destination-Host AVP is present in the request and = its value > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP; or the Destination-Host is not = present > in the request but the value of peer identity associated with = the connection > used to send the request matches the value of the Origin-Host = AVP of the > received message that contained the OC-OLR AVP.=20 > Regards, >=20 s/"of peer identity"/"of the peer identity" Otherwise WFM. /Ben= From nobody Tue Apr 29 00:25:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D5C1A0746 for ; Tue, 29 Apr 2014 00:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7UYHSCbt5eI for ; Tue, 29 Apr 2014 00:24:56 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 762171A0317 for ; Tue, 29 Apr 2014 00:24:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s3T7OsXE027288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Apr 2014 07:24:54 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s3T7Oq4J030252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Apr 2014 09:24:53 +0200 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 29 Apr 2014 09:24:52 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.33]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0181.006; Tue, 29 Apr 2014 09:24:52 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell , Steve Donovan Thread-Topic: [Dime] [dime] #65 (draft-ietf-dime-ovli): Definition of messages impacted by host overload report Thread-Index: AQHPYxCUm+IwhSIzdUyOnK54gKkmWZsnXkwAgADO2lA= Date: Tue, 29 Apr 2014 07:24:51 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151E3D6E@DEMUMBX014.nsn-intra.net> References: <066.a99805710f0922547f49ff6eb5d6c0fa@trac.tools.ietf.org> <535E9F54.7010607@usdonovans.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1555 X-purgate-ID: 151667::1398756294-00001564-C0A80978/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hH3gu4P_mDbyGOugrH-jgQMmWg8 Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #65 (draft-ietf-dime-ovli): Definition of messages impacted by host overload report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 07:24:59 -0000 Steve, I agree with the principle, however, with regard to e.g. issue #66, it may = eventually not be the "value of the Origin-Host AVP of the received message= that contained the OC-OLR AVP". Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Monday, April 28, 2014 10:47 PM To: Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] [dime] #65 (draft-ietf-dime-ovli): Definition of messag= es impacted by host overload report On Apr 28, 2014, at 1:35 PM, Steve Donovan wrote= : > All, >=20 > I am planning to update the wording per the following minor adjustment to= Lionel's suggested wording for second paragraph of the following. =20 >=20 > Let me know if there are any objections to closing this issue with the pr= oposed wording. >=20 > Either the Destination-Host AVP is present in the request and its v= alue > matches the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP; or the Destination-Host is not prese= nt > in the request but the value of peer identity associated with the c= onnection > used to send the request matches the value of the Origin-Host AVP o= f the > received message that contained the OC-OLR AVP.=20 > Regards, >=20 s/"of peer identity"/"of the peer identity" Otherwise WFM. /Ben _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Apr 29 07:17:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA5B1A08D5 for ; Tue, 29 Apr 2014 07:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sI4oAuMk3QP9 for ; Tue, 29 Apr 2014 07:17:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id F30111A08DD for ; Tue, 29 Apr 2014 07:17:09 -0700 (PDT) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s3TEH6ZD099289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Apr 2014 09:17:07 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151E3D6E@DEMUMBX014.nsn-intra.net> Date: Tue, 29 Apr 2014 09:17:05 -0500 X-Mao-Original-Outgoing-Id: 420473825.517595-2e25303f7e4f33c6d247f883c87dae93 Content-Transfer-Encoding: quoted-printable Message-Id: <3C05F1EA-30D8-419B-A97F-9C1EB8E12BAD@nostrum.com> References: <066.a99805710f0922547f49ff6eb5d6c0fa@trac.tools.ietf.org> <535E9F54.7010607@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151E3D6E@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fm5j9VAhPDhzOiuAqOgNL819h5o Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #65 (draft-ietf-dime-ovli): Definition of messages impacted by host overload report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 14:17:12 -0000 On Apr 29, 2014, at 2:24 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Steve, >=20 > I agree with the principle, however, with regard to e.g. issue #66, it = may eventually not be the "value of the Origin-Host AVP of the received = message that contained the OC-OLR AVP". >=20 > Ulrich >=20 Thank's for bring that up! I think it likely we will have to put the origin-host identity inside = the OLR before this is all said and done, but I think Steve's language = makes sense until such time that we have a conclusion on issue 66. Thanks! /Ben > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben = Campbell > Sent: Monday, April 28, 2014 10:47 PM > To: Steve Donovan > Cc: dime@ietf.org > Subject: Re: [Dime] [dime] #65 (draft-ietf-dime-ovli): Definition of = messages impacted by host overload report >=20 >=20 > On Apr 28, 2014, at 1:35 PM, Steve Donovan = wrote: >=20 >> All, >>=20 >> I am planning to update the wording per the following minor = adjustment to Lionel's suggested wording for second paragraph of the = following. =20 >>=20 >> Let me know if there are any objections to closing this issue with = the proposed wording. >>=20 >> Either the Destination-Host AVP is present in the request and = its value >> matches the value of the Origin-Host AVP of the received message >> that contained the OC-OLR AVP; or the Destination-Host is not = present >> in the request but the value of peer identity associated with = the connection >> used to send the request matches the value of the Origin-Host = AVP of the >> received message that contained the OC-OLR AVP.=20 >> Regards, >>=20 >=20 > s/"of peer identity"/"of the peer identity" >=20 > Otherwise WFM. >=20 > /Ben > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Apr 29 07:34:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAD21A0903 for ; Tue, 29 Apr 2014 07:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eI_RvehMUnTd for ; Tue, 29 Apr 2014 07:34:28 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 791FF1A04AC for ; Tue, 29 Apr 2014 07:34:28 -0700 (PDT) Received: from mail73-co9-R.bigfish.com (10.236.132.234) by CO9EHSOBE023.bigfish.com (10.236.130.86) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 Apr 2014 14:34:27 +0000 Received: from mail73-co9 (localhost [127.0.0.1]) by mail73-co9-R.bigfish.com (Postfix) with ESMTP id 08CD6240339 for ; Tue, 29 Apr 2014 14:34:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.26; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm2.corp.sprint.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(z579ehz9f17Rc85fhzz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1033IL17326ah8275dh18c673h1de097h186068hz2fh109h2a8h839hbe3hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h9a9j1155h) Received-SPF: pass (mail73-co9: domain of sprint.com designates 144.230.168.26 as permitted sender) client-ip=144.230.168.26; envelope-from=Brent.Hirschman@sprint.com; helo=plsasdm2.corp.sprint.com ; p.sprint.com ; Received: from mail73-co9 (localhost.localdomain [127.0.0.1]) by mail73-co9 (MessageSwitch) id 1398782064719291_28499; Tue, 29 Apr 2014 14:34:24 +0000 (UTC) Received: from CO9EHSMHS010.bigfish.com (unknown [10.236.132.251]) by mail73-co9.bigfish.com (Postfix) with ESMTP id ABA2F400C5 for ; Tue, 29 Apr 2014 14:34:24 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by CO9EHSMHS010.bigfish.com (10.236.130.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 29 Apr 2014 14:34:24 +0000 Received: from PDAWEH03.ad.sprint.com (pdaweh03.corp.sprint.com [144.226.110.91]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s3TEYMQ9004737 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Apr 2014 09:34:22 -0500 Received: from PLSWE13M02.ad.sprint.com (144.229.214.21) by PDAWEH03.ad.sprint.com (144.226.110.91) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Apr 2014 09:34:21 -0500 Received: from PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) by plswe13m02.ad.sprint.com (2002:90e5:d615::90e5:d615) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 29 Apr 2014 09:34:21 -0500 Received: from PREWE13M04.ad.sprint.com ([fe80::6848:f832:11d7:eaca]) by PREWE13M04.ad.sprint.com ([fe80::6848:f832:11d7:eaca%15]) with mapi id 15.00.0775.031; Tue, 29 Apr 2014 10:34:20 -0400 From: "Hirschman, Brent B [CTO]" To: "dime@ietf.org" Thread-Topic: Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - ECE and CWR Thread-Index: Ac9juBMOQgOoQXQmRW+JZUdT9oQ0cw== Date: Tue, 29 Apr 2014 14:34:20 +0000 Message-ID: <514f538ef4f74db8a2103cc222be5baa@PREWE13M04.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.29] Content-Type: multipart/alternative; boundary="_000_514f538ef4f74db8a2103cc222be5baaPREWE13M04adsprintcom_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3Yt3inseRN_QbTQVidVhOr_PEiM Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - ECE and CWR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 14:34:35 -0000 --_000_514f538ef4f74db8a2103cc222be5baaPREWE13M04adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At IETF 89 in London, during the discussion of the draft-ietf-dime-congesti= on-flow-attributes-00.txt, Two areas were requested to be investigated furt= her. We will be addressing them in separate email threads to keep the disc= ussion focused on each topic. This is Topic 1. First discussion topic, whether ECE and CWR flags needed to be added to thi= s draft. After further investigation, these flags are already included as = part of Section 4.1.8.10 or RFC5777. The TCP-Flag-Type AVP (AVP Code 544) is of type Unsigned32 and specifies the TCP control flag types that must be matched. The first 16 bits match the TCP header format defined in [RFC3168], and the subsequent 16 bits are unused. Within the first 16 bits, bits 0 to 3 are unused and bits 4 to 15 are managed by IANA under the TCP Header Flag registry as defined in [RFC3168= ]. The support of ECN flags (in this draft) are needed since they were omitted= in RFC5777: The ECN flags are still required and here is why. The prob= lem is that RFC 2474 (DSCP) update was made prior to 3168. They studied an= d made recommendations for this situation in RFC 3260 Section 4. The DS Field has a six bit Diffserv Codepoint and two "currently unused" bi= ts. ... It has been pointed out that this leads to inconsistencies and ambiguities. In particular, the "Currently Unused" (CU) bits of the DS Field have not been assigned to Diffserv, and subsequent to the publication of RFC 2474, they were a= ssigned for explicit congestion notification, as defined in RFC 3168= [4] ... Therefore, for use in future documents, including the next update to RFC 2474, the following definitions = should apply: - the Differentiated Services Field (DSField) is the six most significant bits of the (former) IPV4 TOS octet or the (former) IPV6 Traffic Class octet. - the Differentiated Services Codepoint (DSCP) is a value which is encoded in the DS field, and which each DS Node MUST use to select the PHB which is to be experienced by each packet it forwards. The two least significant bits of the IPV4 TOS octet and the IPV6 Traffic Class octet are not used by Diffserv. When RFC 2474 is updated, considerat= ion should be given to changing the designation "currently unused (CU)" to "explicit congestion notification (ECN)" and referencing RFC 3168 (or its successor). Note here they are essentially dropping the "CU" bits in the definition its= elf. This removes overlap in ECN 3186. For RFC 5777, the authors wrote the AVP definition for DSCP in such a way t= hat it is not impacted so long as the registry is correct from 2474 and its= successors. Below is the RFC 5777 definition for DSCP. 4.1.8.1. Diffserv-Code= -Point AVP The Diffserv-Code-Point AVP (AVP Code 535) is of type Enumerated and specifies the Differentiated Services Field Codepoints to match in the IP header. The values are managed by IANA under the Differentiated Services Field Codepoints registry as defined in [RFC2474]. The registry is to be updated to exclude the LU/Exp DSCPs from 2474. This = is specified in RFC 3260. 8. IANA Considerations IANA has requested clarification of a point in RFC 2474, concerning registration of experimental/local use DSCPs. When RFC 2474 is revised, the following should be added to Section 6: IANA is requested to maintain a registry of RECOMMENDED DSCP values assigned by standards action. EXP/LU values are not to be registered. In summary the ECN flags are no longer considered DSCP "CU" bits. They are= also not covered any IANA value. This results in a gap in 5777 and requir= es the update. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_514f538ef4f74db8a2103cc222be5baaPREWE13M04adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At IETF 89 in London, during the discussion of the d= raft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were requested = to be investigated further.  We will be addressing them in separate em= ail threads to keep the discussion focused on each topic.  This is Topic 1.

First discussion topic, whether ECE and CWR flags ne= eded to be added to this draft.  After further investigation, these fl= ags are already included as part of Section 4.1.8.10 or RFC5777.

The T= CP-Flag-Type AVP (AVP Code 544) is of type Unsigned32 and

 = ;  specifies the TCP control flag types that must be matched.  Th= e first

 = ;  16 bits match the TCP header format defined in [RFC3168], and the

 = ;  subsequent 16 bits are unused.  Within the first 16 bits, bits= 0 to 3

 = ;  are unused and bits 4 to 15 are managed by IANA under the TCP Heade= r

   Flag regis= try as defined in [R= FC3168].

The support of ECN flags (in this draft) are needed = since they were omitted in RFC5777:

        &nbs= p;       The ECN flags are still required and= here is why.  The problem is that RFC 2474 (DSCP) update was made pri= or to 3168.  They studied and made recommendations for this situation = in RFC 3260 Section 4.

The DS Field has a six bit Diffserv Codepoint a= nd two "currently unused" bits.

…

It has been pointed out that this leads to inconsist= encies and

   ambiguities.  In particular, the &= quot;Currently Unused" (CU) bits of the

   DS Field have not been assigned to Diff= serv, and subsequent to the

   publication of RFC 2474, they were assigned for explicit congestion

   notification, as defined in RFC 3168 [= 4]

…

   Therefore, for use in future documents,= including the next update to

   RFC 2474, the following definitions should apply:

 

      -  the Different= iated Services Field (DSField) is the six most

         sig= nificant bits of the (former) IPV4 TOS octet or the (former)

         IPV= 6 Traffic Class octet.

 

      -  the Different= iated Services Codepoint (DSCP) is a value which

         is = encoded in the DS field, and which each DS Node MUST use to

         sel= ect the PHB which is to be experienced by each packet it

         for= wards.

   The two least significant bits of the I= PV4 TOS octet and the IPV6

   Traffic Class octet are not used by Dif= fserv.

 

   When RFC 2474 is updated, consideration should be given to chan= ging

   the designation "currently unused = (CU)" to "explicit congestion

   notification (ECN)" and referencin= g RFC 3168 (or its successor).

 

Note here they are essentially dropping the “C= U” bits in the definition itself.  This removes overlap in ECN 3= 186.

 

For RFC 5777, the authors wrote the AVP definition f= or DSCP in such a way that it is not impacted so long as the registry is co= rrect from 2474 and its successors.  Below is the RFC 5777 definition = for DSCP.

4.1.8.1.  Diffserv-C= ode-Point AVP

 

   The Diffserv-Code-Point AVP (AVP Code 5= 35) is of type Enumerated and

   specifies the Differentiated Services F= ield Codepoints to match in

   the IP header.  The values are man= aged by IANA under the

   Differentiated Services Field Codepoint= s registry as defined in

   [RFC2474].

 

The registry is to be updated to exclude the LU/Exp = DSCPs from 2474.  This is specified in RFC 3260.

8. IANA Considerations

 

   IANA has requested clarification of a p= oint in RFC 2474, concerning

   registration of experimental/local use = DSCPs.  When RFC 2474 is

   revised, the following should be added = to Section 6:

 

      IANA is requested to = maintain a registry of RECOMMENDED DSCP

      values assigned by st= andards action.  EXP/LU values are not to be

      registered.

 

In summary the ECN flags are no longer considered DS= CP “CU” bits.  They are also not covered any IANA value.&n= bsp; This results in a gap in 5777 and requires the update.

 

 

Brent Hirschman=

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_514f538ef4f74db8a2103cc222be5baaPREWE13M04adsprintcom_-- From nobody Tue Apr 29 07:36:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976E81A0793 for ; Tue, 29 Apr 2014 07:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNpSTrp4dr-6 for ; Tue, 29 Apr 2014 07:35:51 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 72D4C1A04AC for ; Tue, 29 Apr 2014 07:35:51 -0700 (PDT) Received: from mail193-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE026.bigfish.com (10.236.130.89) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 Apr 2014 14:35:50 +0000 Received: from mail193-co9 (localhost [127.0.0.1]) by mail193-co9-R.bigfish.com (Postfix) with ESMTP id 215271000EB for ; Tue, 29 Apr 2014 14:35:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.25; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI X-SpamScore: -8 X-BigFish: VS-8(zz9f17Rc85fhzz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz18c673h1de097hz2fh109h2a8h839hbe3hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25f6h2605h268bh26d3h9a9j1155h) Received-SPF: pass (mail193-co9: domain of sprint.com designates 144.230.168.25 as permitted sender) client-ip=144.230.168.25; envelope-from=Brent.Hirschman@sprint.com; helo=plsasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail193-co9 (localhost.localdomain [127.0.0.1]) by mail193-co9 (MessageSwitch) id 1398782148671889_6830; Tue, 29 Apr 2014 14:35:48 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.231]) by mail193-co9.bigfish.com (Postfix) with ESMTP id 9FC91680045 for ; Tue, 29 Apr 2014 14:35:48 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 29 Apr 2014 14:35:48 +0000 Received: from PLSWEH04.ad.sprint.com (plsweh04.corp.sprint.com [144.226.251.22]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s3TEZkZX019942 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Apr 2014 09:35:47 -0500 Received: from PLSWE13M02.ad.sprint.com (144.229.214.21) by PLSWEH04.ad.sprint.com (144.226.251.22) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Apr 2014 09:35:46 -0500 Received: from PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) by plswe13m02.ad.sprint.com (2002:90e5:d615::90e5:d615) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 29 Apr 2014 09:35:46 -0500 Received: from PREWE13M04.ad.sprint.com ([fe80::6848:f832:11d7:eaca]) by PREWE13M04.ad.sprint.com ([fe80::6848:f832:11d7:eaca%15]) with mapi id 15.00.0775.031; Tue, 29 Apr 2014 10:35:45 -0400 From: "Hirschman, Brent B [CTO]" To: "dime@ietf.org" Thread-Topic: Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases Thread-Index: Ac9juE1vbr3p/ZQ9STaza+gT8Lz6aA== Date: Tue, 29 Apr 2014 14:35:44 +0000 Message-ID: <9203f8d398b14340b45617e019dc512e@PREWE13M04.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.29] Content-Type: multipart/alternative; boundary="_000_9203f8d398b14340b45617e019dc512ePREWE13M04adsprintcom_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xTqTLZfDmHc7xgueGxQBFGrh9V0 Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 14:35:57 -0000 --_000_9203f8d398b14340b45617e019dc512ePREWE13M04adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At IETF 89 in London, during the discussion of the draft-ietf-dime-congesti= on-flow-attributes-00.txt, Two areas were requested to be investigated furt= her. We will be addressing them in separate email threads to keep the disc= ussion focused on each topic. This is Topic 2: Second, we were requested to investigate providing example use cases of ECN= . RFC5777 already provides a set of use cases for reporting and ECN is jus= t one of many such reporting parameters such as byte count. Adding a parag= raph of text such as the following may add some information but the authors= feel little incremental information is needed because of the work already = in RFC 5777. "Diameter nodes along the bearer path can implement filters to collect acco= unting and policy control information based on these congestion parameters = similar to byte count information. These filters on flows and overall node = congestion for these AVPs can report a measure of quality of byte counts to= collection points in the network where decisions can be made to mitigate o= r mediate any congestion conditions for accounting or real time policy cont= rol. These AVPs provide supplemental information as described in the use c= ases discussed in RFC5777." Thus, the authors are proposing no modification to the working group draft = at this time. Comments are welcome. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_9203f8d398b14340b45617e019dc512ePREWE13M04adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At IETF 89 in London, during the discussion of the d= raft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were requested = to be investigated further.  We will be addressing them in separate em= ail threads to keep the discussion focused on each topic.  This is Topic 2:

 

Second, we were requested to investigate providing e= xample use cases of ECN.  RFC5777 already provides a set of use cases = for reporting and ECN is just one of many such reporting parameters such as= byte count.  Adding a paragraph of text such as the following may add some information but the authors feel little= incremental information is needed because of the work already in RFC 5777.=

“= Diameter nodes along the bearer path can implement filters to collect accou= nting and policy control information based on these congestion parameters s= imilar to byte count information. These filters on flows and overall node congestion for these AVPs can report a measure o= f quality of byte counts to collection points in the network where decision= s can be made to mitigate or mediate any congestion conditions for accounti= ng or real time policy control.  These AVPs provide supplemental information as described in the use cases = discussed in RFC5777.”

 

Thus, the authors are proposing no modification to t= he working group draft at this time.  Comments are welcome.

 

 

 

Brent Hirschman=

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_9203f8d398b14340b45617e019dc512ePREWE13M04adsprintcom_--