From nobody Wed Jul 1 09:10:45 2015 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 BFB331A90DB; Wed, 1 Jul 2015 09:10:43 -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 gtL7KLEXoDyn; Wed, 1 Jul 2015 09:10:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 780F01A8F51; Wed, 1 Jul 2015 09:10:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150701161042.27158.98819.idtracker@ietfa.amsl.com> Date: Wed, 01 Jul 2015 09:10:42 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-congestion-flow-attributes-02.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: Wed, 01 Jul 2015 16:10:43 -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 : Lyle Bertz Serge Manning Brent Hirschman Filename : draft-ietf-dime-congestion-flow-attributes-02.txt Pages : 10 Date : 2015-07-01 Abstract: This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification (ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN and minimize Diameter filter administration. RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions and actions. It however, 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. Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g. packets) are not captured by Accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition. The optional attributes defined in this document 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: https://tools.ietf.org/html/draft-ietf-dime-congestion-flow-attributes-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-congestion-flow-attributes-02 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 Thu Jul 2 15:46:21 2015 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 EDB451AC449; Thu, 2 Jul 2015 15:46:19 -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 ykNeydcEEjOz; Thu, 2 Jul 2015 15:46:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD121AC40F; Thu, 2 Jul 2015 15:46:18 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t62Mk7HY005384 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Jul 2015 17:46:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Bertz, Lyle T [CTO]" Date: Thu, 02 Jul 2015 17:46:07 -0500 Message-ID: In-Reply-To: <7c2281e81c8c4f7592d8fcd8478211bd@PLSWE13M07.ad.sprint.com> References: <20150609185615.7145.32430.idtracker@ietfa.amsl.com> <7c2281e81c8c4f7592d8fcd8478211bd@PLSWE13M07.ad.sprint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , The IESG Subject: Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) 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, 02 Jul 2015 22:46:20 -0000 Thanks for the response. I've removed sections for points that do not seem to need further discussion. Ben. On 15 Jun 2015, at 11:43, Bertz, Lyle T [CTO] wrote: [...] > > substantive: > > -- Abstract: I concur with Stephen that the abstract doesn't really > address the heart of the matter. (It also seems longer than needed.) > >>>>> We responded to Stephen's comments regarding the intro. If you >>>>> could give your feedback on that thread it would be much >>>>> appreciated. The first paragraph of the abstract in version 2 is better. If it were me, I'd move the rest to the introduction, if they are not already covered, and keep the abstract to one paragraph. But that's up to you. > > --6, first sentence. > > I’d like to see a little more “show your work" here. These AVPs > carry new kinds of content. That, in itself, might add new security > considerations (e.g. is the content privacy-sensitive, especially > damaging if tampered with, etc). Please consider adding a few > sentences describing the new content, and why you believe that content > does or does not have new security considerations. You kind of do that > for ECN-IP-Codepoint and Congestion-Treatment, but I don't see > anything for the other two new AVPs. > > (I'm probably the other person that Stephen mentioned consider such > sentences as a red flag.) > >>>>> Ok. Bigger update here. [...] The new security considerations are considerably improved, thanks! [...] From nobody Sun Jul 5 15:21:07 2015 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 8BED81AC423 for ; Sun, 5 Jul 2015 15:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 gKFQhx9FgS6A for ; Sun, 5 Jul 2015 15:21:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA331AC3F8 for ; Sun, 5 Jul 2015 15:21:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5B827BE4C for ; Sun, 5 Jul 2015 23:21:00 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy6W90ofHYE3 for ; Sun, 5 Jul 2015 23:20:59 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.30.169]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 34664BDD0 for ; Sun, 5 Jul 2015 23:20:59 +0100 (IST) Message-ID: <5599ADCA.9080208@cs.tcd.ie> Date: Sun, 05 Jul 2015 23:20:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dime@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Dime] AD review of draft-ietf-dime-ovli-08 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: Sun, 05 Jul 2015 22:21:05 -0000 Hi, Firstly, I'm your new helper-AD, Kathleen and I had to swap a few working groups so I'll be helping out now. Most of the stuff I've seen from this WG is pretty well baked these days though so I'm sure it'll all be fine. (Kathleen will continue to handle discuss-clearing for the congestion control document.) Anyway, here's my AD review for draft-ietf-dime-ovli-08. I just have one question to check before I start IETF last call. The rest of my comments (below) can be handled along with any other last call comments received unless you'd prefer to fix something before we start IETF last call. The one I'd like to chat about before IETF LC is: I see that both WG chairs are authors on this one, so how was WG consensus evaluation handled? That was probably before I joined the list I guess but I didn't spot it in the archive after a quick glance. Thanks, S. - 55 pages! sigh;-) - 2: throttling definition uses "DIOC" but earlier in this section you just say reacting-node. Maybe good to be fully consistent. - 4 (intro) I wondered why no new messages were defined for this and you decided to only piggyback. Maybe good to say why and also to give an example of the kind of thing on which you'd normally expect DOIC stuff to be piggybacked. (That could be done in 4.1 too.) - 4.2 - the reporting node picks the abatement algorithm that the reacting node will apply - is that correct? (from 2nd last para of p8) Does that mean that DOIC will in the end only be used intra-domain since reacting nodes aren't likely to accept such instructions from "anyone" else? If so, it'd be good to point that out early, and not only in section 10. - 4.2, last para/Note: This seems to be punting on interop which isn't a good thing for the IETF to be doing is it? Why is that ok here? - 4.3: Could anyone inject an OLR with a duration of zero as a DoS? Is there something hard to guess? (Turns out, no there's nothing added here that's hard to guess.) Maybe think about putting in a note about that? - Figure 1: how come there are no reporting or reacting nodes included? I'd have thought it'd be good to have (an example of) those in a figure. - 5.1.2, 5th last para: is "indicate support" right here? isn't this the reporting node asking that that alg be used, but the alg is really "supported" at the reacting node? - 5.2.1.3: Where do you say how to handle the case where a sequence number wraps around? Even if that's highly improbable the text to say what to do is cheap. - 5.3: "[RFC6733] defined Grouped AVP extension mechanisms apply. " is unclear, to me anyway. What's it mean? - 6.1, step 4: I think that has to be a uniformly selected random number. - 6.3: "If reacting node comes out of the 100 percent traffic reduction..." I don't get what that condition means exactly. Would all implementers read it to mean the same thing? - 7.5: What does a receiver do if a duration value that's greater than 24 hours is received? One could barf the message or treat it as default (30s) or as a day I guess. If this is covered by some generic Diameter default handling of bad values, that's fine. - 10.1 says: "t's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility..." but I don't see how that can be done solely using Diameter protocol elements so don't you need to say that some out-of-band agreement/information is needed for this to work? Even within a single administrative domain, a node would need to check that the peer is "inside" and presumably border nodes would need even more. - 10.2, para 1: I think it'd be helpful here if an example Diameter application with a really bad potential for a DoS, just for emphasis. As-is, it's not really clear how bad a potential DoS might be. - C.5 - section 10 seems to me to be a new vulnerability that is entirely due to DOIC, so this seems wrong. It's also a tad late for early security review. I'd say to strike the entire C.5 section, or at least re-word. - Appendix C.6: I skipped this one. Not sure if it's better to keep or drop. Keeping it might just lead to more argument is the concern. From nobody Sun Jul 5 16:48:07 2015 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 B8FA91A8785 for ; Sun, 5 Jul 2015 16:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vzfUqbf2-N0n for ; Sun, 5 Jul 2015 16:48:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547751A8780 for ; Sun, 5 Jul 2015 16:48:03 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 33EE52AC93E; Mon, 6 Jul 2015 01:48:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 169E0384066; Mon, 6 Jul 2015 01:48:01 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0235.001; Mon, 6 Jul 2015 01:48:00 +0200 From: To: Stephen Farrell , "dime@ietf.org" Thread-Topic: [Dime] AD review of draft-ietf-dime-ovli-08 Thread-Index: AQHQt3DlaEJsMrWSA0+iHDsZWbY5BZ3Ner8A Date: Sun, 5 Jul 2015 23:47:59 +0000 Message-ID: <25620_1436140081_5599C231_25620_10339_1_6B7134B31289DC4FAF731D844122B36E01CB70F2@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <5599ADCA.9080208@cs.tcd.ie> In-Reply-To: <5599ADCA.9080208@cs.tcd.ie> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.5.232716 Archived-At: Subject: Re: [Dime] AD review of draft-ietf-dime-ovli-08 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: Sun, 05 Jul 2015 23:48:06 -0000 Hi Stephen, This draft is the result of a joint effort between IETF and 3GPP for the de= finition of an overload control mechanism over Diameter. Both chairs are (unfortunately maybe) part of the authors but around 20+ pe= ople were active in DIME WG and 3GPP WGs to review and comment the document= s, with confcalls and ad-hoc meetings dedicated to this topic. The document went through 2 WGLCs in December 2014 and January 2015), with = cross review by 3GPP. The current document takes into account all the comments received during th= e 2 WGLCs and the feedback received from 3GPP folks. We can safely conclude that a rough consensus has been reached for this doc= ument. It ends a cooperative work started in Sept 2012, with the definition= of the requirements (captured in RFC 7068), and reflects the constructive = compromise reached by all the involved parties. For your information, due to the participation of both chairs in this work,= Benoit has been involved from the very beginning on the discussions on thi= s document to monitor the discussion. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Stephen Farrell Envoy=E9 : lundi 6 juillet 2015 00:21 =C0 : dime@ietf.org Objet : [Dime] AD review of draft-ietf-dime-ovli-08 Hi, Firstly, I'm your new helper-AD, Kathleen and I had to swap a few working g= roups so I'll be helping out now. Most of the stuff I've seen from this WG = is pretty well baked these days though so I'm sure it'll all be fine. (Kath= leen will continue to handle discuss-clearing for the congestion control do= cument.) Anyway, here's my AD review for draft-ietf-dime-ovli-08. I just have one qu= estion to check before I start IETF last call. The rest of my comments (bel= ow) can be handled along with any other last call comments received unless = you'd prefer to fix something before we start IETF last call. The one I'd like to chat about before IETF LC is: I see that both WG chairs= are authors on this one, so how was WG consensus evaluation handled? That = was probably before I joined the list I guess but I didn't spot it in the a= rchive after a quick glance. Thanks, S. - 55 pages! sigh;-) - 2: throttling definition uses "DIOC" but earlier in this section you just= say reacting-node. Maybe good to be fully consistent. - 4 (intro) I wondered why no new messages were defined for this and you de= cided to only piggyback. Maybe good to say why and also to give an example= of the kind of thing on which you'd normally expect DOIC stuff to be piggy= backed. (That could be done in 4.1 too.) - 4.2 - the reporting node picks the abatement algorithm that the reacting = node will apply - is that correct? (from 2nd last para of p8) Does that mea= n that DOIC will in the end only be used intra-domain since reacting nodes = aren't likely to accept such instructions from "anyone" else? If so, it'd b= e good to point that out early, and not only in section 10. - 4.2, last para/Note: This seems to be punting on interop which isn't a go= od thing for the IETF to be doing is it? Why is that ok here? - 4.3: Could anyone inject an OLR with a duration of zero as a DoS? Is ther= e something hard to guess? (Turns out, no there's nothing added here that's= hard to guess.) Maybe think about putting in a note about that? - Figure 1: how come there are no reporting or reacting nodes included? I'd= have thought it'd be good to have (an example of) those in a figure. - 5.1.2, 5th last para: is "indicate support" right here? isn't this the reporting node asking that that alg be used, but the alg is = really "supported" at the reacting node? - 5.2.1.3: Where do you say how to handle the case where a sequence number = wraps around? Even if that's highly improbable the text to say what to do i= s cheap. - 5.3: "[RFC6733] defined Grouped AVP extension mechanisms apply. " is uncl= ear, to me anyway. What's it mean? - 6.1, step 4: I think that has to be a uniformly selected random number. - 6.3: "If reacting node comes out of the 100 percent traffic reduction..."= I don't get what that condition means exactly. Would all implementers read it to mean the same thing? - 7.5: What does a receiver do if a duration value that's greater than 24 h= ours is received? One could barf the message or treat it as default (30s) o= r as a day I guess. If this is covered by some generic Diameter default ha= ndling of bad values, that's fine. - 10.1 says: "t's critical that nodes validate that an overload report rece= ived from a peer actually falls within that peer's responsibility..." but I= don't see how that can be done solely using Diameter protocol elements so = don't you need to say that some out-of-band agreement/information is needed= for this to work? Even within a single administrative domain, a node would= need to check that the peer is "inside" and presumably border nodes would = need even more. - 10.2, para 1: I think it'd be helpful here if an example Diameter applica= tion with a really bad potential for a DoS, just for emphasis. As-is, it's = not really clear how bad a potential DoS might be. - C.5 - section 10 seems to me to be a new vulnerability that is entirely d= ue to DOIC, so this seems wrong. It's also a tad late for early security re= view. I'd say to strike the entire C.5 section, or at least re-word. - Appendix C.6: I skipped this one. Not sure if it's better to keep or drop= . Keeping it might just lead to more argument is the concern. _______________________________________________ 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 Mon Jul 6 02:18:26 2015 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 CBA3F1A9143 for ; Mon, 6 Jul 2015 02:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 np3nLmJdkHSe for ; Mon, 6 Jul 2015 02:18:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F4B1A9174 for ; Mon, 6 Jul 2015 02:18:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C6B2FBDD8; Mon, 6 Jul 2015 10:18:19 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLYtwB2pqJnk; Mon, 6 Jul 2015 10:18:19 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9D989BDCC; Mon, 6 Jul 2015 10:18:19 +0100 (IST) Message-ID: <559A47DB.6040100@cs.tcd.ie> Date: Mon, 06 Jul 2015 10:18:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <5599ADCA.9080208@cs.tcd.ie> <25620_1436140081_5599C231_25620_10339_1_6B7134B31289DC4FAF731D844122B36E01CB70F2@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <25620_1436140081_5599C231_25620_10339_1_6B7134B31289DC4FAF731D844122B36E01CB70F2@OPEXCLILM43.corporate.adroot.infra.ftgroup> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dime] AD review of draft-ietf-dime-ovli-08 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, 06 Jul 2015 09:18:26 -0000 Hi Lionel, That all sounds good. How's about though, just to be sure to be sure, that I wait a week before starting IETF LC and ask that during that week, anyone who has concerns about the chairs' evaluation of WG consensus for this draft, please either send to the list or else tell me offlist (if there's a good reason that's needed). That way, if someone asks about this during IETF LC or IESG evaluation, we can point them at this (recent) thread. If, as I expect, I hear no objections, I'll start IETF LC in a week and that'll have no effect on the overall timing given the upcoming IETF meeting - we'll still be fine all going well to put this on the August 5th IESG telechat. If something (*) does come up in the next week, we'll deal with that as necessary. In the meantime, the authors should feel free to respond to any of my review comments that are useful (or useless:-) Or if you want, it's fine to wait and handle 'em with other IETF LC comments received if you prefer that. Cheers, S. (*) By "something" here I *only* mean issues related to the chairs' evaluation of the level of WG consensus for this draft. I do not mean it's ok to re-raise technical topics that were already discussed on the list or at meetings and disposed of via the usual WG process. On 06/07/15 00:47, lionel.morand@orange.com wrote: > Hi Stephen, > > This draft is the result of a joint effort between IETF and 3GPP for > the definition of an overload control mechanism over Diameter. Both > chairs are (unfortunately maybe) part of the authors but around 20+ > people were active in DIME WG and 3GPP WGs to review and comment the > documents, with confcalls and ad-hoc meetings dedicated to this > topic. > > The document went through 2 WGLCs in December 2014 and January 2015), > with cross review by 3GPP. The current document takes into account > all the comments received during the 2 WGLCs and the feedback > received from 3GPP folks. > > We can safely conclude that a rough consensus has been reached for > this document. It ends a cooperative work started in Sept 2012, with > the definition of the requirements (captured in RFC 7068), and > reflects the constructive compromise reached by all the involved > parties. > > For your information, due to the participation of both chairs in this > work, Benoit has been involved from the very beginning on the > discussions on this document to monitor the discussion. > > Regards, > > Lionel > > -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] > De la part de Stephen Farrell Envoyé : lundi 6 juillet 2015 00:21 À : > dime@ietf.org Objet : [Dime] AD review of draft-ietf-dime-ovli-08 > > > Hi, > > Firstly, I'm your new helper-AD, Kathleen and I had to swap a few > working groups so I'll be helping out now. Most of the stuff I've > seen from this WG is pretty well baked these days though so I'm sure > it'll all be fine. (Kathleen will continue to handle discuss-clearing > for the congestion control document.) > > Anyway, here's my AD review for draft-ietf-dime-ovli-08. I just have > one question to check before I start IETF last call. The rest of my > comments (below) can be handled along with any other last call > comments received unless you'd prefer to fix something before we > start IETF last call. > > The one I'd like to chat about before IETF LC is: I see that both WG > chairs are authors on this one, so how was WG consensus evaluation > handled? That was probably before I joined the list I guess but I > didn't spot it in the archive after a quick glance. > > Thanks, S. > > > - 55 pages! sigh;-) > > - 2: throttling definition uses "DIOC" but earlier in this section > you just say reacting-node. Maybe good to be fully consistent. > > - 4 (intro) I wondered why no new messages were defined for this and > you decided to only piggyback. Maybe good to say why and also to > give an example of the kind of thing on which you'd normally expect > DOIC stuff to be piggybacked. (That could be done in 4.1 too.) > > - 4.2 - the reporting node picks the abatement algorithm that the > reacting node will apply - is that correct? (from 2nd last para of > p8) Does that mean that DOIC will in the end only be used > intra-domain since reacting nodes aren't likely to accept such > instructions from "anyone" else? If so, it'd be good to point that > out early, and not only in section 10. > > - 4.2, last para/Note: This seems to be punting on interop which > isn't a good thing for the IETF to be doing is it? Why is that ok > here? > > - 4.3: Could anyone inject an OLR with a duration of zero as a DoS? > Is there something hard to guess? (Turns out, no there's nothing > added here that's hard to guess.) Maybe think about putting in a note > about that? > > - Figure 1: how come there are no reporting or reacting nodes > included? I'd have thought it'd be good to have (an example of) those > in a figure. > > - 5.1.2, 5th last para: is "indicate support" right here? isn't this > the reporting node asking that that alg be used, but the alg is > really "supported" at the reacting node? > > - 5.2.1.3: Where do you say how to handle the case where a sequence > number wraps around? Even if that's highly improbable the text to say > what to do is cheap. > > - 5.3: "[RFC6733] defined Grouped AVP extension mechanisms apply. " > is unclear, to me anyway. What's it mean? > > - 6.1, step 4: I think that has to be a uniformly selected random > number. > > - 6.3: "If reacting node comes out of the 100 percent traffic > reduction..." I don't get what that condition means exactly. Would > all implementers read it to mean the same thing? > > - 7.5: What does a receiver do if a duration value that's greater > than 24 hours is received? One could barf the message or treat it as > default (30s) or as a day I guess. If this is covered by some > generic Diameter default handling of bad values, that's fine. > > - 10.1 says: "t's critical that nodes validate that an overload > report received from a peer actually falls within that peer's > responsibility..." but I don't see how that can be done solely using > Diameter protocol elements so don't you need to say that some > out-of-band agreement/information is needed for this to work? Even > within a single administrative domain, a node would need to check > that the peer is "inside" and presumably border nodes would need even > more. > > - 10.2, para 1: I think it'd be helpful here if an example Diameter > application with a really bad potential for a DoS, just for emphasis. > As-is, it's not really clear how bad a potential DoS might be. > > - C.5 - section 10 seems to me to be a new vulnerability that is > entirely due to DOIC, so this seems wrong. It's also a tad late for > early security review. I'd say to strike the entire C.5 section, or > at least re-word. > > - Appendix C.6: I skipped this one. Not sure if it's better to keep > or drop. Keeping it might just lead to more argument is the concern. > > > > > > _______________________________________________ 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. > > > From nobody Mon Jul 6 03:49:29 2015 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 68C571A007E for ; Mon, 6 Jul 2015 03:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gHByoOC5k_76 for ; Mon, 6 Jul 2015 03:49:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725531A0065 for ; Mon, 6 Jul 2015 03:49:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AC04EBE2F for ; Mon, 6 Jul 2015 11:49:24 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4-2lvQySQr1 for ; Mon, 6 Jul 2015 11:49:24 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8EFBABDD8 for ; Mon, 6 Jul 2015 11:49:24 +0100 (IST) Message-ID: <559A5D34.2040807@cs.tcd.ie> Date: Mon, 06 Jul 2015 11:49:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dime@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dime] AD review of draft-ietf-dime-4over6-provisioning-03 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, 06 Jul 2015 10:49:28 -0000 Hiya, I've done my AD review of draft-ietf-dime-4over6-provisioning-03 Seems to me like all's well. I'll start IETF LC shortly. My few nitty comments are below, please treat then as IETF LC comments. Thanks, S. - intro, 3rd last para: You use both MAP-E and MAP (without a -E) here. Are they the same or is that an implicit subtlty that'd be better explicit? I'd say either use MAP-E in both cases, or explain in general what's meant when you use each. - intro; The last para is very unclear. What does "doesn't specify and that the AVPs...." mean? I'd say split into two sentences. - section 2, 2nd para: Why "allowed to use"? That's wrong anyway, a customer could do other things as well as what one operator provisions for that customer. S/is allowed/wants/ would be fine. - 2.2 and 2.3: Are we only talking source ports for outgoing traffic here, or is this the list of all ports on which this customer can receive inbound traffic? Would it help to say, since the latter can be bigger than the former? I assume we mean the latter anyway. (This may be a dumb question - sorry if my ignorance of LW4over6 and MAP-E is showing there:-) - 2.5, typo: s/Pv4/IPv4/ - 3.1, I'm surprised there wasn't already an AVP for that. If there is one, or a similar one, it might be good to say and give a bit of a hint when to use which. - 8.1: the softwire I-D references are outdated. Does everything still work ok with the latest draft versions? From nobody Mon Jul 6 07:40:08 2015 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 AA3FC1AD0AC; Mon, 6 Jul 2015 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 TEqO6UnRrdl6; Mon, 6 Jul 2015 07:40:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 714791A0055; Mon, 6 Jul 2015 07:40:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150706144005.20952.85013.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 07:40:05 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] Last Call: (Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:40:06 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-07-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, AAA support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) attribute-value pairs to be used for that purpose. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dime-4over6-provisioning/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-4over6-provisioning/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jul 6 09:14:58 2015 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 390911B2F87; Mon, 6 Jul 2015 09:14:56 -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 kdo-9h4UKDrP; Mon, 6 Jul 2015 09:14:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FB81B2F72; Mon, 6 Jul 2015 09:14:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706161455.18208.67484.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 09:14:55 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-load-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: Mon, 06 Jul 2015 16:14:56 -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 Load Information Conveyance Authors : Ben Campbell Steve Donovan Jean-Jacques Trottin Filename : draft-ietf-dime-load-00.txt Pages : 15 Date : 2015-07-06 Abstract: This document defines a mechanism for sharing of Diameter load information. RFC 7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The Diameter Overload Information Conveyance (DOIC) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-load/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-load-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 Mon Jul 6 11:00:35 2015 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 7E0751A1B30 for ; Mon, 6 Jul 2015 11:00:33 -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 KcXd3JX5ocV6 for ; Mon, 6 Jul 2015 11:00:30 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823971A1B6E for ; Mon, 6 Jul 2015 11:00:23 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so98995212pab.1 for ; Mon, 06 Jul 2015 11:00:23 -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=lGzsnzmTrGV0hKZD5BtwcazkjQ5tPkVdtMRR6+VcQPM=; b=KhF6tebTgKS62CJDatdSL0hiE1DbtjClFj3kDnIYgpdz1zeDZtHc/i1VFX0gurC+ux TTjPxlaRYSRsyTCJ0SyOrhJ2fHTfPtQ3TgmTaOsbsEFmeL9q8CoumAiU9Pxfizg+xcUx CsvId8N/2K7tz29hbIZyKPU2522lMi1xddO1mxWBv6lcJ/6LJm+vbJtNVXoC8JqwX3Ko ia1HwwX5/XYqzJVjczj3j3S6qhWt9PwNwKK0+3sxRH4C4W5pvoBbh4GU0psdGBlcvecJ vLfhzFk/wJo58jvOZlRTQ3SXJiPeaBh/3jwHcTMozhHwB4ffs9RokLVjnwWAttSKVYuL ec9g== X-Received: by 10.66.222.161 with SMTP id qn1mr248445pac.66.1436205623202; Mon, 06 Jul 2015 11:00:23 -0700 (PDT) Received: from [10.16.11.35] ([216.31.219.19]) by mx.google.com with ESMTPSA id i4sm19021318pdk.74.2015.07.06.11.00.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 11:00:22 -0700 (PDT) Message-ID: <559AC235.7030708@gmail.com> Date: Mon, 06 Jul 2015 11:00:21 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , lionel.morand@orange.com, "dime@ietf.org" References: <5599ADCA.9080208@cs.tcd.ie> <25620_1436140081_5599C231_25620_10339_1_6B7134B31289DC4FAF731D844122B36E01CB70F2@OPEXCLILM43.corporate.adroot.infra.ftgroup> <559A47DB.6040100@cs.tcd.ie> In-Reply-To: <559A47DB.6040100@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dime] AD review of draft-ietf-dime-ovli-08 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, 06 Jul 2015 18:00:33 -0000 Stephen, We also ran all the questions and concerns through issue tracker. That also documents the process of concensus reaching way before we entered into WGLCs. See: http://www.ietf.org/mail-archive/web/dime/current/msg06443.html And as usual with all that I govern can also be found from github where every change is pretty much traceable: https://github.com/jounikor/draft-docdt-dime-ovli - Jouni 7/6/2015, 2:18 AM, Stephen Farrell kirjoitti: > > Hi Lionel, > > That all sounds good. How's about though, just to be sure to be > sure, that I wait a week before starting IETF LC and ask that during > that week, anyone who has concerns about the chairs' evaluation of WG > consensus for this draft, please either send to the list or else tell > me offlist (if there's a good reason that's needed). That way, if > someone asks about this during IETF LC or IESG evaluation, we can > point them at this (recent) thread. > > If, as I expect, I hear no objections, I'll start IETF LC in a week > and that'll have no effect on the overall timing given the upcoming > IETF meeting - we'll still be fine all going well to put this on > the August 5th IESG telechat. If something (*) does come up in the > next week, we'll deal with that as necessary. > > In the meantime, the authors should feel free to respond to any of > my review comments that are useful (or useless:-) Or if you want, > it's fine to wait and handle 'em with other IETF LC comments > received if you prefer that. > > Cheers, > S. > > (*) By "something" here I *only* mean issues related to the chairs' > evaluation of the level of WG consensus for this draft. I do not > mean it's ok to re-raise technical topics that were already discussed > on the list or at meetings and disposed of via the usual WG process. > > > On 06/07/15 00:47, lionel.morand@orange.com wrote: >> Hi Stephen, >> >> This draft is the result of a joint effort between IETF and 3GPP for >> the definition of an overload control mechanism over Diameter. Both >> chairs are (unfortunately maybe) part of the authors but around 20+ >> people were active in DIME WG and 3GPP WGs to review and comment the >> documents, with confcalls and ad-hoc meetings dedicated to this >> topic. >> >> The document went through 2 WGLCs in December 2014 and January 2015), >> with cross review by 3GPP. The current document takes into account >> all the comments received during the 2 WGLCs and the feedback >> received from 3GPP folks. >> >> We can safely conclude that a rough consensus has been reached for >> this document. It ends a cooperative work started in Sept 2012, with >> the definition of the requirements (captured in RFC 7068), and >> reflects the constructive compromise reached by all the involved >> parties. >> >> For your information, due to the participation of both chairs in this >> work, Benoit has been involved from the very beginning on the >> discussions on this document to monitor the discussion. >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] >> De la part de Stephen Farrell Envoyé : lundi 6 juillet 2015 00:21 À : >> dime@ietf.org Objet : [Dime] AD review of draft-ietf-dime-ovli-08 >> >> >> Hi, >> >> Firstly, I'm your new helper-AD, Kathleen and I had to swap a few >> working groups so I'll be helping out now. Most of the stuff I've >> seen from this WG is pretty well baked these days though so I'm sure >> it'll all be fine. (Kathleen will continue to handle discuss-clearing >> for the congestion control document.) >> >> Anyway, here's my AD review for draft-ietf-dime-ovli-08. I just have >> one question to check before I start IETF last call. The rest of my >> comments (below) can be handled along with any other last call >> comments received unless you'd prefer to fix something before we >> start IETF last call. >> >> The one I'd like to chat about before IETF LC is: I see that both WG >> chairs are authors on this one, so how was WG consensus evaluation >> handled? That was probably before I joined the list I guess but I >> didn't spot it in the archive after a quick glance. >> >> Thanks, S. >> >> >> - 55 pages! sigh;-) >> >> - 2: throttling definition uses "DIOC" but earlier in this section >> you just say reacting-node. Maybe good to be fully consistent. >> >> - 4 (intro) I wondered why no new messages were defined for this and >> you decided to only piggyback. Maybe good to say why and also to >> give an example of the kind of thing on which you'd normally expect >> DOIC stuff to be piggybacked. (That could be done in 4.1 too.) >> >> - 4.2 - the reporting node picks the abatement algorithm that the >> reacting node will apply - is that correct? (from 2nd last para of >> p8) Does that mean that DOIC will in the end only be used >> intra-domain since reacting nodes aren't likely to accept such >> instructions from "anyone" else? If so, it'd be good to point that >> out early, and not only in section 10. >> >> - 4.2, last para/Note: This seems to be punting on interop which >> isn't a good thing for the IETF to be doing is it? Why is that ok >> here? >> >> - 4.3: Could anyone inject an OLR with a duration of zero as a DoS? >> Is there something hard to guess? (Turns out, no there's nothing >> added here that's hard to guess.) Maybe think about putting in a note >> about that? >> >> - Figure 1: how come there are no reporting or reacting nodes >> included? I'd have thought it'd be good to have (an example of) those >> in a figure. >> >> - 5.1.2, 5th last para: is "indicate support" right here? isn't this >> the reporting node asking that that alg be used, but the alg is >> really "supported" at the reacting node? >> >> - 5.2.1.3: Where do you say how to handle the case where a sequence >> number wraps around? Even if that's highly improbable the text to say >> what to do is cheap. >> >> - 5.3: "[RFC6733] defined Grouped AVP extension mechanisms apply. " >> is unclear, to me anyway. What's it mean? >> >> - 6.1, step 4: I think that has to be a uniformly selected random >> number. >> >> - 6.3: "If reacting node comes out of the 100 percent traffic >> reduction..." I don't get what that condition means exactly. Would >> all implementers read it to mean the same thing? >> >> - 7.5: What does a receiver do if a duration value that's greater >> than 24 hours is received? One could barf the message or treat it as >> default (30s) or as a day I guess. If this is covered by some >> generic Diameter default handling of bad values, that's fine. >> >> - 10.1 says: "t's critical that nodes validate that an overload >> report received from a peer actually falls within that peer's >> responsibility..." but I don't see how that can be done solely using >> Diameter protocol elements so don't you need to say that some >> out-of-band agreement/information is needed for this to work? Even >> within a single administrative domain, a node would need to check >> that the peer is "inside" and presumably border nodes would need even >> more. >> >> - 10.2, para 1: I think it'd be helpful here if an example Diameter >> application with a really bad potential for a DoS, just for emphasis. >> As-is, it's not really clear how bad a potential DoS might be. >> >> - C.5 - section 10 seems to me to be a new vulnerability that is >> entirely due to DOIC, so this seems wrong. It's also a tad late for >> early security review. I'd say to strike the entire C.5 section, or >> at least re-word. >> >> - Appendix C.6: I skipped this one. Not sure if it's better to keep >> or drop. Keeping it might just lead to more argument is the concern. >> >> >> >> >> >> _______________________________________________ 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 > From nobody Mon Jul 6 11:21:09 2015 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 313631B2C5C for ; Mon, 6 Jul 2015 11:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yxkHeJAiPSQF for ; Mon, 6 Jul 2015 11:21:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BD61B2C5D for ; Mon, 6 Jul 2015 11:21:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 49736BE35; Mon, 6 Jul 2015 19:20:59 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfAUA3cUg9Pl; Mon, 6 Jul 2015 19:20:56 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.23.241]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3033ABE2F; Mon, 6 Jul 2015 19:20:56 +0100 (IST) Message-ID: <559AC706.2000501@cs.tcd.ie> Date: Mon, 06 Jul 2015 19:20:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jouni Korhonen , lionel.morand@orange.com, "dime@ietf.org" References: <5599ADCA.9080208@cs.tcd.ie> <25620_1436140081_5599C231_25620_10339_1_6B7134B31289DC4FAF731D844122B36E01CB70F2@OPEXCLILM43.corporate.adroot.infra.ftgroup> <559A47DB.6040100@cs.tcd.ie> <559AC235.7030708@gmail.com> In-Reply-To: <559AC235.7030708@gmail.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dime] AD review of draft-ietf-dime-ovli-08 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, 06 Jul 2015 18:21:08 -0000 Hi Jouni, Great - if anything comes up then that'd help us figure out what happened. But I don't really expect anything to come up here, we're just being doubly-sure everyone's had a chance to raise issues if needed. Cheers, S. On 06/07/15 19:00, Jouni Korhonen wrote: > Stephen, > > We also ran all the questions and concerns through issue tracker. That > also documents the process of concensus reaching way before we entered > into WGLCs. See: > http://www.ietf.org/mail-archive/web/dime/current/msg06443.html > > And as usual with all that I govern can also be found from github where > every change is pretty much traceable: > https://github.com/jounikor/draft-docdt-dime-ovli > > > - Jouni > > 7/6/2015, 2:18 AM, Stephen Farrell kirjoitti: >> >> Hi Lionel, >> >> That all sounds good. How's about though, just to be sure to be >> sure, that I wait a week before starting IETF LC and ask that during >> that week, anyone who has concerns about the chairs' evaluation of WG >> consensus for this draft, please either send to the list or else tell >> me offlist (if there's a good reason that's needed). That way, if >> someone asks about this during IETF LC or IESG evaluation, we can >> point them at this (recent) thread. >> >> If, as I expect, I hear no objections, I'll start IETF LC in a week >> and that'll have no effect on the overall timing given the upcoming >> IETF meeting - we'll still be fine all going well to put this on >> the August 5th IESG telechat. If something (*) does come up in the >> next week, we'll deal with that as necessary. >> >> In the meantime, the authors should feel free to respond to any of >> my review comments that are useful (or useless:-) Or if you want, >> it's fine to wait and handle 'em with other IETF LC comments >> received if you prefer that. >> >> Cheers, >> S. >> >> (*) By "something" here I *only* mean issues related to the chairs' >> evaluation of the level of WG consensus for this draft. I do not >> mean it's ok to re-raise technical topics that were already discussed >> on the list or at meetings and disposed of via the usual WG process. >> >> >> On 06/07/15 00:47, lionel.morand@orange.com wrote: >>> Hi Stephen, >>> >>> This draft is the result of a joint effort between IETF and 3GPP for >>> the definition of an overload control mechanism over Diameter. Both >>> chairs are (unfortunately maybe) part of the authors but around 20+ >>> people were active in DIME WG and 3GPP WGs to review and comment the >>> documents, with confcalls and ad-hoc meetings dedicated to this >>> topic. >>> >>> The document went through 2 WGLCs in December 2014 and January 2015), >>> with cross review by 3GPP. The current document takes into account >>> all the comments received during the 2 WGLCs and the feedback >>> received from 3GPP folks. >>> >>> We can safely conclude that a rough consensus has been reached for >>> this document. It ends a cooperative work started in Sept 2012, with >>> the definition of the requirements (captured in RFC 7068), and >>> reflects the constructive compromise reached by all the involved >>> parties. >>> >>> For your information, due to the participation of both chairs in this >>> work, Benoit has been involved from the very beginning on the >>> discussions on this document to monitor the discussion. >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] >>> De la part de Stephen Farrell Envoyé : lundi 6 juillet 2015 00:21 À : >>> dime@ietf.org Objet : [Dime] AD review of draft-ietf-dime-ovli-08 >>> >>> >>> Hi, >>> >>> Firstly, I'm your new helper-AD, Kathleen and I had to swap a few >>> working groups so I'll be helping out now. Most of the stuff I've >>> seen from this WG is pretty well baked these days though so I'm sure >>> it'll all be fine. (Kathleen will continue to handle discuss-clearing >>> for the congestion control document.) >>> >>> Anyway, here's my AD review for draft-ietf-dime-ovli-08. I just have >>> one question to check before I start IETF last call. The rest of my >>> comments (below) can be handled along with any other last call >>> comments received unless you'd prefer to fix something before we >>> start IETF last call. >>> >>> The one I'd like to chat about before IETF LC is: I see that both WG >>> chairs are authors on this one, so how was WG consensus evaluation >>> handled? That was probably before I joined the list I guess but I >>> didn't spot it in the archive after a quick glance. >>> >>> Thanks, S. >>> >>> >>> - 55 pages! sigh;-) >>> >>> - 2: throttling definition uses "DIOC" but earlier in this section >>> you just say reacting-node. Maybe good to be fully consistent. >>> >>> - 4 (intro) I wondered why no new messages were defined for this and >>> you decided to only piggyback. Maybe good to say why and also to >>> give an example of the kind of thing on which you'd normally expect >>> DOIC stuff to be piggybacked. (That could be done in 4.1 too.) >>> >>> - 4.2 - the reporting node picks the abatement algorithm that the >>> reacting node will apply - is that correct? (from 2nd last para of >>> p8) Does that mean that DOIC will in the end only be used >>> intra-domain since reacting nodes aren't likely to accept such >>> instructions from "anyone" else? If so, it'd be good to point that >>> out early, and not only in section 10. >>> >>> - 4.2, last para/Note: This seems to be punting on interop which >>> isn't a good thing for the IETF to be doing is it? Why is that ok >>> here? >>> >>> - 4.3: Could anyone inject an OLR with a duration of zero as a DoS? >>> Is there something hard to guess? (Turns out, no there's nothing >>> added here that's hard to guess.) Maybe think about putting in a note >>> about that? >>> >>> - Figure 1: how come there are no reporting or reacting nodes >>> included? I'd have thought it'd be good to have (an example of) those >>> in a figure. >>> >>> - 5.1.2, 5th last para: is "indicate support" right here? isn't this >>> the reporting node asking that that alg be used, but the alg is >>> really "supported" at the reacting node? >>> >>> - 5.2.1.3: Where do you say how to handle the case where a sequence >>> number wraps around? Even if that's highly improbable the text to say >>> what to do is cheap. >>> >>> - 5.3: "[RFC6733] defined Grouped AVP extension mechanisms apply. " >>> is unclear, to me anyway. What's it mean? >>> >>> - 6.1, step 4: I think that has to be a uniformly selected random >>> number. >>> >>> - 6.3: "If reacting node comes out of the 100 percent traffic >>> reduction..." I don't get what that condition means exactly. Would >>> all implementers read it to mean the same thing? >>> >>> - 7.5: What does a receiver do if a duration value that's greater >>> than 24 hours is received? One could barf the message or treat it as >>> default (30s) or as a day I guess. If this is covered by some >>> generic Diameter default handling of bad values, that's fine. >>> >>> - 10.1 says: "t's critical that nodes validate that an overload >>> report received from a peer actually falls within that peer's >>> responsibility..." but I don't see how that can be done solely using >>> Diameter protocol elements so don't you need to say that some >>> out-of-band agreement/information is needed for this to work? Even >>> within a single administrative domain, a node would need to check >>> that the peer is "inside" and presumably border nodes would need even >>> more. >>> >>> - 10.2, para 1: I think it'd be helpful here if an example Diameter >>> application with a really bad potential for a DoS, just for emphasis. >>> As-is, it's not really clear how bad a potential DoS might be. >>> >>> - C.5 - section 10 seems to me to be a new vulnerability that is >>> entirely due to DOIC, so this seems wrong. It's also a tad late for >>> early security review. I'd say to strike the entire C.5 section, or >>> at least re-word. >>> >>> - Appendix C.6: I skipped this one. Not sure if it's better to keep >>> or drop. Keeping it might just lead to more argument is the concern. >>> >>> >>> >>> >>> >>> _______________________________________________ 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 >> > > From nobody Mon Jul 6 16:54:19 2015 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 29E7F1A1BE0; Mon, 6 Jul 2015 16:54: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] 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 hiijJd0ERYx0; Mon, 6 Jul 2015 16:54:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA011A1BD1; Mon, 6 Jul 2015 16:54:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706235416.11542.97783.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 16:54:16 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-group-signaling-05.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: Mon, 06 Jul 2015 23:54:18 -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 Group Signaling Authors : Mark Jones Marco Liebsch Lionel Morand Filename : draft-ietf-dime-group-signaling-05.txt Pages : 24 Date : 2015-07-06 Abstract: In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter nodes to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-group-signaling-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-group-signaling-05 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 Wed Jul 8 23:37:16 2015 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 DC6B71A92DE for ; Wed, 8 Jul 2015 23:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 PsDGE9rq13H9 for ; Wed, 8 Jul 2015 23:37:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA98B1A92BB for ; Wed, 8 Jul 2015 23:37:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYO06662; Thu, 09 Jul 2015 06:37:09 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jul 2015 07:37:08 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.22]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Thu, 9 Jul 2015 14:37:01 +0800 From: "Zhouqian (Cathy)" To: Stephen Farrell , "dime@ietf.org" Thread-Topic: [Dime] AD review of draft-ietf-dime-4over6-provisioning-03 Thread-Index: AQHQt9l2u8LOq0lkNkeTATlbAO4Q1p3PlHjA Date: Thu, 9 Jul 2015 06:37:01 +0000 Message-ID: References: <559A5D34.2040807@cs.tcd.ie> In-Reply-To: <559A5D34.2040807@cs.tcd.ie> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.95] Content-Type: multipart/alternative; boundary="_000_A6A061BEE5DDC94A9692D9D81AF776DF409748E3SZXEMA512MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Dime] AD review of draft-ietf-dime-4over6-provisioning-03 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, 09 Jul 2015 06:37:15 -0000 --_000_A6A061BEE5DDC94A9692D9D81AF776DF409748E3SZXEMA512MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Stephen, Thank you for your comments, my reply is in line with [CZ].. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Monday, July 06, 2015 6:49 PM To: dime@ietf.org Subject: [Dime] AD review of draft-ietf-dime-4over6-provisioning-03 Hiya, I've done my AD review of draft-ietf-dime-4over6-provisioning-03 Seems to me like all's well. I'll start IETF LC shortly. My few nitty comme= nts are below, please treat then as IETF LC comments. Thanks, S. - intro, 3rd last para: You use both MAP-E and MAP (without a -E) here. Are= they the same or is that an implicit subtlty that'd be better explicit? I'= d say either use MAP-E in both cases, or explain in general what's meant wh= en you use each. [CZ]: It should be MAP-E in both cases. - intro; The last para is very unclear. What does "doesn't specify and = that the AVPs...." mean? I'd say split into two sentences. [CZ]: We will split it as " This document doesn't specify any new commands = or Application-Ids. The AVPs specified could be used for any Diameter appli= cation suitable for provisioning." - section 2, 2nd para: Why "allowed to use"? That's wrong anyway, a custome= r could do other things as well as what one operator provisions for that cu= stomer. S/is allowed/wants/ would be fine. [CZ]: We will change "allowed" to "wants". - 2.2 and 2.3: Are we only talking source ports for outgoing traffic here, = or is this the list of all ports on which this customer can receive inbound= traffic? Would it help to say, since the latter can be bigger than the for= mer? I assume we mean the latter anyway. (This may be a dumb question - sor= ry if my ignorance of LW4over6 and MAP-E is showing there:-) [CZ]: We are talking about the source ports here. As defined in LW4over6, w= hen the CE receives an IPv4 packet from the user, it performs a NAPT44 func= tion on the source address and port by using the public IPv4 address and a = port number from the allocated port-set. - 2.5, typo: s/Pv4/IPv4/ [CZ]We will fix it in next version. - 3.1, I'm surprised there wasn't already an AVP for that. If there is one,= or a similar one, it might be good to say and give a bit of a hint when to= use which. [CZ]: There is already an IP-Address-Range AVP defined in [rfc5777], howeve= r, there is no definition of the real IP prefix length AVP when it is in a = grouped AVP. As also noted in this document, "the IP-Prefix-Length AVP is o= nly relevant when associated with an IP-Address AVP in a Grouped AVP." - 8.1: the softwire I-D references are outdated. Does everything still work= ok with the latest draft versions? [CZ]: We will update the references in the next version and this dime-provi= sioning document is consistent with the latest versions. Best Regards, Cathy _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_A6A061BEE5DDC94A9692D9D81AF776DF409748E3SZXEMA512MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Stephen,

Thank you for your comments,= my reply is in line with [CZ]..

 

 

-----Original Message-----

From: DiME [mailto:dime-boun= ces@ietf.org] On Behalf Of Stephen Farrell

Sent: Monday, July 06, 2015 = 6:49 PM

To: dime@ietf.org=

Subject: [Dime] AD review of= draft-ietf-dime-4over6-provisioning-03

 

 

Hiya,

 

I've done my AD review of dr= aft-ietf-dime-4over6-provisioning-03

 

Seems to me like all's well.= I'll start IETF LC shortly. My few nitty comments are below, please treat = then as IETF LC comments.

 

Thanks,

S.

 

- intro, 3rd last para: You = use both MAP-E and MAP (without a -E) here. Are they the same or is that an= implicit subtlty that'd be better explicit? I'd say either use MAP-E in bo= th cases, or explain in general what's meant when you use each.

 

[CZ]: It should be MAP-E in = both cases.

 

- intro; The last para is ve= ry unclear. What does "doesn't specify <x> and that the AVPs....= " mean? I'd say split into two sentences.

[CZ]: We will split it as &q= uot; This document doesn't specify any new commands or Application-Ids. The= AVPs specified could be used for any Diameter application suitable for pro= visioning."

 

- section 2, 2nd para: Why &= quot;allowed to use"? That's wrong anyway, a customer could do other t= hings as well as what one operator provisions for that customer.  S/is= allowed/wants/ would be fine.

 

[CZ]: We will change "a= llowed" to "wants".

 

- 2.2 and 2.3: Are we only t= alking source ports for outgoing traffic here, or is this the list of all p= orts on which this customer can receive inbound traffic? Would it help to s= ay, since the latter can be bigger than the former? I assume we mean the latter anyway. (This may be a dumb questi= on - sorry if my ignorance of LW4over6 and MAP-E is showing there:-)

[CZ]: We are talking about t= he source ports here. As defined in LW4over6, when the CE receives an IPv4 = packet from the user, it performs a NAPT44 function on the source address a= nd port by using the public IPv4 address and a port number from the allocated port-set.

 

- 2.5, typo: s/Pv4/IPv4/

[CZ]We will fix it in next v= ersion.

 

- 3.1, I'm surprised there w= asn't already an AVP for that. If there is one, or a similar one, it might = be good to say and give a bit of a hint when to use which.

[CZ]: There is already an IP-Address-Range AVP defined in [rfc5777], however, = there is no definition of the real IP prefix length AVP when it is in a gro= uped AVP. As also noted in this document, "the IP-Prefix-Length AVP is only relevan= t when associated with an IP-Address AVP in a Grouped AVP."

 

 

- 8.1: the softwire I-D refe= rences are outdated. Does everything still work ok with the latest draft ve= rsions?

[CZ]: We will update the ref= erences in the next version and this dime-provisioning document is consiste= nt with the latest versions.

 

 

Best Regards,

Cathy

____________________________= ___________________

DiME mailing list=

DiME@ietf.org

https://www.ietf.org/mailman= /listinfo/dime

--_000_A6A061BEE5DDC94A9692D9D81AF776DF409748E3SZXEMA512MBXchi_-- From nobody Thu Jul 9 00:29:17 2015 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 280FB1AC42F for ; Thu, 9 Jul 2015 00:29:16 -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 lFoqBUxLEY9g for ; Thu, 9 Jul 2015 00:29:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DAB21AC42B for ; Thu, 9 Jul 2015 00:29:13 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-b8-559e22c7a79c Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 10.62.32595.7C22E955; Thu, 9 Jul 2015 09:29:11 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.17]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Thu, 9 Jul 2015 09:29:11 +0200 From: John Basha To: "dime@ietf.org" Thread-Topic: Result Code 4010 Handling by GGSN in case of Gy Interface Thread-Index: AdC6F4X8FAZn7zwITmOVcAooNo2ktw== Date: Thu, 9 Jul 2015 07:29:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_EEF22AB1A43B1F49A1AA33231F387F89175CADA0ESESSMB203erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje5xpXmhBocu6FrM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCNzMgqafSqm71vH1MD40qmLkZNDQsBE4vStR+wQtpjEhXvr 2boYuTiEBI4yStx7doARwlnEKHHj4kJmkCo2AS2J3k8ngDo4OEQElCVO/3IACQsLOEkcPXAB bJCIgLvE72cP2CBK9CSuzzMHCbMIqEi8WXKOFcTmFfCV2LHxN1g5I9De76fWMIHYzALiEree zGeCuEdAYsme88wQtqjEy8f/WCFsJYnGJU9YIerzJRa0zmWBmCkocXLmE5YJjEKzkIyahaRs FpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRtDi1OCk33chYL7UoM7m4OD9PLy+1 ZBMjMB4ObvmtuoPx8hvHQ4wCHIxKPLwLrs4NFWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGRofutV+aTUTaFu5vKl3xbMn9cscTj4tk/s5z45uaOktzdbfA 33SL7bv8uS6b1r8QMfL0/VY07feJPNNL6RcDvy85/eTzyXUzpp175Ton4k5Sh8hKsxj2p+vr BLXvmYT/dTxvnLTHJ5TlZr2gY9DcegOm3yxijxc89neKFPNf+0z2xJRovsdCf5VYijMSDbWY i4oTAbgrE01oAgAA Archived-At: Subject: [Dime] Result Code 4010 Handling by GGSN in case of Gy Interface 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, 09 Jul 2015 07:29:16 -0000 --_000_EEF22AB1A43B1F49A1AA33231F387F89175CADA0ESESSMB203erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Community, I have a very basic question on the behavior of GGSN when OCS sends result = code 4010 for a service on MSCC level. There is a slight deviation in the definition of Result-Code 4010 between 3= GPP 32299 and RFC 4006. As per RFC 6733, it is clearly mentioned to deduct(Highlighted in yellow) t= he Used-Service-Unit(USU) if reported by GGSN(Client) when OCS sends 4010 a= nd I mentioned it to your for your kind reference. DIAMETER_END_USER_SERVICE_DENIED 4010 The credit-control server denies the service request due to service restrictions. If the CCR contained used-service-units, they are deducted, if possible. But as per 3GPP 32299((Under section 7.1.6 Result-Code AVP), there is nothi= ng mentioned about USU. DIAMETER_END_USER_SERVICE_DENIED 4010 The OCF denies the service request due to service restrictions= (e.g. terminate rating group) or limitations related to the end-user, for = example the end-user's account could not cover the requested service. My question here is that, which behavior should I expect from GGSN when OC= S sends 4010 for a service? 1. Should we expect USU from GGSN after OCS sends 4010?(According to = RFC 4006) 2. Shouldn't we expect USU from GGSN after OCS sends 4010?(According = to 3GPP 32299) Kindly clarify. Regards, Basha S --_000_EEF22AB1A43B1F49A1AA33231F387F89175CADA0ESESSMB203erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Community,

 

I have a very basic question on the behavior of GGSN= when OCS sends result code 4010 for a service on MSCC level.

 

There is a slight deviation in the definition of Res= ult-Code 4010 between 3GPP 32299 and RFC 4006.

 

As per RFC 6733, it is clearly mentioned to de= duct(Highlighted in yellow) the Used-Service-Unit(USU) if reported by GGSN(= Client) when OCS sends 4010 and I mentioned it to your for your kind refere= nce.

 

   DIAMETER_END_USER_SERVICE_DENIED&= nbsp;          4010=

      The credit-cont= rol server denies the service request due to

      service restric= tions.  If the CCR contained= used-service-units,

 &= nbsp;    they are deducted, if possible.

 

 

But as per 3GPP 32299((Under section 7.1.6 Result-Code AVP), there is nothing mentioned about USU.

 

    =          DIAMETER_END_USER_SERVICE_= DENIED            &n= bsp;    4010

    =          The OCF denies the service= request due to service restrictions (e.g. terminate rating group) or limit= ations related to the end-user, for example the end-user's account could no= t cover the requested service.

 

 

My question here is that,  which behavior shoul= d I expect from GGSN when OCS sends 4010 for a service?

 

1.     &= nbsp; Should we expect USU from GGSN after OCS sends 4010= ?(According to RFC 4006)

2.     &= nbsp; Shouldn’t we expect USU from GGSN after OCS s= ends 4010?(According to 3GPP 32299)

 

Kindly clarify.

 

Regards,

Basha S

--_000_EEF22AB1A43B1F49A1AA33231F387F89175CADA0ESESSMB203erics_-- From nobody Thu Jul 9 02:37:49 2015 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 23B061A893B for ; Thu, 9 Jul 2015 02:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 yny8htOuan_R for ; Thu, 9 Jul 2015 02:37:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C121A8902 for ; Thu, 9 Jul 2015 02:37:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0C099BE53; Thu, 9 Jul 2015 10:37:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436434665; bh=J+crNYWAZI6VLQ1gCVHQMHZ4qKYEE++FNTfesgNVlH4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=P+NmdIHhDbCb4kvzxMJcdtlDHe9tdOJ99TY/7TzrFAbk8GH025IYeNmUfkmQHxus2 8cdiI2CV20ai0rGBTSst55ZiSF+4tucSx/xBfGFMy3plgNmM82JZDRp4dXqZJU5WBw NhDlnAFCFPvCNK5pMhKvl0Vtn2O6nvYG685A6Y6s= Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auZ8fedkt9Og; Thu, 9 Jul 2015 10:37:44 +0100 (IST) Received: from [134.226.63.24] (cswireless63-24.scss.tcd.ie [134.226.63.24]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C7AC4BE50; Thu, 9 Jul 2015 10:37:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436434664; bh=J+crNYWAZI6VLQ1gCVHQMHZ4qKYEE++FNTfesgNVlH4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fiOtPPqa/9M8Dg8QGie31b2M6a4v64noSfWVLzeiNm+WZken8Cds6qA0Ob9EoNO8d NWzBOXBMjFyDljrFpoWn9mUjnnBrkYli7OPK4xUT4t5MowNjL1jbt1Wc9LPsN+uaQR zu+dKKPLlhZFhBnkTd7CYlLZCJ5skRtcDML5n6ko= Message-ID: <559E40E8.8020709@cs.tcd.ie> Date: Thu, 09 Jul 2015 10:37:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Zhouqian (Cathy)" , "dime@ietf.org" References: <559A5D34.2040807@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] AD review of draft-ietf-dime-4over6-provisioning-03 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, 09 Jul 2015 09:37:48 -0000 Hi Cathty, Those all look good. One question below though Cheers, S. On 09/07/15 07:37, Zhouqian (Cathy) wrote: > Dear Stephen, > > Thank you for your comments, my reply is in line with [CZ].. > > > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Stephen > Farrell > > Sent: Monday, July 06, 2015 6:49 PM > > To: dime@ietf.org > > Subject: [Dime] AD review of draft-ietf-dime-4over6-provisioning-03 > > > > > > Hiya, > > > > I've done my AD review of draft-ietf-dime-4over6-provisioning-03 > > > > Seems to me like all's well. I'll start IETF LC shortly. My few nitty > comments are below, please treat then as IETF LC comments. > > > > Thanks, > > S. > > > > - intro, 3rd last para: You use both MAP-E and MAP (without a -E) > here. Are they the same or is that an implicit subtlty that'd be > better explicit? I'd say either use MAP-E in both cases, or explain > in general what's meant when you use each. > > > > [CZ]: It should be MAP-E in both cases. > > > > - intro; The last para is very unclear. What does "doesn't specify > and that the AVPs...." mean? I'd say split into two sentences. > > [CZ]: We will split it as " This document doesn't specify any new > commands or Application-Ids. The AVPs specified could be used for any > Diameter application suitable for provisioning." > > > > - section 2, 2nd para: Why "allowed to use"? That's wrong anyway, a > customer could do other things as well as what one operator > provisions for that customer. S/is allowed/wants/ would be fine. > > > > [CZ]: We will change "allowed" to "wants". > > > > - 2.2 and 2.3: Are we only talking source ports for outgoing traffic > here, or is this the list of all ports on which this customer can > receive inbound traffic? Would it help to say, since the latter can > be bigger than the former? I assume we mean the latter anyway. (This > may be a dumb question - sorry if my ignorance of LW4over6 and MAP-E > is showing there:-) > > [CZ]: We are talking about the source ports here. As defined in > LW4over6, when the CE receives an IPv4 packet from the user, it > performs a NAPT44 function on the source address and port by using > the public IPv4 address and a port number from the allocated > port-set. Hmm. So you can't allocate a port to someone unless they send a packet using that as the source port? That seems a bit odd to me. How would one support a server in such a case? > > > > - 2.5, typo: s/Pv4/IPv4/ > > [CZ]We will fix it in next version. > > > > - 3.1, I'm surprised there wasn't already an AVP for that. If there > is one, or a similar one, it might be good to say and give a bit of a > hint when to use which. [CZ]: There is already an IP-Address-Range > AVP defined in [rfc5777], however, there is no definition of the real > IP prefix length AVP when it is in a grouped AVP. As also noted in > this document, "the IP-Prefix-Length AVP is only relevant when > associated with an IP-Address AVP in a Grouped AVP." > > > > > > - 8.1: the softwire I-D references are outdated. Does everything > still work ok with the latest draft versions? > > [CZ]: We will update the references in the next version and this > dime-provisioning document is consistent with the latest versions. > > > > > > Best Regards, > > Cathy > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > From nobody Thu Jul 9 02:58:06 2015 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 4EC3A1A914C for ; Thu, 9 Jul 2015 02:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Wj9ggd6jUG_4 for ; Thu, 9 Jul 2015 02:58:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A980F1A90CD for ; Thu, 9 Jul 2015 02:58:00 -0700 (PDT) Received: from BN3PR0501MB1571.namprd05.prod.outlook.com (10.161.217.149) by BN3PR0501MB1249.namprd05.prod.outlook.com (10.160.183.140) with Microsoft SMTP Server (TLS) id 15.1.207.19; Thu, 9 Jul 2015 09:57:40 +0000 Received: from BN3PR0501MB1572.namprd05.prod.outlook.com (10.161.217.15) by BN3PR0501MB1571.namprd05.prod.outlook.com (10.161.217.149) with Microsoft SMTP Server (TLS) id 15.1.207.19; Thu, 9 Jul 2015 09:57:39 +0000 Received: from BN3PR0501MB1572.namprd05.prod.outlook.com ([10.161.217.15]) by BN3PR0501MB1572.namprd05.prod.outlook.com ([10.161.217.15]) with mapi id 15.01.0207.004; Thu, 9 Jul 2015 09:57:39 +0000 From: Jens Schendel To: John Basha , "dime@ietf.org" Thread-Topic: Result Code 4010 Handling by GGSN in case of Gy Interface Thread-Index: AdC6F4X8FAZn7zwITmOVcAooNo2ktwAEMeeg Date: Thu, 9 Jul 2015 09:57:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; x-originating-ip: [213.61.69.222] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1571; 5:15oSjWwpwDRomLZgQrX99RXezRvfK6kDn11MiSTOZIipIuo7gP4ftuoU9RXz7hd5oDXFFuT/OXz0Wx/pECijZValoKMvqNhkgRV7fJVM7Jck40BDBpkbbZg4z9EZUtAq8cCljWzFVXnEYnZ3PJ/lbw==; 24:T3SJcuIwTJFrAFELyMmeMbG/hcvWGzmRc1vdZWXrS2ZCakcG9NgupdXpDGke2/cBXgLEbIenpROwDiiu0tsA3L5bEONtpgRKZOYFfSw+jQs=; 20:tbgXMnzRguoa71nXWCuCMW3VrCRJUtypRJXUrF9xr50I1bURMSAzClF+99obziFk/S0NLYUez2QzWTHvJ4wx5w== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1571; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1249; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN3PR0501MB1571; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1571; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(102836002)(15975445007)(77096005)(107886002)(5001960100002)(2950100001)(2900100001)(77156002)(16236675004)(62966003)(74316001)(5003600100002)(92566002)(76176999)(50986999)(54356999)(66066001)(2501003)(46102003)(19625215002)(5001770100001)(40100003)(33656002)(19580395003)(19580405001)(19300405004)(87936001)(2656002)(86362001)(99286002)(122556002)(189998001)(5002640100001)(19609705001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1571; H:BN3PR0501MB1572.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0501MB1572F2D8D67BBD6DB000DCF1E1900BN3PR0501MB1572_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2015 09:57:38.9034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c452882-d89d-4c15-bdff-49dbef6eddcf X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1571 X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1249; 2:72JC8Hpubh2cc4jdAdW33lbAw5eODKOwAwvgUOAVenTl7q80cfdazgVMMWjSG7YA; 3:00EnQnk+a6MPMR95ivZ1aWtzHzJ/JoyFk69unp1xpPxcWDCnkWpbJ5OqZxQVQR9h72ozY1mCX2JuJDJdf3+rC66W2qBhwJBeecgDc/CJGbkEZPjb8v8Z/mp12FD8yaha4RChxfgAeGj7m3WRCojA3g==; 25:b35GjKIuCAUm4c4UJA3ZevOuOQxWH8ZVbS01ZT4rnsdEMBuP2DkNz/6CQI9YSsSVJtIpgS0SVKruSceH38exy11LPtviBExqpJYRsUAQ7tssZn1VSRqhwz0+FBiq+h6X2p3977T2fGMp/kHNx7JPGP6MabPZz9lbZBWFWPLXF+tDl4vFN4BJwROD12hHtj+mGSpLSLfXCKH/2BMgE9FVI6xft67tDpES2r7pmosVqqrnuaoUEm75zKY0sjA8JaklrEuNniDr/Uf816cf2oSqZw==; 23:uckDjBvK3lsGtMr2yX1FBwlQTvTxXjw1HZ50JRHGmX3MZDHovmExejEFB8u4AiZJADDZ3cC+BjJ9a/hOtSxN7OB8jUS5nZfOUfXne9M7wn0wqfpG1nzGV+/GMQ76JHlpG3GDpkqDEIMppAvx/C1WoMFp5rfrEUSqayvcZDC6KmiMRKCGkFRPpM304bF7kFzBhQRWCPqCTM4YHM/BYsII8qZ/OHY2SQjkQ9Xmo32xbQH23qtk7q+MegYO/ea36XGZ X-OriginatorOrg: redknee.com Archived-At: Subject: Re: [Dime] Result Code 4010 Handling by GGSN in case of Gy Interface 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, 09 Jul 2015 09:58:04 -0000 --_000_BN3PR0501MB1572F2D8D67BBD6DB000DCF1E1900BN3PR0501MB1572_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Basha, actually, I cannot see any specific text in the quotes below from RFC 4006 = and 3GPP TS 32.299 that describes the sending of a follow-up CCR Update aft= er receiving CCA with Result-Code=3D 4010. The "If the CCR contained used-s= ervice-units, they are deducted,..." refers to the CCR Update that is then = answered by 4010. Similar for Credit_Limit_Reached 4012. The 3GPP TS 32.299= inherits Diameter Base / DCCA behavior, see text in the Result-Code secti= on: "The Result-Code AVP operates as described in RFC 3588 [401] and RFC 4006 [= 402]. The following result code descriptions are examples of the possible u= ses for the code:... " In practice, it is not uncommon to send that mentioned follow-up CCR Update= with possibly some remaining quota (gap between previous CCR and CCA) on t= hat specific Result-Code (and in the same way also for 4012), so that the s= erver eventually gets the completely used quota. The 3GPP specification doe= s neither prohibit nor explicitly describe this flow. Thus, in my opinion t= he follow-up CCR Update is the recommended behavior. Jens From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of John Basha Sent: Donnerstag, 9. Juli 2015 09:29 To: dime@ietf.org Subject: [Dime] Result Code 4010 Handling by GGSN in case of Gy Interface Dear Community, I have a very basic question on the behavior of GGSN when OCS sends result = code 4010 for a service on MSCC level. There is a slight deviation in the definition of Result-Code 4010 between 3= GPP 32299 and RFC 4006. As per RFC 6733, it is clearly mentioned to deduct(Highlighted in yellow) t= he Used-Service-Unit(USU) if reported by GGSN(Client) when OCS sends 4010 a= nd I mentioned it to your for your kind reference. DIAMETER_END_USER_SERVICE_DENIED 4010 The credit-control server denies the service request due to service restrictions. If the CCR contained used-service-units, they are deducted, if possible. But as per 3GPP 32299((Under section 7.1.6 Result-Code AVP), there is nothi= ng mentioned about USU. DIAMETER_END_USER_SERVICE_DENIED 4010 The OCF denies the service request due to service restrictions= (e.g. terminate rating group) or limitations related to the end-user, for = example the end-user's account could not cover the requested service. My question here is that, which behavior should I expect from GGSN when OC= S sends 4010 for a service? 1. Should we expect USU from GGSN after OCS sends 4010?(According to = RFC 4006) 2. Shouldn't we expect USU from GGSN after OCS sends 4010?(According = to 3GPP 32299) Kindly clarify. Regards, Basha S --_000_BN3PR0501MB1572F2D8D67BBD6DB000DCF1E1900BN3PR0501MB1572_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Basha,

 

actually, I cannot see= any specific text in the quotes below from RFC 4006 and 3GPP TS 32.299 tha= t describes the sending of a follow-up CCR Update after receiving CCA with = Result-Code=3D 4010. The “If the CCR contained used-service-units, they are deducted,…” refers to the CCR Upd= ate that is then answered by 4010. Similar for Credit_Limit_Reached 4012. T= he 3GPP TS 32.299 inherits Diameter Base / DCCA  behavior, see text in= the Result-Code section:

“The Resu= lt-Code AVP operates as described in RFC 3588 [401] and RFC 4006 [402]. The= following result code descriptions are examples of the possible uses for t= he code:… “

 

In practice, it is not= uncommon to send that mentioned follow-up CCR Update with possibly some re= maining quota (gap between previous CCR and CCA) on that specific Result-Co= de (and in the same way also for 4012), so that the server eventually gets the completely used quota. The 3GPP spe= cification does neither prohibit nor explicitly describe this flow. Thus, i= n my opinion the follow-up CCR Update is the recommended behavior.

 

Jens=

 

From: DiME [mailto:dime-bounces@ietf.org] = On Behalf Of John Basha
Sent: Donnerstag, 9. Juli 2015 09:29
To: dime@ietf.org
Subject: [Dime] Result Code 4010 Handling by GGSN in case of Gy Inte= rface

 

Dear Community,

 

I have a very basic question on the behavior of GGSN= when OCS sends result code 4010 for a service on MSCC level.

 

There is a slight deviation in the definition of Res= ult-Code 4010 between 3GPP 32299 and RFC 4006.

 

As per RFC 6733, it is clearly mentioned to de= duct(Highlighted in yellow) the Used-Service-Unit(USU) if reported by GGSN(= Client) when OCS sends 4010 and I mentioned it to your for your kind refere= nce.

 

   DIAMETER_END_USER_SERVICE_DENIED&= nbsp;          4010=

      The credit-cont= rol server denies the service request due to

      service restric= tions.  If the CCR contained= used-service-units,

 &= nbsp;    they are deducted, if possible.

 

 

But as per 3GPP 32299((Under section 7.1.6 Result-Code AVP), there is nothing mentioned about USU.

 

    =          DIAMETER_END_USER_SERVICE_= DENIED            &n= bsp;    4010

    =          The OCF denies the service= request due to service restrictions (e.g. terminate rating group) or limit= ations related to the end-user, for example the end-user's account could no= t cover the requested service.

 

 

My question here is that,  which behavior shoul= d I expect from GGSN when OCS sends 4010 for a service?

 

1.     &= nbsp; Should we expect USU from GGSN after OCS sends 4010= ?(According to RFC 4006)

2.     &= nbsp; Shouldn’t we expect USU from GGSN after OCS s= ends 4010?(According to 3GPP 32299)

 

Kindly clarify.

 

Regards,

Basha S

--_000_BN3PR0501MB1572F2D8D67BBD6DB000DCF1E1900BN3PR0501MB1572_-- From nobody Thu Jul 9 03:13:19 2015 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 204271ACEED; Thu, 9 Jul 2015 03:13:17 -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, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 PbywYpJKUqHD; Thu, 9 Jul 2015 03:13:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 312811ACE91; Thu, 9 Jul 2015 03:13:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150709101316.15125.13372.idtracker@ietfa.amsl.com> Date: Thu, 09 Jul 2015 03:13:16 -0700 Archived-At: Cc: dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Martin Stiemerling's No Objection on draft-ietf-dime-congestion-flow-attributes-02: (with COMMENT) 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: Thu, 09 Jul 2015 10:13:17 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sorry for taking so long and thank you for addressing David's and my concerns. From nobody Thu Jul 9 04:09:00 2015 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 03AA91A702D for ; Thu, 9 Jul 2015 04:08:59 -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 MqksDdAkiN_g for ; Thu, 9 Jul 2015 04:08:57 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28511A7D81 for ; Thu, 9 Jul 2015 04:08:57 -0700 (PDT) Received: by igoe12 with SMTP id e12so11393429igo.1 for ; Thu, 09 Jul 2015 04:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=Jg1eqVlhtJN3AVpI2DtCz6nFxYL37D3C/YO84PArY5c=; b=dAAAyEwNAmiduChflKXE5n8TjDZCxh/JIOxYaUOOt0jshLYiDN7/0tgsiqRr0hPGJK 0j23AMfF07OwBu1nKF/UL2v61Sh7zMEX6g1L3O5oYaQQ71VLpxpJGIW8JsauTf+mRv32 6obHI+IauCS5JJqFGak4RrakpasMx+1Zr5IHh9rr2td8w5MZnIm9D2WC9W9V41IsnF3o UDWZ7Er/t37YiyA5/d0ZtU4pVM3bTYRIE8+Alhvv1icRNPU2ECgqkaGEHWPLsPKKZHcF AQov5q5euwlEVOtJgnN1x6xsNTnLkYhibhvNPd+EDc9DfmtNuw44YdTE/7Yw0cqSjXKp 7Yxg== X-Received: by 10.107.39.209 with SMTP id n200mr25625898ion.59.1436440137106; Thu, 09 Jul 2015 04:08:57 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-132-76.tor.primus.ca. [173.206.132.76]) by smtp.gmail.com with ESMTPSA id d4sm16332170igl.1.2015.07.09.04.08.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2015 04:08:56 -0700 (PDT) To: Stephen Farrell , "Zhouqian (Cathy)" , "dime@ietf.org" References: <559A5D34.2040807@cs.tcd.ie> <559E40E8.8020709@cs.tcd.ie> From: Tom Taylor Message-ID: <559E5646.5060607@gmail.com> Date: Thu, 9 Jul 2015 07:08:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <559E40E8.8020709@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] AD review of draft-ietf-dime-4over6-provisioning-03 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, 09 Jul 2015 11:08:59 -0000 On 09/07/2015 5:37 AM, Stephen Farrell wrote: > > Hi Cathty, > > Those all look good. One question below though > ... >> >> - 2.2 and 2.3: Are we only talking source ports for outgoing traffic >> here, or is this the list of all ports on which this customer can >> receive inbound traffic? Would it help to say, since the latter can >> be bigger than the former? I assume we mean the latter anyway. (This >> may be a dumb question - sorry if my ignorance of LW4over6 and MAP-E >> is showing there:-) >> >> [CZ]: We are talking about the source ports here. As defined in >> LW4over6, when the CE receives an IPv4 packet from the user, it >> performs a NAPT44 function on the source address and port by using >> the public IPv4 address and a port number from the allocated >> port-set. > > Hmm. So you can't allocate a port to someone unless they send a > packet using that as the source port? That seems a bit odd to me. > How would one support a server in such a case? > ... [PTT] This is typical behaviour for a NAT. However, it is also possible to set up static allocations, and you probably would for a server. From nobody Mon Jul 13 04:40:53 2015 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 CB7591A905E for ; Mon, 13 Jul 2015 04:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 j9uRl0OX7W3l for ; Mon, 13 Jul 2015 04:40:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6921A905A for ; Mon, 13 Jul 2015 04:40:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3B63ABDD0 for ; Mon, 13 Jul 2015 12:40:46 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d486WrCwORY3 for ; Mon, 13 Jul 2015 12:40:46 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DEEA9BDCA for ; Mon, 13 Jul 2015 12:40:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436787646; bh=W7Z1/6AveMEilevphIwX6kXZ8u7RRqwjujsRbJMxQUw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=pLksEs9U9cPROpugha45O+Rq5xCHZdZbbLulT4VN+auI6VV/ZIsJ53s3jzjp3W9P5 LbgmwXGYNAE5rNpV3CdYgUmuscsrZN0baHiz9P/HIKwNIe7JuhWAUJPd8sLTkDZ64Z gCm0axNDiBdgRvhutE64gtF+lQGrcMmiC4JnQeNU= Message-ID: <55A3A3BD.3080709@cs.tcd.ie> Date: Mon, 13 Jul 2015 12:40:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <5599ADCA.9080208@cs.tcd.ie> <25620_1436140081_5599C231_25620_10339_1_6B7134B31289DC4FAF731D844122B36E01CB70F2@OPEXCLILM43.corporate.adroot.infra.ftgroup> <559A47DB.6040100@cs.tcd.ie> In-Reply-To: <559A47DB.6040100@cs.tcd.ie> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dime] AD review of draft-ietf-dime-ovli-08 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, 13 Jul 2015 11:40:52 -0000 And a week has passed. I heard nothing so I'll start IETF LC now. Thanks for your patience. Please consider my other comments as part of the IETF LC. Thanks, S. On 06/07/15 10:18, Stephen Farrell wrote: > > Hi Lionel, > > That all sounds good. How's about though, just to be sure to be > sure, that I wait a week before starting IETF LC and ask that during > that week, anyone who has concerns about the chairs' evaluation of WG > consensus for this draft, please either send to the list or else tell > me offlist (if there's a good reason that's needed). That way, if > someone asks about this during IETF LC or IESG evaluation, we can > point them at this (recent) thread. > > If, as I expect, I hear no objections, I'll start IETF LC in a week > and that'll have no effect on the overall timing given the upcoming > IETF meeting - we'll still be fine all going well to put this on > the August 5th IESG telechat. If something (*) does come up in the > next week, we'll deal with that as necessary. > > In the meantime, the authors should feel free to respond to any of > my review comments that are useful (or useless:-) Or if you want, > it's fine to wait and handle 'em with other IETF LC comments > received if you prefer that. > > Cheers, > S. > > (*) By "something" here I *only* mean issues related to the chairs' > evaluation of the level of WG consensus for this draft. I do not > mean it's ok to re-raise technical topics that were already discussed > on the list or at meetings and disposed of via the usual WG process. > > > On 06/07/15 00:47, lionel.morand@orange.com wrote: >> Hi Stephen, >> >> This draft is the result of a joint effort between IETF and 3GPP for >> the definition of an overload control mechanism over Diameter. Both >> chairs are (unfortunately maybe) part of the authors but around 20+ >> people were active in DIME WG and 3GPP WGs to review and comment the >> documents, with confcalls and ad-hoc meetings dedicated to this >> topic. >> >> The document went through 2 WGLCs in December 2014 and January 2015), >> with cross review by 3GPP. The current document takes into account >> all the comments received during the 2 WGLCs and the feedback >> received from 3GPP folks. >> >> We can safely conclude that a rough consensus has been reached for >> this document. It ends a cooperative work started in Sept 2012, with >> the definition of the requirements (captured in RFC 7068), and >> reflects the constructive compromise reached by all the involved >> parties. >> >> For your information, due to the participation of both chairs in this >> work, Benoit has been involved from the very beginning on the >> discussions on this document to monitor the discussion. >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] >> De la part de Stephen Farrell Envoyé : lundi 6 juillet 2015 00:21 À : >> dime@ietf.org Objet : [Dime] AD review of draft-ietf-dime-ovli-08 >> >> >> Hi, >> >> Firstly, I'm your new helper-AD, Kathleen and I had to swap a few >> working groups so I'll be helping out now. Most of the stuff I've >> seen from this WG is pretty well baked these days though so I'm sure >> it'll all be fine. (Kathleen will continue to handle discuss-clearing >> for the congestion control document.) >> >> Anyway, here's my AD review for draft-ietf-dime-ovli-08. I just have >> one question to check before I start IETF last call. The rest of my >> comments (below) can be handled along with any other last call >> comments received unless you'd prefer to fix something before we >> start IETF last call. >> >> The one I'd like to chat about before IETF LC is: I see that both WG >> chairs are authors on this one, so how was WG consensus evaluation >> handled? That was probably before I joined the list I guess but I >> didn't spot it in the archive after a quick glance. >> >> Thanks, S. >> >> >> - 55 pages! sigh;-) >> >> - 2: throttling definition uses "DIOC" but earlier in this section >> you just say reacting-node. Maybe good to be fully consistent. >> >> - 4 (intro) I wondered why no new messages were defined for this and >> you decided to only piggyback. Maybe good to say why and also to >> give an example of the kind of thing on which you'd normally expect >> DOIC stuff to be piggybacked. (That could be done in 4.1 too.) >> >> - 4.2 - the reporting node picks the abatement algorithm that the >> reacting node will apply - is that correct? (from 2nd last para of >> p8) Does that mean that DOIC will in the end only be used >> intra-domain since reacting nodes aren't likely to accept such >> instructions from "anyone" else? If so, it'd be good to point that >> out early, and not only in section 10. >> >> - 4.2, last para/Note: This seems to be punting on interop which >> isn't a good thing for the IETF to be doing is it? Why is that ok >> here? >> >> - 4.3: Could anyone inject an OLR with a duration of zero as a DoS? >> Is there something hard to guess? (Turns out, no there's nothing >> added here that's hard to guess.) Maybe think about putting in a note >> about that? >> >> - Figure 1: how come there are no reporting or reacting nodes >> included? I'd have thought it'd be good to have (an example of) those >> in a figure. >> >> - 5.1.2, 5th last para: is "indicate support" right here? isn't this >> the reporting node asking that that alg be used, but the alg is >> really "supported" at the reacting node? >> >> - 5.2.1.3: Where do you say how to handle the case where a sequence >> number wraps around? Even if that's highly improbable the text to say >> what to do is cheap. >> >> - 5.3: "[RFC6733] defined Grouped AVP extension mechanisms apply. " >> is unclear, to me anyway. What's it mean? >> >> - 6.1, step 4: I think that has to be a uniformly selected random >> number. >> >> - 6.3: "If reacting node comes out of the 100 percent traffic >> reduction..." I don't get what that condition means exactly. Would >> all implementers read it to mean the same thing? >> >> - 7.5: What does a receiver do if a duration value that's greater >> than 24 hours is received? One could barf the message or treat it as >> default (30s) or as a day I guess. If this is covered by some >> generic Diameter default handling of bad values, that's fine. >> >> - 10.1 says: "t's critical that nodes validate that an overload >> report received from a peer actually falls within that peer's >> responsibility..." but I don't see how that can be done solely using >> Diameter protocol elements so don't you need to say that some >> out-of-band agreement/information is needed for this to work? Even >> within a single administrative domain, a node would need to check >> that the peer is "inside" and presumably border nodes would need even >> more. >> >> - 10.2, para 1: I think it'd be helpful here if an example Diameter >> application with a really bad potential for a DoS, just for emphasis. >> As-is, it's not really clear how bad a potential DoS might be. >> >> - C.5 - section 10 seems to me to be a new vulnerability that is >> entirely due to DOIC, so this seems wrong. It's also a tad late for >> early security review. I'd say to strike the entire C.5 section, or >> at least re-word. >> >> - Appendix C.6: I skipped this one. Not sure if it's better to keep >> or drop. Keeping it might just lead to more argument is the concern. >> >> >> >> >> >> _______________________________________________ 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 > From nobody Mon Jul 13 07:59:58 2015 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 1FE0A1B2B7C; Mon, 13 Jul 2015 07:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 feGAjBjntAEz; Mon, 13 Jul 2015 07:59:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B546E1B2B75; Mon, 13 Jul 2015 07:59:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150713145944.5973.94391.idtracker@ietfa.amsl.com> Date: Mon, 13 Jul 2015 07:59:44 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter Overload Indication Conveyance) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 14:59:48 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Overload Indication Conveyance' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-07-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jul 14 13:16:28 2015 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 C058A1B2C1E for ; Tue, 14 Jul 2015 13:16:26 -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 e7BpRZ4iPlPu for ; Tue, 14 Jul 2015 13:16:25 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953421B2AD7 for ; Tue, 14 Jul 2015 13:16:25 -0700 (PDT) Received: by pachj5 with SMTP id hj5so10862800pac.3 for ; Tue, 14 Jul 2015 13:16:25 -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=GJo8ZGotiMWluzegXeoqbedENOt35bOXmh8OmYL79v0=; b=StzYsAQKO5RT5dTg0arIktJFCzNZ8Uf5Dze6Jipa6A6KYPhvxw3LQ4OsBkTJNnPDB7 LfN352bdbPuvgUeKeV9wT5GirvigFEaAv5XhKRE45wY2zGt13nAwlxxceRb8vVC+na0/ Ip+x2kpIpT8r5vdDVEMgY6CpvBeShzsEeVWP7saWJHtuU/6Ef96kqQtkRsjwAIUNOXg5 Lo/Vz5ElZLyS87CzzjSsKdJEVrgz2ugXR+XXabvhp/98YFTLdFMlvhVJd7few4Gq2+8J GZ2XIguipfU+3WBNgnGXLMExGtRT83BuSnvy0qg3u2Fspmke7DbJCSpDVs/xGFDsPqQz 1NVg== X-Received: by 10.68.68.235 with SMTP id z11mr760330pbt.126.1436904985269; Tue, 14 Jul 2015 13:16:25 -0700 (PDT) Received: from [10.100.18.235] (rrcs-24-43-232-186.west.biz.rr.com. [24.43.232.186]) by smtp.googlemail.com with ESMTPSA id j2sm2264061pdk.21.2015.07.14.13.16.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jul 2015 13:16:24 -0700 (PDT) Message-ID: <55A56E16.7050509@gmail.com> Date: Tue, 14 Jul 2015 13:16:22 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dime] draft agenda 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, 14 Jul 2015 20:16:26 -0000 Folks, Forgot to ping the list. The draft agenda has been out now for a while already, see: http://tools.ietf.org/wg/dime/agenda - JOuni From nobody Sun Jul 19 19:27:35 2015 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 0894C1B2D3D; Sun, 19 Jul 2015 19:27:35 -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 MKrCtJsY5HL1; Sun, 19 Jul 2015 19:27:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8705B1ACF08; Sun, 19 Jul 2015 19:27:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720022733.21034.85868.idtracker@ietfa.amsl.com> Date: Sun, 19 Jul 2015 19:27:33 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-4over6-provisioning-04.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: Mon, 20 Jul 2015 02:27:35 -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 : Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions Authors : Cathy Zhou Tom Taylor Qiong Sun Mohamed Boucadair Filename : draft-ietf-dime-4over6-provisioning-04.txt Pages : 21 Date : 2015-07-19 Abstract: During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, AAA support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) attribute-value pairs to be used for that purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-4over6-provisioning/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-4over6-provisioning-04 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 Mon Jul 20 05:09:56 2015 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 800A81A3BA1; Mon, 20 Jul 2015 05:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 oW0QYrFO4-QU; Mon, 20 Jul 2015 05:09:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268181A21BF; Mon, 20 Jul 2015 05:09:46 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9C49C22C8E2; Mon, 20 Jul 2015 14:09:44 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6C224238151; Mon, 20 Jul 2015 14:09:44 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 14:09:43 +0200 From: To: "Douglas Gash (dcmgash)" , "aaa-doctors@ietf.org" , "radext@ietf.org" Thread-Topic: TACACS+ RFC Presentation Thread-Index: AQHQwuLALKIr+80AlEiIFGtOVffheJ3kQ8Ug Date: Mon, 20 Jul 2015 12:09:43 +0000 Message-ID: <17768_1437394184_55ACE508_17768_3037_1_6B7134B31289DC4FAF731D844122B36E01CCA3E5@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01CCA3E5OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.20.111516 Archived-At: Cc: "joelja@bogus.com" , Andrej Ota , "dime@ietf.org" , Thorsten Dahm Subject: Re: [Dime] TACACS+ RFC Presentation 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, 20 Jul 2015 12:09:52 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01CCA3E5OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for the notification. Adding the dime mailing list in the loop for information. Lionel De : radext [mailto:radext-bounces@ietf.org] De la part de Douglas Gash (dc= mgash) Envoy=E9 : lundi 20 juillet 2015 13:54 =C0 : aaa-doctors@ietf.org; radext@ietf.org Cc : Benoit Claise (bclaise); joelja@bogus.com; Andrej Ota; Thorsten Dahm Objet : [radext] TACACS+ RFC Presentation Hi, Please note that we are presenting a TACACS+ specification during the Ops A= rea open meeting today in Karin I (17:40 - 18:40). The Ops AD suggested tha= t this may be of interest to RADIUS and AAA groups. Many thanks, Regards, Thorsten Dahm, Andrej Ota, Doug Gash. https://www.ietf.org/proceedings/93/slides/slides-93-opsarea-2.pdf ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E01CCA3E5OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thank you = for the notification.

Adding the= dime mailing list in the loop for information.

Lionel

 = ;

De : rade= xt [mailto:radext-bounces@ietf.org] De la part de Douglas Gash (dcmgash)
Envoy=E9 : lundi 20 juillet 2015 13:54
=C0 : aaa-doctors@ietf.org; radext@ietf.org
Cc : Benoit Claise (bclaise); joelja@bogus.com; Andrej Ota; Tho= rsten Dahm
Objet : [radext] TACACS+ RFC Presentation=

 

Hi,

 

Please note that we are pre= senting a TACACS+ specification during the Ops Area open meeting today = in Karin I (17:40 – 18:40). The Ops AD suggested that this may be of interest to RADIUS and AAA groups.

 

Many thanks,

 

Regards,<= /p>

 

Thorsten Dahm, Andrej Ota, = Doug Gash.

 

______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E01CCA3E5OPEXCLILM43corp_-- From nobody Mon Jul 20 05:47:05 2015 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 F19491A8749 for ; Mon, 20 Jul 2015 05:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 8yyaz3Q5S5Vx for ; Mon, 20 Jul 2015 05:47:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A231A8741 for ; Mon, 20 Jul 2015 05:46:29 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1B7B788EBBDE1 for ; Mon, 20 Jul 2015 12:46:25 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6KCkA45001670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jul 2015 14:46:27 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.211]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 14:46:13 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: DA overload comment on 3.2 Diameter end-point use cases Thread-Index: AdDC6g2uriHYpm5ITxC41K9wntoyhQ== Date: Mon, 20 Jul 2015 12:46:13 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D202C1F55CFR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: Subject: [Dime] DA overload comment on 3.2 Diameter end-point 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: Mon, 20 Jul 2015 12:47:04 -0000 --_000_E194C2E18676714DACA9C3A2516265D202C1F55CFR712WXCHMBA12z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi About DA overload (draft-ietf-dime-agent-overload), I have a comment about = section 3.2 (Diameter Endpoint Use Cases) / 3.2.1. I do not well see the re= asons why a server would send "peer overload" reports in addition to the o= vli OLRs specified in draft-ietf-dime-ovli , as it creates overlap. The DA = is aware that it is a peer of the server; so the DA can handle the received= ovli OLRs from the server as peer OLRs if it wants. So I would limit the d= raft-ietf-dime-agent-overload only to DA overload and the associated peer = overload report to be generated by DA only . Best regards JJacques --_000_E194C2E18676714DACA9C3A2516265D202C1F55CFR712WXCHMBA12z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

About DA overload (draft-ietf-dime-agent-overload), = I have a comment about section 3.2 (Diameter Endpoint Use Cases) / 3.2.1. I= do not well see the reasons  why a server would send “peer over= load” reports in addition to the ovli OLRs specified in draft-ietf-dime-ovli , as it creates overlap. The DA is aware that it i= s a peer of the server; so the DA can handle the received ovli OLRs from th= e server as peer OLRs if it wants. So I would limit the draft-ietf-dime-age= nt-overload only to DA overload  and the associated peer overload report to be generated by DA only .=

 

Best regards

 

JJacques

--_000_E194C2E18676714DACA9C3A2516265D202C1F55CFR712WXCHMBA12z_-- From nobody Mon Jul 20 08:08:21 2015 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 35B701A8AC6 for ; Mon, 20 Jul 2015 08:08:19 -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 fTGFKv7aKKWT for ; Mon, 20 Jul 2015 08:08:17 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B9B1A8AB9 for ; Mon, 20 Jul 2015 08:08:07 -0700 (PDT) Received: from 83-167-240-135.static.masterinter.net ([83.167.240.135]:63601 helo=dhcp-b09f.meeting.ietf.org) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZHCfj-0001By-UG for dime@ietf.org; Mon, 20 Jul 2015 08:08:06 -0700 Message-ID: <55AD0ED2.9030106@usdonovans.com> Date: Mon, 20 Jul 2015 17:08:02 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000302000902050201030707" X-OutGoing-Spam-Status: No, score=-1.0 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: Subject: Re: [Dime] DA overload comment on 3.2 Diameter end-point 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: Mon, 20 Jul 2015 15:08:19 -0000 This is a multi-part message in MIME format. --------------000302000902050201030707 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit JJacques, Thanks for the comment. I would assume that the Diameter endpoint (server for this discussion) would send either a peer report or a host report. There would be no reason for the server to send both. A host report is processed and passed on by agents. A peer report is consumed by agents and, most likely, a new peer report is generated by the agent. The peer report is envisioned to be used for multiple reasons. The first is defined in the agent overload draft to allow agents to communicate overload state. The second is for overload abatement algorithms that require peer-to-peer semantics. The first case of this second usage is the rate overload abatement algorithm. Regards, Steve On 7/20/15 2:46 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > > Hi > > About DA overload (draft-ietf-dime-agent-overload), I have a comment > about section 3.2 (Diameter Endpoint Use Cases) / 3.2.1. I do not well > see the reasons why a server would send “peer overload” reports in > addition to the ovli OLRs specified in draft-ietf-dime-ovli , as it > creates overlap. The DA is aware that it is a peer of the server; so > the DA can handle the received ovli OLRs from the server as peer OLRs > if it wants. So I would limit the draft-ietf-dime-agent-overload only > to DA overload and the associated peer overload report to be > generated by DA only . > > Best regards > > JJacques > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------000302000902050201030707 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit JJacques,

Thanks for the comment.

I would assume that the Diameter endpoint (server for this discussion) would send either a peer report or a host report.  There would be no reason for the server to send both.

A host report is processed and passed on by agents.

A peer report is consumed by agents and, most likely, a new peer report is generated by the agent.

The peer report is envisioned to be used for multiple reasons.  The first is defined in the agent overload draft to allow agents to communicate overload state.  The second is for overload abatement algorithms that require peer-to-peer semantics.  The first case of this second usage is the rate overload abatement algorithm.

Regards,

Steve

On 7/20/15 2:46 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:

Hi

 

About DA overload (draft-ietf-dime-agent-overload), I have a comment about section 3.2 (Diameter Endpoint Use Cases) / 3.2.1. I do not well see the reasons  why a server would send “peer overload” reports in addition to the ovli OLRs specified in draft-ietf-dime-ovli , as it creates overlap. The DA is aware that it is a peer of the server; so the DA can handle the received ovli OLRs from the server as peer OLRs if it wants. So I would limit the draft-ietf-dime-agent-overload only to DA overload  and the associated peer overload report to be generated by DA only .

 

Best regards

 

JJacques 



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

--------------000302000902050201030707-- From nobody Thu Jul 23 08:35:37 2015 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 6844B1A0033 for ; Thu, 23 Jul 2015 08:35:36 -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 RYgE6anhKg58 for ; Thu, 23 Jul 2015 08:35:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7251ACD0B for ; Thu, 23 Jul 2015 08:35:30 -0700 (PDT) Received: from dhcp-89c4.meeting.ietf.org ([IPv6:2001:67c:370:136:594f:1083:e2b8:26a0]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6NFZRtN099325 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 23 Jul 2015 10:35:29 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:370:136:594f:1083:e2b8:26a0] claimed to be dhcp-89c4.meeting.ietf.org To: "dime@ietf.org" From: "A. Jean Mahoney" Message-ID: <55B109BF.6080006@nostrum.com> Date: Thu, 23 Jul 2015 17:35:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dime] Summary notes from Dime 93 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, 23 Jul 2015 15:35:36 -0000 Hi all, Below are my summary notes from the meeting yesterday: Jean ------------------------------------------ IETF-93 dime Session 2015-07-22 1300-1530: Karlin III 13:00 - 13:20, Preliminaries (20 minutes) ------------------------------------------ Audio/Video & Remote Presentation Debugging Presentation: https://www.ietf.org/proceedings/93/agenda/agenda-93-dime Presenters: Jouni Korhonen, Lionel Morand Note Takers: Jean Mahoney Jabber relay: Jean Mahoney Jabber log: http://www.ietf.org/jabber/logs/dime/2015-07-22.html Agenda change: Group Signaling added to the end of the meeting. Steve Donovan requested comments on the agent overload and rate control drafts. ACTION: Remind mailing list to review draft-ietf-dime-agent-overload and draft-ietf-dime-doic-rate-control. Working group draft discussion (30 minutes) ------------------------------------------- 13:20 - 13:40 Diameter Load Information Conveyance, (Steve Donovan 20 min) Document: draft-ietf-dime-load-00 Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dime-1.pdf The presentation focused on the server load concept, which requires non-base-protocol routing criteria, but would be useful in real-world deployments. Martin Dolly expressed his support of the server load work. Lionel Morand said that the server load information could be presented in a separate section in the draft, with notes that the routing did not use base protocol criteria, and that, if middle nodes did not support it, it may not work. The draft would provide guidelines on how to use load info, but not normative text on how to do load balancing. Since there no proscriptive behavior tied to the AVPs, there is no need for capability negotiation. Martin advised keeping the AVPs simple. Balint Uveges wondered about load info persistence. A restart of the server would wipe out the server's load. Jean-Jacques expressed a preference for a new grouped AVP, since some networks would only use peer and not server load information, and peers in those networks would not need to look at server load. As for indicating source, Conrad pointed at the History-Info header in SIP, and said that he did not want something as complicated. For the server-load case, Lionel asked if freshness was an issue and if a timestamp would be necessary. ACTION: Put the server load information in a separate section of the draft, note that it is not Diameter base, and, if any node in the middle does not support it, it may not work. Steve and Jean-Jacques to work on the mechanism part of the draft before Yokohama. 13:40 - 13:50 Diameter Overload Indication Conveyance, (Jouni 10 min) Status Update Document: draft-ietf-dime-ovli-08 Presentation: None The draft is in last call. Jouni reported that, although Stephen Farrell originally had concerns because both chairs were authors, the working group could show that process was used and issues resolution was traceable. IANA has allocated code points. Care will need be taken to ensure that changes due to LC comments do not re-open issues on which the working group had achieved rough consensus. ACTION: Steve to address LC comments. Individual draft discussion (15 minutes) ---------------------------------------- 13:50 - 14:05 Diameter Routing Message Priority, (Steve 15 min) Document: draft-donovan-dime-drmp-01 Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dime-0.pdf Martin pointed out that network priority needed to be coordinated with radio priority so that the mechanism doesn't interfere with emergency first responders. He said that ATIS is defining priorities for first responders and government in North America and each carrier will create its own guidelines based on that. Steve realized that maybe DRMP should be application specific so that it could be configurable. Jean-Jacques said that operators configured policies to map an external network's priority to it's own priorities. There was a discussion about whether the highest priority level should be 0 or 4, and how many levels there should be. Steve said he made it consistent with the SIP Resource-Priority header (RPH). Steve requested to turn the draft into working group item. Martin supported and said that 3GPP CT was working on a public safety Push-To-Talk solution. Three other people supported by raising hands. No one objected. Lionel said that the draft would become a work item once confirmed on list. ACTION: Confirm making DRMP a working group item on the mailing list. Group Signaling --------------- Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dime-2.pdf Presenter: Marco Steve volunteered to review the draft. ACTION: Steve to review the group signaling draft. Wrap-up (nn minutes) -------------------- 14:05 - 14:20 Next Steps / AOB: WG Chairs & ADs (nn minutes) There is an effort to standardize TACACS, which is a regex-like mechanism defined by Cisco. The discussion can be followed on opsarea list. Now that the security requirements document is done, a security draft is needed. Lionel said that AD suggested that the draft be written and then submitted for security review. Lionel encouraged the working group to be active. ACTION: Jouni to resurrect the old security document. From nobody Thu Jul 23 08:37:20 2015 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 D0D8A1ACF16 for ; Thu, 23 Jul 2015 08:37:18 -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 RQW26_5vmfZA for ; Thu, 23 Jul 2015 08:37:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C428A1ACEEB for ; Thu, 23 Jul 2015 08:36:54 -0700 (PDT) Received: from dhcp-89c4.meeting.ietf.org ([IPv6:2001:67c:370:136:594f:1083:e2b8:26a0]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6NFapaW099476 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 23 Jul 2015 10:36:53 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:370:136:594f:1083:e2b8:26a0] claimed to be dhcp-89c4.meeting.ietf.org To: "dime@ietf.org" From: "A. Jean Mahoney" Message-ID: <55B10A13.4050608@nostrum.com> Date: Thu, 23 Jul 2015 17:36:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dime] More verbose notes from Dime 93 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, 23 Jul 2015 15:37:19 -0000 Hi all, And here are the more detailed notes from the session. Jean ------------------------------------------------------ IETF-93 dime Session 2015-07-22 1300-1530: Karlin III 13:00 - 13:20, Preliminaries (20 minutes) ------------------------------------------ Audio/Video & Remote Presentation Debugging Presentation: https://www.ietf.org/proceedings/93/agenda/agenda-93-dime Presenters: Jouni Korhonen, Lionel Morand Note Takers: Jean Mahoney Jabber relay: Jean Mahoney Jabber log: http://www.ietf.org/jabber/logs/dime/2015-07-22.html Note well Agenda bash Jouni Korhonen: Group Signaling added to the end of the meeting. Document Status o draft-ietf-dime-agent-overload-01 -> in WG o draft-ietf-dime-doic-rate-control-01 -> in WG o draft-ietf-dime-load-00 -> in WG o draft-ietf-dime-group-signaling-05 -> in WG; recently revised o draft-ietf-dime-e2e-sec-req-03 -> to be submitted to IESG; recently revised o draft-ietf-dime-congestion-flow-attributes-01 -> in AD followup o draft-ietf-dime-4over6-provisioning-03 -> in IETF LC; IANA expert review done o draft-ietf-dime-ovli-08 -> in AD Evaluation; going to IETF LC Steve Donovan: I want to solicit comments on agent overload and rate control. There have been no changes since the last meeting. We need to move the docs forward. ACTION: Remind mailing list to review draft-ietf-dime-agent-overload and draft-ietf-dime-doic-rate-control. Working group draft discussion (30 minutes) ------------------------------------------- 13:20 - 13:40 Diameter Load Information Conveyance, (Steve 20 min) Document: draft-ietf-dime-load-00 Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dime-1.pdf slide 1: Title Steve: The draft is incomplete, provides a first definition. slide 2: draft-ietf-dime-load slide 3: Peer-to-peer mechanism Steve: I believe we have consensus on peer-to-peer. Want to clarify the server load concept before defining the AVP. slide 4: Server Load Martin Dolly: We believe this work needs to be supported due to our network deployment. Steve: Partitioning can be based on users or geography. Sometimes the clients choose the server rather than the agent. I think the base spec is inconsistent on using only Destination-Realm and app-id. We could separate this out if we think we need a bis on the base spec. I don't think that's necessary, and can cover it in a separate section in this doc. Objections? Lionel Morand: It can be indicated in a separate section that Destination-Host could be used in the routing decision. It could be application specific, or context specific. If any node in the middle doesn't support it, it may not work. You can indicate that it is not Diameter base related. Steve: if an application does incorporate the server load concept, we would define the AVPs to do so in this draft. Instead of the Cx, Dx specs, etc. Lionel: A new type of AVP. Steve: for us to decide. Conrad, Deutsche Telekom: You would give hints on how to use the AVP, right? Steve: We'd provide guidelines on how to use the info, but not normative text on how to do load balancing. Conrad: That satisfies me. slide 5: AVP Design Steve: It's a hint, there's not proscriptive behavior tied to it. Thus no capability negotiation. Martin: I don't think we need it here. You're going to use load info to balance traffic in order to avoid overload. There is room for error if you are off. Keep it simpler, and out of sequence. Steve: my thoughts also Lionel: Same Balint Uveges: ... Steve: A restart would wipe out load info. Lionel: needs to be clarified. It assumes that the node sending request that ... any destination or peers, would react to info from the network. Steve: there is no requirement to keep state over restart. slide 6: AVP Design Steve: Agents propagate a server's report and create their own. Or servers could create 2 reports but sometimes there are direct connections between server and client and there's no agent. Jean-Jacques: I prefer a new grouped AVP, some networks only use peer and not server selection. If diameter node looks at server load only, a node that doesn't do server selection doesn't have to look. Conrad: On one side, indicating for server load. How will we mark AVPs from source? Steve: That's the question. The peer AVP will have DiameterID in it. Is one enough? If we pass that through? If there are multiple agents - one from the peer and one from endpoint - we'll need to differentiate. Conrad: We have a History-Info header in SIP, but I don't want it that complicated. It should be an easy mechanism. Steve: This is just giving you additional info to choose the next hop. I agree that it should be straightforward. Lionel: For the second type, server-load case, do we need something else? From a peer it would be from a node that is not a peer. Need something about the freshness of the information received. Steve: A timestamp? Good point. Lionel: could be implementation specific. Need to talk about it. Steve: It might imply that the end point generates the report rather than the agent. slide 7: Security Considerations slide 8: Next Steps Steve: Do we have a decision on server load? Lionel: Be careful about the wording around ... You may use additional routing info that is app-specific. Could be used for routing decision - make it generic. Can't assume that all nodes could use it though. Otherwise a 3GPP decision. Steve: if you have the need to insert Destination-Host in the request, you could use this to influence what to put in Destination-Host. Lionel: This info could be sent to the peer anyways. Steve: Need to flesh out the mechanism parts of the draft. I'll work with JJ on that before Yokohama. Lionel: you need to have review and comments. Need to have people involved. ACTION: Put the server load information in a separate section of the draft, note that it is not Diameter base, and, if any node in the middle does not support it, it may not work. Steve and Jean-Jacques to work on the mechanism part of the draft before Yokohama. 13:40 - 13:50 Diameter Overload Indication Conveyance, (Jouni 10 min) Status Update Document: draft-ietf-dime-ovli-08 Presentation: None Jouni: Draft is in IETF LC. AD had concerns because the co-chairs were both authors. However, we could show that the process was used and issues were traced. No concerns anymore. IANA has allocated code points. There may be some LC comments. Steve: I'll take care of Stephen's LC comments when LC ends. Jouni: We don't need to update based on Ulrich's comments. Lionel: If there is a real concern about text, it can't be done after LC. And it needs to be discussed on list. Jouni: Avoid re-opening items that we had reached rough consensus on. ACTION: Steve to address comments. Individual draft discussion (15 minutes) ---------------------------------------- 13:50 - 14:05 Diameter Routing Message Priority, (Steve 15 min) Document: draft-donovan-dime-drmp-01 Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dime-0.pdf slide 1: Title slide 2: Problem Statement slide 3: DRMP Use Cases Martin: For example, government priority services - first responders HPA (??) Need to coordinate the priority of the phone attach to eNodeB, otherwise this could tear down the work done there. slide 4: DRMP Mechanism slide 5: DRMP Mechanism slide 6: DRMP Mechanism slide 7: Open Questions Martin: Sounds like the Resource-Priority header in SIP based on trust boundary. I as a carrier trust ABC but not XYZ. There's a default value, but local policy sets the values. Steve: The S6a application may set it differently than PCC. Martin: We've talked about this in ATT. There's coexistence of first responses and gov priority, each carrier will create guidelines. ATIS is defining this for North America. It's a national issue. Steve: Make it application specific so that it's configurable. JJ: It's an operator's local policy to configure policies. If you receive priority from an external network, you'll have to map it to your own priorities. The number of priority levels - you have chosen 5 - is this consistent? enough? In 3GPP, 0 is the highest priority. Steve: I've seen it defined in both directions, we just have to choose one. Martin: I recommend mirroring the Resource-Priority header (RPH) where 0 is highest. Look at RPH namespaces and value ranges. Will indicate if 5 is good enough. Steve: I did that, none has more than 5. I thought 0 was lowest. It may not be consistent across name spaces. I trying to make it consistent with RPH. Lionel: The value of the priority can change depending on context. Steve: Yes. slide 8: Next Steps Steve: Request to turn into working group item - we had deferred the decision in Dallas. Martin: I support that. There's a 3GPP CT meeting in August. They're working on Push to talk for public safety. Lionel: Show of hands: who's read? Lionel: Make it a wg item? 3 hands Lionel: No? No hands Lionel: This will become a work item, use this doc, will confirm on mailing list. Martin: within US, the nimstick (?) reqs, they would be interested. They were concerned about radio access priority. They would need this in the network, they hadn't concerned it. ACTION: Confirm making DRMP a working group item on the mailing list. Group Signaling --------------- Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dime-2.pdf Presenter: Marco slide 1: Title slide 2: Summary of the 5th revision slide 3: Summary of the 5th revision slide 4: Next Steps Steve: I'll volunteer to review. Lionel: We can initiate WGLC when it's stable. Need expression of support for the document. Any comments are welcome. Marco: Make a decision and progress it. ACTION: Steve to review the group signaling draft. Wrap-up (nn minutes) -------------------- 14:05 - 14:20 Next Steps / AOB: WG Chairs & ADs (nn minutes) Lionel: Discussion in the opsarea to standardize TACACS, which is a regex-like mechanism defined by Cisco. If you are interested, discussion on opsarea list. Lionel: The security requirements are done, now we need a security draft. Jouni: I'll resurrect the old document. Lionel: I talked with the new AD. He suggested that we write the draft, then get security review, rather than get input up front. Lionel, to the group: please be active in the working group. ACTION: Jouni to resurrect the old security document. From nobody Fri Jul 24 02:05:44 2015 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 1844B1A1A6D for ; Fri, 24 Jul 2015 02:05:43 -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 5pMNlEFppLHg for ; Fri, 24 Jul 2015 02:05:37 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C141A876B for ; Fri, 24 Jul 2015 02:05:36 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-04-55b1ffdea86f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EE.C0.32595.EDFF1B55; Fri, 24 Jul 2015 11:05:34 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.16]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Fri, 24 Jul 2015 11:05:34 +0200 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts) Thread-Index: AdDF71+UBcWVniMNRyao3kUKvudioQ== Date: Fri, 24 Jul 2015 09:05:32 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9218047A22@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9218047A22ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje69/xtDDXp3mljM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujP75kxgL3m9jqri0oaiB8c8Epi5GTg4JAROJpkefWCFsMYkL 99azdTFycQgJHGWUmHFwMhOEs5hRYs2mX2AdbAJ2EpdOvwCyOThEBJQlTv9yADGFBaIk3m73 BKkQEYiX2LZ9GQuErSfx7NhuZhCbRUBVYs7jFrBdvAK+Ete2PgazGYH2fj+1Bmw6s4C4xK0n 86FuE5BYsuc8M4QtKvHy8T+oOxUlPr7axwhRny9x++ZPNoiZghInZz5hmcAoNAvJqFlIymYh KYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2 MQJj4uCW36o7GC+/cTzEKMDBqMTDqzBnY6gQa2JZcWXuIUZpDhYlcd4Zm/NChQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTDWOazq2+E859vCfcw/mZTl6p3W+2Y/vyohbv1NaMeUWcKTSm6K pX3zbZnt84Ej7OTfBQf1D80tceveVulyLqGo3fuxUfKxx5pM++/+jzq+36XmvqnRna7tKxcZ TV4TmM0oPnnF0mfGEjM+iisfqNu15tX+gkyxxi4l0aX/zvHF7ZCzd2R5VrVEiaU4I9FQi7mo OBEA29Rvo2oCAAA= Archived-At: Subject: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts) 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, 24 Jul 2015 09:05:43 -0000 --_000_087A34937E64E74E848732CFF8354B9218047A22ESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I would like to expand a bit on the need for a PEER report by an abatement = algorithm, what I do not think is correct. This is being commented in previous question "[Dime] DA overload comment on= 3.2 Diameter end-point use cases", but I would like to provide some reflec= tions as well on the RATE draft in this respect. Therefore my comments affect both draft-ietf-dime-doic-rate-control and dr= aft-ietf-dime-agent-overload. I will split my comment to make it is easier to reply and act upon: a) RATE draft, PEER usage: In Rate draft, draft-ietf-dime-doic-rate-control-01, it is somehow assume= d that the Report Type to be used is "Peer", in fact, we still have an Open= Issue about whether it is applicable to Host and Realm report. See clause= 3, "Interaction with DOIC report types": 3. Interaction with DOIC report types As of the publication of this specification there are two DOIC report types defined with the specification of a third in progress: 1. Host - Overload of a specific Diameter Application at a specific Diameter Node as defined in [I-D.ietf-dime-ovli]. 2. Realm - Overload of a specific Diameter Application at a specific Diameter Realm as defined in [I-D.ietf-dime-ovli]. 3. Peer - Overload of a specific Diameter peer as defined in [I-D.ietf-dime-agent-overload]. The rate algorithm MAY be selected by reporting nodes for any of these report types. Editor's note: It needs to be validated that use of the rate algorithm applies to the host and realm report types. In my opinion, Rate should work with Host and Realm, and as well with Peer= . But whatever it is required should be described in DOIC (host and Realm),= and Agent Overload (Peer). I understand there is a different thing with Rate comparing with the Defaul= t algorithm: the reporting node needs to keep track of the "target", since = only some Reacting nodes will use Rate. But this does not imply that Host a= nd Realm will not be able to be used. Apart from that, any specifics about = the Peer Report Type usage needs to be covered in Agent Overload draft. b) AGENT draft, requirement on the PEER usage: to be removed It seems that in Agent Overload draft it is implied that Rate requires Peer= Report Type, what I do not think is right. See in draft-ietf-dime-agent-overload-01 , clause 3.2: 3.2. Diameter Endpoint Use Cases This section outlines use cases for the peer report feature involving Diameter Clients and Diameter Servers. 3.2.1. Hop-by-hop Abatement Algorithms It is envisioned that abatement algorithms will be defined that will support the option for Diameter Endpoints to send peer reports. For instance, it is envisioned that one usage scenario for the rate algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked on by the DIME working group as this is written, will involve abatement being done on a hop-by-hop basis. This rate deployment scenario would involve Diameter Endpoints generating peer reports and selecting the rate algorithm for abatement of overload conditions. I think this paragraph should be removed from Agent Overload draft. c) RATE draft, PEER references On the other hand, there are some other references to PEER Report behavior = along draft, that in my opinion should be removed, this should be described= only in Agent Overload draft. See following text: 4. Capability Announcement ... For peer reports the selected algorithm is reflected in the OC- Peer-Algo AVP sent as part of the OC-Supported-Features AVP included answer messages for transaction where the request contained an OC-Supported-Features AVP. This is per the procedures defined in [I-D.ietf-dime-agent-overload]. Editor's Node: The peer report specification is still under development and, as such, the above paragraph is subject to change. 5.3. Reporting Node Maintenance of Overload Control State ... o For Peer reports the target is the DiameterID of the Diameter Peer from which the request was received. 6.2. OC-OLR AVP This extension defines the OC-Maximum-Rate AVP to be an optional part of the OC-OLR AVP. OC-OLR ::=3D < AVP Header: TBD2 > < OC-Sequence-Number > < OC-Report-Type > [ OC-Reduction-Percentage ] [ OC-Validity-Duration ] [ OC-Source-ID ] [ OC-Abatement-Algorithm ] [ OC-Maximum-Rate ] * [ AVP ] This extension makes no changes to the other AVPs that are part of the OC-OLR AVP. This extension does not define new overload report types. The existing report types of host and realm defined in [I-D.ietf-dime-ovli] apply to the rate control algorithm. The peer report type defined in [I-D.ietf-dime-agent-overload] also applies to the rate control algorithm. For the last paragraph, remove at least Agent Overload draft is approved. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 20 de julio de 2015 17:08 To: dime@ietf.org Subject: Re: [Dime] DA overload comment on 3.2 Diameter end-point use cases JJacques, Thanks for the comment. I would assume that the Diameter endpoint (server for this discussion) woul= d send either a peer report or a host report. There would be no reason for= the server to send both. A host report is processed and passed on by agents. A peer report is consumed by agents and, most likely, a new peer report is = generated by the agent. The peer report is envisioned to be used for multiple reasons. The first i= s defined in the agent overload draft to allow agents to communicate overlo= ad state. The second is for overload abatement algorithms that require pee= r-to-peer semantics. The first case of this second usage is the rate overl= oad abatement algorithm. Regards, Steve On 7/20/15 2:46 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: Hi About DA overload (draft-ietf-dime-agent-overload), I have a comment about = section 3.2 (Diameter Endpoint Use Cases) / 3.2.1. I do not well see the re= asons why a server would send "peer overload" reports in addition to the o= vli OLRs specified in draft-ietf-dime-ovli , as it creates overlap. The DA = is aware that it is a peer of the server; so the DA can handle the received= ovli OLRs from the server as peer OLRs if it wants. So I would limit the d= raft-ietf-dime-agent-overload only to DA overload and the associated peer = overload report to be generated by DA only . Best regards JJacques _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_087A34937E64E74E848732CFF8354B9218047A22ESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,<= /span>

 

I would like to expand= a bit on the need for a PEER report by an abatement algorithm, what I do n= ot think is correct.

This is being commente= d in previous question “[Dime] DA overload comment on 3.2 Diameter en= d-point use cases”, but I would like to provide some reflections as w= ell on the RATE draft in this respect.

 

Therefore my comments affect both draft-ietf-dime-doic-rate-co= ntrol and  dr= aft-ietf-dime-agent-overload.

I will split my commen= t to make it is easier to reply and act upon:

 

a) &= nbsp;    RATE dr= aft, PEER usage:

In Rate draft, &n= bsp; draft-ietf-dime-doic-rate-control-01, it is somehow assumed that the Report Type to be used is “Peer”, in fact, we still have an Open Issue about whether it = is applicable to Host and Realm report.  See clause 3, “Interact= ion with DOIC report types”:

 

3.  Interaction with DOIC report types=

 

   As of the publication of this = specification there are two DOIC report

   types defined with the specifi= cation of a third in progress:

 

   1.  Host - Overload of a = specific Diameter Application at a specific

       Diamet= er Node as defined in [I-D.ietf-dime-ovli].

 

   2.  Realm - Overload of a= specific Diameter Application at a specific

       Diamet= er Realm as defined in [I-D.ietf-dime-ovli].

 

   3.  Peer - Ov= erload of a specific Diameter peer as defined in

&n= bsp;      [I-D.ietf-dime-agent-overload].

 

   The rate algorithm MAY be sele= cted by reporting nodes for any of

   these report types.=

 

      Editor's note: It needs to be= validated that use of the rate

&n= bsp;     algorithm applies to the host and realm report= types.

 

In my opinion, Rate sh= ould work with Host and Realm, and as well  with Peer. But whatever it= is required should be described in DOIC (host and Realm), and Agent Overlo= ad (Peer).

I understand there is = a different thing with Rate comparing with the Default algorithm: the repor= ting node needs to keep track of the “target”, since only some = Reacting nodes will use Rate. But this does not imply that Host and Realm will not be able to be used. Apart from that, an= y specifics about the Peer Report Type usage needs to be covered in Agent O= verload draft.

 

b) &= nbsp;    AGENT d= raft, requirement on the PEER usage: to be removed

It seems that in Agent= Overload draft it is implied that Rate requires Peer Report Type, what I d= o not think is right.

See in draft-ietf-dime-a= gent-overload-01 , clause 3.2:

 

3.2.  Diameter Endpoint Use Cases

 

   This section outlines use case= s for the peer report feature involving

   Diameter Clients and Diameter = Servers.

 

3.2.1.  Hop-by-hop Abatement Algorithm= s

 

   It is envisioned that abatemen= t algorithms will be defined that will

   support the option for Diamete= r Endpoints to send peer reports.  For

   instance, it is envisioned tha= t one usage scenario for the rate

   algorithm, [I-D.ietf-dime-doic= -rate-control], which is being worked

   on by the DIME working group a= s this is written, will involve

   abatement being done on a hop-= by-hop basis.

 

   This rate deployment scenario = would involve Diameter Endpoints

   generating peer reports and se= lecting the rate algorithm for

   abatement of overload conditio= ns.

 

I think this paragraph= should be removed from Agent Overload draft.

 

c) &= nbsp;     RATE dr= aft, PEER references

 

On the other hand, there are some other refer= ences to PEER Report behavior along draft, that in my opinion should be rem= oved, this should be described only in Agent Overload draft.

See following text:

 

4.  Capability Announcement=

…

      For peer rep= orts the selected algorithm is reflected in the OC-

      Peer-Algo AV= P sent as part of the OC-Supported-Features AVP

      included ans= wer messages for transaction where the request

      contained an= OC-Supported-Features AVP.  This is per the

      procedures d= efined in [I-D.ietf-dime-agent-overload].

 

      Editor's Nod= e: The peer report specification is still under

      development = and, as such, the above paragraph is subject to

      change.=

 

5.3.  Reporting Node Maintenance of Ov= erload Control State

…

   o  For Peer reports the t= arget is the DiameterID of the Diameter Peer

      from which t= he request was received.

 

 

6.2.  OC-OLR AVP

 

   This extension defines the OC-= Maximum-Rate AVP to be an optional part

   of the OC-OLR AVP.<= /span>

 

      OC-OLR ::=3D= < AVP Header: TBD2 >

       &= nbsp;         < OC-Sequence-Numb= er >

       &= nbsp;         < OC-Report-Type &= gt;

       &= nbsp;         [ OC-Reduction-Percen= tage ]

       &= nbsp;         [ OC-Validity-Duratio= n ]

       &= nbsp;         [ OC-Source-ID ]

&n= bsp;            = ;    [ OC-Abatement-Algorithm ]

       &= nbsp;         [ OC-Maximum-Rat= e ]

       &= nbsp;       * [ AVP ]

 

 

   This extension makes no change= s to the other AVPs that are part of

   the OC-OLR AVP.

 

   This extension does not define= new overload report types.  The

   existing report types of host = and realm defined in

   [I-D.ietf-dime-ovli] apply to = the rate control algorithm.  The peer

&n= bsp;  report type defined in [I-D.ietf-dime-agent-overload] also appli= es to

&n= bsp;  the rate control algorithm.  

 

For the last paragraph, remove at least= Agent Overload draft is approved.

 

Best regards

/MCruz

 

 

 

 

 

 

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 20 de julio de 2015 17:08
To: dime@ietf.org
Subject: Re: [Dime] DA overload comment on 3.2 Diameter end-point us= e cases

 

JJacques,

Thanks for the comment.

I would assume that the Diameter endpoint (server for this discussion) woul= d send either a peer report or a host report.  There would be no reaso= n for the server to send both.

A host report is processed and passed on by agents.

A peer report is consumed by agents and, most likely, a new peer report is = generated by the agent.

The peer report is envisioned to be used for multiple reasons.  The fi= rst is defined in the agent overload draft to allow agents to communicate o= verload state.  The second is for overload abatement algorithms that r= equire peer-to-peer semantics.  The first case of this second usage is the rate overload abatement algorithm.

Regards,

Steve

On 7/20/15 2:46 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQ= UES) wrote:

Hi

 

About DA overload (draft-ietf-dime-agent-overload), = I have a comment about section 3.2 (Diameter Endpoint Use Cases) / 3.2.1. I= do not well see the reasons  why a server would send “peer over= load” reports in addition to the ovli OLRs specified in draft-ietf-dime-ovli , as it creates overlap. The DA is aware that it i= s a peer of the server; so the DA can handle the received ovli OLRs from th= e server as peer OLRs if it wants. So I would limit the draft-ietf-dime-age= nt-overload only to DA overload  and the associated peer overload report to be generated by DA only .=

 

Best regards

 

JJacques 




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

 

--_000_087A34937E64E74E848732CFF8354B9218047A22ESESSMB101erics_-- From nobody Tue Jul 28 11:57:11 2015 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 C60F91B2DCC; Tue, 28 Jul 2015 11:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 3EgJTnfOWCi1; Tue, 28 Jul 2015 11:57:04 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37CD1B2DC7; Tue, 28 Jul 2015 11:57:03 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-85.messagelabs.com!1438109821!15450425!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8099 invoked from network); 28 Jul 2015 18:57:01 -0000 Received: from amer-mta102.csc.com (HELO amer-mta112.csc.com) (20.137.2.88) by server-10.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jul 2015 18:57:01 -0000 Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta112.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id t6SIv0eS011067; Tue, 28 Jul 2015 14:57:00 -0400 In-Reply-To: References: <55B10A13.4050608@nostrum.com> To: "A. Jean Mahoney" , "dime@ietf.org" , "DiME" MIME-Version: 1.0 X-KeepSent: A668EA03:A727DCE9-85257E90:00681010; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Tue, 28 Jul 2015 14:56:59 -0400 X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.3FP5|July 31, 2013) at 07/28/2015 02:57:00 PM, Serialize complete at 07/28/2015 02:57:00 PM Content-Type: multipart/alternative; boundary="=_alternative 0068181985257E90_=" Archived-At: Subject: Re: [Dime] DRMP Re: More verbose notes from Dime 93 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, 28 Jul 2015 18:57:11 -0000 This is a multipart message in MIME format. --=_alternative 0068181985257E90_= Content-Type: text/plain; charset="US-ASCII" This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: Janet P Gunn/USA/CSC To: "A. Jean Mahoney" Cc: "dime@ietf.org" , "DiME" Date: 07/23/2015 04:42 PM Subject: DRMP Re: [Dime] More verbose notes from Dime 93 I had hoped to be able to "remotely attend", but the logistics did not work out. My comments in line "DiME" wrote on 07/23/2015 11:36:51 AM: > From: "A. Jean Mahoney" > To: "dime@ietf.org" > Date: 07/23/2015 11:37 AM > Subject: [Dime] More verbose notes from Dime 93 > Sent by: "DiME" > > Hi all, > > And here are the more detailed notes from the session. > > Jean > > ... > > 13:50 - 14:05 Diameter Routing Message Priority, (Steve 15 min) > Document: draft-donovan-dime-drmp-01 > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dime-0.pdf > > slide 1: Title > > slide 2: Problem Statement > > slide 3: DRMP Use Cases > > Martin: For example, government priority services - first responders HPA > (??) Need to coordinate the priority of the phone attach to eNodeB, > otherwise this could tear down the work done there. > > slide 4: DRMP Mechanism > > slide 5: DRMP Mechanism > > slide 6: DRMP Mechanism > > slide 7: Open Questions > > Martin: Sounds like the Resource-Priority header in SIP based on trust > boundary. I as a carrier trust ABC but not XYZ. There's a default value, > but local policy sets the values. > > Steve: The S6a application may set it differently than PCC. > > Martin: We've talked about this in ATT. There's coexistence of first > responses and gov priority, each carrier will create guidelines. ATIS is > defining this for North America. It's a national issue. Sounds right to me. > > Steve: Make it application specific so that it's configurable. > > JJ: It's an operator's local policy to configure policies. If you > receive priority from an external network, you'll have to map it to your > own priorities. The number of priority levels - you have chosen 5 - is > this consistent? enough? In 3GPP, 0 is the highest priority. > > Steve: I've seen it defined in both directions, we just have to choose one. > > Martin: I recommend mirroring the Resource-Priority header (RPH) where 0 > is highest. Look at RPH namespaces and value ranges. Will indicate if 5 > is good enough. > > Steve: I did that, none has more than 5. I thought 0 was lowest. It may > not be consistent across name spaces. I trying to make it consistent > with RPH. in RFC4412 (RPH) all the namespaces that use numbers for priority have "0' as the HIGHEST priority. I suggest sticking with that convention. > > Lionel: The value of the priority can change depending on context. > > Steve: Yes. > > slide 8: Next Steps > > Steve: Request to turn into working group item - we had deferred the > decision in Dallas. > > Martin: I support that. There's a 3GPP CT meeting in August. They're > working on Push to talk for public safety. > > Lionel: Show of hands: who's read? > > Lionel: Make it a wg item? > > 3 hands I have read it and I support making it a WG item. I will comment on the list. > Lionel: No? > > No hands > > Lionel: This will become a work item, use this doc, will confirm on > mailing list. > > Martin: within US, the nimstick (?) reqs, they would be interested. They > were concerned about radio access priority. They would need this in the > network, they hadn't concerned it. > > ACTION: Confirm making DRMP a working group item on the mailing list. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=_alternative 0068181985257E90_= Content-Type: text/html; charset="US-ASCII"

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:        Janet P Gunn/USA/CSC
To:        "A. Jean Mahoney" <mahoney@nostrum.com>
Cc:        "dime@ietf.org" <dime@ietf.org>, "DiME" <dime-bounces@ietf.org>
Date:        07/23/2015 04:42 PM
Subject:        DRMP Re: [Dime] More verbose notes from Dime 93


I had hoped to be able  to "remotely attend", but the logistics did not work out.

My comments in line
"DiME" <dime-bounces@ietf.org> wrote on 07/23/2015 11:36:51 AM:

> From: "A. Jean Mahoney" <mahoney@nostrum.com>
> To: "dime@ietf.org" <dime@ietf.org>
> Date: 07/23/2015 11:37 AM
> Subject: [Dime] More verbose notes from Dime 93
> Sent by: "DiME" <dime-bounces@ietf.org>
>
> Hi all,
>
> And here are the more detailed notes from the session.
>
> Jean
>
>
...


>
> 13:50 - 14:05 Diameter Routing Message Priority, (Steve 15 min)
> Document: draft-donovan-dime-drmp-01
> Presentation:
> https://www.ietf.org/proceedings/93/slides/slides-93-dime-0.pdf
>
> slide 1: Title
>
> slide 2: Problem Statement
>
> slide 3: DRMP Use Cases
>
> Martin: For example, government priority services - first responders HPA
> (??) Need to coordinate the priority of the phone attach to eNodeB,
> otherwise this could tear down the work done there.
>
> slide 4: DRMP Mechanism
>
> slide 5: DRMP Mechanism
>
> slide 6: DRMP Mechanism
>
> slide 7: Open Questions
>
> Martin: Sounds like the Resource-Priority header in SIP based on trust
> boundary. I as a carrier trust ABC but not XYZ. There's a default value,
> but local policy sets the values.
>
> Steve: The S6a application may set it differently than PCC.
>
> Martin: We've talked about this in ATT. There's coexistence of first
> responses and gov priority, each carrier will create guidelines. ATIS is
> defining this for North America. It's a national issue.
<JPG> Sounds right to me.

>
> Steve: Make it application specific so that it's configurable.
>
> JJ: It's an operator's local policy to configure policies. If you
> receive priority from an external network, you'll have to map it to your
> own priorities. The number of priority levels - you have chosen 5 - is
> this consistent? enough? In 3GPP, 0 is the highest priority.
>
> Steve: I've seen it defined in both directions, we just have to choose one.
>
> Martin: I recommend mirroring the Resource-Priority header (RPH) where 0
> is highest. Look at RPH namespaces and value ranges. Will indicate if 5
> is good enough.
>
> Steve: I did that, none has more than 5. I thought 0 was lowest. It may
> not be consistent across name spaces. I trying to make it consistent
> with RPH.
<JPG> in RFC4412 (RPH) all the namespaces that use numbers for priority have "0' as the HIGHEST priority.  I suggest sticking with that convention.
>
> Lionel: The value of the priority can change depending on context.
>
> Steve: Yes.
>
> slide 8: Next Steps
>
> Steve: Request to turn into working group item - we had deferred the
> decision in Dallas.
>
> Martin: I support that. There's a 3GPP CT meeting in August. They're
> working on Push to talk for public safety.
>
> Lionel: Show of hands: who's read?
>
> Lionel: Make it a wg item?
>
> 3 hands

<JPG> I have read it and I support making it a WG item.  I will comment on the list.

> Lionel: No?
>
> No hands
>
> Lionel: This will become a work item, use this doc, will confirm on
> mailing list.
>
> Martin: within US, the nimstick (?) reqs, they would be interested. They
> were concerned about radio access priority. They would need this in the
> network, they hadn't concerned it.
>
> ACTION: Confirm making DRMP a working group item on the mailing list.
>
>

> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
--=_alternative 0068181985257E90_=--