From nobody Tue Aug 4 04:47:59 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 69EBD1B37CC for ; Tue, 4 Aug 2015 04:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gCEVfPrb8pQ for ; Tue, 4 Aug 2015 04:47:56 -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 85AF41B37BD for ; Tue, 4 Aug 2015 04:47:56 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:61690 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZMahG-0004MQ-A7 for dime@ietf.org; Tue, 04 Aug 2015 04:47:56 -0700 Message-ID: <55C0A669.20403@usdonovans.com> Date: Tue, 04 Aug 2015 06:47:53 -0500 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: <5599ADCA.9080208@cs.tcd.ie> In-Reply-To: <5599ADCA.9080208@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] 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: Tue, 04 Aug 2015 11:47:58 -0000 Stephen, Please find my responses inline. Regards, Steve On 7/5/15 5:20 PM, Stephen Farrell wrote: > 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. SRD> Agreed. Propose removing the "DOIC" from the throttling definition. > > - 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.) SRD> This was one of the early decisions made. We can add wording along the lines of "This eases the integration of the DOIC mechanism into existing applications as all that is required is defining new AVPs." I am, however, hesitant to add a lot of rational for decisions made in the design phase. As you point out, it is already 55 pages. :-) > > - 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. SRD> Yes, the reporting node selects from the abatement algorithms advertised by the reacting node. I don't see the inter/intra domain issue. The reacting node indicates what it supports, the reporting nodes selects one of the algorithms. If the reacting node doesn't want to support an algorithm then it won't advertise support in the first place. SRD> There are other inter domain issues that are discussed in Appendix B (Topology Hiding Interactions) that are considered outside of the scope of the DOIC specification. > > - 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? SRD> The logic of an agent in this case is considered to be an implementation decision. When an agent handles this scenario, it is, in essence, acting as a back-to-back agent. It is a reporting node on one side and a reacting node on the other. Maybe it would help to add wording to the effect that the agent must be a fully compliant reporting node and reacting node. That was the intent of the statement "Care must be taken not to introduce interoperability issues for downstream or upstream DOIC nodes." SRD> I'm happy to beef this up if it is considered necessary. > > - 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? SRD> Yes, this is an issue. It is addressed in the first paragraph of the security considerations section. Do we need to discuss it in the intro section as well? > > - 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. SRD> This is because all of the Diameter nodes in the picture can take on both reacting and reporting node functionality depending on the context of an individual transaction. Would it suffice to put wording to this effect in the paragraph after Figure 1? > > - 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? SRD> I agree, the wording is misleading. I propose to change it to "A reporting node MUST select a single abatement algorithm in the OC-Feature-Vector AVP. > > - 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. SRD> Agreed. How about the following: "If the reacting node determines that the sequence number has rolled over then the reacting node MUST update the matching OCS entry. This can be determined by recognizing that the number has changed from something close to the maximum value in the OC-Sequence-Number AVP to something close to the minimum value in the OC-Sequence-Number AVP. > > - 5.3: "[RFC6733] defined Grouped AVP extension mechanisms > apply. " is unclear, to me anyway. What's it mean? SRD> This is a reference back to the base Diameter specification saying that extensibility mechanisms defined there also apply to the DOIC group AVPs. This means that it is always possible to add new sub AVPs and that a node receiving a sub AVP that it does not understand should just ignore the sub AVP. > > - 6.1, step 4: I think that has to be a uniformly selected > random number. SRD> Agreed. > > - 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? SRD> There is one way to get into 100% reduction - with an OLR indicating such. A reacting node comes out of this when the OLR expires. I'm not sure there is ambiguity here but we can modify the first sentence as follows if we think it is necessary: "If reacting node comes out of the 100 percent traffic reduction, meaning it has received an OLR indicating that no traffic should be sent, as a result of the overload report timing out..." > > - 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. SRD> The receiving node should use the default value in this case. I thought we had that there already. I propose adding the following: "If the value received in the OC-Validity-Duration is greater than the maximum value then the default value applies." > > - 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. SRD> Would it suffice to add the following: "This may require out-of-band, non Diameter agreements and/or mechanisms." > > - 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. SRD> We could add: "In the worst case, where the Diameter application is being used for access control into an IP network, a coordinated DOS attack could result in the blockage of all traffic into that network." > > - 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. SRD> I vote that we strike all of Appendix C. This was mostly a checkpoint to see how well the DOIC spec met requirements. I'm not sure it adds value a part of an RFC. > > - 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. SRD> See my previous comment. > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Aug 4 06:10:52 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 671A31A9032 for ; Tue, 4 Aug 2015 06:10:50 -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 NGObZqGfrajV for ; Tue, 4 Aug 2015 06:10:47 -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 3079D1A89D3 for ; Tue, 4 Aug 2015 06:10:47 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:61865 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZMbzP-0004Ye-4D for dime@ietf.org; Tue, 04 Aug 2015 06:10:47 -0700 Message-ID: <55C0B9D2.4080208@usdonovans.com> Date: Tue, 04 Aug 2015 08:10:42 -0500 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: <087A34937E64E74E848732CFF8354B9218047A22@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9218047A22@ESESSMB101.ericsson.se> Content-Type: multipart/alternative; boundary="------------000304000601030807030803" 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] 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: Tue, 04 Aug 2015 13:10:50 -0000 This is a multi-part message in MIME format. --------------000304000601030807030803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Maria Cruz, Thank you for the reviews. See my comments inline. Regards, Steve On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote: > > 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 reflections as well on the RATE draft in this respect. > > Therefore my comments affect both draft-ietf-dime-doic-rate-controland > draft-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 > 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, “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 > Default 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 and 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. > SRD> I agree that the current writing of the draft is focused on the use of the rate algorithm in a peer report. I intentionally put the editor's note in the document to make sure that we have the discussion on whether or not there is reason to also allow use of the rate algorithm in host and realm reports. SRD> It is, however, not clear to me how rate would be an effective overload control mechanism in host reports, at least not in the general sense. Any time that a Diameter application allows for realm routed requests to be sent by a client it becomes impossible for a client to know the rate of requests that will arrive at a specific server. I'd like to see some thought put into how this would work before indicating support for it in the rate draft. SRD> I agree there may be times that a reporting nodes sends both rate and loss reports. I would expect this to be in transition periods as an operator turns on rate control. It seems, however, more likely that an operator would turn on rate between a reporting node and the first hop agents first and, if needed, have the agent translate rate OLRs into loss OLRs for reacting nodes that do not support rate. > > *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. > SRD> I don't see why. This is an explanation of how peer might be used, not a prescription that it must happen. > > *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]. > SRD> This is explicitly referring back to the agent overload draft, where, I agree, the behavior is to be defined. > > 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 ::= < 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. > SRD> I don't understand what is being proposed but the rate algorithm has a dependency on the agent overload draft because at least one of the report types it needs to support is peer, and peer is defined in the agent overload draft. > > 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) > 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 > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------000304000601030807030803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Maria Cruz,

Thank you for the reviews.  See my comments inline.

Regards,

Steve

On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote:

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 reflections as well on the RATE draft in this respect.

 

Therefore my comments affect both draft-ietf-dime-doic-rate-control and  draft-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 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, “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 Default 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 and 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.

SRD> I agree that the current writing of the draft is focused on the use of the rate algorithm in a peer report.  I intentionally put the editor's note in the document to make sure that we have the discussion on whether or not there is reason to also allow use of the rate algorithm in host and realm reports.

SRD> It is, however, not clear to me how rate would be an effective overload control mechanism in host reports, at least not in the general sense.  Any time that a Diameter application allows for realm routed requests to be sent by a client it becomes impossible for a client to know the rate of requests that will arrive at a specific server.  I'd like to see some thought put into how this would work before indicating support for it in the rate draft.

SRD> I agree there may be times that a reporting nodes sends both rate and loss reports.  I would expect this to be in transition periods as an operator turns on rate control.  It seems, however, more likely that an operator would turn on rate between a reporting node and the first hop agents first and, if needed, have the agent translate rate OLRs into loss OLRs for reacting nodes that do not support rate.

 

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.

SRD> I don't see why.  This is an explanation of how peer might be used, not a prescription that it must happen.

 

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].

SRD> This is explicitly referring back to the agent overload draft, where, I agree, the behavior is to be defined.

 

      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 ::= < 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.

SRD> I don't understand what is being proposed but the rate algorithm has a dependency on the agent overload draft because at least one of the report types it needs to support is peer, and peer is defined in the agent overload draft.

 

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) 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

 



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

--------------000304000601030807030803-- From nobody Tue Aug 4 08:24: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 E6ECD1A1B34; Tue, 4 Aug 2015 08:24:51 -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 VnASzfOWZd90; Tue, 4 Aug 2015 08:24:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F33F1A1B72; Tue, 4 Aug 2015 08:23:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150804152348.1378.21580.idtracker@ietfa.amsl.com> Date: Tue, 04 Aug 2015 08:23:48 -0700 Archived-At: Cc: draft-ietf-dime-4over6-provisioning@ietf.org, dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-4over6-provisioning.shepherd@ietf.org, draft-ietf-dime-4over6-provisioning.ad@ietf.org Subject: [Dime] Spencer Dawkins' No Objection on draft-ietf-dime-4over6-provisioning-04: (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: Tue, 04 Aug 2015 15:24:52 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dime-4over6-provisioning-04: 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-4over6-provisioning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A nit - this text [RFC6519] sets a precedent for representation of the IPv6 address of a border router as an FQDN. This can be dereferenced to one or more IP addresses by the provisioning system before being passed to the customer equipment, or left as an FQDN as it as in [RFC6334]. ^^^^^^^^^^^ seems garbled. In this text 3.4.1. Delegated-IPv6-Prefix As the IPv6 Binding Prefix The Delegated-IPv6-Prefix AVP (AVP code 123) is of type Octetstring, and is defined in [RFC4818]. Within the Tunnel-Source-Pref-Or-Addr AVP, it conveys the IPv6 Binding Prefix assigned to the CE. Valid values in the Prefix-Length field are from 0 to 128 (full address), although a more restricted range is obviously more reasonable. ^^^^^^^^^^^^^^^^^^^^^^^^^ I wonder if "obviously more reasonable" is the right thing to say. Is this saying something like "more scalable" (compared to bunches of 128-bit IP binding prefixes)? Or am I misunderstanding the point? From nobody Tue Aug 4 08:30:27 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 AF8001A1B3D; Tue, 4 Aug 2015 08:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GypE76nShllw; Tue, 4 Aug 2015 08:30:11 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 818EC1A1B20; Tue, 4 Aug 2015 08:27:43 -0700 (PDT) Received: by vkgc186 with SMTP id c186so4925614vkg.0; Tue, 04 Aug 2015 08:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dlH1uztTWRj5yw6Hilo6fPoPO4vnO1m7Vfg4YdbEkbU=; b=tOWuqmo0iJzLpFBk5wGg1O/RLMJBUQDZZ25h8EEOgeI0BSQQ67ZAHpO1kUyXVouzDz kXfR3l/p66VVd7pkxA/nCYyFGNE16DKBsLjEAELZFMRN+t90IHLcwbamDLkb40PxKjoh wC4YCT/rty5dCP5rUHaBw6oH2YKiHkraTas3j7EDEU5LSkfHx/uOFjeSCKs6Fc01hmqG kAaE/S2x2d6wACYjKMGT3PFYMVda44+LH20/mOsa0/FVaOS5tiXQxJBk2uvrYTpSt9L0 hgVCLazUkefLzTMNymqm6YNNH+dl5cJksepO2CFZfkbcH9wUpBlL0JfZxDW1s0qwuKr6 g1ig== MIME-Version: 1.0 X-Received: by 10.52.165.201 with SMTP id za9mr5380113vdb.86.1438702062702; Tue, 04 Aug 2015 08:27:42 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Tue, 4 Aug 2015 08:27:42 -0700 (PDT) In-Reply-To: <20150804152348.1378.21580.idtracker@ietfa.amsl.com> References: <20150804152348.1378.21580.idtracker@ietfa.amsl.com> Date: Tue, 4 Aug 2015 10:27:42 -0500 Message-ID: From: Spencer Dawkins at IETF To: The IESG Content-Type: multipart/alternative; boundary=001a11c20f1a62a711051c7ded93 Archived-At: Cc: draft-ietf-dime-4over6-provisioning@ietf.org, dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-4over6-provisioning.ad@ietf.org, draft-ietf-dime-4over6-provisioning.shepherd@ietf.org Subject: Re: [Dime] Spencer Dawkins' No Objection on draft-ietf-dime-4over6-provisioning-04: (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: Tue, 04 Aug 2015 15:30:19 -0000 --001a11c20f1a62a711051c7ded93 Content-Type: text/plain; charset=UTF-8 Just curious. Does anyone have an updated address for Sun Qiong? I'm getting (expanded from ): host mail.ctbri.com.cn[219.142.69.47] said: 554 5.7.1 Error: invalid sender by SPF from 4.31.198.44 (in reply to RCPT TO command) Final-Recipient: rfc822; sunqiong@ctbri.com.cn Original-Recipient: rfc822; expand-draft-ietf-dime-4over6-provisioning@virtual.ietf.org Action: failed Status: 5.7.1 Remote-MTA: dns; mail.ctbri.com.cn Diagnostic-Code: smtp; 554 5.7.1 Error: invalid sender by SPF from 4.31.198.44 Thanks! Spencer On Tue, Aug 4, 2015 at 10:23 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-dime-4over6-provisioning-04: 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-4over6-provisioning/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A nit - this text > > [RFC6519] sets a precedent for representation of the IPv6 address of > a border router as an FQDN. This can be dereferenced to one or more > IP addresses by the provisioning system before being passed to the > customer equipment, or left as an FQDN as it as in [RFC6334]. > ^^^^^^^^^^^ > > seems garbled. > > In this text > > 3.4.1. Delegated-IPv6-Prefix As the IPv6 Binding Prefix > > The Delegated-IPv6-Prefix AVP (AVP code 123) is of type Octetstring, > and is defined in [RFC4818]. Within the Tunnel-Source-Pref-Or-Addr > AVP, it conveys the IPv6 Binding Prefix assigned to the CE. Valid > values in the Prefix-Length field are from 0 to 128 (full address), > although a more restricted range is obviously more reasonable. > ^^^^^^^^^^^^^^^^^^^^^^^^^ > I wonder if "obviously more reasonable" is the right thing to say. Is > this saying something like "more scalable" (compared to bunches of > 128-bit IP binding prefixes)? Or am I misunderstanding the point? > > > --001a11c20f1a62a711051c7ded93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just curious. Does anyone have an updated address for Sun = Qiong?

I'm getting

<sunqiong@ctbri.com.cn> (expanded from
=C2=A0 =C2=A0 <expand-draft-ietf-dime-4over6-provisionin= g@virtual.ietf.org>): h= ost
=C2=A0 =C2=A0=C2=A0mail.ctbri.com.cn[219.142.69.47] sai= d: 554 5.7.1 Error: invalid sender by
=C2=A0 =C2=A0 SPF = from 4.31.198.44 (in reply to RCPT TO command)

Final-Recipient: rfc822;=C2=A0sunqiong@ctbri.com.cn
Original-Recipient: rfc822;=C2=A0expand-draft-ietf-dime-4over= 6-provisioning@virtual.ietf.org
Action: failed
Status: 5.7.1
Remote-MTA: dns;=C2=A0mail.ctbri.com.cn
Diagnos= tic-Code: smtp; 554 5.7.1 Error: invalid sender by SPF from 4.31.198.44
Thanks!
=
Spencer

On Tue, Aug 4, 2015 at 10:23 AM, Spencer D= awkins <spencerdawkins.ietf@gmail.com> wrote:
Spencer Dawkins has entered the following b= allot position for
draft-ietf-dime-4over6-provisioning-04: 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/s= tatement/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/do= c/draft-ietf-dime-4over6-provisioning/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A nit - this text

=C2=A0 =C2=A0[RFC6519] sets a precedent for representation of the IPv6 addr= ess of
=C2=A0 =C2=A0a border router as an FQDN.=C2=A0 This can be dereferenced to = one or more
=C2=A0 =C2=A0IP addresses by the provisioning system before being passed to= the
=C2=A0 =C2=A0customer equipment, or left as an FQDN as it as in [RFC6334].<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^= ^^^^^^^^^^

seems garbled.

In this text

3.4.1.=C2=A0 Delegated-IPv6-Prefix As the IPv6 Binding Prefix

=C2=A0 =C2=A0The Delegated-IPv6-Prefix AVP (AVP code 123) is of type Octets= tring,
=C2=A0 =C2=A0and is defined in [RFC4818].=C2=A0 Within the Tunnel-Source-Pr= ef-Or-Addr
=C2=A0 =C2=A0AVP, it conveys the IPv6 Binding Prefix assigned to the CE.=C2= =A0 Valid
=C2=A0 =C2=A0values in the Prefix-Length field are from 0 to 128 (full addr= ess),
=C2=A0 =C2=A0although a more restricted range is obviously more reasonable.=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^= ^^^^^^^^^^^^^^^^
I wonder if "obviously more reasonable" is the right thing to say= . Is
this saying something like "more scalable" (compared to bunches o= f
128-bit IP binding prefixes)? Or am I misunderstanding the point?



--001a11c20f1a62a711051c7ded93-- From nobody Wed Aug 5 02:11:13 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 CC7281B2E04 for ; Wed, 5 Aug 2015 02:11:11 -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 B7OD6u4FMHfd for ; Wed, 5 Aug 2015 02:11:00 -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 DDD341B2DFF for ; Wed, 5 Aug 2015 02:10:58 -0700 (PDT) X-AuditID: c1b4fb25-f79446d000003bb1-76-55c1d32083e9 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DD.57.15281.023D1C55; Wed, 5 Aug 2015 11:10:56 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.16]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Wed, 5 Aug 2015 11:10:55 +0200 From: Maria Cruz Bartolome To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts) Thread-Index: AdDF71+UBcWVniMNRyao3kUKvudioQIttQMAAC3IJfA= Date: Wed, 5 Aug 2015 09:10:55 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921804A3FE@ESESSMB101.ericsson.se> References: <087A34937E64E74E848732CFF8354B9218047A22@ESESSMB101.ericsson.se> <55C0B9D2.4080208@usdonovans.com> In-Reply-To: <55C0B9D2.4080208@usdonovans.com> 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_087A34937E64E74E848732CFF8354B921804A3FEESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja7C5YOhBg33DS3m9q5gs9jQxOPA 5LFkyU8mj1Vv+1gDmKK4bFJSczLLUov07RK4Ml6t9ytY0ctc0Tl3E2sD44rbTF2MnBwSAiYS S04eZYGwxSQu3FvP1sXIxSEkcJRRYuHlBWwgCSGBRYwSC1YXgdhsAnYSl06/AGsWEfCVON55 GqxZWCBOYv+yN8wQ8XiJbduXsUDYVhJHLxwAq2cRUJHY+fEmO4jNC9R79dc5Foj5hRI/FvwB 28UpoCex7NYMsDgj0EHfT60B62UWEJe49WQ+1NECEkv2nGeGsEUlXj7+xwphK0k0LnnCClGf LzFtC8RtvAKCEidnPmGZwCgyC8moWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM 7KsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAuPq4JbfqjsYL79xPMQowMGoxMOrkHcwVIg1 say4MvcQozQHi5I474zNeaFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGCUNFkwVE9u+kl/1 5fvfmdodpq3/HCIl9jqKJtW9suiLe3N/upfLLqFKr5ZDb5aHr3kqcfSqVVnF8t3rJolOmdWZ Xip319lv4/vXEgUfg3KyVhq9dX9rqFNdPV3synsF5YZMsbc/e4UOuxnNK8hIm2VSceBsk6Ih +yMLWcG8/7rqCX5R4UfNlViKMxINtZiLihMBBcil/YwCAAA= Archived-At: Subject: Re: [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: Wed, 05 Aug 2015 09:11:12 -0000 --_000_087A34937E64E74E848732CFF8354B921804A3FEESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Steve, Thanks for your response. See my comments below Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: martes, 04 de agosto de 2015 15:11 To: dime@ietf.org Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate = Algorithm drafts) Maria Cruz, Thank you for the reviews. See my comments inline. Regards, Steve On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote: 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. SRD> I agree that the current writing of the draft is focused on the use of= the rate algorithm in a peer report. I intentionally put the editor's not= e in the document to make sure that we have the discussion on whether or no= t there is reason to also allow use of the rate algorithm in host and realm= reports. SRD> It is, however, not clear to me how rate would be an effective overloa= d control mechanism in host reports, at least not in the general sense. An= y time that a Diameter application allows for realm routed requests to be s= ent by a client it becomes impossible for a client to know the rate of requ= ests that will arrive at a specific server. I'd like to see some thought p= ut into how this would work before indicating support for it in the rate dr= aft. MCRUZ> I do not understand your concern. A rate of message will be ensure i= n the reacting node either for a particular host or for a realm. Could you = clarify please? SRD> I agree there may be times that a reporting nodes sends both rate and = loss reports. I would expect this to be in transition periods as an operat= or turns on rate control. It seems, however, more likely that an operator = would turn on rate between a reporting node and the first hop agents first = and, if needed, have the agent translate rate OLRs into loss OLRs for react= ing nodes that do not support rate. MCRUZ> Not sure how this is related to the discussion here 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. SRD> I don't see why. This is an explanation of how peer might be used, no= t a prescription that it must happen. MCRUZ> "this section outlines use cases for the peer report feature involvi= ng Clients and Servers". Why is this needed? I think the Agent draft should= cover only Agent overload use cases, nothing else. 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]. SRD> This is explicitly referring back to the agent overload draft, where, = I agree, the behavior is to be defined. MCRUZ> then do you agree about removal? 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. SRD> I don't understand what is being proposed but the rate algorithm has a= dependency on the agent overload draft because at least one of the report = types it needs to support is peer, and peer is defined in the agent overloa= d draft. MCRUZ> my point is that what belongs to Agent overload's draft shall be onl= y in Agent overload's draft. I highlighted paragraphs above that belongs to= Agent overload's draft. 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_087A34937E64E74E848732CFF8354B921804A3FEESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Steve,

Thanks for your respon= se.

See my comments below<= o:p>

Best regards

/MCruz

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 04 de agosto de 2015 15:11
To: dime@ietf.org
Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload = + Rate Algorithm drafts)

 

Maria Cruz,

Thank you for the reviews.  See my comments inline.

Regards,

Steve

On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote:=

Hello all,=

 

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-control and  draft-ietf-dime-agent-overload.

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

 

a)      RATE draft, PEER u= sage:

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 whe= ther it is applicable to Host and Realm report.  See clause 3, “= Interaction with DOIC report types”:

 

3.  Interaction with= DOIC report types

 <= /p>

   As of the pu= blication of this specification there are two DOIC report=

   types define= d with the specification of a third in progress:

 <= /p>

   1.  Hos= t - Overload of a specific Diameter Application at a specific

    &= nbsp;  Diameter Node as defined in [I-D.ietf-dime-ovli].

 <= /p>

   2.  Rea= lm - Overload of a specific Diameter Application at a specific<= /o:p>

     =   Diameter Realm as defined in [I-D.ietf-dime-ovli].<= /o:p>

 <= /p>

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

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

 <= /p>

   The rate alg= orithm MAY be selected by reporting nodes for any of

   these report= types.

 <= /p>

     =  Editor's not= e: 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.

SRD> I agree that the current wri= ting of the draft is focused on the use of the rate algorithm in a peer rep= ort.  I intentionally put the editor's note in the document to make sure that we have the discussion on whether or not there is reason= to also allow use of the rate algorithm in host and realm reports.

SRD> It is, however, not clear to me how rate would be an effective over= load control mechanism in host reports, at least not in the general sense.&= nbsp; Any time that a Diameter application allows for realm routed requests= to be sent by a client it becomes impossible for a client to know the rate of requests that will arrive at a specific s= erver.  I'd like to see some thought put into how this would work befo= re indicating support for it in the rate draft.
MCRUZ> I do not understand your con= cern. A rate of message will be ensure in the reacting node either for a pa= rticular host or for a realm. Could you clarify please?


SRD> I agree there may be times that a reporting nodes sends both rate a= nd loss reports.  I would expect this to be in transition periods as a= n operator turns on rate control.  It seems, however, more likely that= an operator would turn on rate between a reporting node and the first hop agents first and, if needed, have the agent transla= te rate OLRs into loss OLRs for reacting nodes that do not support rate. MCRUZ> Not sure how this is related= to the discussion here

 

 

b)      AGENT draft, requi= rement 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-agent-overload-01 , c= lause 3.2:

 

3.2.  Diameter Endpo= int Use Cases

 <= /p>

   This section= outlines use cases for the peer report feature involving=

   Diameter Cli= ents and Diameter Servers.

 <= /p>

3.2.1.  Hop-by-hop A= batement Algorithms

 <= /p>

   It is envisi= oned that abatement algorithms will be defined that will<= /p>

   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 DI= ME working group as this is written, will involve

   abatement be= ing done on a hop-by-hop basis.

 <= /p>

   This rate de= ployment scenario would involve Diameter Endpoints

   generating p= eer reports and selecting the rate algorithm for

   abatement of= overload conditions.

 

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

SRD> I don't see why.  This = is an explanation of how peer might be used, not a prescription that it mus= t happen.
MCRUZ> “this section outlines= use cases for the peer report feature involving Clients and Servers”= . Why is this needed? I think the Agent draft should cover only Agent overload use cases, nothing else.=

 

c)       RATE draft, PEER r= eferences

 

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 Annou= ncement

…

    &= nbsp; For peer reports the selected algorithm is reflected in the OC-

    &= nbsp; Peer-Algo AVP sent as part of the OC-Supported-Features AVP

    &= nbsp; included answer messages for transaction where the request

    &= nbsp; contained an OC-Supported-Features AVP.  This is per the<= o:p>

    &= nbsp; procedures defined in [I-D.ietf-dime-agent-overload].

SRD> This is explicitly referring= back to the agent overload draft, where, I agree, the behavior is to be de= fined.
MCRUZ> then do you agree about remo= val?

 <= /p>

    &= nbsp; Editor's Node: The peer report specification is still under

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

    &= nbsp; change.

 

5.3.  Reporting Node= Maintenance of Overload Control State

…

   o  For = Peer reports the target is the DiameterID of the Diameter Peer<= /o:p>

    &= nbsp; from which the request was received.

 

 

6.2.  OC-OLR AVP

 <= /p>

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

   of the OC-OL= R AVP.

 <= /p>

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

    &= nbsp;            <= ; OC-Sequence-Number >

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

    &= nbsp;            [ O= C-Reduction-Percentage ]

    &= nbsp;            [ O= C-Validity-Duration ]

    &= nbsp;            [ OC-Source-ID ]

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

    &= nbsp;           &nbs= p;[ OC-Maximum-Rate ]

    &= nbsp;          * [ AVP ]

 <= /p>

 <= /p>

   This extensi= on makes no changes to the other AVPs that are part of

   the OC-OLR A= VP.

 <= /p>

   This extensi= on does not define new overload report types.  The

   existing rep= ort types of host and realm defined in

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

   report = type defined in [I-D.ietf-dime-agent-overload] also applies to

   the rat= e control algorithm.  

 <= /p>

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

SRD> I don't understand what is b= eing proposed but the rate algorithm has a dependency on the agent overload= draft because at least one of the report types it needs to support is peer, and peer is defined in the agent overload draft.
MCRUZ> my point is that what belong= s to Agent overload’s draft shall be only in Agent overload’s d= raft. I highlighted paragraphs above that belongs to Agent overload’s draft.

 

Best regards

/MCruz

 <= /p>

 

 

 

 

 

 

 

From: DiME [ma= ilto: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

 




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

 

--_000_087A34937E64E74E848732CFF8354B921804A3FEESESSMB101erics_-- From nobody Wed Aug 5 09:40: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 5E67B1A21BA for ; Wed, 5 Aug 2015 09:40:15 -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 0DGpEtX7bqbZ for ; Wed, 5 Aug 2015 09:40:10 -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 7C3B81A3B9C for ; Wed, 5 Aug 2015 09:40:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B0687BE88; Wed, 5 Aug 2015 17:40:04 +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 vS8Tvk9ISOyD; Wed, 5 Aug 2015 17:40:04 +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 78686BE7C; Wed, 5 Aug 2015 17:40:04 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438792804; bh=EKaQs7+2ifQYzXqJSe0GW+o4o1qf2SU2nDM2zjU9t7U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Q0XdotNdscvKrV44xARq18FBi0x760HUZibHXNN9ZdljSlwXG+2DpGeAlwnpIA+sQ WqfhzULOr4lx0G9+D4xGEAwZakmfNFomh5PuBydXJSB+bi9QBnuPxfNavsBivQ1L4R Nr++q7LBLa/hOu6fCspFbipOiJBCip60EFvKYutU= Message-ID: <55C23C64.5060503@cs.tcd.ie> Date: Wed, 05 Aug 2015 17:40:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Steve Donovan , dime@ietf.org References: <5599ADCA.9080208@cs.tcd.ie> <55C0A669.20403@usdonovans.com> In-Reply-To: <55C0A669.20403@usdonovans.com> 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-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: Wed, 05 Aug 2015 16:40:15 -0000 Hiya, A few notes below. Where I don't respond, your suggestions are just fine. I guess I'll mark this one as revised-I-D needed to handle this and the gen-art review stuff and then when we get that I can put it on an IESG telechat agenda. Thanks, S. On 04/08/15 12:47, Steve Donovan wrote: > Stephen, > > Please find my responses inline. > > Regards, > > Steve > > On 7/5/15 5:20 PM, Stephen Farrell wrote: >> 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. > SRD> Agreed. Propose removing the "DOIC" from the throttling definition. >> >> - 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.) > SRD> This was one of the early decisions made. We can add wording along > the lines of "This eases the integration of the DOIC mechanism into > existing applications as all that is required is defining new AVPs." I > am, however, hesitant to add a lot of rational for decisions made in the > design phase. As you point out, it is already 55 pages. :-) Fair enough. >> >> - 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. > SRD> Yes, the reporting node selects from the abatement algorithms > advertised by the reacting node. I don't see the inter/intra domain > issue. The reacting node indicates what it supports, the reporting > nodes selects one of the algorithms. If the reacting node doesn't want > to support an algorithm then it won't advertise support in the first place. Maybe. I guess. I'd be surprised if folks took instructions from outside that included saying to drop packets and how, especially in the absence of any e2e security, but perhaps you're right. > > SRD> There are other inter domain issues that are discussed in Appendix > B (Topology Hiding Interactions) that are considered outside of the > scope of the DOIC specification. >> >> - 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? > SRD> The logic of an agent in this case is considered to be an > implementation decision. When an agent handles this scenario, it is, in > essence, acting as a back-to-back agent. It is a reporting node on one > side and a reacting node on the other. Maybe it would help to add > wording to the effect that the agent must be a fully compliant reporting > node and reacting node. That was the intent of the statement "Care must > be taken not to introduce interoperability issues for downstream or > upstream DOIC nodes." > > SRD> I'm happy to beef this up if it is considered necessary. Hmm. Sorry I'm still not getting it. Maybe if you said how one could preserve or bugger-up interop that'd help? >> >> - 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? > SRD> Yes, this is an issue. It is addressed in the first paragraph of > the security considerations section. Do we need to discuss it in the > intro section as well? I'd say either mention if in 4.3 or else refer to a duration of zero in section 10 if that's not there somewhere (and I don't see it, just a mention of DoS in general). >> >> - 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. > SRD> This is because all of the Diameter nodes in the picture can take > on both reacting and reporting node functionality depending on the > context of an individual transaction. Would it suffice to put wording > to this effect in the paragraph after Figure 1? I just wondered. Do as you think best. >> >> - 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? > SRD> I agree, the wording is misleading. I propose to change it to "A > reporting node MUST select a single abatement algorithm in the > OC-Feature-Vector AVP. >> >> - 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. > SRD> Agreed. How about the following: "If the reacting node determines > that the sequence number has rolled over then the reacting node MUST > update the matching OCS entry. This can be determined by recognizing > that the number has changed from something close to the maximum value in > the OC-Sequence-Number AVP to something close to the minimum value in > the OC-Sequence-Number AVP. >> >> - 5.3: "[RFC6733] defined Grouped AVP extension mechanisms >> apply. " is unclear, to me anyway. What's it mean? > SRD> This is a reference back to the base Diameter specification saying > that extensibility mechanisms defined there also apply to the DOIC group > AVPs. This means that it is always possible to add new sub AVPs and > that a node receiving a sub AVP that it does not understand should just > ignore the sub AVP. >> >> - 6.1, step 4: I think that has to be a uniformly selected >> random number. > SRD> Agreed. >> >> - 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? > SRD> There is one way to get into 100% reduction - with an OLR > indicating such. A reacting node comes out of this when the OLR > expires. I'm not sure there is ambiguity here but we can modify the > first sentence as follows if we think it is necessary: "If reacting node > comes out of the 100 percent traffic reduction, meaning it has received > an OLR indicating that no traffic should be sent, as a result of the > overload report timing out..." >> >> - 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. > SRD> The receiving node should use the default value in this case. I > thought we had that there already. I propose adding the following: "If > the value received in the OC-Validity-Duration is greater than the > maximum value then the default value applies." >> >> - 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. > SRD> Would it suffice to add the following: "This may require > out-of-band, non Diameter agreements and/or mechanisms." >> >> - 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. > SRD> We could add: "In the worst case, where the Diameter application is > being used for access control into an IP network, a coordinated DOS > attack could result in the blockage of all traffic into that network." >> >> - 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. > SRD> I vote that we strike all of Appendix C. This was mostly a > checkpoint to see how well the DOIC spec met requirements. I'm not sure > it adds value a part of an RFC. >> >> - 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. > SRD> See my previous comment. >> >> >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From nobody Wed Aug 5 12:58:42 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 204E71A016C; Wed, 5 Aug 2015 12:58:37 -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 Uiq5qaA1tFSI; Wed, 5 Aug 2015 12:58:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 019F71A0372; Wed, 5 Aug 2015 12:58:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150805195831.24117.11508.idtracker@ietfa.amsl.com> Date: Wed, 05 Aug 2015 12:58:31 -0700 Archived-At: Cc: draft-ietf-dime-4over6-provisioning@ietf.org, dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-4over6-provisioning.shepherd@ietf.org, draft-ietf-dime-4over6-provisioning.ad@ietf.org Subject: [Dime] Ben Campbell's No Objection on draft-ietf-dime-4over6-provisioning-04: (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: Wed, 05 Aug 2015 19:58:37 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dime-4over6-provisioning-04: 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-4over6-provisioning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for an easy-to-read document. I have a few questions and comments, that I hope can be resolve easily: -- 3.2: Is it possible (or reasonable) for the FQDN to include an internationalized domain name? That is, is there a need for a idn or precis dependency? (I'm not saying there _is_ such a need; I'm just asking.) -- 6.1, 2nd paragraph: So you mean MiTM attacks _on_ peers, or _by_ peers? I assume the second, since the first can be mitigated with TLS. (I’m not sure I would call this a MiTM per se, it’s just an issue that compromised or malicious nodes already in the path may do bad things.) -- 6.2: Thanks for including this--but I think it needs a bit more. I assume from these sections that some of these AVPs are "security-sensitive" as defined in the referenced section of RFC 6733. That section invokes requirements to use mutually authenticated TLS or IPSec, and to be sure that messages do not traverse any nodes that are not explicitly trusted. It would be good to explicitly list which AVPs from this draft qualify as such (unless the answer is "all of them"), and to explicitly mention that the additional requirements apply to their use. From nobody Wed Aug 5 14:17:54 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 AE7EF1AC3C6; Wed, 5 Aug 2015 14:17:51 -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 BtzP5Z-Js6BO; Wed, 5 Aug 2015 14:17:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 661391AC3A6; Wed, 5 Aug 2015 14:17:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150805211750.17217.6618.idtracker@ietfa.amsl.com> Date: Wed, 05 Aug 2015 14:17:50 -0700 Archived-At: Cc: draft-ietf-dime-4over6-provisioning@ietf.org, dime-chairs@ietf.org, tjc@ecs.soton.ac.uk, dime@ietf.org, draft-ietf-dime-4over6-provisioning.shepherd@ietf.org, draft-ietf-dime-4over6-provisioning.ad@ietf.org Subject: [Dime] Benoit Claise's No Objection on draft-ietf-dime-4over6-provisioning-04: (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: Wed, 05 Aug 2015 21:17:51 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dime-4over6-provisioning-04: 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-4over6-provisioning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As reported by Tim Chown in his OPS DIR review: Overall, I believe the document is Ready. Despite its nature (as a list of definitions) it generally reads very well. There are some minor typos, and items to be checked, as listed below, some of which would no doubt be picked up by the RFC Editor: 1. Section 2.1 line 4, should be “provisions†(plural). 2. Section 2.5, line 5 of second bullet point, “IPv4†not “Pv4â€. 3. Section 3.3.2. I found the third paragraph a little clumsy to read; perhaps clarify the SSM prefix of ff3x::/32 in effect being a /96?. Also, do you mean bits 33-95 here, or bits 32-95 (twice)? 4. Section 3.5, Figure 5. Should the vertical lines be below 8 and 16, rather than below 7 and 15? 5. Section 6 reads a little strangely, in that it says in 6.1 “hey, you can mitm Diameterâ€, then 6.2 says “you MUST use TLS/IPsec avoiding intermediate nodesâ€. Seems a little conflicting in outlook? 6. Two transition drafts cited in the text are now published as RFC 7596 and RFC 7597. From nobody Wed Aug 5 14:19:34 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 AFD771A894C for ; Wed, 5 Aug 2015 14:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4WSwgacngwK6 for ; Wed, 5 Aug 2015 14:19:32 -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 556D81A8944 for ; Wed, 5 Aug 2015 14:19:32 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:54404 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZN65u-0003EH-G3; Wed, 05 Aug 2015 14:19:30 -0700 Message-ID: <55C27DDD.2010801@usdonovans.com> Date: Wed, 05 Aug 2015 16:19:25 -0500 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: Stephen Farrell , dime@ietf.org References: <5599ADCA.9080208@cs.tcd.ie> <55C0A669.20403@usdonovans.com> <55C23C64.5060503@cs.tcd.ie> In-Reply-To: <55C23C64.5060503@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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] 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: Wed, 05 Aug 2015 21:19:33 -0000 On 8/5/15 11:40 AM, Stephen Farrell wrote: > Hiya, > > A few notes below. Where I don't respond, your suggestions > are just fine. > > I guess I'll mark this one as revised-I-D needed to handle > this and the gen-art review stuff and then when we get that > I can put it on an IESG telechat agenda. > > Thanks, > S. > > On 04/08/15 12:47, Steve Donovan wrote: >> Stephen, >> >> Please find my responses inline. >> >> Regards, >> >> Steve >> >> On 7/5/15 5:20 PM, Stephen Farrell wrote: > >>> - 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. >> SRD> Yes, the reporting node selects from the abatement algorithms >> advertised by the reacting node. I don't see the inter/intra domain >> issue. The reacting node indicates what it supports, the reporting >> nodes selects one of the algorithms. If the reacting node doesn't want >> to support an algorithm then it won't advertise support in the first place. > Maybe. I guess. I'd be surprised if folks took instructions > from outside that included saying to drop packets and how, > especially in the absence of any e2e security, but perhaps > you're right. SRD2> Yes, but what you are talking about is a local policy decision. It's actually pretty likely that an operator won't let an overload report from individual servers be sent across administrative boundaries, as many consider the topology information contained to be sensitive information. There is likely to be enforcement of reduction of Diameter signaling done at the edge of Diameter networks. This, however, is just moving where the reacting node sits and is a deployment decision. SRD2> I'll look to add some wording to the introductory section summarizing this. > >> SRD> There are other inter domain issues that are discussed in Appendix >> B (Topology Hiding Interactions) that are considered outside of the >> scope of the DOIC specification. >>> - 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? >> SRD> The logic of an agent in this case is considered to be an >> implementation decision. When an agent handles this scenario, it is, in >> essence, acting as a back-to-back agent. It is a reporting node on one >> side and a reacting node on the other. Maybe it would help to add >> wording to the effect that the agent must be a fully compliant reporting >> node and reacting node. That was the intent of the statement "Care must >> be taken not to introduce interoperability issues for downstream or >> upstream DOIC nodes." >> >> SRD> I'm happy to beef this up if it is considered necessary. > Hmm. Sorry I'm still not getting it. Maybe if you said how one > could preserve or bugger-up interop that'd help? SRD2> I can add some wording on how to preserve. Something to the effect that the agent must operate as a fully compliant reporting node in one direction and as a fully compliant reacting node in the other. > >>> - 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? >> SRD> Yes, this is an issue. It is addressed in the first paragraph of >> the security considerations section. Do we need to discuss it in the >> intro section as well? > I'd say either mention if in 4.3 or else refer to a duration of > zero in section 10 if that's not there somewhere (and I don't > see it, just a mention of DoS in general). SRD> Ok. I'll look at adding something in both places. From nobody Wed Aug 5 14:31:38 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 185E11A89ED for ; Wed, 5 Aug 2015 14:31:36 -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 4S0RdyOoB1M4 for ; Wed, 5 Aug 2015 14:31:32 -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 68A5A1A894C for ; Wed, 5 Aug 2015 14:31:32 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:54554 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZN6HZ-000CMB-9G; Wed, 05 Aug 2015 14:31:32 -0700 Message-ID: <55C280B0.1000807@usdonovans.com> Date: Wed, 05 Aug 2015 16:31:28 -0500 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: Maria Cruz Bartolome , "dime@ietf.org" References: <087A34937E64E74E848732CFF8354B9218047A22@ESESSMB101.ericsson.se> <55C0B9D2.4080208@usdonovans.com> <087A34937E64E74E848732CFF8354B921804A3FE@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B921804A3FE@ESESSMB101.ericsson.se> Content-Type: multipart/alternative; boundary="------------000604030104070406030008" 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] 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: Wed, 05 Aug 2015 21:31:36 -0000 This is a multi-part message in MIME format. --------------000604030104070406030008 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Maria Cruz, The agent overload draft is defining a new type of overload report -- the peer report. While agent overload handling is the primary use case for this overload report type, it is not the only. It is better to define one generic capability then to partially define it in the agent overload draft for one set of use cases and then extend the definition in a separate draft for another set of use cases. Especially when those two sets of use cases are understood at the time of writing. This is why I added the use case description in section 3.2. We should define peer report handling as completely as possible in the agent overload draft. If the name of the draft is confusing then we should consider changing the name of the draft to reflect this. The rate draft should then focus on the definition of the rate algorithm and how it is used in various overload report types. I'll send a separate response on the question of whether or not a rate overload report makes sense in a host report. Regards, Steve On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote: > > Hello Steve, > > Thanks for your response. > > See my comments below > > Best regards > > /MCruz > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan > *Sent:* martes, 04 de agosto de 2015 15:11 > *To:* dime@ietf.org > *Subject:* Re: [Dime] PEER Report with RATE algorithm (Agent Overload > + Rate Algorithm drafts) > > Maria Cruz, > > Thank you for the reviews. See my comments inline. > > Regards, > > Steve > > On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote: > > 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 reflections as well on the RATE draft in this respect. > > Therefore my comments affect both > draft-ietf-dime-doic-rate-controland draft-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 > 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, “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 Default 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 and 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. > > SRD> I agree that the current writing of the draft is focused on the > use of the rate algorithm in a peer report. I intentionally put the > editor's note in the document to make sure that we have the discussion > on whether or not there is reason to also allow use of the rate > algorithm in host and realm reports. > > SRD> It is, however, not clear to me how rate would be an effective > overload control mechanism in host reports, at least not in the > general sense. Any time that a Diameter application allows for realm > routed requests to be sent by a client it becomes impossible for a > client to know the rate of requests that will arrive at a specific > server. I'd like to see some thought put into how this would work > before indicating support for it in the rate draft. > MCRUZ> I do not understand your concern. A rate of message will be > ensure in the reacting node either for a particular host or for a > realm. Could you clarify please? > > > SRD> I agree there may be times that a reporting nodes sends both rate > and loss reports. I would expect this to be in transition periods as > an operator turns on rate control. It seems, however, more likely that > an operator would turn on rate between a reporting node and the first > hop agents first and, if needed, have the agent translate rate OLRs > into loss OLRs for reacting nodes that do not support rate. > MCRUZ> Not sure how this is related to the discussion here > > 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. > > SRD> I don't see why. This is an explanation of how peer might be > used, not a prescription that it must happen. > MCRUZ> “this section outlines use cases for the peer report feature > involving Clients and Servers”. Why is this needed? I think the Agent > draft should cover only Agent overload use cases, nothing else. > > 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]. > > SRD> This is explicitly referring back to the agent overload draft, > where, I agree, the behavior is to be defined. > MCRUZ> then do you agree about removal? > > 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 ::= < 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. > > SRD> I don't understand what is being proposed but the rate algorithm > has a dependency on the agent overload draft because at least one of > the report types it needs to support is peer, and peer is defined in > the agent overload draft. > MCRUZ> my point is that what belongs to Agent overload’s draft shall > be only in Agent overload’s draft. I highlighted paragraphs above that > belongs to Agent overload’s draft. > > 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) > 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 > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------000604030104070406030008 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Maria Cruz,

The agent overload draft is defining a new type of overload report -- the peer report.  While agent overload handling is the primary use case for this overload report type, it is not the only.  It is better to define one generic capability then to partially define it in the agent overload draft for one set of use cases and then extend the definition in a separate draft for another set of use cases.  Especially when those two sets of use cases are understood at the time of writing.

This is why I added the use case description in section 3.2.

We should define peer report handling as completely as possible in the agent overload draft.  If the name of the draft is confusing then we should consider changing the name of the draft to reflect this.

The rate draft should then focus on the definition of the rate algorithm and how it is used in various overload report types.

I'll send a separate response on the question of whether or not a rate overload report makes sense in a host report.

Regards,

Steve

On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote:

Hello Steve,

Thanks for your response.

See my comments below

Best regards

/MCruz

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 04 de agosto de 2015 15:11
To: dime@ietf.org
Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts)

 

Maria Cruz,

Thank you for the reviews.  See my comments inline.

Regards,

Steve

On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote:

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 reflections as well on the RATE draft in this respect.

 

Therefore my comments affect both draft-ietf-dime-doic-rate-control and  draft-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 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, “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 Default 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 and 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.

SRD> I agree that the current writing of the draft is focused on the use of the rate algorithm in a peer report.  I intentionally put the editor's note in the document to make sure that we have the discussion on whether or not there is reason to also allow use of the rate algorithm in host and realm reports.

SRD> It is, however, not clear to me how rate would be an effective overload control mechanism in host reports, at least not in the general sense.  Any time that a Diameter application allows for realm routed requests to be sent by a client it becomes impossible for a client to know the rate of requests that will arrive at a specific server.  I'd like to see some thought put into how this would work before indicating support for it in the rate draft.
MCRUZ> I do not understand your concern. A rate of message will be ensure in the reacting node either for a particular host or for a realm. Could you clarify please?


SRD> I agree there may be times that a reporting nodes sends both rate and loss reports.  I would expect this to be in transition periods as an operator turns on rate control.  It seems, however, more likely that an operator would turn on rate between a reporting node and the first hop agents first and, if needed, have the agent translate rate OLRs into loss OLRs for reacting nodes that do not support rate.
MCRUZ> Not sure how this is related to the discussion here

 

 

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.

SRD> I don't see why.  This is an explanation of how peer might be used, not a prescription that it must happen.
MCRUZ> “this section outlines use cases for the peer report feature involving Clients and Servers”. Why is this needed? I think the Agent draft should cover only Agent overload use cases, nothing else.

 

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].

SRD> This is explicitly referring back to the agent overload draft, where, I agree, the behavior is to be defined.
MCRUZ> then do you agree about removal?

 

      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 ::= < 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.

SRD> I don't understand what is being proposed but the rate algorithm has a dependency on the agent overload draft because at least one of the report types it needs to support is peer, and peer is defined in the agent overload draft.
MCRUZ> my point is that what belongs to Agent overload’s draft shall be only in Agent overload’s draft. I highlighted paragraphs above that belongs to Agent overload’s draft.

 

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) 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

 




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

 


--------------000604030104070406030008-- From nobody Wed Aug 5 15:15:39 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 8CEB71ACD79 for ; Wed, 5 Aug 2015 15:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, 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 8uJJTNYKxMOw for ; Wed, 5 Aug 2015 15:15:33 -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 0D79F1ACD65 for ; Wed, 5 Aug 2015 15:15:33 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:54883 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZN6y9-0000W4-O8; Wed, 05 Aug 2015 15:15:32 -0700 Message-ID: <55C28B01.1010800@usdonovans.com> Date: Wed, 05 Aug 2015 17:15:29 -0500 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: Maria Cruz Bartolome , "dime@ietf.org" References: <087A34937E64E74E848732CFF8354B9218047A22@ESESSMB101.ericsson.se> <55C0B9D2.4080208@usdonovans.com> <087A34937E64E74E848732CFF8354B921804A3FE@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B921804A3FE@ESESSMB101.ericsson.se> Content-Type: multipart/alternative; boundary="------------090808070709030708020809" 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: [Dime] Host report containing rate abatement algorithm (was Re: 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: Wed, 05 Aug 2015 22:15:37 -0000 This is a multi-part message in MIME format. --------------090808070709030708020809 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit There is an open question in the rate draft as to whether or not the rate abatement algorithm should be supported in host overload reports with the implication that the server is controlling the maximum rate of Diameter traffic sent to the server from a single client. The draft outlines use of the rate algorithm in peer reports (which are defined in the agent overload draft). This can be used in both agent based and non agent based networks to effectively control the rate arriving at the overloaded server as the server explicitly knows the identity of all peers and can allocate traffic between them. The peers also know what traffic would normally be sent to the endpoint and can effectively apply abatement strategies to control the traffic actually sent to that endpoint. The question is whether it makes sense to support the rate algorithm in host and realm reports. I'm ignoring realm reports for the time being but I suspect similar considerations exist for realm reports as for host reports. My concerns with this scenario are the following: First, the overloaded server doesn't have full knowledge of all sources (client endpoints) of traffic. This however can be learned by the server remembering the identity of all clients sending it traffic. There currently isn't a requirement that the server remember the source of all clients supporting DOIC so this would be new functionality. Second, endpoints (clients) do not know where all of the Diameter requests it generates will be routed. Clients send two types of traffic, host routed and realm routed requests. What does a client do when it receives a Host:Rate report indicating a maximum rate to be sent to the server from that client? All that the client can do to influence the amount of traffic sent to the overloaded server is to apply abatement treatment to host routed requests targeted for that server. This is unlikely to match the servers expectation when sending the Host:Rate report. I guess the client could throttle a percentage of the realm routed requests based on an algorithm including usual percentage of realm routed requests and number of servers that might eventually handle those requests but this seems pretty convoluted and unlikely to accurately control traffic sent to the server. We addressed this issue with Host:Loss reports by splitting the abatement handling between the endpoint (which handles abatement of host routed requests) and last-hop agents (which handle abatement of realm routed requests). This works because the loss algorithm is stateless. If we keep this split for Host:Rate reports then there is the need for shared information between clients and agents to control the amount of traffic sent to a server. The actual rate of traffic sent to the server would be the sum of all host routed requests allowed by all clients plus the sum of all realm routed requests allowed by all agents. I personally don't think we want to try to specify how this exchange of state would work and how it would then be used to make throttling decisions. My recommendation, if it isn't obvious from the above, is that we limit support for the rate algorithm to peer reports. If we come up with an elegant way of addressing the above concerns sometime in the future then that could be a new extension draft. Regards, Steve On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote: > > Hello Steve, > > Thanks for your response. > > See my comments below > > Best regards > > /MCruz > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan > *Sent:* martes, 04 de agosto de 2015 15:11 > *To:* dime@ietf.org > *Subject:* Re: [Dime] PEER Report with RATE algorithm (Agent Overload > + Rate Algorithm drafts) > > Maria Cruz, > > Thank you for the reviews. See my comments inline. > > Regards, > > Steve > > On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote: > > 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 reflections as well on the RATE draft in this respect. > > Therefore my comments affect both > draft-ietf-dime-doic-rate-controland draft-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 > 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, “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 Default 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 and 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. > > SRD> I agree that the current writing of the draft is focused on the > use of the rate algorithm in a peer report. I intentionally put the > editor's note in the document to make sure that we have the discussion > on whether or not there is reason to also allow use of the rate > algorithm in host and realm reports. > > SRD> It is, however, not clear to me how rate would be an effective > overload control mechanism in host reports, at least not in the > general sense. Any time that a Diameter application allows for realm > routed requests to be sent by a client it becomes impossible for a > client to know the rate of requests that will arrive at a specific > server. I'd like to see some thought put into how this would work > before indicating support for it in the rate draft. > MCRUZ> I do not understand your concern. A rate of message will be > ensure in the reacting node either for a particular host or for a > realm. Could you clarify please? > > > SRD> I agree there may be times that a reporting nodes sends both rate > and loss reports. I would expect this to be in transition periods as > an operator turns on rate control. It seems, however, more likely that > an operator would turn on rate between a reporting node and the first > hop agents first and, if needed, have the agent translate rate OLRs > into loss OLRs for reacting nodes that do not support rate. > MCRUZ> Not sure how this is related to the discussion here > > 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. > > SRD> I don't see why. This is an explanation of how peer might be > used, not a prescription that it must happen. > MCRUZ> “this section outlines use cases for the peer report feature > involving Clients and Servers”. Why is this needed? I think the Agent > draft should cover only Agent overload use cases, nothing else. > > 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]. > > SRD> This is explicitly referring back to the agent overload draft, > where, I agree, the behavior is to be defined. > MCRUZ> then do you agree about removal? > > 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 ::= < 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. > > SRD> I don't understand what is being proposed but the rate algorithm > has a dependency on the agent overload draft because at least one of > the report types it needs to support is peer, and peer is defined in > the agent overload draft. > MCRUZ> my point is that what belongs to Agent overload’s draft shall > be only in Agent overload’s draft. I highlighted paragraphs above that > belongs to Agent overload’s draft. > > 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) > 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 > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------090808070709030708020809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit There is an open question in the rate draft as to whether or not the rate abatement algorithm should be supported in host overload reports with the implication that the server is controlling the maximum rate of Diameter traffic sent to the server from a single client.

The draft outlines use of the rate algorithm in peer reports (which are defined in the agent overload draft).  This can be used in both agent based and non agent based networks to effectively control the rate arriving at the overloaded server as the server explicitly knows the identity of all peers and can allocate traffic between them.  The peers also know what traffic would normally be sent to the endpoint and can effectively apply abatement strategies to control the traffic actually sent to that endpoint.

The question is whether it makes sense to support the rate algorithm in host and realm reports.  I'm ignoring realm reports for the time being but I suspect similar considerations exist for realm reports as for host reports. 

My concerns with this scenario are the following:

First, the overloaded server doesn't have full knowledge of all sources (client endpoints) of traffic.  This however can be learned by the server remembering the identity of all clients sending it traffic.  There currently isn't a requirement that the server remember the source of all clients supporting DOIC so this would be new functionality.

Second, endpoints (clients) do not know where all of the Diameter requests it generates will be routed.  Clients send two types of traffic, host routed and realm routed requests.  What does a client do when it receives a Host:Rate report indicating a maximum rate to be sent to the server from that client?  All that the client can do to influence the amount of traffic sent to the overloaded server is to apply abatement treatment to host routed requests targeted for that server.  This is unlikely to match the servers expectation when sending the Host:Rate report.  I guess the client could throttle a percentage of the realm routed requests based on an algorithm including usual percentage of realm routed requests and number of servers that might eventually handle those requests but this seems pretty convoluted and unlikely to accurately control traffic sent to the server.

We addressed this issue with Host:Loss reports by splitting the abatement handling between the endpoint (which handles abatement of host routed requests) and last-hop agents (which handle abatement of realm routed requests).  This works because the loss algorithm is stateless.  If we keep this split for Host:Rate reports then there is the need for shared information between clients and agents to control the amount of traffic sent to a server.  The actual rate of traffic sent to the server would be the sum of all host routed requests allowed by all clients plus the sum of all realm routed requests allowed by all agents.  I personally don't think we want to try to specify how this exchange of state would work and how it would then be used to make throttling decisions.

My recommendation, if it isn't obvious from the above, is that we limit support for the rate algorithm to peer reports.  If we come up with an elegant way of addressing the above concerns sometime in the future then that could be a new extension draft.

Regards,

Steve


On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote:

Hello Steve,

Thanks for your response.

See my comments below

Best regards

/MCruz

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 04 de agosto de 2015 15:11
To: dime@ietf.org
Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts)

 

Maria Cruz,

Thank you for the reviews.  See my comments inline.

Regards,

Steve

On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote:

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 reflections as well on the RATE draft in this respect.

 

Therefore my comments affect both draft-ietf-dime-doic-rate-control and  draft-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 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, “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 Default 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 and 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.

SRD> I agree that the current writing of the draft is focused on the use of the rate algorithm in a peer report.  I intentionally put the editor's note in the document to make sure that we have the discussion on whether or not there is reason to also allow use of the rate algorithm in host and realm reports.

SRD> It is, however, not clear to me how rate would be an effective overload control mechanism in host reports, at least not in the general sense.  Any time that a Diameter application allows for realm routed requests to be sent by a client it becomes impossible for a client to know the rate of requests that will arrive at a specific server.  I'd like to see some thought put into how this would work before indicating support for it in the rate draft.
MCRUZ> I do not understand your concern. A rate of message will be ensure in the reacting node either for a particular host or for a realm. Could you clarify please?


SRD> I agree there may be times that a reporting nodes sends both rate and loss reports.  I would expect this to be in transition periods as an operator turns on rate control.  It seems, however, more likely that an operator would turn on rate between a reporting node and the first hop agents first and, if needed, have the agent translate rate OLRs into loss OLRs for reacting nodes that do not support rate.
MCRUZ> Not sure how this is related to the discussion here

 

 

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.

SRD> I don't see why.  This is an explanation of how peer might be used, not a prescription that it must happen.
MCRUZ> “this section outlines use cases for the peer report feature involving Clients and Servers”. Why is this needed? I think the Agent draft should cover only Agent overload use cases, nothing else.

 

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].

SRD> This is explicitly referring back to the agent overload draft, where, I agree, the behavior is to be defined.
MCRUZ> then do you agree about removal?

 

      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 ::= < 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.

SRD> I don't understand what is being proposed but the rate algorithm has a dependency on the agent overload draft because at least one of the report types it needs to support is peer, and peer is defined in the agent overload draft.
MCRUZ> my point is that what belongs to Agent overload’s draft shall be only in Agent overload’s draft. I highlighted paragraphs above that belongs to Agent overload’s draft.

 

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) 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

 




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

 


--------------090808070709030708020809-- From nobody Thu Aug 6 00:13: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 E3D101A905C; Thu, 6 Aug 2015 00:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBIhyl0h6AMP; Thu, 6 Aug 2015 00:13:49 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 86AF61A8A72; Thu, 6 Aug 2015 00:13:49 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so5913865igb.0; Thu, 06 Aug 2015 00:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=9cQaFO59gAtz+gR3vXLclw129acYT8vvuytXEmW0tAE=; b=olWtyggcDAMIvU6fduMQBJnFjHFRqWDup9n/qo9eiqcGTJxnyes44pNpeIjbNtR73K f9ourGDIFefprTdU44BVXknRA+zfhsdFcgJnqecFJZFfgUEvJu095+MBEpv5VDiAoSwT 8VLYFKyFhDeNLp1A1mmbdqbasIf/TY21RVY/kJ9RmSiXjkf5RQKO5dNIRzZXBtiz7LSB MsgQvJPjw8gS148DU2ZE2Die81boKIAEcc20RRKnHXShrue16xT+EQNCun8Cpa6cyLWC m6lJUoyI5LcAuB60hH794cZQ4bCjkdRnWBgp9qE5+L1JiizUZrBsj+A0wQL4iyi87tto A+ww== X-Received: by 10.50.64.244 with SMTP id r20mr1799166igs.33.1438845228925; Thu, 06 Aug 2015 00:13:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.196.194 with HTTP; Thu, 6 Aug 2015 00:13:09 -0700 (PDT) From: Qiong Date: Thu, 6 Aug 2015 15:13:09 +0800 Message-ID: To: Spencer Dawkins , dime@ietf.org Content-Type: multipart/alternative; boundary=047d7bea3d22c1ca4d051c9f42a1 Archived-At: Cc: dime-chairs@ietf.org, draft-ietf-dime-4over6-provisioning@ietf.org, draft-ietf-dime-4over6-provisioning.ad@ietf.org, draft-ietf-dime-4over6-provisioning.shepherd@ietf.org Subject: [Dime] [dime] Re: Spencer Dawkins' No Objection on draft-ietf-dime-4over6-provisioning-04: (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, 06 Aug 2015 07:13:52 -0000 --047d7bea3d22c1ca4d051c9f42a1 Content-Type: text/plain; charset=UTF-8 Dear Spencer, This is Qiong Sun. My email address (sunqiong@ctbri.com.cn) is correct, but it seems blocked the emails from draft-ietf-dime-4over6-provisioning@ietf.org and I cannot send the email neither. I will contact the IT in my office ASAP. Thanks! Best wishes Qiong From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] Sent: Tuesday, August 04, 2015 11:28 PM To: The IESG Cc: lionel.morand@orange.com; draft-ietf-dime-4over6-provisioning@ietf.org; dime-chairs@ietf.org; dime@ietf.org; draft-ietf-dime-4over6-provisioning.shepherd@ietf.org; draft-ietf-dime-4over6-provisioning.ad@ietf.org Subject: Re: Spencer Dawkins' No Objection on draft-ietf-dime-4over6-provisioning-04: (with COMMENT) Just curious. Does anyone have an updated address for Sun Qiong? I'm getting (expanded from ): host mail.ctbri.com.cn[219.142.69.47] said: 554 5.7.1 Error: invalid sender by SPF from 4.31.198.44 (in reply to RCPT TO command) Final-Recipient: rfc822; sunqiong@ctbri.com.cn Original-Recipient: rfc822; expand-draft-ietf-dime-4over6-provisioning@virtual.ietf.org Action: failed Status: 5.7.1 Remote-MTA: dns; mail.ctbri.com.cn Diagnostic-Code: smtp; 554 5.7.1 Error: invalid sender by SPF from 4.31.198.44 Thanks! Spencer On Tue, Aug 4, 2015 at 10:23 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: Spencer Dawkins has entered the following ballot position for draft-ietf-dime-4over6-provisioning-04: 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-4over6-provisioning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A nit - this text [RFC6519] sets a precedent for representation of the IPv6 address of a border router as an FQDN. This can be dereferenced to one or more IP addresses by the provisioning system before being passed to the customer equipment, or left as an FQDN as it as in [RFC6334]. ^^^^^^^^^^^ seems garbled. In this text 3.4.1. Delegated-IPv6-Prefix As the IPv6 Binding Prefix The Delegated-IPv6-Prefix AVP (AVP code 123) is of type Octetstring, and is defined in [RFC4818]. Within the Tunnel-Source-Pref-Or-Addr AVP, it conveys the IPv6 Binding Prefix assigned to the CE. Valid values in the Prefix-Length field are from 0 to 128 (full address), although a more restricted range is obviously more reasonable. ^^^^^^^^^^^^^^^^^^^^^^^^^ I wonder if "obviously more reasonable" is the right thing to say. Is this saying something like "more scalable" (compared to bunches of 128-bit IP binding prefixes)? Or am I misunderstanding the point? -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --047d7bea3d22c1ca4d051c9f42a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Spencer,

This is Qiong Sun. My ema= il address (sunqiong@ctbri.com.cn<= /a>) is correct, but it seems blocked the emails from=C2=A0draft-ietf-dime-4o= ver6-provisioning@ietf.org and =C2=A0I cannot send the email neither. I= will contact the IT in my office ASAP.

Thanks!

<= /span>
Best wishes
Qiong


From: Spencer Dawkins at IETF [= mailto:spencerdawkins.ietf= @gmail.com]=C2=A0
Sent: Tuesday, August 04, 2015 11:28 PM
To: The IESG
Subject: Re: Spencer Dawkins' No Objection on draft-ietf-dime-4over6-p= rovisioning-04: (with COMMENT)
=C2=A0
Just curious. Doe= s anyone have an updated address for Sun Qiong?
=C2=A0
= I'm getting

<sunqiong@ctbri.com.cn> (expanded from
=C2=A0 =C2=A0 mail.ctbri.com.cn[219.142.69.47] said: 554 5.7.1 Error: invalid sender= by
=C2=A0 =C2=A0 SPF from 4.31.198.44 (in reply to RCPT TO comma= nd)

Final-Recipient: rfc822; sunqiong@ctbri.com.cn
Dia= gnostic-Code: smtp; 554 5.7.1 Error: invalid sender by SPF from 4.31.198.44=
=C2=A0
Thanks!
=C2=A0
Spencer
=C2=A0
On Tue, Aug 4, 2015 at 10:23 AM, Spencer Dawkins <= ;spencerdawkins.ietf@gmail= .com> wrote:
Spencer Dawkins has entered the following bal= lot position for
draft-ietf-dime-4over6-provisioning-04: No Objec= tion

When responding, please keep the subject line= intact and reply to all
email addresses included in the To and C= C lines. (Feel free to cut this
introductory paragraph, however.)=


for more information about= IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
=



---------= -------------------------------------------------------------
COM= MENT:
-----------------------------------------------------------= -----------

A nit - this text

=
=C2=A0 =C2=A0[RFC6519] sets a precedent for representation of the IPv6= address of
=C2=A0 =C2=A0a border router as an FQDN.=C2=A0 This c= an be dereferenced to one or more
=C2=A0 =C2=A0IP addresses by th= e provisioning system before being passed to the
=C2=A0 =C2=A0cus= tomer equipment, or left as an FQDN as it as in [RFC6334].
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^= ^^^

seems garbled.

In thi= s text

3.4.1.=C2=A0 Delegated-IPv6-Prefix As the I= Pv6 Binding Prefix

=C2=A0 =C2=A0The Delegated-IPv6= -Prefix AVP (AVP code 123) is of type Octetstring,
=C2=A0 =C2=A0a= nd is defined in [RFC4818].=C2=A0 Within the Tunnel-Source-Pref-Or-Addr
=C2=A0 =C2=A0AVP, it conveys the IPv6 Binding Prefix assigned to the= CE.=C2=A0 Valid
=C2=A0 =C2=A0values in the Prefix-Length field a= re from 0 to 128 (full address),
=C2=A0 =C2=A0although a more res= tricted range is obviously more reasonable.
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^
I wonder if "obviously more reasonable" is the right thing = to say. Is
this saying something like "more scalable" (= compared to bunches of
128-bit IP binding prefixes)? Or am I misu= nderstanding the point?

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Qiong Sun
China Telecom Beijing Research Institude


Ope= n source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdem= o/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

--047d7bea3d22c1ca4d051c9f42a1-- From nobody Thu Aug 6 00:34:39 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 A53331ACD86; Thu, 6 Aug 2015 00:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QdbLnFfhDTkG; Thu, 6 Aug 2015 00:34:35 -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 AEFA61ACD84; Thu, 6 Aug 2015 00:34:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVY24025; Thu, 06 Aug 2015 07:34:32 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 6 Aug 2015 08:34:31 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.182]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Thu, 6 Aug 2015 15:34:24 +0800 From: "Zhouqian (Cathy)" To: Ben Campbell , The IESG Thread-Topic: [Dime] Ben Campbell's No Objection on draft-ietf-dime-4over6-provisioning-04: (with COMMENT) Thread-Index: AQHQz7kkM+psF2YBkU60UpkoW1k0DZ3+h2Yg Date: Thu, 6 Aug 2015 07:34:24 +0000 Message-ID: References: <20150805195831.24117.11508.idtracker@ietfa.amsl.com> In-Reply-To: <20150805195831.24117.11508.idtracker@ietfa.amsl.com> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dime-chairs@ietf.org" , "draft-ietf-dime-4over6-provisioning@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-4over6-provisioning.shepherd@ietf.org" , "draft-ietf-dime-4over6-provisioning.ad@ietf.org" Subject: Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-4over6-provisioning-04: (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, 06 Aug 2015 07:34:37 -0000 SGkgQmVuLA0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkgcmVwbHkgYmVs b3c6DQoNCkJlc3QgUmVnYXJkcywNCkNhdGh5DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEJlbiBDYW1wYmVsbA0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDA2LCAyMDE1IDM6NTkg QU0NCj4gVG86IFRoZSBJRVNHDQo+IENjOiBkcmFmdC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lv bmluZ0BpZXRmLm9yZzsgZGltZS1jaGFpcnNAaWV0Zi5vcmc7DQo+IGRpbWVAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtZGltZS00b3ZlcjYtcHJvdmlzaW9uaW5nLnNoZXBoZXJkQGlldGYub3JnOw0KPiBk cmFmdC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lvbmluZy5hZEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBbRGltZV0gQmVuIENhbXBiZWxsJ3MgTm8gT2JqZWN0aW9uIG9uDQo+IGRyYWZ0LWlldGYtZGlt ZS00b3ZlcjYtcHJvdmlzaW9uaW5nLTA0OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gQmVuIENhbXBi ZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFm dC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lvbmluZy0wNDogTm8gT2JqZWN0aW9uDQo+IA0KPiBX aGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCBy ZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg bGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwg aG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3Jn L2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+ IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg Zm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1kaW1lLTRvdmVyNi1wcm92aXNpb25pbmcvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhhbmtzIGZvciBhbiBlYXN5LXRv LXJlYWQgZG9jdW1lbnQuIEkgaGF2ZSBhIGZldyBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzLA0KPiB0 aGF0IEkgaG9wZSBjYW4gYmUgcmVzb2x2ZSBlYXNpbHk6DQo+IA0KPiAtLSAzLjI6DQo+IElzIGl0 IHBvc3NpYmxlIChvciByZWFzb25hYmxlKSBmb3IgdGhlIEZRRE4gdG8gaW5jbHVkZSBhbiBpbnRl cm5hdGlvbmFsaXplZA0KPiBkb21haW4gbmFtZT8gVGhhdCBpcywgaXMgdGhlcmUgYSBuZWVkIGZv ciBhIGlkbiBvciBwcmVjaXMgZGVwZW5kZW5jeT8gKEknbSBub3QNCj4gc2F5aW5nIHRoZXJlIF9p c18gc3VjaCBhIG5lZWQ7IEknbSBqdXN0DQo+IGFza2luZy4pDQpJIHRoaW5rIGl0IGlzIHBvc3Np YmxlIGZvciB0aGUgRlFETiB0byBpbmNsdWRlIGFuIElETi4gQnV0IHRoaXMgZG9jdW1lbnQgZG9l cyBub3QgZGVmaW5lIHRoZSBGUUROIGVuY29kaW5nLiANCkl0IGp1c3QgZm9sbG93cyB0aGUgZGVm aW5pdGlvbiBpbiBSRkMxMDM1LCBSRkMxMTIzIGFuZCBSRkMyMTgxLg0KPiANCj4gLS0gNi4xLCAy bmQgcGFyYWdyYXBoOg0KPiANCj4gU28geW91IG1lYW4gTWlUTSBhdHRhY2tzIF9vbl8gcGVlcnMs IG9yIF9ieV8gcGVlcnM/IEkgYXNzdW1lIHRoZSBzZWNvbmQsDQo+IHNpbmNlIHRoZSBmaXJzdCBj YW4gYmUgbWl0aWdhdGVkIHdpdGggVExTLiAoSeKAmW0gbm90IHN1cmUgSSB3b3VsZCBjYWxsIHRo aXMgYSBNaVRNDQo+IHBlciBzZSwgaXTigJlzIGp1c3QgYW4gaXNzdWUgdGhhdCBjb21wcm9taXNl ZCBvciBtYWxpY2lvdXMgbm9kZXMgYWxyZWFkeSBpbiB0aGUNCj4gcGF0aCBtYXkgZG8gYmFkIHRo aW5ncy4pDQpUaGUgTWlUTSBhdHRhY2tlciBtYXkgYWx0ZXIgdGhlIGluZm9ybWF0aW9uIHNlbnQg YmV0d2VlbiB0aGUgcGVlcnMuIFNvIHlvdSBhcmUgcmlnaHQsIGl0IHNob3VsZCBiZSBjaGFuZ2Vk IHRvICJieV9wZWVycyIuIFRoYW5rcy4NCg0KPiANCj4gLS0gNi4yOg0KPiBUaGFua3MgZm9yIGlu Y2x1ZGluZyB0aGlzLS1idXQgSSB0aGluayBpdCBuZWVkcyBhIGJpdCBtb3JlLiAgSSBhc3N1bWUg ZnJvbSB0aGVzZQ0KPiBzZWN0aW9ucyB0aGF0IHNvbWUgb2YgdGhlc2UgQVZQcyBhcmUgInNlY3Vy aXR5LXNlbnNpdGl2ZSIgYXMgZGVmaW5lZCBpbiB0aGUNCj4gcmVmZXJlbmNlZCBzZWN0aW9uIG9m IFJGQyA2NzMzLiBUaGF0IHNlY3Rpb24gaW52b2tlcyByZXF1aXJlbWVudHMgdG8gdXNlDQo+IG11 dHVhbGx5IGF1dGhlbnRpY2F0ZWQgVExTIG9yIElQU2VjLCBhbmQgdG8gYmUgc3VyZSB0aGF0IG1l c3NhZ2VzIGRvIG5vdA0KPiB0cmF2ZXJzZSBhbnkgbm9kZXMgdGhhdCBhcmUgbm90IGV4cGxpY2l0 bHkgdHJ1c3RlZC4NCj4gSXQgd291bGQgYmUgZ29vZCB0byBleHBsaWNpdGx5IGxpc3Qgd2hpY2gg QVZQcyBmcm9tIHRoaXMgZHJhZnQgcXVhbGlmeSBhcyBzdWNoDQo+ICh1bmxlc3MgdGhlIGFuc3dl ciBpcyAiYWxsIG9mIHRoZW0iKSwgYW5kIHRvIGV4cGxpY2l0bHkgbWVudGlvbiB0aGF0IHRoZQ0K PiBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBhcHBseSB0byB0aGVpciB1c2UuDQpJIHRoaW5rIGFs bCB0aGUgQVZQcyBpbiB0aGlzIGRyYWZ0IHF1YWxpZnkgdGhlIHJlcXVpcmVtZW50cyBkZWZpbmVk IGluIFJGQyA2NzMzLg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IERpTUUgbWFpbGluZyBsaXN0DQo+IERpTUVAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo= From nobody Thu Aug 6 00:58: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 41C911AD05E; Thu, 6 Aug 2015 00:58:16 -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 Z2wiY0gCKOHk; Thu, 6 Aug 2015 00:58:14 -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 5CF891AD055; Thu, 6 Aug 2015 00:58:14 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id E555B374363; Thu, 6 Aug 2015 09:58:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id B8403158078; Thu, 6 Aug 2015 09:58:09 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 09:58:07 +0200 From: To: Spencer Dawkins Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-dime-4over6-provisioning-04: (with COMMENT) Thread-Index: AQHQzsm3NOVpOdOt6UKcOajIStyRBp3+knNg Date: Thu, 6 Aug 2015 07:58:06 +0000 Message-ID: <32086804-cc33-4842-b972-431b71d9149b@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <20150804152348.1378.21580.idtracker@ietfa.amsl.com> In-Reply-To: <20150804152348.1378.21580.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.8.6.70616 Archived-At: Cc: "draft-ietf-dime-4over6-provisioning@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-4over6-provisioning.shepherd@ietf.org" , The IESG , "draft-ietf-dime-4over6-provisioning.ad@ietf.org" Subject: Re: [Dime] Spencer Dawkins' No Objection on draft-ietf-dime-4over6-provisioning-04: (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, 06 Aug 2015 07:58:16 -0000 SGkgU3BlbmNlciwNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KUGxlYXNlIHNlZSBp bmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiBTcGVuY2VyIERhd2tpbnMgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWls LmNvbV0NCj4gRW52b3nDqcKgOiBtYXJkaSA0IGFvw7t0IDIwMTUgMTc6MjQNCj4gw4DCoDogVGhl IElFU0cNCj4gQ2PCoDogTU9SQU5EIExpb25lbCBJTVQvT0xOOyBkaW1lLWNoYWlyc0BpZXRmLm9y ZzsgZHJhZnQtaWV0Zi1kaW1lLTRvdmVyNi0NCj4gcHJvdmlzaW9uaW5nQGlldGYub3JnOyBkcmFm dC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lvbmluZy5hZEBpZXRmLm9yZzsNCj4gZHJhZnQtaWV0 Zi1kaW1lLTRvdmVyNi1wcm92aXNpb25pbmcuc2hlcGhlcmRAaWV0Zi5vcmc7IGRpbWVAaWV0Zi5v cmcNCj4gT2JqZXTCoDogU3BlbmNlciBEYXdraW5zJyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0 Zi1kaW1lLTRvdmVyNi0NCj4gcHJvdmlzaW9uaW5nLTA0OiAod2l0aCBDT01NRU5UKQ0KPiANCj4g U3BlbmNlciBEYXdraW5zIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcg0KPiBkcmFmdC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lvbmluZy0wNDogTm8gT2JqZWN0 aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5 IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8v d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Lg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRp b25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1kaW1lLTRvdmVyNi1wcm92aXNpb25pbmcvDQo+IA0KPiANCj4gDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gQSBuaXQgLSB0 aGlzIHRleHQNCj4gDQo+ICAgIFtSRkM2NTE5XSBzZXRzIGEgcHJlY2VkZW50IGZvciByZXByZXNl bnRhdGlvbiBvZiB0aGUgSVB2NiBhZGRyZXNzIG9mDQo+ICAgIGEgYm9yZGVyIHJvdXRlciBhcyBh biBGUUROLiAgVGhpcyBjYW4gYmUgZGVyZWZlcmVuY2VkIHRvIG9uZSBvciBtb3JlDQo+ICAgIElQ IGFkZHJlc3NlcyBieSB0aGUgcHJvdmlzaW9uaW5nIHN5c3RlbSBiZWZvcmUgYmVpbmcgcGFzc2Vk IHRvIHRoZQ0KPiAgICBjdXN0b21lciBlcXVpcG1lbnQsIG9yIGxlZnQgYXMgYW4gRlFETiBhcyBp dCBhcyBpbiBbUkZDNjMzNF0uDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIF5eXl5eXl5eXl5eDQo+IA0KW01lZF0gRml4ZWQuDQoNCj4gc2VlbXMgZ2FyYmxlZC4N Cj4gDQo+IEluIHRoaXMgdGV4dA0KPiANCj4gMy40LjEuICBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgg QXMgdGhlIElQdjYgQmluZGluZyBQcmVmaXgNCj4gDQo+ICAgIFRoZSBEZWxlZ2F0ZWQtSVB2Ni1Q cmVmaXggQVZQIChBVlAgY29kZSAxMjMpIGlzIG9mIHR5cGUgT2N0ZXRzdHJpbmcsDQo+ICAgIGFu ZCBpcyBkZWZpbmVkIGluIFtSRkM0ODE4XS4gIFdpdGhpbiB0aGUgVHVubmVsLVNvdXJjZS1QcmVm LU9yLUFkZHINCj4gICAgQVZQLCBpdCBjb252ZXlzIHRoZSBJUHY2IEJpbmRpbmcgUHJlZml4IGFz c2lnbmVkIHRvIHRoZSBDRS4gIFZhbGlkDQo+ICAgIHZhbHVlcyBpbiB0aGUgUHJlZml4LUxlbmd0 aCBmaWVsZCBhcmUgZnJvbSAwIHRvIDEyOCAoZnVsbCBhZGRyZXNzKSwNCj4gICAgYWx0aG91Z2gg YSBtb3JlIHJlc3RyaWN0ZWQgcmFuZ2UgaXMgb2J2aW91c2x5IG1vcmUgcmVhc29uYWJsZS4NCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXg0KPiBJIHdvbmRlciBpZiAib2J2aW91c2x5IG1vcmUgcmVhc29uYWJsZSIgaXMgdGhl IHJpZ2h0IHRoaW5nIHRvIHNheS4gSXMNCj4gdGhpcyBzYXlpbmcgc29tZXRoaW5nIGxpa2UgIm1v cmUgc2NhbGFibGUiIChjb21wYXJlZCB0byBidW5jaGVzIG9mDQo+IDEyOC1iaXQgSVAgYmluZGlu ZyBwcmVmaXhlcyk/IE9yIGFtIEkgbWlzdW5kZXJzdGFuZGluZyB0aGUgcG9pbnQ/DQo+IA0KW01l ZF0gIm1vcmUgcmVhc29uYWJsZSIgaXMgdXNlZCBiZWNhdXNlIGhvc3RzIGFyZSB1c3VhbGx5IHBy b3Zpc2lvbmVkIHdpdGggcHJlZml4ZXMgc3VjaCBhcyAvNDgsIC81NiBvciAvNjQgKHdoaWNoIGFy ZSAicmVzdHJpY3RlZCByYW5nZXMiKS4gDQoNCldlIGNhbiBkZWxldGUgImFsdGhvdWdoIGEgbW9y ZSByZXN0cmljdGVkIHJhbmdlIGlzIG9idmlvdXNseSBtb3JlIHJlYXNvbmFibGUiIGlmIHRoaXMg aXMgY29uZnVzaW5nLg0KDQo= From nobody Thu Aug 6 01:13:01 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 9CDD21AD255; Thu, 6 Aug 2015 01:13:00 -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 JZhpMQamvQNE; Thu, 6 Aug 2015 01:12:50 -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 B07111AD1A3; Thu, 6 Aug 2015 01:12:49 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 19BF03B466E; Thu, 6 Aug 2015 10:12:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id D13A1158088; Thu, 6 Aug 2015 10:12:47 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 10:12:47 +0200 From: To: "Zhouqian (Cathy)" , Ben Campbell , The IESG Thread-Topic: [Dime] Ben Campbell's No Objection on draft-ietf-dime-4over6-provisioning-04: (with COMMENT) Thread-Index: AQHQz7kinh5e0uR0AUeXRZsNAhY8+J3+c6gAgAArowA= Date: Thu, 6 Aug 2015 08:12:46 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933005373F2A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20150805195831.24117.11508.idtracker@ietfa.amsl.com> 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.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.8.5.215416 Archived-At: Cc: "dime-chairs@ietf.org" , "draft-ietf-dime-4over6-provisioning@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-4over6-provisioning.shepherd@ietf.org" , "draft-ietf-dime-4over6-provisioning.ad@ietf.org" Subject: Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-4over6-provisioning-04: (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, 06 Aug 2015 08:13:00 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFpob3VxaWFuIChDYXRoeSkgW21haWx0bzpjYXRo eS56aG91QGh1YXdlaS5jb21dDQo+IEVudm95w6nCoDogamV1ZGkgNiBhb8O7dCAyMDE1IDA5OjM0 DQo+IMOAwqA6IEJlbiBDYW1wYmVsbDsgVGhlIElFU0cNCj4gQ2PCoDogZHJhZnQtaWV0Zi1kaW1l LTRvdmVyNi1wcm92aXNpb25pbmdAaWV0Zi5vcmc7IGRpbWUtY2hhaXJzQGlldGYub3JnOw0KPiBk aW1lQGlldGYub3JnOyBkcmFmdC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lvbmluZy5zaGVwaGVy ZEBpZXRmLm9yZzsNCj4gZHJhZnQtaWV0Zi1kaW1lLTRvdmVyNi1wcm92aXNpb25pbmcuYWRAaWV0 Zi5vcmcNCj4gT2JqZXTCoDogUkU6IFtEaW1lXSBCZW4gQ2FtcGJlbGwncyBObyBPYmplY3Rpb24g b24gZHJhZnQtaWV0Zi1kaW1lLTRvdmVyNi0NCj4gcHJvdmlzaW9uaW5nLTA0OiAod2l0aCBDT01N RU5UKQ0KPiANCj4gSGkgQmVuLA0KPiBUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gUGxlYXNlIHNl ZSBteSByZXBseSBiZWxvdzoNCj4gDQo+IEJlc3QgUmVnYXJkcywNCj4gQ2F0aHkNCj4gDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVuIENhbXBiZWxsDQo+ID4gU2VudDogVGh1 cnNkYXksIEF1Z3VzdCAwNiwgMjAxNSAzOjU5IEFNDQo+ID4gVG86IFRoZSBJRVNHDQo+ID4gQ2M6 IGRyYWZ0LWlldGYtZGltZS00b3ZlcjYtcHJvdmlzaW9uaW5nQGlldGYub3JnOyBkaW1lLWNoYWly c0BpZXRmLm9yZzsNCj4gPiBkaW1lQGlldGYub3JnOyBkcmFmdC1pZXRmLWRpbWUtNG92ZXI2LXBy b3Zpc2lvbmluZy5zaGVwaGVyZEBpZXRmLm9yZzsNCj4gPiBkcmFmdC1pZXRmLWRpbWUtNG92ZXI2 LXByb3Zpc2lvbmluZy5hZEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFtEaW1lXSBCZW4gQ2FtcGJl bGwncyBObyBPYmplY3Rpb24gb24NCj4gPiBkcmFmdC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lv bmluZy0wNDogKHdpdGggQ09NTUVOVCkNCj4gPg0KPiA+IEJlbiBDYW1wYmVsbCBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPiBkcmFmdC1pZXRmLWRpbWUt NG92ZXI2LXByb3Zpc2lvbmluZy0wNDogTm8gT2JqZWN0aW9uDQo+ID4NCj4gPiBXaGVuIHJlc3Bv bmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBh bGwNCj4gZW1haWwNCj4gPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5l cy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPiBpbnRyb2R1Y3RvcnkNCj4gPiBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KPiA+DQo+ID4NCj4gPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy0NCj4gY3JpdGVyaWEuaHRtbA0KPiA+IGZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu DQo+ID4NCj4gPg0KPiA+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z aXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lvbmluZy8NCj4gPg0KPiA+DQo+ ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gQ09NTUVOVDoNCj4gPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ID4NCj4gPiBUaGFua3MgZm9yIGFuIGVhc3ktdG8tcmVhZCBkb2N1bWVudC4gSSBoYXZlIGEgZmV3 IHF1ZXN0aW9ucyBhbmQNCj4gY29tbWVudHMsDQo+ID4gdGhhdCBJIGhvcGUgY2FuIGJlIHJlc29s dmUgZWFzaWx5Og0KPiA+DQo+ID4gLS0gMy4yOg0KPiA+IElzIGl0IHBvc3NpYmxlIChvciByZWFz b25hYmxlKSBmb3IgdGhlIEZRRE4gdG8gaW5jbHVkZSBhbg0KPiBpbnRlcm5hdGlvbmFsaXplZA0K PiA+IGRvbWFpbiBuYW1lPyBUaGF0IGlzLCBpcyB0aGVyZSBhIG5lZWQgZm9yIGEgaWRuIG9yIHBy ZWNpcyBkZXBlbmRlbmN5Pw0KPiAoSSdtIG5vdA0KPiA+IHNheWluZyB0aGVyZSBfaXNfIHN1Y2gg YSBuZWVkOyBJJ20ganVzdA0KPiA+IGFza2luZy4pDQo+IEkgdGhpbmsgaXQgaXMgcG9zc2libGUg Zm9yIHRoZSBGUUROIHRvIGluY2x1ZGUgYW4gSUROLiBCdXQgdGhpcyBkb2N1bWVudA0KPiBkb2Vz IG5vdCBkZWZpbmUgdGhlIEZRRE4gZW5jb2RpbmcuDQo+IEl0IGp1c3QgZm9sbG93cyB0aGUgZGVm aW5pdGlvbiBpbiBSRkMxMDM1LCBSRkMxMTIzIGFuZCBSRkMyMTgxLg0KPiA+DQo+ID4gLS0gNi4x LCAybmQgcGFyYWdyYXBoOg0KPiA+DQo+ID4gU28geW91IG1lYW4gTWlUTSBhdHRhY2tzIF9vbl8g cGVlcnMsIG9yIF9ieV8gcGVlcnM/IEkgYXNzdW1lIHRoZSBzZWNvbmQsDQo+ID4gc2luY2UgdGhl IGZpcnN0IGNhbiBiZSBtaXRpZ2F0ZWQgd2l0aCBUTFMuIChJ4oCZbSBub3Qgc3VyZSBJIHdvdWxk IGNhbGwNCj4gdGhpcyBhIE1pVE0NCj4gPiBwZXIgc2UsIGl04oCZcyBqdXN0IGFuIGlzc3VlIHRo YXQgY29tcHJvbWlzZWQgb3IgbWFsaWNpb3VzIG5vZGVzIGFscmVhZHkNCj4gaW4gdGhlDQo+ID4g cGF0aCBtYXkgZG8gYmFkIHRoaW5ncy4pDQo+IFRoZSBNaVRNIGF0dGFja2VyIG1heSBhbHRlciB0 aGUgaW5mb3JtYXRpb24gc2VudCBiZXR3ZWVuIHRoZSBwZWVycy4gU28geW91DQo+IGFyZSByaWdo dCwgaXQgc2hvdWxkIGJlIGNoYW5nZWQgdG8gImJ5X3BlZXJzIi4gVGhhbmtzLg0KDQpbTWVkXSBG aXhlZC4NCg0KPiANCj4gPg0KPiA+IC0tIDYuMjoNCj4gPiBUaGFua3MgZm9yIGluY2x1ZGluZyB0 aGlzLS1idXQgSSB0aGluayBpdCBuZWVkcyBhIGJpdCBtb3JlLiAgSSBhc3N1bWUNCj4gZnJvbSB0 aGVzZQ0KPiA+IHNlY3Rpb25zIHRoYXQgc29tZSBvZiB0aGVzZSBBVlBzIGFyZSAic2VjdXJpdHkt c2Vuc2l0aXZlIiBhcyBkZWZpbmVkIGluDQo+IHRoZQ0KPiA+IHJlZmVyZW5jZWQgc2VjdGlvbiBv ZiBSRkMgNjczMy4gVGhhdCBzZWN0aW9uIGludm9rZXMgcmVxdWlyZW1lbnRzIHRvIHVzZQ0KPiA+ IG11dHVhbGx5IGF1dGhlbnRpY2F0ZWQgVExTIG9yIElQU2VjLCBhbmQgdG8gYmUgc3VyZSB0aGF0 IG1lc3NhZ2VzIGRvIG5vdA0KPiA+IHRyYXZlcnNlIGFueSBub2RlcyB0aGF0IGFyZSBub3QgZXhw bGljaXRseSB0cnVzdGVkLg0KPiA+IEl0IHdvdWxkIGJlIGdvb2QgdG8gZXhwbGljaXRseSBsaXN0 IHdoaWNoIEFWUHMgZnJvbSB0aGlzIGRyYWZ0IHF1YWxpZnkNCj4gYXMgc3VjaA0KPiA+ICh1bmxl c3MgdGhlIGFuc3dlciBpcyAiYWxsIG9mIHRoZW0iKSwgYW5kIHRvIGV4cGxpY2l0bHkgbWVudGlv biB0aGF0IHRoZQ0KPiA+IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGFwcGx5IHRvIHRoZWlyIHVz ZS4NCj4gSSB0aGluayBhbGwgdGhlIEFWUHMgaW4gdGhpcyBkcmFmdCBxdWFsaWZ5IHRoZSByZXF1 aXJlbWVudHMgZGVmaW5lZCBpbiBSRkMNCj4gNjczMy4NCg0KW01lZF0gSSBtYWRlIHRoaXMgY2hh bmdlOg0KDQpPTEQ6DQoNCiAgIFRoZSBBVlBzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCByZXZl YWwgcHJpdmFjeS1yZWxhdGVkIGluZm9ybWF0aW9uDQogICAoZS5nLiwgc3Vic2NyaWJlciBhZGRy ZXNzZXMpIHRoYXQgY2FuIGJlIHVzZWQgZm9yIHRyYWNraW5nIHByb3Bvc2VzLg0KICAgQ29uc2lk ZXJhdGlvbnMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMTMuMyBvZiBbUkZDNjczM10gTVVTVCBiZQ0K ICAgZm9sbG93ZWQuDQoNCk5FVzoNCg0KICAgVGhlIEFWUHMgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50IHJldmVhbCBwcml2YWN5LXJlbGF0ZWQgaW5mb3JtYXRpb24NCiAgICAoZS5nLiwgc3Vic2Ny aWJlciBhZGRyZXNzZXMpIHRoYXQgY2FuIGJlIHVzZWQgZm9yIHRyYWNraW5nIHByb3Bvc2VzLg0K ICAgQWxsIHRoZXNlIEFWUHMgYXJlIGNvbnNpZGVyZWQgdG8gYmUgc2VjdXJpdHktc2Vuc2l0aXZl Lg0KICAgQ29uc2lkZXJhdGlvbnMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMTMuMyBvZiBbUkZDNjcz M10gTVVTVCBiZQ0KICAgZm9sbG93ZWQgZm9yIERpYW1ldGVyIG1lc3NhZ2VzIGNvbnRhaW5pbmcg dGhlc2UgQVZQcy4NCg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IERpTUUgbWFpbGluZyBsaXN0DQo+ID4gRGlNRUBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K From nobody Thu Aug 6 01:28: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 27CFE1B29DC; Thu, 6 Aug 2015 01:28: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 l3Erk76AdQCu; Thu, 6 Aug 2015 01:28:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 099821B29C7; Thu, 6 Aug 2015 01:28: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.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150806082842.14632.5934.idtracker@ietfa.amsl.com> Date: Thu, 06 Aug 2015 01:28:42 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-4over6-provisioning-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: Thu, 06 Aug 2015 08:28: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 : 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-05.txt Pages : 22 Date : 2015-08-06 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-4over6-provisioning-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 Thu Aug 6 05:32: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 B39351B2E5D; Thu, 6 Aug 2015 05:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzox4n1WCmaR; Thu, 6 Aug 2015 05:32:50 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 4B9BA1B2E5E; Thu, 6 Aug 2015 05:32:50 -0700 (PDT) Received: by vkhl6 with SMTP id l6so26478178vkh.1; Thu, 06 Aug 2015 05:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4YdMKoWH3+EeCpn/slPB1+BOgLoA1cUcpbKjvqyjnTc=; b=lWPe1/UrA7/fuvzIMSyHDAGpXk82X9kb1mKqevLFjp19Z8pwA+OVJKdeEBpRqo67la ErZIamGdC2gkztOyr3t5QbAYBhM3pttPRk2uRuVxFoZkknq2rILRn+mhmz6FgelnfyKm GIRcMxPfp7fmbV3x4Znu1Yl5xsV7nzzFYkbsaLRA/XpgLAswOirbN2BSa4ftJowwH11n x1aYM/H1fh3iJAnGpP5iP9hmo6uuSnEdKv96VJKQopJnhOtxFLSVwZ/G4eKm2wOwOesQ lxm8gxG1VvtRHHDoRFpmQukGY2OxnwvAEBZ7Eat4NgI4RFrAXPy+rkJ1APkO3kRWOBEL T8Zg== MIME-Version: 1.0 X-Received: by 10.52.120.18 with SMTP id ky18mr1581764vdb.94.1438864369557; Thu, 06 Aug 2015 05:32:49 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Thu, 6 Aug 2015 05:32:49 -0700 (PDT) In-Reply-To: <32086804-cc33-4842-b972-431b71d9149b@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <20150804152348.1378.21580.idtracker@ietfa.amsl.com> <32086804-cc33-4842-b972-431b71d9149b@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Thu, 6 Aug 2015 07:32:49 -0500 Message-ID: From: Spencer Dawkins at IETF To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=089e0122f124a0a6b2051ca3b7ac Archived-At: Cc: "draft-ietf-dime-4over6-provisioning@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-4over6-provisioning.shepherd@ietf.org" , The IESG , "draft-ietf-dime-4over6-provisioning.ad@ietf.org" Subject: Re: [Dime] Spencer Dawkins' No Objection on draft-ietf-dime-4over6-provisioning-04: (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, 06 Aug 2015 12:32:52 -0000 --089e0122f124a0a6b2051ca3b7ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 6, 2015 at 2:58 AM, wrote: > Hi Spencer, > > Thank you for the review. Thank you for the quick response! > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com] > > Envoy=C3=A9 : mardi 4 ao=C3=BBt 2015 17:24 > > =C3=80 : The IESG > > Cc : MORAND Lionel IMT/OLN; dime-chairs@ietf.org; > draft-ietf-dime-4over6- > > provisioning@ietf.org; draft-ietf-dime-4over6-provisioning.ad@ietf.org; > > draft-ietf-dime-4over6-provisioning.shepherd@ietf.org; dime@ietf.org > > Objet : Spencer Dawkins' No Objection on draft-ietf-dime-4over6- > > provisioning-04: (with COMMENT) > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-dime-4over6-provisioning-04: 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-4over6-provisioning/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > A nit - this text > > > > [RFC6519] sets a precedent for representation of the IPv6 address of > > a border router as an FQDN. This can be dereferenced to one or more > > IP addresses by the provisioning system before being passed to the > > customer equipment, or left as an FQDN as it as in [RFC6334]. > > ^^^^^^^^^^^ > > > [Med] Fixed. > > > seems garbled. > > > > In this text > > > > 3.4.1. Delegated-IPv6-Prefix As the IPv6 Binding Prefix > > > > The Delegated-IPv6-Prefix AVP (AVP code 123) is of type Octetstring, > > and is defined in [RFC4818]. Within the Tunnel-Source-Pref-Or-Addr > > AVP, it conveys the IPv6 Binding Prefix assigned to the CE. Valid > > values in the Prefix-Length field are from 0 to 128 (full address), > > although a more restricted range is obviously more reasonable. > > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > I wonder if "obviously more reasonable" is the right thing to say. Is > > this saying something like "more scalable" (compared to bunches of > > 128-bit IP binding prefixes)? Or am I misunderstanding the point? > > > [Med] "more reasonable" is used because hosts are usually provisioned wit= h > prefixes such as /48, /56 or /64 (which are "restricted ranges"). > > We can delete "although a more restricted range is obviously more > reasonable" if this is confusing. > What I was thinking, was that the value you use in the Prefix-Length isn't because it's reasonable, it's because that's actually the provisioned prefix length. Deleting that text would work for me (at the level of a comment, of course)= . Spencer --089e0122f124a0a6b2051ca3b7ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 2:58 AM, <mohamed.boucadair@orange.= com> wrote:
Hi Spencer,

Thank you for the review.

Thank you for the= quick response!
=C2=A0
Pleas= e see inline.

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com]
> Envoy=C3=A9=C2=A0: mardi 4 ao=C3=BBt 2015 17:24
> =C3=80=C2=A0: The IESG
> Cc=C2=A0: MORAND Lionel IMT/OLN; dime-chairs@ietf.org; draft-ietf-dime-4over6-
> provisioning@ietf.org; draft-ietf= -dime-4over6-provisioning.ad@ietf.org;
> draft-ietf-dime-4over6-provisioning.shepherd@ietf.org; dime@ietf.org
> Objet=C2=A0: Spencer Dawkins' No Objection on draft-ietf-dime-4ove= r6-
> provisioning-04: (with COMMENT)
>
> Spencer Dawkins has entered the following ballot posi= tion for
> draft-ietf-dime-4over6-provisioning-04: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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.o= rg/doc/draft-ietf-dime-4over6-provisioning/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> A nit - this text
>
>=C2=A0 =C2=A0 [RFC6519] sets a precedent for representation of the IPv6= address of
>=C2=A0 =C2=A0 a border router as an FQDN.=C2=A0 This can be dereference= d to one or more
>=C2=A0 =C2=A0 IP addresses by the provisioning system before being pass= ed to the
>=C2=A0 =C2=A0 customer equipment, or left as an FQDN as it as in [RFC63= 34].
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0^^^^^^^^^^^
>
[Med] Fixed.

> seems garbled.
>
> In this text
>
> 3.4.1.=C2=A0 Delegated-IPv6-Prefix As the IPv6 Binding Prefix
>
>=C2=A0 =C2=A0 The Delegated-IPv6-Prefix AVP (AVP code 123) is of type O= ctetstring,
>=C2=A0 =C2=A0 and is defined in [RFC4818].=C2=A0 Within the Tunnel-Sour= ce-Pref-Or-Addr
>=C2=A0 =C2=A0 AVP, it conveys the IPv6 Binding Prefix assigned to the C= E.=C2=A0 Valid
>=C2=A0 =C2=A0 values in the Prefix-Length field are from 0 to 128 (full= address),
>=C2=A0 =C2=A0 although a more restricted range is obviously more reason= able.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^= ^^^^^^^^^^^^^^^^^^^^
> I wonder if "obviously more reasonable" is the right thing t= o say. Is
> this saying something like "more scalable" (compared to bunc= hes of
> 128-bit IP binding prefixes)? Or am I misunderstanding the point?
>
[Med] "more reasonable" is used because hosts are usually = provisioned with prefixes such as /48, /56 or /64 (which are "restrict= ed ranges").

We can delete "although a more restricted range is obviously more reas= onable" if this is confusing.

What= I was thinking, was that the value you use in the Prefix-Length isn't = because it's reasonable, it's because that's actually the provi= sioned prefix length.

Deleting that text would wor= k for me (at the level of a comment, of course).

S= pencer
--089e0122f124a0a6b2051ca3b7ac-- From nobody Thu Aug 6 05:38:46 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 C6BEC1B2E8A; Thu, 6 Aug 2015 05:38:41 -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 JCk6vbz6UKK0; Thu, 6 Aug 2015 05:38:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BAA81B2E8B; Thu, 6 Aug 2015 05:38:38 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 75C593B455E; Thu, 6 Aug 2015 14:38:36 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 4ECFC38404E; Thu, 6 Aug 2015 14:38:36 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 14:38:33 +0200 From: To: Spencer Dawkins at IETF Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-dime-4over6-provisioning-04: (with COMMENT) Thread-Index: AQHQ0EQBNOVpOdOt6UKcOajIStyRBp3+5+2g Date: Thu, 6 Aug 2015 12:38:32 +0000 Message-ID: <01f92fdb-f5f1-42e5-ac6e-fee3359c1ce4@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20150804152348.1378.21580.idtracker@ietfa.amsl.com> <32086804-cc33-4842-b972-431b71d9149b@OPEXCLILM21.corporate.adroot.infra.ftgroup> 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.3] Content-Type: multipart/alternative; boundary="_000_01f92fdbf5f142e5ac6efee3359c1ce4OPEXCLILMA4corporateadr_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.8.6.111516 Archived-At: Cc: "draft-ietf-dime-4over6-provisioning@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-4over6-provisioning.shepherd@ietf.org" , The IESG , "draft-ietf-dime-4over6-provisioning.ad@ietf.org" Subject: Re: [Dime] Spencer Dawkins' No Objection on draft-ietf-dime-4over6-provisioning-04: (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, 06 Aug 2015 12:38:42 -0000 --_000_01f92fdbf5f142e5ac6efee3359c1ce4OPEXCLILMA4corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpEZWFsIQ0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBTcGVuY2VyIERhd2tpbnMgYXQg SUVURiBbbWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tXQ0KRW52b3nDqSA6IGpl dWRpIDYgYW/Du3QgMjAxNSAxNDozMw0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQpD YyA6IE1PUkFORCBMaW9uZWwgSU1UL09MTjsgZGltZS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWll dGYtZGltZS00b3ZlcjYtcHJvdmlzaW9uaW5nQGlldGYub3JnOyBUaGUgSUVTRzsgZHJhZnQtaWV0 Zi1kaW1lLTRvdmVyNi1wcm92aXNpb25pbmcuYWRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS00 b3ZlcjYtcHJvdmlzaW9uaW5nLnNoZXBoZXJkQGlldGYub3JnOyBkaW1lQGlldGYub3JnOyBRaW9u Zw0KT2JqZXQgOiBSZTogU3BlbmNlciBEYXdraW5zJyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0 Zi1kaW1lLTRvdmVyNi1wcm92aXNpb25pbmctMDQ6ICh3aXRoIENPTU1FTlQpDQoNCg0KDQpPbiBU aHUsIEF1ZyA2LCAyMDE1IGF0IDI6NTggQU0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQpIaSBTcGVuY2Vy LA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQoNClRoYW5rIHlvdSBmb3IgdGhlIHF1aWNr IHJlc3BvbnNlIQ0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlIDogU3BlbmNlciBEYXdraW5zIFttYWlsdG86 c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZA Z21haWwuY29tPl0NCj4gRW52b3nDqSA6IG1hcmRpIDQgYW/Du3QgMjAxNSAxNzoyNA0KPiDDgCA6 IFRoZSBJRVNHDQo+IENjIDogTU9SQU5EIExpb25lbCBJTVQvT0xOOyBkaW1lLWNoYWlyc0BpZXRm Lm9yZzxtYWlsdG86ZGltZS1jaGFpcnNAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWRpbWUtNG92ZXI2 LQ0KPiBwcm92aXNpb25pbmdAaWV0Zi5vcmc8bWFpbHRvOnByb3Zpc2lvbmluZ0BpZXRmLm9yZz47 IGRyYWZ0LWlldGYtZGltZS00b3ZlcjYtcHJvdmlzaW9uaW5nLmFkQGlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lvbmluZy5hZEBpZXRmLm9yZz47DQo+IGRyYWZ0 LWlldGYtZGltZS00b3ZlcjYtcHJvdmlzaW9uaW5nLnNoZXBoZXJkQGlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lvbmluZy5zaGVwaGVyZEBpZXRmLm9yZz47IGRp bWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQo+IE9iamV0IDogU3BlbmNlciBEYXdr aW5zJyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1kaW1lLTRvdmVyNi0NCj4gcHJvdmlzaW9u aW5nLTA0OiAod2l0aCBDT01NRU5UKQ0KPg0KPiBTcGVuY2VyIERhd2tpbnMgaGFzIGVudGVyZWQg dGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtZGltZS00b3Zl cjYtcHJvdmlzaW9uaW5nLTA0OiBObyBPYmplY3Rpb24NCj4NCj4gV2hlbiByZXNwb25kaW5nLCBw bGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVt YWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVl IHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPg0KPg0K PiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlz Y3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElT Q1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+DQo+DQo+IFRoZSBkb2N1bWVudCwgYWxvbmcg d2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLTRvdmVyNi1wcm92aXNp b25pbmcvDQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPg0KPiBBIG5pdCAtIHRoaXMgdGV4dA0KPg0KPiAgICBbUkZDNjUxOV0gc2V0cyBhIHBy ZWNlZGVudCBmb3IgcmVwcmVzZW50YXRpb24gb2YgdGhlIElQdjYgYWRkcmVzcyBvZg0KPiAgICBh IGJvcmRlciByb3V0ZXIgYXMgYW4gRlFETi4gIFRoaXMgY2FuIGJlIGRlcmVmZXJlbmNlZCB0byBv bmUgb3IgbW9yZQ0KPiAgICBJUCBhZGRyZXNzZXMgYnkgdGhlIHByb3Zpc2lvbmluZyBzeXN0ZW0g YmVmb3JlIGJlaW5nIHBhc3NlZCB0byB0aGUNCj4gICAgY3VzdG9tZXIgZXF1aXBtZW50LCBvciBs ZWZ0IGFzIGFuIEZRRE4gYXMgaXQgYXMgaW4gW1JGQzYzMzRdLg0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXg0KPg0KW01lZF0gRml4ZWQuDQoN Cj4gc2VlbXMgZ2FyYmxlZC4NCj4NCj4gSW4gdGhpcyB0ZXh0DQo+DQo+IDMuNC4xLiAgRGVsZWdh dGVkLUlQdjYtUHJlZml4IEFzIHRoZSBJUHY2IEJpbmRpbmcgUHJlZml4DQo+DQo+ICAgIFRoZSBE ZWxlZ2F0ZWQtSVB2Ni1QcmVmaXggQVZQIChBVlAgY29kZSAxMjMpIGlzIG9mIHR5cGUgT2N0ZXRz dHJpbmcsDQo+ICAgIGFuZCBpcyBkZWZpbmVkIGluIFtSRkM0ODE4XS4gIFdpdGhpbiB0aGUgVHVu bmVsLVNvdXJjZS1QcmVmLU9yLUFkZHINCj4gICAgQVZQLCBpdCBjb252ZXlzIHRoZSBJUHY2IEJp bmRpbmcgUHJlZml4IGFzc2lnbmVkIHRvIHRoZSBDRS4gIFZhbGlkDQo+ICAgIHZhbHVlcyBpbiB0 aGUgUHJlZml4LUxlbmd0aCBmaWVsZCBhcmUgZnJvbSAwIHRvIDEyOCAoZnVsbCBhZGRyZXNzKSwN Cj4gICAgYWx0aG91Z2ggYSBtb3JlIHJlc3RyaWN0ZWQgcmFuZ2UgaXMgb2J2aW91c2x5IG1vcmUg cmVhc29uYWJsZS4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KPiBJIHdvbmRlciBpZiAib2J2aW91c2x5IG1vcmUgcmVh c29uYWJsZSIgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIHNheS4gSXMNCj4gdGhpcyBzYXlpbmcgc29t ZXRoaW5nIGxpa2UgIm1vcmUgc2NhbGFibGUiIChjb21wYXJlZCB0byBidW5jaGVzIG9mDQo+IDEy OC1iaXQgSVAgYmluZGluZyBwcmVmaXhlcyk/IE9yIGFtIEkgbWlzdW5kZXJzdGFuZGluZyB0aGUg cG9pbnQ/DQo+DQpbTWVkXSAibW9yZSByZWFzb25hYmxlIiBpcyB1c2VkIGJlY2F1c2UgaG9zdHMg YXJlIHVzdWFsbHkgcHJvdmlzaW9uZWQgd2l0aCBwcmVmaXhlcyBzdWNoIGFzIC80OCwgLzU2IG9y IC82NCAod2hpY2ggYXJlICJyZXN0cmljdGVkIHJhbmdlcyIpLg0KDQpXZSBjYW4gZGVsZXRlICJh bHRob3VnaCBhIG1vcmUgcmVzdHJpY3RlZCByYW5nZSBpcyBvYnZpb3VzbHkgbW9yZSByZWFzb25h YmxlIiBpZiB0aGlzIGlzIGNvbmZ1c2luZy4NCg0KV2hhdCBJIHdhcyB0aGlua2luZywgd2FzIHRo YXQgdGhlIHZhbHVlIHlvdSB1c2UgaW4gdGhlIFByZWZpeC1MZW5ndGggaXNuJ3QgYmVjYXVzZSBp dCdzIHJlYXNvbmFibGUsIGl0J3MgYmVjYXVzZSB0aGF0J3MgYWN0dWFsbHkgdGhlIHByb3Zpc2lv bmVkIHByZWZpeCBsZW5ndGguDQoNCkRlbGV0aW5nIHRoYXQgdGV4dCB3b3VsZCB3b3JrIGZvciBt ZSAoYXQgdGhlIGxldmVsIG9mIGEgY29tbWVudCwgb2YgY291cnNlKS4NCg0KU3BlbmNlcg0K --_000_01f92fdbf5f142e5ac6efee3359c1ce4OPEXCLILMA4corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPkRlYWwhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1l ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3BlbmNlciBEYXdraW5zIGF0IElFVEYgW21h aWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJz cDs6PC9iPiBqZXVkaSA2IGFvw7t0IDIwMTUgMTQ6MzM8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJP VUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IE1PUkFORCBMaW9u ZWwgSU1UL09MTjsgZGltZS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS00b3ZlcjYt cHJvdmlzaW9uaW5nQGlldGYub3JnOyBUaGUgSUVTRzsgZHJhZnQtaWV0Zi1kaW1lLTRvdmVyNi1w cm92aXNpb25pbmcuYWRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS00b3ZlcjYtcHJvdmlzaW9u aW5nLnNoZXBoZXJkQGlldGYub3JnOyBkaW1lQGlldGYub3JnOyBRaW9uZzxicj4NCjxiPk9iamV0 Jm5ic3A7OjwvYj4gUmU6IFNwZW5jZXIgRGF3a2lucycgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWll dGYtZGltZS00b3ZlcjYtcHJvdmlzaW9uaW5nLTA0OiAod2l0aCBDT01NRU5UKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyA2LCAyMDE1IGF0IDI6 NTggQU0sICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFNwZW5jZXIsPGJyPg0K PGJyPg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciB0aGUgcXVpY2sgcmVzcG9uc2UhPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlBsZWFzZSBzZWUgaW5saW5lLjxicj4NCjxicj4NCkNoZWVycyw8YnI+DQpNZWQ8YnI+DQo8YnI+ DQomZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4NCiZndDsgRGUmbmJzcDs6IFNw ZW5jZXIgRGF3a2lucyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRm QGdtYWlsLmNvbSI+c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208L2E+XTxicj4NCiZndDsg RW52b3nDqSZuYnNwOzogbWFyZGkgNCBhb8O7dCAyMDE1IDE3OjI0PGJyPg0KJmd0OyDDgCZuYnNw OzogVGhlIElFU0c8YnI+DQomZ3Q7IENjJm5ic3A7OiBNT1JBTkQgTGlvbmVsIElNVC9PTE47IDxh IGhyZWY9Im1haWx0bzpkaW1lLWNoYWlyc0BpZXRmLm9yZyI+ZGltZS1jaGFpcnNAaWV0Zi5vcmc8 L2E+OyBkcmFmdC1pZXRmLWRpbWUtNG92ZXI2LTxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnBy b3Zpc2lvbmluZ0BpZXRmLm9yZyI+cHJvdmlzaW9uaW5nQGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWlldGYtZGltZS00b3ZlcjYtcHJvdmlzaW9uaW5nLmFkQGlldGYub3JnIj4N CmRyYWZ0LWlldGYtZGltZS00b3ZlcjYtcHJvdmlzaW9uaW5nLmFkQGlldGYub3JnPC9hPjs8YnI+ DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lvbmlu Zy5zaGVwaGVyZEBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1kaW1lLTRvdmVyNi1wcm92aXNpb25pbmcu c2hlcGhlcmRAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRp bWVAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBPYmpldCZuYnNwOzogU3BlbmNlciBEYXdraW5zJyBO byBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1kaW1lLTRvdmVyNi08YnI+DQomZ3Q7IHByb3Zpc2lv bmluZy0wNDogKHdpdGggQ09NTUVOVCk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTcGVuY2VyIERhd2tp bnMgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyPg0KJmd0 OyBkcmFmdC1pZXRmLWRpbWUtNG92ZXI2LXByb3Zpc2lvbmluZy0wNDogTm8gT2JqZWN0aW9uPGJy Pg0KJmd0Ozxicj4NCiZndDsgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyPg0KJmd0OyBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpczxi cj4NCiZndDsgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IFBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEu aHRtbDwvYT48YnI+DQomZ3Q7IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VT UyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRo ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZTo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtZGltZS00b3ZlcjYtcHJvdmlzaW9uaW5nLyIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLTRvdmVy Ni1wcm92aXNpb25pbmcvPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgQ09NTUVOVDo8YnI+DQomZ3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIG5pdCAtIHRoaXMgdGV4dDxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyBbUkZDNjUxOV0gc2V0cyBhIHByZWNlZGVudCBmb3IgcmVwcmVzZW50 YXRpb24gb2YgdGhlIElQdjYgYWRkcmVzcyBvZjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGEgYm9y ZGVyIHJvdXRlciBhcyBhbiBGUUROLiZuYnNwOyBUaGlzIGNhbiBiZSBkZXJlZmVyZW5jZWQgdG8g b25lIG9yIG1vcmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBJUCBhZGRyZXNzZXMgYnkgdGhlIHBy b3Zpc2lvbmluZyBzeXN0ZW0gYmVmb3JlIGJlaW5nIHBhc3NlZCB0byB0aGU8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyBjdXN0b21lciBlcXVpcG1lbnQsIG9yIGxlZnQgYXMgYW4gRlFETiBhcyBpdCBh cyBpbiBbUkZDNjMzNF0uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO15eXl5eXl5eXl5ePGJyPg0KJmd0Ozxicj4NCltNZWRdIEZpeGVkLjxicj4NCjxicj4N CiZndDsgc2VlbXMgZ2FyYmxlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiB0aGlzIHRleHQ8YnI+ DQomZ3Q7PGJyPg0KJmd0OyAzLjQuMS4mbmJzcDsgRGVsZWdhdGVkLUlQdjYtUHJlZml4IEFzIHRo ZSBJUHY2IEJpbmRpbmcgUHJlZml4PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IFRo ZSBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXggQVZQIChBVlAgY29kZSAxMjMpIGlzIG9mIHR5cGUgT2N0 ZXRzdHJpbmcsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgYW5kIGlzIGRlZmluZWQgaW4gW1JGQzQ4 MThdLiZuYnNwOyBXaXRoaW4gdGhlIFR1bm5lbC1Tb3VyY2UtUHJlZi1Pci1BZGRyPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgQVZQLCBpdCBjb252ZXlzIHRoZSBJUHY2IEJpbmRpbmcgUHJlZml4IGFz c2lnbmVkIHRvIHRoZSBDRS4mbmJzcDsgVmFsaWQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB2YWx1 ZXMgaW4gdGhlIFByZWZpeC1MZW5ndGggZmllbGQgYXJlIGZyb20gMCB0byAxMjggKGZ1bGwgYWRk cmVzcyksPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgYWx0aG91Z2ggYSBtb3JlIHJlc3RyaWN0ZWQg cmFuZ2UgaXMgb2J2aW91c2x5IG1vcmUgcmVhc29uYWJsZS48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5ePGJyPg0KJmd0OyBJIHdvbmRl ciBpZiAmcXVvdDtvYnZpb3VzbHkgbW9yZSByZWFzb25hYmxlJnF1b3Q7IGlzIHRoZSByaWdodCB0 aGluZyB0byBzYXkuIElzPGJyPg0KJmd0OyB0aGlzIHNheWluZyBzb21ldGhpbmcgbGlrZSAmcXVv dDttb3JlIHNjYWxhYmxlJnF1b3Q7IChjb21wYXJlZCB0byBidW5jaGVzIG9mPGJyPg0KJmd0OyAx MjgtYml0IElQIGJpbmRpbmcgcHJlZml4ZXMpPyBPciBhbSBJIG1pc3VuZGVyc3RhbmRpbmcgdGhl IHBvaW50Pzxicj4NCiZndDs8YnI+DQpbTWVkXSAmcXVvdDttb3JlIHJlYXNvbmFibGUmcXVvdDsg aXMgdXNlZCBiZWNhdXNlIGhvc3RzIGFyZSB1c3VhbGx5IHByb3Zpc2lvbmVkIHdpdGggcHJlZml4 ZXMgc3VjaCBhcyAvNDgsIC81NiBvciAvNjQgKHdoaWNoIGFyZSAmcXVvdDtyZXN0cmljdGVkIHJh bmdlcyZxdW90OykuPGJyPg0KPGJyPg0KV2UgY2FuIGRlbGV0ZSAmcXVvdDthbHRob3VnaCBhIG1v cmUgcmVzdHJpY3RlZCByYW5nZSBpcyBvYnZpb3VzbHkgbW9yZSByZWFzb25hYmxlJnF1b3Q7IGlm IHRoaXMgaXMgY29uZnVzaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBJIHdhcyB0aGlua2luZywgd2FzIHRoYXQgdGhl IHZhbHVlIHlvdSB1c2UgaW4gdGhlIFByZWZpeC1MZW5ndGggaXNuJ3QgYmVjYXVzZSBpdCdzIHJl YXNvbmFibGUsIGl0J3MgYmVjYXVzZSB0aGF0J3MgYWN0dWFsbHkgdGhlIHByb3Zpc2lvbmVkIHBy ZWZpeCBsZW5ndGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRlbGV0aW5nIHRoYXQgdGV4dCB3b3VsZCB3b3JrIGZvciBtZSAoYXQgdGhlIGxl dmVsIG9mIGEgY29tbWVudCwgb2YgY291cnNlKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlbmNlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_01f92fdbf5f142e5ac6efee3359c1ce4OPEXCLILMA4corporateadr_-- From nobody Thu Aug 6 07:47:47 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 A443B1A923E for ; Thu, 6 Aug 2015 07:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-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 5V_-Ii837-hP for ; Thu, 6 Aug 2015 07:47:45 -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 2FCC91B3AC2 for ; Thu, 6 Aug 2015 07:46:01 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:58536 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZNMQe-0006RN-Ml; Thu, 06 Aug 2015 07:46:00 -0700 Message-ID: <55C37323.6080907@usdonovans.com> Date: Thu, 06 Aug 2015 09:45:55 -0500 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, Stephen Farrell References: <5599ADCA.9080208@cs.tcd.ie> <55C0A669.20403@usdonovans.com> <55C23C64.5060503@cs.tcd.ie> <55C27DDD.2010801@usdonovans.com> In-Reply-To: <55C27DDD.2010801@usdonovans.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] 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: Thu, 06 Aug 2015 14:47:46 -0000 I think the following point is better handled in the deployment considerations appendix. As such, I've added the following wording to that appendix: Inter Realm/Administrative Domain Considerations There are likely to be special considerations for handling DOIC signaling across administrative boundaries. This includes considerations for whether or not information included in the DOIC signaling should be sent across those boundaries. In addition consideration should be taken as to whether or not a reacting node in one realm can be trusted to implement the requested overload abatement handling for overload reports received from a separately administered realm. Steve >>>> - 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. >>> SRD> Yes, the reporting node selects from the abatement algorithms >>> advertised by the reacting node. I don't see the inter/intra domain >>> issue. The reacting node indicates what it supports, the reporting >>> nodes selects one of the algorithms. If the reacting node doesn't want >>> to support an algorithm then it won't advertise support in the first >>> place. >> Maybe. I guess. I'd be surprised if folks took instructions >> from outside that included saying to drop packets and how, >> especially in the absence of any e2e security, but perhaps >> you're right. > SRD2> Yes, but what you are talking about is a local policy decision. > It's actually pretty likely that an operator won't let an overload > report from individual servers be sent across administrative > boundaries, as many consider the topology information contained to be > sensitive information. There is likely to be enforcement of reduction > of Diameter signaling done at the edge of Diameter networks. This, > however, is just moving where the reacting node sits and is a > deployment decision. > > SRD2> I'll look to add some wording to the introductory section > summarizing this. >> From nobody Thu Aug 6 11:35: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 7BE171A1A4C; Thu, 6 Aug 2015 11:35:17 -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 sTqDXq5wj9y4; Thu, 6 Aug 2015 11:35:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CB31A1A7C; Thu, 6 Aug 2015 11:34:59 -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.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150806183459.7428.28023.idtracker@ietfa.amsl.com> Date: Thu, 06 Aug 2015 11:34:59 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-ovli-09.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: Thu, 06 Aug 2015 18:35:17 -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 Overload Indication Conveyance Authors : Jouni Korhonen Steve Donovan Ben Campbell Lionel Morand Filename : draft-ietf-dime-ovli-09.txt Pages : 41 Date : 2015-08-06 Abstract: This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-ovli-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-09 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 Aug 6 13:34:30 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 196521A033A for ; Thu, 6 Aug 2015 13:34:30 -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 psY10H_rEOUG for ; Thu, 6 Aug 2015 13:34:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D0E1A010C for ; Thu, 6 Aug 2015 13:34:27 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 0496B190A0E; Thu, 6 Aug 2015 22:34:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id B2BAE158059; Thu, 6 Aug 2015 22:34:25 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 22:34:25 +0200 From: To: "dime@ietf.org" Thread-Topic: DIME WG Call for adoption: draft-donovan-dime-drmp-01 Thread-Index: AdDQhwONrfHuUOO4QdCGEvDOcCtHNQ== Date: Thu, 6 Aug 2015 20:34:24 +0000 Message-ID: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> 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_6B7134B31289DC4FAF731D844122B36E01CE616COPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.8.6.183315 Archived-At: Subject: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 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, 06 Aug 2015 20:34:30 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01CE616COPEXCLILM43corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, As we discussed and agreed during the last IETF meeting, we ask for the WG = adoption for draft-donovan-dime-drmp-01, which was considered as stable eno= ugh to become a WG document. Abstract When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document defines a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. This mail officially starts a one-week adoption call for draft-donovan-dime= -drmp-01 as a WG document. Express your support or disagreement on the mailing list. The call will end= on August, 13th EOB (CET). - Jouni & Lionel ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E01CE616COPEXCLILM43corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

As we discussed and agreed d= uring the last IETF meeting, we ask for the WG adoption for draft-donovan-d= ime-drmp-01, which was considered as stable enough to become a WG document.=

 

Abstract=

 

   When m= aking routing and resource allocation decisions, Diameter nodes<= /span>

   curren= tly have no generic mechanism to determine the relative

   priori= ty of Diameter messages.  This document defines a mechanism to

   allow = Diameter endpoints to indicate the relative priority of

   Diamet= er transactions.  With this information Diameter nodes can<= /span>

   factor= that priority into routing, resource allocation and overload

   abatement decisions.

 

This mail officially starts = a one-week adoption call for draft-donovan-dime-drmp-01 as a WG document.

 

Express your support or disa= greement on the mailing list. The call will end on August, 13th = EOB (CET).

 

- Jouni & Lionel

 

______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E01CE616COPEXCLILM43corp_-- From nobody Thu Aug 6 13:40:23 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 78ABE1A03B3 for ; Thu, 6 Aug 2015 13:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 TjWytAbtNuTO for ; Thu, 6 Aug 2015 13:40:20 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5771A03E3 for ; Thu, 6 Aug 2015 13:40:20 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 336c3c55.0.2798189.00-2324.7890363.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 06 Aug 2015 20:40:20 +0000 (UTC) X-MXL-Hash: 55c3c63462003cac-3e85bdd74ceb54b88ca8385146fcfb1d932480b8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t76KeIXp006282; Thu, 6 Aug 2015 16:40:19 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t76Ke89x006094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Aug 2015 16:40:13 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 6 Aug 2015 20:39:51 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.200]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0224.002; Thu, 6 Aug 2015 16:39:51 -0400 From: "DOLLY, MARTIN C" To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: DIME WG Call for adoption: draft-donovan-dime-drmp-01 Thread-Index: AdDQhwONrfHuUOO4QdCGEvDOcCtHNQAAQGOQ Date: Thu, 6 Aug 2015 20:39:50 +0000 Message-ID: References: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.156.35] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365603701EDAMISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=WKnIqAQR c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=pIl9mmPkM6cA:10 a=uRRa7] X-AnalysisOut: [4qj2VoA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=s95G6sGz-dY] X-AnalysisOut: [kAuAMld4A:9 a=CjuIK1q_8ugA:10 a=Gv1fH7Y2LcPoS07B:21 a=x_eC] X-AnalysisOut: [xXt4vJvrfWNh:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=rK1Kkr] X-AnalysisOut: [3Z-cz6OlfSWi0A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZ] X-AnalysisOut: [eC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=MeUSeyD93dd2oNwV:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 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, 06 Aug 2015 20:40:22 -0000 --_000_E42CCDDA6722744CB241677169E8365603701EDAMISOUT7MSGUSRDB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Thursday, August 06, 2015 4:34 PM To: dime@ietf.org Subject: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 Folks, As we discussed and agreed during the last IETF meeting, we ask for the WG = adoption for draft-donovan-dime-drmp-01, which was considered as stable eno= ugh to become a WG document. Abstract When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document defines a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. This mail officially starts a one-week adoption call for draft-donovan-dime= -drmp-01 as a WG document. Express your support or disagreement on the mailing list. The call will end= on August, 13th EOB (CET). - Jouni & Lionel ___________________________________________________________________________= ______________________________________________ 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_E42CCDDA6722744CB241677169E8365603701EDAMISOUT7MSGUSRDB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support

 

From: DiME [mailto:dime-bounces@ietf.org] = On Behalf Of lionel.morand@orange.com
Sent: Thursday, August 06, 2015 4:34 PM
To: dime@ietf.org
Subject: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-0= 1

 

Folks,

 

As we discussed and agreed during the last IETF m= eeting, we ask for the WG adoption for draft-donovan-dime-drmp-01, which wa= s considered as stable enough to become a WG document.

 

Abstract

 

   When making routing a= nd resource allocation decisions, Diameter nodes

   currently have no gen= eric mechanism to determine the relative

   priority of Diameter = messages.  This document defines a mechanism to

   allow Diameter endpoi= nts to indicate the relative priority of

   Diameter transactions= .  With this information Diameter nodes can

   factor that priority = into routing, resource allocation and overload

   abatement decisions.=

 

This mail officially starts a one-week adoption c= all for draft-donovan-dime-drmp-01 as a WG document.

 

Express your support or disagreement on the maili= ng list. The call will end on August, 13th EOB (CET).=

 

- Jouni & Lionel=

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_E42CCDDA6722744CB241677169E8365603701EDAMISOUT7MSGUSRDB_-- From nobody Thu Aug 6 13:41:47 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 C100E1A70FE for ; Thu, 6 Aug 2015 13:41:45 -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 ctDKmI8Hu6Ml for ; Thu, 6 Aug 2015 13:41:43 -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 5134E1A1A90 for ; Thu, 6 Aug 2015 13:41:43 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 0647C96F32997; Thu, 6 Aug 2015 20:41:38 +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 t76Kff4s018852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Aug 2015 22:41:41 +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; Thu, 6 Aug 2015 22:41:41 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: DIME WG Call for adoption: draft-donovan-dime-drmp-01 Thread-Index: AdDQhwONrfHuUOO4QdCGEvDOcCtHNQAAQGOQAAAOPaA= Date: Thu, 6 Aug 2015 20:41:41 +0000 Message-ID: References: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: 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_E194C2E18676714DACA9C3A2516265D202C25135FR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 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, 06 Aug 2015 20:41:45 -0000 --_000_E194C2E18676714DACA9C3A2516265D202C25135FR712WXCHMBA12z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 6 ao=FBt 2015 22:40 =C0 : lionel.morand@orange.com; dime@ietf.org Objet : Re: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 I support From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Thursday, August 06, 2015 4:34 PM To: dime@ietf.org Subject: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 Folks, As we discussed and agreed during the last IETF meeting, we ask for the WG = adoption for draft-donovan-dime-drmp-01, which was considered as stable eno= ugh to become a WG document. Abstract When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document defines a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. This mail officially starts a one-week adoption call for draft-donovan-dime= -drmp-01 as a WG document. Express your support or disagreement on the mailing list. The call will end= on August, 13th EOB (CET). - Jouni & Lionel ___________________________________________________________________________= ______________________________________________ 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_E194C2E18676714DACA9C3A2516265D202C25135FR712WXCHMBA12z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I support

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 6 ao=FBt 2015 22:40
=C0 : lionel.morand@orange.com; dime@ietf.org
Objet : Re: [Dime] DIME WG Call for adoption: draft-donovan-dim= e-drmp-01

 

I support

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.mora= nd@orange.com
Sent: Thursday, August 06, 2015 4:34 PM
To: dime@ietf.org
Subject: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-0= 1

 

Folks,

 

As we discussed and agreed during the last IETF m= eeting, we ask for the WG adoption for draft-donovan-dime-drmp-01, which wa= s considered as stable enough to become a WG document.

 

Abstract

 

   When making routing and resource allocation d= ecisions, Diameter nodes

   currently have no generic mechanism to determ= ine the relative

   priority of Diameter messages.  This doc= ument defines a mechanism to

   allow Diameter endpoints to indicate the rela= tive priority of

   Diameter transactions.  With this inform= ation Diameter nodes can

   factor that priority into routing, resource a= llocation and overload

   abatement decisions.

 

This mail officially starts a one-week adoption c= all for draft-donovan-dime-drmp-01 as a WG document.

 

Express your support or disagreement on the maili= ng list. The call will end on August, 13th EOB (CET).=

 

- Jouni & Lionel=

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.
--_000_E194C2E18676714DACA9C3A2516265D202C25135FR712WXCHMBA12z_-- From nobody Thu Aug 6 13:56:15 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 B775C1B3320; Thu, 6 Aug 2015 13:56:13 -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=unavailable 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 b-EZrZVF6moF; Thu, 6 Aug 2015 13:56:13 -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 2A5211B3319; Thu, 6 Aug 2015 13:56:13 -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.2/8.14.9) with ESMTPSA id t76KtW5J029134 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Aug 2015 15:55:42 -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: Zhouqian Date: Thu, 06 Aug 2015 15:55:31 -0500 Message-ID: <80DD195E-CC55-4187-A925-2B198E2A792B@nostrum.com> In-Reply-To: References: <20150805195831.24117.11508.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-dime-4over6-provisioning.shepherd@ietf.org, draft-ietf-dime-4over6-provisioning@ietf.org, dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-4over6-provisioning.ad@ietf.org, The IESG Subject: Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-4over6-provisioning-04: (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, 06 Aug 2015 20:56:13 -0000 Hi, one final comment, inline: On 6 Aug 2015, at 2:34, Zhouqian (Cathy) wrote: >> -- 3.2: >> Is it possible (or reasonable) for the FQDN to include an >> internationalized >> domain name? That is, is there a need for a idn or precis dependency? >> (I'm not >> saying there _is_ such a need; I'm just >> asking.) > I think it is possible for the FQDN to include an IDN. But this > document does not define the FQDN encoding. > It just follows the definition in RFC1035, RFC1123 and RFC2181. It might not hurt to mention that if IDNs are used, they should be encoded as RFC 5891 A-labels. (But I'm okay with it if you don't.) [...] From nobody Thu Aug 6 14:14:34 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 65DBC1A8849; Thu, 6 Aug 2015 14:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 zN-GxyRMDJnQ; Thu, 6 Aug 2015 14:14:28 -0700 (PDT) Received: from mail210.messagelabs.com (mail210.messagelabs.com [216.82.250.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58EA1A8025; Thu, 6 Aug 2015 14:14:28 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-16.tower-210.messagelabs.com!1438895666!21081258!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7857 invoked from network); 6 Aug 2015 21:14:27 -0000 Received: from amer-mta101.csc.com (HELO amer-mta111.csc.com) (20.137.2.87) by server-16.tower-210.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Aug 2015 21:14:27 -0000 Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta111.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id t76LEODc021285; Thu, 6 Aug 2015 17:14:26 -0400 In-Reply-To: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: MIME-Version: 1.0 X-KeepSent: D02D85FC:CDB2A63B-85257E99:0074A1DF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Thu, 6 Aug 2015 17:14:25 -0400 X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.3FP5|July 31, 2013) at 08/06/2015 05:14:26 PM, Serialize complete at 08/06/2015 05:14:26 PM Content-Type: multipart/alternative; boundary="=_alternative 0074AD1085257E99_=" Archived-At: Cc: DiME , "dime@ietf.org" Subject: Re: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 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, 06 Aug 2015 21:14:33 -0000 This is a multipart message in MIME format. --=_alternative 0074AD1085257E99_= Content-Type: text/plain; charset="US-ASCII" I support, and intend to review and make comments. Janet 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: To: "dime@ietf.org" Date: 08/06/2015 04:34 PM Subject: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 Sent by: "DiME" Folks, As we discussed and agreed during the last IETF meeting, we ask for the WG adoption for draft-donovan-dime-drmp-01, which was considered as stable enough to become a WG document. Abstract When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document defines a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. This mail officially starts a one-week adoption call for draft-donovan-dime-drmp-01 as a WG document. Express your support or disagreement on the mailing list. The call will end on August, 13th EOB (CET). - Jouni & Lionel _________________________________________________________________________________________________________________________ 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 --=_alternative 0074AD1085257E99_= Content-Type: text/html; charset="US-ASCII" I support, and intend to review and make comments.
Janet

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:        <lionel.morand@orange.com>
To:        "dime@ietf.org" <dime@ietf.org>
Date:        08/06/2015 04:34 PM
Subject:        [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01
Sent by:        "DiME" <dime-bounces@ietf.org>



Folks,
 
As we discussed and agreed during the last IETF meeting, we ask for the WG adoption for draft-donovan-dime-drmp-01, which was considered as stable enough to become a WG document.
 
Abstract
 
   When making routing and resource allocation decisions, Diameter nodes
   currently have no generic mechanism to determine the relative
   priority of Diameter messages.  This document defines a mechanism to
   allow Diameter endpoints to indicate the relative priority of
   Diameter transactions.  With this information Diameter nodes can
   factor that priority into routing, resource allocation and overload
   abatement decisions.
 
This mail officially starts a one-week adoption call for draft-donovan-dime-drmp-01 as a WG document.
 
Express your support or disagreement on the mailing list. The call will end on August, 13th EOB (CET).
 
- Jouni & Lionel
 
_________________________________________________________________________________________________________________________

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
--=_alternative 0074AD1085257E99_=-- From nobody Thu Aug 6 19:33:13 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 BC0711B40AF; Thu, 6 Aug 2015 19:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wMel6Vgzom47; Thu, 6 Aug 2015 19:33:08 -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 E0A811B40AC; Thu, 6 Aug 2015 19:33:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVZ08128; Fri, 07 Aug 2015 02:33:04 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 7 Aug 2015 03:33:02 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.182]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Fri, 7 Aug 2015 10:32:58 +0800 From: "Zhouqian (Cathy)" To: Ben Campbell Thread-Topic: [Dime] Ben Campbell's No Objection on draft-ietf-dime-4over6-provisioning-04: (with COMMENT) Thread-Index: AQHQz7kkM+psF2YBkU60UpkoW1k0DZ3+h2YggABngYCAAOQPoA== Date: Fri, 7 Aug 2015 02:32:58 +0000 Message-ID: References: <20150805195831.24117.11508.idtracker@ietfa.amsl.com> <80DD195E-CC55-4187-A925-2B198E2A792B@nostrum.com> In-Reply-To: <80DD195E-CC55-4187-A925-2B198E2A792B@nostrum.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-dime-4over6-provisioning.shepherd@ietf.org" , "draft-ietf-dime-4over6-provisioning@ietf.org" , "dime-chairs@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-4over6-provisioning.ad@ietf.org" , The IESG Subject: Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-4over6-provisioning-04: (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: Fri, 07 Aug 2015 02:33:09 -0000 Hi Ben, We will mention it in the next version. Thanks. Best Regards, Cathy > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Friday, August 07, 2015 4:56 AM > To: Zhouqian (Cathy) > Cc: The IESG; dime-chairs@ietf.org; > draft-ietf-dime-4over6-provisioning@ietf.org; dime@ietf.org; > draft-ietf-dime-4over6-provisioning.shepherd@ietf.org; > draft-ietf-dime-4over6-provisioning.ad@ietf.org > Subject: Re: [Dime] Ben Campbell's No Objection on > draft-ietf-dime-4over6-provisioning-04: (with COMMENT) >=20 > Hi, one final comment, inline: >=20 > On 6 Aug 2015, at 2:34, Zhouqian (Cathy) wrote: >=20 > >> -- 3.2: > >> Is it possible (or reasonable) for the FQDN to include an > >> internationalized domain name? That is, is there a need for a idn or > >> precis dependency? > >> (I'm not > >> saying there _is_ such a need; I'm just > >> asking.) > > I think it is possible for the FQDN to include an IDN. But this > > document does not define the FQDN encoding. > > It just follows the definition in RFC1035, RFC1123 and RFC2181. >=20 > It might not hurt to mention that if IDNs are used, they should be encode= d as > RFC 5891 A-labels. (But I'm okay with it if you don't.) >=20 > [...] From nobody Thu Aug 6 22:53:04 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 3BE421B36A8; Thu, 6 Aug 2015 22:53:03 -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 5FfZhXQVVRRw; Thu, 6 Aug 2015 22:53:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 048081B369E; Thu, 6 Aug 2015 22:53:02 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150807055302.6522.73401.idtracker@ietfa.amsl.com> Date: Thu, 06 Aug 2015 22:53:02 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-4over6-provisioning-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 05:53:03 -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-06.txt Pages : 22 Date : 2015-08-06 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-4over6-provisioning-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 7 01: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 5DDB01A8996 for ; Fri, 7 Aug 2015 01: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 vTsH5ayV9NEZ for ; Fri, 7 Aug 2015 01:29:14 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55511A00E5 for ; Fri, 7 Aug 2015 01:29:13 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-db-55c46c57685f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 24.80.12828.75C64C55; Fri, 7 Aug 2015 10:29:11 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.16]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Fri, 7 Aug 2015 10:29:10 +0200 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: DIME WG Call for adoption: draft-donovan-dime-drmp-01 Thread-Index: AdDQhwONrfHuUOO4QdCGEvDOcCtHNQAZA6Fg Date: Fri, 7 Aug 2015 08:29:09 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921804AD33@ESESSMB101.ericsson.se> References: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B921804AD33ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+JvjW54zpFQg02PVSzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxosN19kLPsVVLGlrZG1gPBTcxcjJISFgIvH66m4mCFtM4sK9 9WxdjFwcQgJHGSVatk2CchYxSqz5vJkVpIpNwE7i0ukXQB0cHCICyhKnfzmAhIUFnCQuPJ/K BmKLCDhLXF60GMo2kliwYgs7SDmLgIrEnR3cIGFeAV+J6UunsEOMb2OU+Nq+H2wXp0A7o0Tj zZOMIFWMQBd9P7UG7DpmAXGJW0/mQ10qILFkz3lmCFtU4uXjf6wQtqJE+9MGRoj6fInXp5vY IbYJSpyc+YRlAqPILCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1O LS7OTTcy1kstykwuLs7P08tLLdnECIyig1t+6+5gXP3a8RCjAAejEg+vguCRUCHWxLLiytxD jNIcLErivDM254UKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCx4/T5i1pntf92vfnX/+FPk nu7EH21ntycwKki7VLm2Cq5N7nrVevhJIKfy7qkSC7fHfdW7HbVQavKn5wcvMrIqd8V78jxb U3z7d+EztfocBpdnXg/cQhfNN2F6r7xV/uGu1yHFLkqFD92f/ZJKLdf0NLga3x2xpbw3KeC/ rZn/iW3hVskK/UosxRmJhlrMRcWJAHG6IEmDAgAA Archived-At: Subject: Re: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 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, 07 Aug 2015 08:29:16 -0000 --_000_087A34937E64E74E848732CFF8354B921804AD33ESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support. Thanks From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 06 de agosto de 2015 22:34 To: dime@ietf.org Subject: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 Folks, As we discussed and agreed during the last IETF meeting, we ask for the WG = adoption for draft-donovan-dime-drmp-01, which was considered as stable eno= ugh to become a WG document. Abstract When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document defines a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. This mail officially starts a one-week adoption call for draft-donovan-dime= -drmp-01 as a WG document. Express your support or disagreement on the mailing list. The call will end= on August, 13th EOB (CET). - Jouni & Lionel ___________________________________________________________________________= ______________________________________________ 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_087A34937E64E74E848732CFF8354B921804AD33ESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support.<= /span>

Thanks

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: jueves, 06 de agosto de 2015 22:34
To: dime@ietf.org
Subject: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-0= 1

 

Folks,

 

As we discussed and agreed during the last IETF m= eeting, we ask for the WG adoption for draft-donovan-dime-drmp-01, which wa= s considered as stable enough to become a WG document.

 

Abstract

 

   When making routing a= nd resource allocation decisions, Diameter nodes

   currently have no gen= eric mechanism to determine the relative

   priority of Diameter = messages.  This document defines a mechanism to

   allow Diameter endpoi= nts to indicate the relative priority of

   Diameter transactions= .  With this information Diameter nodes can

   factor that priority = into routing, resource allocation and overload

   abatement decisions.=

 

This mail officially starts a one-week adoption c= all for draft-donovan-dime-drmp-01 as a WG document.

 

Express your support or disagreement on the maili= ng list. The call will end on August, 13th EOB (CET).=

 

- Jouni & Lionel=

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_087A34937E64E74E848732CFF8354B921804AD33ESESSMB101erics_-- From nobody Fri Aug 7 04:37:31 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 7CD721B2AC1 for ; Fri, 7 Aug 2015 04:37:29 -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 1p0DlavMiYb2 for ; Fri, 7 Aug 2015 04:37:27 -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 188821B2AC0 for ; Fri, 7 Aug 2015 04:37:27 -0700 (PDT) Received: from mutabilis-2.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t77BbQdG016262 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 7 Aug 2015 06:37:26 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be mutabilis-2.local To: dime@ietf.org References: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: "A. Jean Mahoney" Message-ID: <55C4986F.1030406@nostrum.com> Date: Fri, 7 Aug 2015 06:37:19 -0500 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 In-Reply-To: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 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, 07 Aug 2015 11:37:29 -0000 I support adopting the draft as a WG item. Jean On 8/6/15 3:34 PM, lionel.morand@orange.com wrote: > > Folks, > > As we discussed and agreed during the last IETF meeting, we ask for > the WG adoption for draft-donovan-dime-drmp-01, which was considered > as stable enough to become a WG document. > > Abstract > > When making routing and resource allocation decisions, Diameter nodes > > currently have no generic mechanism to determine the relative > > priority of Diameter messages. This document defines a mechanism to > > allow Diameter endpoints to indicate the relative priority of > > Diameter transactions. With this information Diameter nodes can > > factor that priority into routing, resource allocation and overload > > abatement decisions. > > This mail officially starts a one-week adoption call for > draft-donovan-dime-drmp-01 as a WG document. > > Express your support or disagreement on the mailing list. The call > will end on August, 13^th EOB (CET). > > - Jouni & Lionel > > _________________________________________________________________________________________________________________________ > > 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 Fri Aug 7 08:13:43 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 37DE91B2E3C; Fri, 7 Aug 2015 08:13:42 -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 HvYwh_A9PGkM; Fri, 7 Aug 2015 08:13:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 098E51B2E42; Fri, 7 Aug 2015 08:13:39 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150807151339.5930.31704.idtracker@ietfa.amsl.com> Date: Fri, 07 Aug 2015 08:13:39 -0700 Archived-At: Cc: dime chair , dime mailing list , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Congestion and Filter Attributes' to Proposed Standard (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: Fri, 07 Aug 2015 15:13:42 -0000 The IESG has approved the following document: - 'Diameter Congestion and Filter Attributes' (draft-ietf-dime-congestion-flow-attributes-02.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise, Kathleen Moriarty and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ Technical Summary This document defines optional Explicit Congestion Notification (ECN) and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. RFC 5777 (Traffic Classification and QoS Attributes for Diameter) defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions. In this draft, the Classifier Grouped AVP contained in the Filter-Rule AVP is extended with the new ECN-IP-Codepoint AVP which gives the Explicit Congestion Notification (ECN) codepoint values (defined in RFC3168) to match in the IP header. Moreover, the Filter-Rule Grouped AVP itself is extended with a new Congestion-Treatment AVP that indicates how congested traffic should be treated. The Flow-Count and Packet-Count AVPs are also defined in this document to be sent to report in application specific command information of the group of flows described by the Filter-Rule, IPFilterRule or other Diameter traffic filters. This information can be used by the application for improved decision making, Charging and rudimentary traffic profiling. Working Group Summary The working group has consensus supporting this draft. Document Quality No additional reviews are requested. Personnel The document shepherd is Lionel Morand. The responsible Area Director is Kathleen Moriarty. IANA Note This daft provides the specification required to add IANA allocated AVP codes in the IANA-controlled namespace registry specified in Section 11.1.1 of [RFC6733] for the AVPs defined in this document. From nobody Mon Aug 10 07:55: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 88AE41A1A56 for ; Mon, 10 Aug 2015 07:55:51 -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 7-5rEB5zEYOG for ; Mon, 10 Aug 2015 07:55:43 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A4C1B364C for ; Mon, 10 Aug 2015 07:55:41 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-1d-55c8bb6c83de Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 74.B3.12828.C6BB8C55; Mon, 10 Aug 2015 16:55:40 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.16]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Mon, 10 Aug 2015 16:55:39 +0200 From: Maria Cruz Bartolome To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts) Thread-Index: AdDF71+UBcWVniMNRyao3kUKvudioQIttQMAAC3IJfAAFf+qAADxr0Dg Date: Mon, 10 Aug 2015 14:55:39 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921804B826@ESESSMB101.ericsson.se> References: <087A34937E64E74E848732CFF8354B9218047A22@ESESSMB101.ericsson.se> <55C0B9D2.4080208@usdonovans.com> <087A34937E64E74E848732CFF8354B921804A3FE@ESESSMB101.ericsson.se> <55C280B0.1000807@usdonovans.com> In-Reply-To: <55C280B0.1000807@usdonovans.com> 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_087A34937E64E74E848732CFF8354B921804B826ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+JvjW7O7hOhBkvWSlrM7V3BZrGhiceB yWPJkp9MHqve9rEGMEVx2aSk5mSWpRbp2yVwZew61MRU8GAjc8XD468ZGxi3/mDqYuTkkBAw kVhwZgILhC0mceHeerYuRi4OIYGjjBJfO28xQjiLGSXufD4FVsUmYCdx6fQLsG4RAV+J452n weLCAnES+5e9YYaIx0ts276MBcJ2k5i1YSE7iM0ioCrR/2wJG4jNC9R75O5sqG03GSXWf3rD CJLgFNCTODT3ANggRqCTvp9aA7aMWUBc4taT+VBnC0gs2XOeGcIWlXj5+B8rhK0k0bjkCStE fb7EqkOXoZYJSpyc+YRlAqPILCSjZiEpm4WkDCKuJ3Fj6hQ2CFtbYtnC18wQtq7EjH+HWJDF FzCyr2IULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjK6DW37r7mBc/drxEKMAB6MSD2/i2eOh QqyJZcWVuYcYpTlYlMR5Z2zOCxUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaFujKVs0+0tM PcdEM4Vpb+d86Jn6/ObLUy7zG/U9zpnIJvMtfS5z/qrNskxJpU7Hw/rljVmvD/DrrnJYeyPS pug0N0uzcNfnrUnrX6y+2xbR6pH76U9KWPW1zZtk9r9PXPBLk/Mh69OuW+7zZGpMTL9cqeHz Y9zLwhF+x/Z7QKG6uIvMArEPSizFGYmGWsxFxYkAWsSsYo8CAAA= Archived-At: Subject: Re: [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: Mon, 10 Aug 2015 14:55:51 -0000 --_000_087A34937E64E74E848732CFF8354B921804B826ESESSMB101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Steve, If the intention with the now called Diameter Agent Overload draft is to co= ver some more generic use cases I think we should extend the title and the = scope probably. Let's see what others think. And then in the Rate draft, the definition of anything related to PEER repo= rts should be omitted, the right place is the Agent draft. Best regards /MCruz From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: mi=E9rcoles, 05 de agosto de 2015 23:31 To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate = Algorithm drafts) Maria Cruz, The agent overload draft is defining a new type of overload report -- the p= eer report. While agent overload handling is the primary use case for this= overload report type, it is not the only. It is better to define one gene= ric capability then to partially define it in the agent overload draft for = one set of use cases and then extend the definition in a separate draft for= another set of use cases. Especially when those two sets of use cases are= understood at the time of writing. This is why I added the use case description in section 3.2. We should define peer report handling as completely as possible in the agen= t overload draft. If the name of the draft is confusing then we should con= sider changing the name of the draft to reflect this. The rate draft should then focus on the definition of the rate algorithm an= d how it is used in various overload report types. I'll send a separate response on the question of whether or not a rate over= load report makes sense in a host report. Regards, Steve On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote: Hello Steve, Thanks for your response. See my comments below Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: martes, 04 de agosto de 2015 15:11 To: dime@ietf.org Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate = Algorithm drafts) Maria Cruz, Thank you for the reviews. See my comments inline. Regards, Steve On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote: 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. SRD> I agree that the current writing of the draft is focused on the use of= the rate algorithm in a peer report. I intentionally put the editor's not= e in the document to make sure that we have the discussion on whether or no= t there is reason to also allow use of the rate algorithm in host and realm= reports. SRD> It is, however, not clear to me how rate would be an effective overloa= d control mechanism in host reports, at least not in the general sense. An= y time that a Diameter application allows for realm routed requests to be s= ent by a client it becomes impossible for a client to know the rate of requ= ests that will arrive at a specific server. I'd like to see some thought p= ut into how this would work before indicating support for it in the rate dr= aft. MCRUZ> I do not understand your concern. A rate of message will be ensure i= n the reacting node either for a particular host or for a realm. Could you = clarify please? SRD> I agree there may be times that a reporting nodes sends both rate and = loss reports. I would expect this to be in transition periods as an operat= or turns on rate control. It seems, however, more likely that an operator = would turn on rate between a reporting node and the first hop agents first = and, if needed, have the agent translate rate OLRs into loss OLRs for react= ing nodes that do not support rate. MCRUZ> Not sure how this is related to the discussion here 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. SRD> I don't see why. This is an explanation of how peer might be used, no= t a prescription that it must happen. MCRUZ> "this section outlines use cases for the peer report feature involvi= ng Clients and Servers". Why is this needed? I think the Agent draft should= cover only Agent overload use cases, nothing else. 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]. SRD> This is explicitly referring back to the agent overload draft, where, = I agree, the behavior is to be defined. MCRUZ> then do you agree about removal? 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. SRD> I don't understand what is being proposed but the rate algorithm has a= dependency on the agent overload draft because at least one of the report = types it needs to support is peer, and peer is defined in the agent overloa= d draft. MCRUZ> my point is that what belongs to Agent overload's draft shall be onl= y in Agent overload's draft. I highlighted paragraphs above that belongs to= Agent overload's draft. 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_087A34937E64E74E848732CFF8354B921804B826ESESSMB101erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Steve,

 

If the intention with = the now called Diameter Agent Overload draft is to cover some more generic = use cases I think we should extend the title and the scope probably.

Let’s see what o= thers think.

 

And then in the Rate d= raft, the definition of anything related to PEER reports should be omitted,= the right place is the Agent draft.

 

Best regards

/MCruz

 

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: mi=E9rcoles, 05 de agosto de 2015 23:31
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload = + Rate Algorithm drafts)

 

Maria Cruz,

The agent overload draft is defining a new type of overload report -- the p= eer report.  While agent overload handling is the primary use case for= this overload report type, it is not the only.  It is better to defin= e one generic capability then to partially define it in the agent overload draft for one set of use cases and then ex= tend the definition in a separate draft for another set of use cases. = Especially when those two sets of use cases are understood at the time of = writing.

This is why I added the use case description in section 3.2.

We should define peer report handling as completely as possible in the agen= t overload draft.  If the name of the draft is confusing then we shoul= d consider changing the name of the draft to reflect this.

The rate draft should then focus on the definition of the rate algorithm an= d how it is used in various overload report types.

I'll send a separate response on the question of whether or not a rate over= load report makes sense in a host report.

Regards,

Steve

On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote:<= /o:p>

Hello Steve,

Thanks for your respon= se.

See my comments below<= /span>

Best regards

/MCruz

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 04 de agosto de 2015 15:11
To: dime@ietf.org
Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload = + Rate Algorithm drafts)

 

Maria Cruz,

Thank you for the reviews.  See my comments inline.

Regards,

Steve

On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote:=

Hello all,=

 

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-control and&= nbsp; draft-ietf-dime-agent-o= verload.

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

 

a)      RATE draft, PEER u= sage:

In Rate draft, &n= bsp; draft-ietf-= dime-doic-rate-control-01, it is someh= ow 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 Rea= lm report.  See clause 3, “Interaction with DOIC report types= 221;:

 

3.  Interact= ion with DOIC report types

 

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

   type= s defined with the specification of a third in progress:<= /p>

 

   1.&n= bsp; Host - Overload of a specific Diameter Application at a specific

   = ;    Diameter Node as defined in [I-D.ietf-dime-ovli].

 

   2.&n= bsp; Realm - Overload of a specific Diameter Application at a specific

   = ;    Diameter 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 selected by reporting nodes for any of

   thes= e report types.

 

   = ;   Edit= or'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.

SRD> I agree that the cur= rent writing of the draft is focused on the use of the rate algorithm in a = peer report.  I intentionally put the editor's note in the document to make sure that we have the discussion on whether or not there = is reason to also allow use of the rate algorithm in host and realm reports= .

SRD> It is, however, not clear to me how rate would be an effective over= load control mechanism in host reports, at least not in the general sense.&= nbsp; Any time that a Diameter application allows for realm routed requests= to be sent by a client it becomes impossible for a client to know the rate of requests that will arrive at a specific s= erver.  I'd like to see some thought put into how this would work befo= re indicating support for it in the rate draft.
MCRUZ> I do not understand your = concern. A rate of message will be ensure in the reacting node either for a= particular host or for a realm. Could you clarify please?


SRD> I agree there may be times that a reporting nodes sends both rate a= nd loss reports.  I would expect this to be in transition periods as a= n operator turns on rate control.  It seems, however, more likely that= an operator would turn on rate between a reporting node and the first hop agents first and, if needed, have the agent transla= te rate OLRs into loss OLRs for reacting nodes that do not support rate. MCRUZ> Not sure how this is rela= ted to the discussion here

 

 

b)      AGENT draft, requi= rement 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-ie= tf-dime-agent-overload-01 , clause 3.2:

 

3.2.  Diamet= er Endpoint Use Cases

 

   This= section outlines use cases for the peer report feature involving

   Diam= eter Clients and Diameter Servers.

 

3.2.1.  Hop-= by-hop Abatement Algorithms

 

   It i= s envisioned that abatement algorithms will be defined that will

   supp= ort the option for Diameter Endpoints to send peer reports.  For

   inst= ance, it is envisioned that one usage scenario for the rate

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

   on b= y the DIME working group as this is written, will involve=

   abat= ement being done on a hop-by-hop basis.

 

   This= rate deployment scenario would involve Diameter Endpoints

   gene= rating peer reports and selecting the rate algorithm for<= /p>

   abat= ement of overload conditions.

 

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

SRD> I don't see why.&nbs= p; This is an explanation of how peer might be used, not a prescription tha= t it must happen.
MCRUZ> “this section outli= nes use cases for the peer report feature involving Clients and ServersR= 21;. Why is this needed? I think the Agent draft should cover only Agent ov= erload use cases, nothing else.

 

c)       RATE draft, PEER r= eferences

 

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.  Capabili= ty Announcement

…

   = ;   For peer reports the selected algorithm is reflected in the O= C-

   = ;   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].<= o:p>

SRD> This is explicitly r= eferring back to the agent overload draft, where, I agree, the behavior is = to be defined.
MCRUZ> then do you agree about r= emoval?

 

   = ;   Editor's Node: The peer report specification is still under

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

   = ;   change.

 

5.3.  Report= ing Node Maintenance of Overload Control State

…

   o&nb= sp; 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 t= he OC-OLR AVP.

 

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

   = ;            &n= bsp; < OC-Sequence-Number >

   = ;            &n= bsp; < OC-Report-Type >

   = ;            &n= bsp; [ OC-Reduction-Percentage ]

   = ;            &n= bsp; [ OC-Validity-Duration ]

   = ;            &n= bsp; [ OC-Source-ID ]

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

   = ;            &n= bsp; [ OC-Maximum-Rate ]

   = ;            * [ AVP= ]

 

 

   This= extension makes no changes to the other AVPs that are part of<= /o:p>

   the = OC-OLR AVP.

 

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

   exis= ting 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 rat= e control algorithm.  

 

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

SRD> I don't understand w= hat is being proposed but the rate algorithm has a dependency on the agent = overload draft because at least one of the report types it needs to support is peer, and peer is defined in the agent overload draft.=
MCRUZ> my point is that what bel= ongs to Agent overload’s draft shall be only in Agent overload’= s draft. I highlighted paragraphs above that belongs to Agent overload̵= 7;s draft.

 

Best regards

/MCruz

 

 

 

 

 

 

 

 

From: DiME [ma= ilto: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

 <= /o:p>





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

 

 

--_000_087A34937E64E74E848732CFF8354B921804B826ESESSMB101erics_-- From nobody Mon Aug 10 16:30: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 3783A1A1AB6; Mon, 10 Aug 2015 16:30:04 -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 AKuhSrCNJ-gZ; Mon, 10 Aug 2015 16:30:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 060651A1AE6; Mon, 10 Aug 2015 16:30:01 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150810233001.27883.14252.idtracker@ietfa.amsl.com> Date: Mon, 10 Aug 2015 16:30:01 -0700 Archived-At: Cc: dime chair , dime mailing list , RFC Editor Subject: [Dime] Protocol Action: 'Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions' to Proposed Standard (draft-ietf-dime-4over6-provisioning-06.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, 10 Aug 2015 23:30:04 -0000 The IESG has approved the following document: - 'Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions' (draft-ietf-dime-4over6-provisioning-06.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Stephen Farrell, Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-4over6-provisioning/ Technical Summary 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. Working Group Summary Don't think so. Can't tell from shepherd write-up. I don't believe there's anything odd here. Document Quality Quality seems fine. Not sure if implementations are planned. Personnel The document shepherd is Lionel Morand. The responsible Area Director is Stephen Farrell. From nobody Tue Aug 11 08:44:54 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 F31141A90EE for ; Tue, 11 Aug 2015 08:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS5psh1LpS2I for ; Tue, 11 Aug 2015 08:44:51 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 4ED8A1A0334 for ; Tue, 11 Aug 2015 08:42:44 -0700 (PDT) Received: by wicja10 with SMTP id ja10so80107663wic.1 for ; Tue, 11 Aug 2015 08:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=31kmUiGrZWFLek2MlLsC+cSMc0WmRyAUke3f9bcO46M=; b=NIlHvR0wGtuMSZqwv1y3o2j35CrNP7CPanD+8jmKk7Cmw8j7LEO8wsUKcZo6GJ3XT3 685NvOvdWNf04GgZSoAipSElSAsVmfKVXQW62+b3jf8b24SQQTBmPIwlutvTfccUs0V0 zhsjEfgZgck79xfTtss7pi43wVF7MeiFZ2UYv7219x1tWDzozRXCJBSgfV+XDoCv0ah/ aOKRrc+frAh7m1cQHnH9siwIKZU6JjnnshrZtybBCFjz4uItyHIxhgbOzwSqols0wGLy KjVn1zkgHfINselYDiXduU8//8/8+evTQIY5/g8FP4Lstb16UTXp+3OwkKSEKEj29g6q wLkw== MIME-Version: 1.0 X-Received: by 10.180.231.40 with SMTP id td8mr38505263wic.9.1439307762902; Tue, 11 Aug 2015 08:42:42 -0700 (PDT) Received: by 10.28.20.132 with HTTP; Tue, 11 Aug 2015 08:42:42 -0700 (PDT) In-Reply-To: <55C4986F.1030406@nostrum.com> References: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55C4986F.1030406@nostrum.com> Date: Tue, 11 Aug 2015 17:42:42 +0200 Message-ID: From: Victor Pascual Avila To: "A. Jean Mahoney" Content-Type: multipart/alternative; boundary=001a1134cc50ee2da4051d0af3f1 Archived-At: Cc: dime@ietf.org Subject: Re: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 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, 11 Aug 2015 15:44:53 -0000 --001a1134cc50ee2da4051d0af3f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Fri, Aug 7, 2015 at 1:37 PM, A. Jean Mahoney wrote= : > I support adopting the draft as a WG item. > > Jean > > On 8/6/15 3:34 PM, lionel.morand@orange.com wrote: > >> >> Folks, >> >> As we discussed and agreed during the last IETF meeting, we ask for the >> WG adoption for draft-donovan-dime-drmp-01, which was considered as stab= le >> enough to become a WG document. >> >> Abstract >> >> When making routing and resource allocation decisions, Diameter nodes >> >> currently have no generic mechanism to determine the relative >> >> priority of Diameter messages. This document defines a mechanism to >> >> allow Diameter endpoints to indicate the relative priority of >> >> Diameter transactions. With this information Diameter nodes can >> >> factor that priority into routing, resource allocation and overload >> >> abatement decisions. >> >> This mail officially starts a one-week adoption call for >> draft-donovan-dime-drmp-01 as a WG document. >> >> Express your support or disagreement on the mailing list. The call will >> end on August, 13^th EOB (CET). >> >> - Jouni & Lionel >> >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --=20 Victor Pascual =C3=81vila --001a1134cc50ee2da4051d0af3f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Fri, Aug 7, 2015 at 1:37 PM, A. Jean Mahoney <= ;mahoney@nostrum.c= om> wrote:
I support adopti= ng the draft as a WG item.

Jean

On 8/6/15 3:34 PM, lionel.morand@orange.com wrote:

Folks,

As we discussed and agreed during the last IETF meeting, we ask for the WG = adoption for draft-donovan-dime-drmp-01, which was considered as stable eno= ugh to become a WG document.

Abstract

=C2=A0 =C2=A0When making routing and resource allocation decisions, Diamete= r nodes

=C2=A0 =C2=A0currently have no generic mechanism to determine the relative<= br>
=C2=A0 =C2=A0priority of Diameter messages.=C2=A0 This document defines a m= echanism to

=C2=A0 =C2=A0allow Diameter endpoints to indicate the relative priority of<= br>
=C2=A0 =C2=A0Diameter transactions.=C2=A0 With this information Diameter no= des can

=C2=A0 =C2=A0factor that priority into routing, resource allocation and ove= rload

abatement decisions.

This mail officially starts a one-week adoption call for draft-donovan-dime= -drmp-01 as a WG document.

 Express your support or disagreement on the mailing list. The call will end= on August, 13^th EOB (CET).

- Jouni & Lionel

___________________________________________________________________________= ______________________________________________

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 message= s 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 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.


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

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



--
=
Victor Pascual =C3=81vila
--001a1134cc50ee2da4051d0af3f1-- From nobody Fri Aug 14 13:30:32 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 863241A88EB for ; Fri, 14 Aug 2015 13:30:31 -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 ORIbng3Sp6CW for ; Fri, 14 Aug 2015 13:30:29 -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 A530B1A88E9 for ; Fri, 14 Aug 2015 13:30:28 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id C72D13B429F for ; Fri, 14 Aug 2015 22:30:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A6B47238048 for ; Fri, 14 Aug 2015 22:30:26 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0248.002; Fri, 14 Aug 2015 22:30:26 +0200 From: To: "dime@ietf.org" Thread-Topic: DIME WG Call for adoption: draft-donovan-dime-drmp-01 Thread-Index: AdDQhwONrfHuUOO4QdCGEvDOcCtHNQGRKSjg Date: Fri, 14 Aug 2015 20:30:26 +0000 Message-ID: <17439_1439584226_55CE4FE2_17439_7031_1_6B7134B31289DC4FAF731D844122B36E01CEE8F0@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <1932_1438893265_55C3C4D1_1932_3541_1_6B7134B31289DC4FAF731D844122B36E01CE616C@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01CEE8F0OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.8.14.194516 Archived-At: Subject: Re: [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 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, 14 Aug 2015 20:30:31 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01CEE8F0OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, As expected, this draft has received a clear support as well as enough prom= ises for review/contribution to support the WG effort in the specification = of the standard solution. This document is then adopted as WG document. Thank for your support. Lionel & Jouni De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange= .com Envoy=E9 : jeudi 6 ao=FBt 2015 22:34 =C0 : dime@ietf.org Objet : [Dime] DIME WG Call for adoption: draft-donovan-dime-drmp-01 Folks, As we discussed and agreed during the last IETF meeting, we ask for the WG = adoption for draft-donovan-dime-drmp-01, which was considered as stable eno= ugh to become a WG document. Abstract When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document defines a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. This mail officially starts a one-week adoption call for draft-donovan-dime= -drmp-01 as a WG document. Express your support or disagreement on the mailing list. The call will end= on August, 13th EOB (CET). - Jouni & Lionel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E01CEE8F0OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Folks,<= o:p>

&n= bsp;

As expe= cted, this draft has received a clear support as well as enough promises fo= r review/contribution to support the WG effort in the specification of the = standard solution.

This do= cument is then adopted as WG document.

&n= bsp;

Thank f= or your support.

&n= bsp;

Lionel = & Jouni

&n= bsp;

De : DiME [mailto:dime-bounces@ietf.= org] De la part de lionel.morand@orange.com
Envoy=E9 : jeudi 6 ao=FBt 2015 22:34
=C0 : dime@ietf.org
Objet : [Dime] DIME WG Call for adoption: draft-donovan-dime-dr= mp-01

 

Folks,

 

As we discussed and agreed d= uring the last IETF meeting, we ask for the WG adoption for draft-donovan-d= ime-drmp-01, which was considered as stable enough to become a WG document.=

 

Abstract=

 

   When m= aking routing and resource allocation decisions, Diameter nodes<= /span>

   curren= tly have no generic mechanism to determine the relative

   priori= ty of Diameter messages.  This document defines a mechanism to

   allow = Diameter endpoints to indicate the relative priority of

   Diamet= er transactions.  With this information Diameter nodes can<= /span>

   factor= that priority into routing, resource allocation and overload

   abatement decisions.

 

This mail officially starts = a one-week adoption call for draft-donovan-dime-drmp-01 as a WG document.

 

Express your support or disa= greement on the mailing list. The call will end on August, 13th = EOB (CET).

 

- Jouni & Lionel

 

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

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E01CEE8F0OPEXCLILM43corp_-- From nobody Fri Aug 14 13:38:22 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 1E18B1A893E; Fri, 14 Aug 2015 13:38:20 -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 7SJUWSgU4LSK; Fri, 14 Aug 2015 13:38:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 350031A8942; Fri, 14 Aug 2015 13:38:18 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150814203818.26034.82180.idtracker@ietfa.amsl.com> Date: Fri, 14 Aug 2015 13:38:18 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-drmp-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 20:38:20 -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 Routing Message Priority Author : Steve Donovan Filename : draft-ietf-dime-drmp-00.txt Pages : 13 Date : 2015-08-06 Abstract: When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document defines a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-drmp-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 Tue Aug 18 10:46: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 8AC1A1A8BC3 for ; Tue, 18 Aug 2015 10:46:04 -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 6VNcsBjYOh6X for ; Tue, 18 Aug 2015 10:46:00 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 7CE011A8AFB for ; Tue, 18 Aug 2015 10:46:00 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:59063 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZRkxR-0002F3-SS; Tue, 18 Aug 2015 10:46:00 -0700 Message-ID: <55D36F54.8030302@usdonovans.com> Date: Tue, 18 Aug 2015 12:45:56 -0500 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: Maria Cruz Bartolome , "dime@ietf.org" References: <087A34937E64E74E848732CFF8354B9218047A22@ESESSMB101.ericsson.se> <55C0B9D2.4080208@usdonovans.com> <087A34937E64E74E848732CFF8354B921804A3FE@ESESSMB101.ericsson.se> <55C280B0.1000807@usdonovans.com> <087A34937E64E74E848732CFF8354B921804B826@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B921804B826@ESESSMB101.ericsson.se> Content-Type: multipart/alternative; boundary="------------090908000101040706020308" 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] 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: Tue, 18 Aug 2015 17:46:04 -0000 This is a multi-part message in MIME format. --------------090908000101040706020308 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Maria Cruz, I am okay with changing the name of the Agent Overload draft to something like Diameter Peer Report type if the group feels there is a need to do so. Lionel, Jouni, Please advise on whether or not you think this change is needed. Regards, Steve On 8/10/15 9:55 AM, Maria Cruz Bartolome wrote: > > Hello Steve, > > If the intention with the now called Diameter Agent Overload draft is > to cover some more generic use cases I think we should extend the > title and the scope probably. > > Let’s see what others think. > > And then in the Rate draft, the definition of anything related to PEER > reports should be omitted, the right place is the Agent draft. > > Best regards > > /MCruz > > *From:*Steve Donovan [mailto:srdonovan@usdonovans.com] > *Sent:* miércoles, 05 de agosto de 2015 23:31 > *To:* Maria Cruz Bartolome; dime@ietf.org > *Subject:* Re: [Dime] PEER Report with RATE algorithm (Agent Overload > + Rate Algorithm drafts) > > Maria Cruz, > > The agent overload draft is defining a new type of overload report -- > the peer report. While agent overload handling is the primary use > case for this overload report type, it is not the only. It is better > to define one generic capability then to partially define it in the > agent overload draft for one set of use cases and then extend the > definition in a separate draft for another set of use cases. > Especially when those two sets of use cases are understood at the time > of writing. > > This is why I added the use case description in section 3.2. > > We should define peer report handling as completely as possible in the > agent overload draft. If the name of the draft is confusing then we > should consider changing the name of the draft to reflect this. > > The rate draft should then focus on the definition of the rate > algorithm and how it is used in various overload report types. > > I'll send a separate response on the question of whether or not a rate > overload report makes sense in a host report. > > Regards, > > Steve > > On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote: > > Hello Steve, > > Thanks for your response. > > See my comments below > > Best regards > > /MCruz > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve > Donovan > *Sent:* martes, 04 de agosto de 2015 15:11 > *To:* dime@ietf.org > *Subject:* Re: [Dime] PEER Report with RATE algorithm (Agent > Overload + Rate Algorithm drafts) > > Maria Cruz, > > Thank you for the reviews. See my comments inline. > > Regards, > > Steve > > On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote: > > 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 reflections as well on the RATE > draft in this respect. > > Therefore my comments affect both > draft-ietf-dime-doic-rate-controland > draft-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 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, > “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 Default 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 and 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. > > SRD> I agree that the current writing of the draft is focused on > the use of the rate algorithm in a peer report. I intentionally > put the editor's note in the document to make sure that we have > the discussion on whether or not there is reason to also allow use > of the rate algorithm in host and realm reports. > > SRD> It is, however, not clear to me how rate would be an > effective overload control mechanism in host reports, at least not > in the general sense. Any time that a Diameter application allows > for realm routed requests to be sent by a client it becomes > impossible for a client to know the rate of requests that will > arrive at a specific server. I'd like to see some thought put > into how this would work before indicating support for it in the > rate draft. > MCRUZ> I do not understand your concern. A rate of message will be > ensure in the reacting node either for a particular host or for a > realm. Could you clarify please? > > > SRD> I agree there may be times that a reporting nodes sends both > rate and loss reports. I would expect this to be in transition > periods as an operator turns on rate control. It seems, however, > more likely that an operator would turn on rate between a > reporting node and the first hop agents first and, if needed, have > the agent translate rate OLRs into loss OLRs for reacting nodes > that do not support rate. > MCRUZ> Not sure how this is related to the discussion here > > 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. > > SRD> I don't see why. This is an explanation of how peer might be > used, not a prescription that it must happen. > MCRUZ> “this section outlines use cases for the peer report > feature involving Clients and Servers”. Why is this needed? I > think the Agent draft should cover only Agent overload use cases, > nothing else. > > 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]. > > SRD> This is explicitly referring back to the agent overload > draft, where, I agree, the behavior is to be defined. > MCRUZ> then do you agree about removal? > > 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 ::= < 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. > > SRD> I don't understand what is being proposed but the rate > algorithm has a dependency on the agent overload draft because at > least one of the report types it needs to support is peer, and > peer is defined in the agent overload draft. > MCRUZ> my point is that what belongs to Agent overload’s draft > shall be only in Agent overload’s draft. I highlighted paragraphs > above that belongs to Agent overload’s draft. > > 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) 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 > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > --------------090908000101040706020308 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Maria Cruz,

I am okay with changing the name of the Agent Overload draft to something like Diameter Peer Report type if the group feels there is a need to do so. 

Lionel,
Jouni,

Please advise on whether or not you think this change is needed.

Regards,

Steve

On 8/10/15 9:55 AM, Maria Cruz Bartolome wrote:

Hello Steve,

 

If the intention with the now called Diameter Agent Overload draft is to cover some more generic use cases I think we should extend the title and the scope probably.

Let’s see what others think.

 

And then in the Rate draft, the definition of anything related to PEER reports should be omitted, the right place is the Agent draft.

 

Best regards

/MCruz

 

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: miércoles, 05 de agosto de 2015 23:31
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts)

 

Maria Cruz,

The agent overload draft is defining a new type of overload report -- the peer report.  While agent overload handling is the primary use case for this overload report type, it is not the only.  It is better to define one generic capability then to partially define it in the agent overload draft for one set of use cases and then extend the definition in a separate draft for another set of use cases.  Especially when those two sets of use cases are understood at the time of writing.

This is why I added the use case description in section 3.2.

We should define peer report handling as completely as possible in the agent overload draft.  If the name of the draft is confusing then we should consider changing the name of the draft to reflect this.

The rate draft should then focus on the definition of the rate algorithm and how it is used in various overload report types.

I'll send a separate response on the question of whether or not a rate overload report makes sense in a host report.

Regards,

Steve

On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote:

Hello Steve,

Thanks for your response.

See my comments below

Best regards

/MCruz

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 04 de agosto de 2015 15:11
To: dime@ietf.org
Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts)

 

Maria Cruz,

Thank you for the reviews.  See my comments inline.

Regards,

Steve

On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote:

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 reflections as well on the RATE draft in this respect.

 

Therefore my comments affect both draft-ietf-dime-doic-rate-control and  draft-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 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, “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 Default 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 and 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.

SRD> I agree that the current writing of the draft is focused on the use of the rate algorithm in a peer report.  I intentionally put the editor's note in the document to make sure that we have the discussion on whether or not there is reason to also allow use of the rate algorithm in host and realm reports.

SRD> It is, however, not clear to me how rate would be an effective overload control mechanism in host reports, at least not in the general sense.  Any time that a Diameter application allows for realm routed requests to be sent by a client it becomes impossible for a client to know the rate of requests that will arrive at a specific server.  I'd like to see some thought put into how this would work before indicating support for it in the rate draft.
MCRUZ> I do not understand your concern. A rate of message will be ensure in the reacting node either for a particular host or for a realm. Could you clarify please?


SRD> I agree there may be times that a reporting nodes sends both rate and loss reports.  I would expect this to be in transition periods as an operator turns on rate control.  It seems, however, more likely that an operator would turn on rate between a reporting node and the first hop agents first and, if needed, have the agent translate rate OLRs into loss OLRs for reacting nodes that do not support rate.
MCRUZ> Not sure how this is related to the discussion here

 

 

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.

SRD> I don't see why.  This is an explanation of how peer might be used, not a prescription that it must happen.
MCRUZ> “this section outlines use cases for the peer report feature involving Clients and Servers”. Why is this needed? I think the Agent draft should cover only Agent overload use cases, nothing else.

 

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].

SRD> This is explicitly referring back to the agent overload draft, where, I agree, the behavior is to be defined.
MCRUZ> then do you agree about removal?

 

      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 ::= < 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.

SRD> I don't understand what is being proposed but the rate algorithm has a dependency on the agent overload draft because at least one of the report types it needs to support is peer, and peer is defined in the agent overload draft.
MCRUZ> my point is that what belongs to Agent overload’s draft shall be only in Agent overload’s draft. I highlighted paragraphs above that belongs to Agent overload’s draft.

 

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) 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

 





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

 

 


--------------090908000101040706020308-- From nobody Tue Aug 18 10:59: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 3B6761A9034 for ; Tue, 18 Aug 2015 10:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lscIJJXNIPHg for ; Tue, 18 Aug 2015 10:59:54 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 366BA1A8F38 for ; Tue, 18 Aug 2015 10:59:54 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:59154 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZRlAv-0000PJ-4v for dime@ietf.org; Tue, 18 Aug 2015 10:59:54 -0700 Message-ID: <55D37298.4040902@usdonovans.com> Date: Tue, 18 Aug 2015 12:59:52 -0500 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" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: [Dime] DRMP: Extensibility of DRMP AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 17:59:55 -0000 All, I have received a question about whether or not the DRMP AVP should be extensible. It is currently defined to be of type Enumerated. This makes extending it difficult. It is my opinion that it should NOT be extensible. If a new set of priority value are identified as being needed then I think it should be explicitly defined as a new AVP so as to reduce potential interactions between the two sets of AVPs. Are there other opinions? Regards, Steve From nobody Tue Aug 18 11:03: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 9017F1A903A for ; Tue, 18 Aug 2015 11:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxyyiSlHikj6 for ; Tue, 18 Aug 2015 11:03:35 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 140201A9039 for ; Tue, 18 Aug 2015 11:03:35 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t7IHxWqI030224; Tue, 18 Aug 2015 14:03:34 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 1wa1d1hsk4-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Aug 2015 14:03:34 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7II3Wjj030460; Tue, 18 Aug 2015 14:03:33 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7II3NaV030334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Aug 2015 14:03:30 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 18 Aug 2015 18:03:15 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.221]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0224.002; Tue, 18 Aug 2015 14:03:15 -0400 From: "DOLLY, MARTIN C" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DRMP: Extensibility of DRMP AVP Thread-Index: AQHQ2d+2yNLKGMyvnEyxLLxNe4/sH54SC+Xw Date: Tue, 18 Aug 2015 18:03:14 +0000 Message-ID: References: <55D37298.4040902@usdonovans.com> In-Reply-To: <55D37298.4040902@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.89.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-08-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1508180241 Archived-At: Subject: Re: [Dime] DRMP: Extensibility of DRMP AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 18:03:36 -0000 Steve, I agree, it does not need to be extensible.=20 As additional namespaces are added for RHP, additional AVPs can be added fo= r DRMP. Regards, Martin -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Tuesday, August 18, 2015 2:00 PM To: dime@ietf.org Subject: [Dime] DRMP: Extensibility of DRMP AVP All, I have received a question about whether or not the DRMP AVP should be exte= nsible. It is currently defined to be of type Enumerated. This makes extending it = difficult. It is my opinion that it should NOT be extensible. If a new set of priorit= y value are identified as being needed then I think it should be explicitly= defined as a new AVP so as to reduce potential interactions between the tw= o sets of AVPs. Are there other opinions? Regards, Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Aug 18 11:24:47 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 E1D051A9068 for ; Tue, 18 Aug 2015 11:24:45 -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 jOOwZSRMFEP1 for ; Tue, 18 Aug 2015 11:24:42 -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 99FC31A9059 for ; Tue, 18 Aug 2015 11:24:42 -0700 (PDT) Received: by pabyb7 with SMTP id yb7so138067624pab.0 for ; Tue, 18 Aug 2015 11:24:42 -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=XIbWQIf7iB9bnsgkyOgcynaphOm3mXDrCw9A766xfoQ=; b=jVXaIq5S2QjzDZAlN389VBUElE5CCYaMzvuUElUW8gEmra5ENIu+JyfDQwCMje0q64 U6FmGSnvnG45Fe26PiziiOUyfMudiOJTUSbhxJR3Z2mMp2mtk8KoBw9A0J61XhZEdJdy SmEX/HuXArKPuRc3DV8nd5HgLHajlnawK1T46zCfajFu4q6OdAReAIBNQnMcYaOp3rUQ tIyZV9ByD0mEAyQRMAFIGDNt5EOa04iMFb6kTLNpFHUAIglQz4kVfYQrul9Qed6cHyWF f+ODc/ytUvfyxUAjnMuEsFXX5kkjB6d6TWO5PU6oCxJUksRSiqxjVe+ePHo3pbn24z6E RBUg== X-Received: by 10.68.215.97 with SMTP id oh1mr15931875pbc.67.1439922282249; Tue, 18 Aug 2015 11:24:42 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:d5a2:2855:8297:4b1c? ([2601:647:4204:228b:d5a2:2855:8297:4b1c]) by smtp.googlemail.com with ESMTPSA id kp5sm18896266pdb.57.2015.08.18.11.24.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Aug 2015 11:24:41 -0700 (PDT) To: Steve Donovan , Maria Cruz Bartolome , "dime@ietf.org" References: <087A34937E64E74E848732CFF8354B9218047A22@ESESSMB101.ericsson.se> <55C0B9D2.4080208@usdonovans.com> <087A34937E64E74E848732CFF8354B921804A3FE@ESESSMB101.ericsson.se> <55C280B0.1000807@usdonovans.com> <087A34937E64E74E848732CFF8354B921804B826@ESESSMB101.ericsson.se> <55D36F54.8030302@usdonovans.com> From: Jouni Korhonen Message-ID: <55D37868.2060703@gmail.com> Date: Tue, 18 Aug 2015 11:24:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55D36F54.8030302@usdonovans.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [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: Tue, 18 Aug 2015 18:24:46 -0000 Steve, Changing the I-D name (but keeping the file name) is not a big issue if that brings clarity. I am OK for it if there are more voices for it than just Maria. - Jouni 8/18/2015, 10:45 AM, Steve Donovan kirjoitti: > Maria Cruz, > > I am okay with changing the name of the Agent Overload draft to > something like Diameter Peer Report type if the group feels there is a > need to do so. > > Lionel, > Jouni, > > Please advise on whether or not you think this change is needed. > > Regards, > > Steve > > On 8/10/15 9:55 AM, Maria Cruz Bartolome wrote: >> >> Hello Steve, >> >> If the intention with the now called Diameter Agent Overload draft is >> to cover some more generic use cases I think we should extend the >> title and the scope probably. >> >> Let’s see what others think. >> >> And then in the Rate draft, the definition of anything related to PEER >> reports should be omitted, the right place is the Agent draft. >> >> Best regards >> >> /MCruz >> >> *From:*Steve Donovan [mailto:srdonovan@usdonovans.com] >> *Sent:* miércoles, 05 de agosto de 2015 23:31 >> *To:* Maria Cruz Bartolome; dime@ietf.org >> *Subject:* Re: [Dime] PEER Report with RATE algorithm (Agent Overload >> + Rate Algorithm drafts) >> >> Maria Cruz, >> >> The agent overload draft is defining a new type of overload report -- >> the peer report. While agent overload handling is the primary use >> case for this overload report type, it is not the only. It is better >> to define one generic capability then to partially define it in the >> agent overload draft for one set of use cases and then extend the >> definition in a separate draft for another set of use cases. >> Especially when those two sets of use cases are understood at the time >> of writing. >> >> This is why I added the use case description in section 3.2. >> >> We should define peer report handling as completely as possible in the >> agent overload draft. If the name of the draft is confusing then we >> should consider changing the name of the draft to reflect this. >> >> The rate draft should then focus on the definition of the rate >> algorithm and how it is used in various overload report types. >> >> I'll send a separate response on the question of whether or not a rate >> overload report makes sense in a host report. >> >> Regards, >> >> Steve >> >> On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote: >> >> Hello Steve, >> >> Thanks for your response. >> >> See my comments below >> >> Best regards >> >> /MCruz >> >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve >> Donovan >> *Sent:* martes, 04 de agosto de 2015 15:11 >> *To:* dime@ietf.org >> *Subject:* Re: [Dime] PEER Report with RATE algorithm (Agent >> Overload + Rate Algorithm drafts) >> >> Maria Cruz, >> >> Thank you for the reviews. See my comments inline. >> >> Regards, >> >> Steve >> >> On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote: >> >> 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 reflections as well on the RATE >> draft in this respect. >> >> Therefore my comments affect both >> draft-ietf-dime-doic-rate-controland >> draft-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 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, >> “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 Default 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 and 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. >> >> SRD> I agree that the current writing of the draft is focused on >> the use of the rate algorithm in a peer report. I intentionally >> put the editor's note in the document to make sure that we have >> the discussion on whether or not there is reason to also allow use >> of the rate algorithm in host and realm reports. >> >> SRD> It is, however, not clear to me how rate would be an >> effective overload control mechanism in host reports, at least not >> in the general sense. Any time that a Diameter application allows >> for realm routed requests to be sent by a client it becomes >> impossible for a client to know the rate of requests that will >> arrive at a specific server. I'd like to see some thought put >> into how this would work before indicating support for it in the >> rate draft. >> MCRUZ> I do not understand your concern. A rate of message will be >> ensure in the reacting node either for a particular host or for a >> realm. Could you clarify please? >> >> >> SRD> I agree there may be times that a reporting nodes sends both >> rate and loss reports. I would expect this to be in transition >> periods as an operator turns on rate control. It seems, however, >> more likely that an operator would turn on rate between a >> reporting node and the first hop agents first and, if needed, have >> the agent translate rate OLRs into loss OLRs for reacting nodes >> that do not support rate. >> MCRUZ> Not sure how this is related to the discussion here >> >> 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. >> >> SRD> I don't see why. This is an explanation of how peer might be >> used, not a prescription that it must happen. >> MCRUZ> “this section outlines use cases for the peer report >> feature involving Clients and Servers”. Why is this needed? I >> think the Agent draft should cover only Agent overload use cases, >> nothing else. >> >> 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]. >> >> SRD> This is explicitly referring back to the agent overload >> draft, where, I agree, the behavior is to be defined. >> MCRUZ> then do you agree about removal? >> >> 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 ::= < 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. >> >> SRD> I don't understand what is being proposed but the rate >> algorithm has a dependency on the agent overload draft because at >> least one of the report types it needs to support is peer, and >> peer is defined in the agent overload draft. >> MCRUZ> my point is that what belongs to Agent overload’s draft >> shall be only in Agent overload’s draft. I highlighted paragraphs >> above that belongs to Agent overload’s draft. >> >> 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) 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 >> >> >> >> >> >> _______________________________________________ >> >> DiME mailing list >> >> DiME@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dime >> > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Aug 19 17:27:51 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 5BFD61A8A8C; Wed, 19 Aug 2015 17:27:47 -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 rsKdx5IQCUxd; Wed, 19 Aug 2015 17:27:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3008C1A8A61; Wed, 19 Aug 2015 17:27:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150820002746.21389.11896.idtracker@ietfa.amsl.com> Date: Wed, 19 Aug 2015 17:27:46 -0700 Archived-At: Cc: dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Kathleen Moriarty's No Objection on draft-ietf-dime-ovli-09: (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, 20 Aug 2015 00:27:47 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-dime-ovli-09: 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-ovli/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nice job on the Security Considerations! It would be very nice if end-to-end encryption were supported, but I do appreciate the detail level on the risks/security considerations that were included in the draft. From nobody Wed Aug 19 19:20:54 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 661E61A8F41; Wed, 19 Aug 2015 19:20:51 -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 FMWSoDfQIcOX; Wed, 19 Aug 2015 19:20:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7DE1A86FD; Wed, 19 Aug 2015 19:20:48 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150820022048.5800.35642.idtracker@ietfa.amsl.com> Date: Wed, 19 Aug 2015 19:20:48 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-ovli-10.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: Thu, 20 Aug 2015 02:20:51 -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 Overload Indication Conveyance Authors : Jouni Korhonen Steve Donovan Ben Campbell Lionel Morand Filename : draft-ietf-dime-ovli-10.txt Pages : 40 Date : 2015-08-19 Abstract: This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-ovli-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-10 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 Aug 24 13:59:13 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 940051A8987 for ; Mon, 24 Aug 2015 13:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.68 X-Spam-Level: X-Spam-Status: No, score=0.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, 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 9DPVLEICbsmn for ; Mon, 24 Aug 2015 13:59:09 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 160CB1A88C3 for ; Mon, 24 Aug 2015 13:59:09 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:51430 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZType-0003bS-1Z for dime@ietf.org; Mon, 24 Aug 2015 13:59:08 -0700 To: "dime@ietf.org" From: Steve Donovan Message-ID: <55DB8599.8070101@usdonovans.com> Date: Mon, 24 Aug 2015 15:59:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050403080205020706020008" 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: [Dime] Load mechanism proposal 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, 24 Aug 2015 20:59:11 -0000 This is a multi-part message in MIME format. --------------050403080205020706020008 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit All, Based on the discussion during the DIME meeting in Prague I have updated the Solution Overview and Theory of Operation sections of the Load draft. I have included those two sections below. These sections reflect the agreement that we would support two types of load reports, one for end-points (clients or servers) that travel end-to-end and one for agents that are processed peer-to-peer. If there is agreement with the approach taken below then I will add the normative behavior and AVP sections to the draft. Regards, Steve 5. Solution Overview The mechanism defined here for the conveyance of load information is similar in some says to the mechanism defined for DOIC and is different in other ways. As with DOIC, load information is conveyed by piggy-backing the load AVPs on existing Diameter applications. There are two primary differences. First, there is no capability negotiation process for load. The sender of the load information is sending it with the expectation that any supporting nodes will use it when making routing decisions. If there are no nodes that support the load extension then the load information is ignored. The second big difference between DOIC and Load is visibility of the DOIC or Load information within a Diameter network. DOIC information is sent end-to-end resulting in the ability of all nodes in the path of the answer message that carries the OC-OLR AVP to act on the information. The DOIC overload reports much remain in the message all the way from the reporting node to the node that is the target for the answer message. For the Load mechanism there are two types of load reports. The first is the load of the end-point sending the answering the message. This load report is carried end-to-end to enable any node that make server selection decisions to use the load status of the sending end-point as part of the server selection decision. The second type of load report is a peer report. This report is used by Diameter nodes as part of the logic to select the next hop Diameter node. Because load reports can traverse Diameter nodes that do not support the load mechanism, it is necessary to include the identity of the node to which the load report applies as part of the load report. This allows for a Diameter node to verify that the load report applies to its peer or if it should be ignored. Editor's note: The source-id is really only needed in peer load reports. The identity of the sender of an end-point report can be determined using the Origin-Host AVP in the answer message. As such, the source-id could be made optional for end-point load reports. Campbell, et al. Expires January 2, 2016 [Page 6] Internet-Draft Abbreviated Title July 2015 The load report includes the relative load of the sending node. This relative load is specified in a manner consistent with that defined for DNS SRV [RFC2782]. The method for calculating the load value included in the load report is left as an implementation decision. The frequency for sending of load reports is also left as an implementation decision. The sending node might choose to send load reports in all messages or it might choose to only send load reports when the load value has changed by some implementation specific value. The important consideration is that all nodes needing the load information have a sufficiently accurate view of the nodes load. 5.1. Theory of Operation This section outlines how the Diameter load mechanism is expected to work. For this discussion, assume the following Diameter network configuration: ---A1---A3----S[1], S[2]...S[p] / | \ / C | x \ | / \ ---A2---A4----S[p+1], S[p+2] ...S[n] Figure 1: Example Diameter Network Also assume that the request for a Diameter transaction takes the following path: C A1 A4 S[n] | | | | |----->|----->|----->| xxR xxR xxR Figure 2: Request Message Path When sending the answer message, an end-point node that supports the Diameter Load mechanism includes it's own load information in the answer message. Because it is a Diameter end-point it includes an end-point load report. Campbell, et al. Expires January 2, 2016 [Page 7] Internet-Draft Abbreviated Title July 2015 C A1 A4 S[n] | | | | | | |<-----| | | xxA(Load type:ep, source:S[n]) | | | | Figure 3: Answer Message from S[n] If Agent A4 supports the Load mechanism then it will verify that the load information received was from its peer. This is achieved by matching the identity included in the load information with the identity of the peer node from which the answer message was received. Note: If A4 does not support the load mechanism then it will relay the answer message without doing any processing on the load information. In this case the load AVPs will be relayed without change. If the identity included in the load information AVPs matches the identity of the peer from which the load information is received then Agent A4 stores the load information for S[n] in its routing tables. Because the load report is an end-point load report, A4 leaves the load report in the message it relays. A4 then calculates its own load information and inserts load information AVPs in the message before sending the message to A1: C A1 A4 S[n] | | | | | |<-----| | | xxA(Load type:peer, source:A4) | xxA(Load type:ep, source:S[n]) | | | | Figure 4: Answer Message from A4 If A1 supports the Load mechanism then it processes each of the Load reports it receives separately. For the peer load report, A1 first determines if the source of the report indicated in the load report matches the DiameterID of the Diameter node from which the request was received. If the identities do not match then the peer load report is discarded. If the identities match then A1 saves the load information in its routing Campbell, et al. Expires January 2, 2016 [Page 8] Internet-Draft Abbreviated Title July 2015 tables for routing of subsequent request messages. In both cases A1 strips the peer load report from the message. For the end-point load report, A1's actions depend on whether A1 is responsible for doing server selection. If not then A1 ignores the end-poind load report. If A1 is responsible for doing server selection then it stores the load information for S[n] in its routing tables for the handling of subsequent request messages. In both cases A1 leaves the end-point report in the message. A1 then calculates its own load information and inserts load information AVPs in the message before sending the message to A1: C A1 A4 S[n] | | | | |<-----| | | xxA(Load type:peer, source:A1) xxA(Load type:ep, source:S[n]) Figure 5: Answer Message from A1 As with A1, C processes each load report separately. For the peer load report, C follows the same procedure for determining if the Load report was received from the peer from which the report was sent and, when finding it does, stores the load information for use when making future routing decisions. For the end-point load report, C saves the load information only if it is responsible for doing server selection. The Load information received by all nodes is then used for routing of subsequent request messages. --------------050403080205020706020008 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit All,

Based on the discussion during the DIME meeting in Prague I have updated the Solution Overview and Theory of Operation sections of the Load draft.  I have included those two sections below.

These sections reflect the agreement that we would support two types of load reports, one for end-points (clients or servers) that travel end-to-end and one for agents that are processed peer-to-peer.

If there is agreement with the approach taken below then I will add the normative behavior and AVP sections to the draft.

Regards,

Steve
5.  Solution Overview

   The mechanism defined here for the conveyance of load information is
   similar in some says to the mechanism defined for DOIC and is
   different in other ways.

   As with DOIC, load information is conveyed by piggy-backing the load
   AVPs on existing Diameter applications.

   There are two primary differences.  First, there is no capability
   negotiation process for load.  The sender of the load information is
   sending it with the expectation that any supporting nodes will use it
   when making routing decisions.  If there are no nodes that support
   the load extension then the load information is ignored.

   The second big difference between DOIC and Load is visibility of the
   DOIC or Load information within a Diameter network.  DOIC information
   is sent end-to-end resulting in the ability of all nodes in the path
   of the answer message that carries the OC-OLR AVP to act on the
   information.  The DOIC overload reports much remain in the message
   all the way from the reporting node to the node that is the target
   for the answer message.

   For the Load mechanism there are two types of load reports.

   The first is the load of the end-point sending the answering the
   message.  This load report is carried end-to-end to enable any node
   that make server selection decisions to use the load status of the
   sending end-point as part of the server selection decision.

   The second type of load report is a peer report.  This report is used
   by Diameter nodes as part of the logic to select the next hop
   Diameter node.

   Because load reports can traverse Diameter nodes that do not support
   the load mechanism, it is necessary to include the identity of the
   node to which the load report applies as part of the load report.
   This allows for a Diameter node to verify that the load report
   applies to its peer or if it should be ignored.

      Editor's note: The source-id is really only needed in peer load
      reports.  The identity of the sender of an end-point report can be
      determined using the Origin-Host AVP in the answer message.  As
      such, the source-id could be made optional for end-point load
      reports.



Campbell, et al.         Expires January 2, 2016                [Page 6]

Internet-Draft              Abbreviated Title                  July 2015


   The load report includes the relative load of the sending node.  This
   relative load is specified in a manner consistent with that defined
   for DNS SRV [RFC2782].

   The method for calculating the load value included in the load report
   is left as an implementation decision.

   The frequency for sending of load reports is also left as an
   implementation decision.  The sending node might choose to send load
   reports in all messages or it might choose to only send load reports
   when the load value has changed by some implementation specific
   value.  The important consideration is that all nodes needing the
   load information have a sufficiently accurate view of the nodes load.

5.1.  Theory of Operation

   This section outlines how the Diameter load mechanism is expected to
   work.

   For this discussion, assume the following Diameter network
   configuration:

           ---A1---A3----S[1], S[2]...S[p]
          /   | \ /
         C    |  x
          \   | / \
           ---A2---A4----S[p+1], S[p+2] ...S[n]


                    Figure 1: Example Diameter Network

   Also assume that the request for a Diameter transaction takes the
   following path:

         C     A1     A4     S[n]
         |      |      |      |
         |----->|----->|----->|
         xxR     xxR    xxR



                      Figure 2: Request Message Path

   When sending the answer message, an end-point node that supports the
   Diameter Load mechanism includes it's own load information in the
   answer message.  Because it is a Diameter end-point it includes an
   end-point load report.




Campbell, et al.         Expires January 2, 2016                [Page 7]

Internet-Draft              Abbreviated Title                  July 2015


         C     A1     A4     S[n]
         |      |      |      |
         |      |      |<-----|
         |      |       xxA(Load type:ep, source:S[n])
         |      |      |      |


                    Figure 3: Answer Message from S[n]

   If Agent A4 supports the Load mechanism then it will verify that the
   load information received was from its peer.  This is achieved by
   matching the identity included in the load information with the
   identity of the peer node from which the answer message was received.

      Note: If A4 does not support the load mechanism then it will relay
      the answer message without doing any processing on the load
      information.  In this case the load AVPs will be relayed without
      change.

   If the identity included in the load information AVPs matches the
   identity of the peer from which the load information is received then
   Agent A4 stores the load information for S[n] in its routing tables.

   Because the load report is an end-point load report, A4 leaves the
   load report in the message it relays.

   A4 then calculates its own load information and inserts load
   information AVPs in the message before sending the message to A1:

         C     A1     A4     S[n]
         |      |      |      |
         |      |<-----|      |
         |       xxA(Load type:peer, source:A4)
         |       xxA(Load type:ep, source:S[n])
         |      |      |      |


                     Figure 4: Answer Message from A4

   If A1 supports the Load mechanism then it processes each of the Load
   reports it receives separately.

   For the peer load report, A1 first determines if the source of the
   report indicated in the load report matches the DiameterID of the
   Diameter node from which the request was received.  If the identities
   do not match then the peer load report is discarded.  If the
   identities match then A1 saves the load information in its routing




Campbell, et al.         Expires January 2, 2016                [Page 8]

Internet-Draft              Abbreviated Title                  July 2015


   tables for routing of subsequent request messages.  In both cases A1
   strips the peer load report from the message.

   For the end-point load report, A1's actions depend on whether A1 is
   responsible for doing server selection.  If not then A1 ignores the
   end-poind load report.  If A1 is responsible for doing server
   selection then it stores the load information for S[n] in its routing
   tables for the handling of subsequent request messages.  In both
   cases A1 leaves the end-point report in the message.

   A1 then calculates its own load information and inserts load
   information AVPs in the message before sending the message to A1:

         C     A1     A4     S[n]
         |      |      |      |
         |<-----|      |      |
          xxA(Load type:peer, source:A1)
          xxA(Load type:ep, source:S[n])


                     Figure 5: Answer Message from A1

   As with A1, C processes each load report separately.

   For the peer load report, C follows the same procedure for
   determining if the Load report was received from the peer from which
   the report was sent and, when finding it does, stores the load
   information for use when making future routing decisions.

   For the end-point load report, C saves the load information only if
   it is responsible for doing server selection.

   The Load information received by all nodes is then used for routing
   of subsequent request messages.

--------------050403080205020706020008-- From nobody Wed Aug 26 00:31:48 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 B067B1A00B9 for ; Wed, 26 Aug 2015 00:31:46 -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 C90X9Imhr3Fr for ; Wed, 26 Aug 2015 00:31:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195471ACDA0 for ; Wed, 26 Aug 2015 00:31:45 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 350EC190258 for ; Wed, 26 Aug 2015 09:31:43 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 0DF3415804E for ; Wed, 26 Aug 2015 09:31:40 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0248.002; Wed, 26 Aug 2015 09:31:39 +0200 From: To: "dime@ietf.org" Thread-Topic: sequence number warp-around detection in draft-ietf-dime-ovli Thread-Index: AdDf0Swp0587cHK9Qje1GMJDjEGTeQ== Date: Wed, 26 Aug 2015 07:31:38 +0000 Message-ID: <5973_1440574300_55DD6B5C_5973_14978_1_6B7134B31289DC4FAF731D844122B36E01CF3C3D@OPEXCLILM43.corporate.adroot.infra.ftgroup> 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="us-ascii" 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.8.26.64515 Archived-At: Subject: [Dime] sequence number warp-around detection in draft-ietf-dime-ovli X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 07:31:46 -0000 Hi, The draft draft-ietf-dime-ovli has been approved by IESG but a final commen= t needs to be taken into account before publication. About the sequence number wrap-around detection, it is said in section 5.2.= 1.3: If the reacting node determines that the sequence number has rolled over then the reacting node MUST update the matching OCS entry. This can be determined by recognizing that the number has changed from something close to the maximum value in the OC-Sequence-Number AVP to something close to the minimum value in the OC-Sequence-Number AVP.=20 It was commented that "something close to" could be more explicit/predictiv= e. Steve has proposed the following clarification: If the reacting node determines that the sequence number has rolled over then the reacting node MUST update the matching OCS entry. This can be determined by recognizing that the number has changed from a value within 1% of the maximum value in the OC-Sequence-Number AVP to a value within 1% of the minimum value in the OC-Sequence-Number AVP. could you please confirm that the proposed clarification is acceptable? regards, Lionel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Aug 26 16:52:43 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 DA5321B33C7 for ; Wed, 26 Aug 2015 16:52:42 -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 JkDFD-2GphCk for ; Wed, 26 Aug 2015 16:52:39 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 73CD31A8A3D for ; Wed, 26 Aug 2015 16:52:39 -0700 (PDT) Received: by pacdd16 with SMTP id dd16so3597696pac.2 for ; Wed, 26 Aug 2015 16:52:39 -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=slwm8dMRZW1YNvDXCIRGV884/SKdBp/d2USb5kUmyLE=; b=iQEmTqnucUKH1iK2RbXTuiS/R4IOMOPmY0Cl+NYLDmMH9lkrpOsDW8ARhsou0FDbdO olQpTNXtxWeWLutnH0uLkyFbRwT0TSJB5wEbGoYo6bo4yBeyEUO+2DWIMYNljzrdVVmv DBYQW/facN4yDjQntEZ9l0rarTL9dQl1tG9fOvJZ9Ah4yVoM+0Pv60lPu5/CWrFbbYXX Q0OhUnJrxEYmuvQtvnFzIM+19kOG4o/HvxokLtmqUm8hcdDXtsf56iRhy4/ZGpaFFsqQ iMktGKLFm4g61GqGGH+fj3WJjtXVEtPs7Xg+6Bw2meM5q/e8DbQc3R/C2K2fedA0TzhX gLoA== X-Received: by 10.66.252.72 with SMTP id zq8mr1943430pac.7.1440633159103; Wed, 26 Aug 2015 16:52:39 -0700 (PDT) Received: from [10.16.10.239] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id r6sm195946pdj.39.2015.08.26.16.52.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Aug 2015 16:52:37 -0700 (PDT) To: lionel.morand@orange.com, "dime@ietf.org" References: <5973_1440574300_55DD6B5C_5973_14978_1_6B7134B31289DC4FAF731D844122B36E01CF3C3D@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Jouni Korhonen Message-ID: <55DE5144.6000903@gmail.com> Date: Wed, 26 Aug 2015 16:52:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5973_1440574300_55DD6B5C_5973_14978_1_6B7134B31289DC4FAF731D844122B36E01CF3C3D@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] sequence number warp-around detection in draft-ietf-dime-ovli X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 23:52:43 -0000 While I do not really see the necessity for this clarification I am _OK_ with the proposed text change. - Jouni 8/26/2015, 12:31 AM, lionel.morand@orange.com kirjoitti: > Hi, > > The draft draft-ietf-dime-ovli has been approved by IESG but a final comment needs to be taken into account before publication. > > About the sequence number wrap-around detection, it is said in section 5.2.1.3: > > If the reacting node determines that the sequence number has rolled > over then the reacting node MUST update the matching OCS entry. This > can be determined by recognizing that the number has changed from > something close to the maximum value in the OC-Sequence-Number AVP to > something close to the minimum value in the OC-Sequence-Number AVP. > > It was commented that "something close to" could be more explicit/predictive. > > Steve has proposed the following clarification: > > If the reacting node determines that the sequence number has rolled > over then the reacting node MUST update the matching OCS entry. This > can be determined by recognizing that the number has changed from > a value within 1% of the maximum value in the OC-Sequence-Number AVP to > a value within 1% of the minimum value in the OC-Sequence-Number AVP. > > could you please confirm that the proposed clarification is acceptable? > > regards, > > Lionel > > _________________________________________________________________________________________________________________________ > > 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 Thu Aug 27 06:42:54 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 313DD1B2B10 for ; Thu, 27 Aug 2015 06:42:52 -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 s8vitJvIMYPu for ; Thu, 27 Aug 2015 06:42:50 -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 57B7D1B3B40 for ; Thu, 27 Aug 2015 06:42:50 -0700 (PDT) Received: from mutabilis-2.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7RDgmI0093278 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 27 Aug 2015 08:42:49 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be mutabilis-2.local To: dime@ietf.org References: <5973_1440574300_55DD6B5C_5973_14978_1_6B7134B31289DC4FAF731D844122B36E01CF3C3D@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55DE5144.6000903@gmail.com> From: "A. Jean Mahoney" Message-ID: <55DF13D2.8010500@nostrum.com> Date: Thu, 27 Aug 2015 08:42:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DE5144.6000903@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] sequence number warp-around detection in draft-ietf-dime-ovli 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, 27 Aug 2015 13:42:52 -0000 Same here. I'm ok with the change. Jean On 8/26/15 6:52 PM, Jouni Korhonen wrote: > > While I do not really see the necessity for this clarification I am > _OK_ with the proposed text change. > > - Jouni > > 8/26/2015, 12:31 AM, lionel.morand@orange.com kirjoitti: >> Hi, >> >> The draft draft-ietf-dime-ovli has been approved by IESG but a final >> comment needs to be taken into account before publication. >> >> About the sequence number wrap-around detection, it is said in >> section 5.2.1.3: >> >> If the reacting node determines that the sequence number has rolled >> over then the reacting node MUST update the matching OCS entry. >> This >> can be determined by recognizing that the number has changed from >> something close to the maximum value in the OC-Sequence-Number >> AVP to >> something close to the minimum value in the OC-Sequence-Number AVP. >> >> It was commented that "something close to" could be more >> explicit/predictive. >> >> Steve has proposed the following clarification: >> >> If the reacting node determines that the sequence number has rolled >> over then the reacting node MUST update the matching OCS entry. >> This >> can be determined by recognizing that the number has changed from >> a value within 1% of the maximum value in the OC-Sequence-Number >> AVP to >> a value within 1% of the minimum value in the OC-Sequence-Number >> AVP. >> >> could you please confirm that the proposed clarification is acceptable? >> >> regards, >> >> Lionel >> >> _________________________________________________________________________________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous >> avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, >> deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender >> and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Aug 27 06:53:03 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 E1EA81A024C for ; Thu, 27 Aug 2015 06:53:01 -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 nrFudUCnModf for ; Thu, 27 Aug 2015 06:53:00 -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 208941ACD11 for ; Thu, 27 Aug 2015 06:52:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E7D44BEA4; Thu, 27 Aug 2015 14:52: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 K1Cj0B5cHfai; Thu, 27 Aug 2015 14:52: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 75592BE8F; Thu, 27 Aug 2015 14:52:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440683549; bh=xRhU/nvjdH+RZSPU3Ib58451/IeVWRB4QiMfXAA9qTs=; h=Date:From:To:Subject:References:In-Reply-To:From; b=4dn7wK07pyWNZuUq1ESSUxKNIZBE4RTzxqnLmidBJr0ttPzEo/9oJYyG9TP9dZwKH yRsCpFhGs1PRqCnqFi2PV5+ISBMucsBvGoxBRQDx40YH2zbKMXRWIrIAFfsjSJb9Gk Jy426lAa9gOBAcehLiruKkMut8qR3yTvzq7Mh1u0= Message-ID: <55DF161D.4050500@cs.tcd.ie> Date: Thu, 27 Aug 2015 14:52:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "A. Jean Mahoney" , dime@ietf.org References: <5973_1440574300_55DD6B5C_5973_14978_1_6B7134B31289DC4FAF731D844122B36E01CF3C3D@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55DE5144.6000903@gmail.com> <55DF13D2.8010500@nostrum.com> In-Reply-To: <55DF13D2.8010500@nostrum.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] sequence number warp-around detection in draft-ietf-dime-ovli 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, 27 Aug 2015 13:53:02 -0000 Great. I've added an RFC editor note to that effect [1] so there's no need to submit a new version. If nobody objects by the end of tomorrow, I'll send the approval announcement and the RFC editors will make the change as they are processing this one. Thanks, S. [1] https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/writeup/ On 27/08/15 14:42, A. Jean Mahoney wrote: > Same here. I'm ok with the change. > > Jean > > On 8/26/15 6:52 PM, Jouni Korhonen wrote: >> >> While I do not really see the necessity for this clarification I am >> _OK_ with the proposed text change. >> >> - Jouni >> >> 8/26/2015, 12:31 AM, lionel.morand@orange.com kirjoitti: >>> Hi, >>> >>> The draft draft-ietf-dime-ovli has been approved by IESG but a final >>> comment needs to be taken into account before publication. >>> >>> About the sequence number wrap-around detection, it is said in >>> section 5.2.1.3: >>> >>> If the reacting node determines that the sequence number has rolled >>> over then the reacting node MUST update the matching OCS entry. >>> This >>> can be determined by recognizing that the number has changed from >>> something close to the maximum value in the OC-Sequence-Number >>> AVP to >>> something close to the minimum value in the OC-Sequence-Number AVP. >>> >>> It was commented that "something close to" could be more >>> explicit/predictive. >>> >>> Steve has proposed the following clarification: >>> >>> If the reacting node determines that the sequence number has rolled >>> over then the reacting node MUST update the matching OCS entry. >>> This >>> can be determined by recognizing that the number has changed from >>> a value within 1% of the maximum value in the OC-Sequence-Number >>> AVP to >>> a value within 1% of the minimum value in the OC-Sequence-Number >>> AVP. >>> >>> could you please confirm that the proposed clarification is acceptable? >>> >>> regards, >>> >>> Lionel >>> >>> _________________________________________________________________________________________________________________________ >>> >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >>> avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>> messages electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, >>> deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender >>> and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have >>> been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From nobody Thu Aug 27 06:59:51 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 05DE61B3860 for ; Thu, 27 Aug 2015 06:59:49 -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 ijeWesBuSb1E for ; Thu, 27 Aug 2015 06:59:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4112D1B3C2A for ; Thu, 27 Aug 2015 06:59:45 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id D985A3748D1; Thu, 27 Aug 2015 15:59:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id AFF3215807F; Thu, 27 Aug 2015 15:59:42 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 15:59:42 +0200 From: To: Stephen Farrell , "A. Jean Mahoney" , "dime@ietf.org" Thread-Topic: [Dime] sequence number warp-around detection in draft-ietf-dime-ovli Thread-Index: AdDf0Swp0587cHK9Qje1GMJDjEGTeQAeFiwAABz9rAAAAFd5gAAEb3Iw Date: Thu, 27 Aug 2015 13:59:41 +0000 Message-ID: <1481_1440683982_55DF17CE_1481_15602_1_6B7134B31289DC4FAF731D844122B36E01CFEA05@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <5973_1440574300_55DD6B5C_5973_14978_1_6B7134B31289DC4FAF731D844122B36E01CF3C3D@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55DE5144.6000903@gmail.com> <55DF13D2.8010500@nostrum.com> <55DF161D.4050500@cs.tcd.ie> In-Reply-To: <55DF161D.4050500@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.3] 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.8.27.125715 Archived-At: Subject: Re: [Dime] sequence number warp-around detection in draft-ietf-dime-ovli 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, 27 Aug 2015 13:59:49 -0000 Thank you, Stephen. -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Stephen Farrell Envoy=E9=A0: jeudi 27 ao=FBt 2015 15:52 =C0=A0: A. Jean Mahoney; dime@ietf.org Objet=A0: Re: [Dime] sequence number warp-around detection in draft-ietf-di= me-ovli Great. I've added an RFC editor note to that effect [1] so there's no need = to submit a new version. If nobody objects by the end of tomorrow, I'll send the approval announceme= nt and the RFC editors will make the change as they are processing this one. Thanks, S. [1] https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/writeup/ On 27/08/15 14:42, A. Jean Mahoney wrote: > Same here. I'm ok with the change. >=20 > Jean >=20 > On 8/26/15 6:52 PM, Jouni Korhonen wrote: >> >> While I do not really see the necessity for this clarification I am=20 >> _OK_ with the proposed text change. >> >> - Jouni >> >> 8/26/2015, 12:31 AM, lionel.morand@orange.com kirjoitti: >>> Hi, >>> >>> The draft draft-ietf-dime-ovli has been approved by IESG but a final=20 >>> comment needs to be taken into account before publication. >>> >>> About the sequence number wrap-around detection, it is said in=20 >>> section 5.2.1.3: >>> >>> If the reacting node determines that the sequence number has rolled >>> over then the reacting node MUST update the matching OCS entry.=20 >>> This >>> can be determined by recognizing that the number has changed from >>> something close to the maximum value in the OC-Sequence-Number=20 >>> AVP to >>> something close to the minimum value in the OC-Sequence-Number AVP. >>> >>> It was commented that "something close to" could be more=20 >>> explicit/predictive. >>> >>> Steve has proposed the following clarification: >>> >>> If the reacting node determines that the sequence number has rolled >>> over then the reacting node MUST update the matching OCS entry. >>> This >>> can be determined by recognizing that the number has changed from >>> a value within 1% of the maximum value in the=20 >>> OC-Sequence-Number AVP to >>> a value within 1% of the minimum value in the=20 >>> OC-Sequence-Number AVP. >>> >>> could you please confirm that the proposed clarification is acceptable? >>> >>> regards, >>> >>> Lionel >>> >>> ____________________________________________________________________ >>> _____________________________________________________ >>> >>> >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>> detruire ainsi que les pieces jointes. Les messages electroniques=20 >>> etant susceptibles d'alteration, Orange decline toute responsabilite=20 >>> si ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> privileged information that may be protected by law; they should not=20 >>> be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender=20 >>> and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that=20 >>> have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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 Fri Aug 28 08:02: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 8205B1A8745; Fri, 28 Aug 2015 08:02:36 -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 VQlJbHpRVKk6; Fri, 28 Aug 2015 08:02:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6FB1B352F; Fri, 28 Aug 2015 08:02:31 -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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150828150231.29424.69059.idtracker@ietfa.amsl.com> Date: Fri, 28 Aug 2015 08:02:31 -0700 Archived-At: Cc: dime chair , dime mailing list , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Overload Indication Conveyance' to Proposed Standard (draft-ietf-dime-ovli-10.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 15:02:36 -0000 The IESG has approved the following document: - 'Diameter Overload Indication Conveyance' (draft-ietf-dime-ovli-10.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Stephen Farrell, Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ Technical Summary The document defines a solution for Diameter Overload Indication Conveyance. (DOIC) Working Group Summary The document had a long process of working group review. It has achieved consensus in the WG. As both WG chairs are co-authors the AD made an additional 1-week call for comments on or off-list in case there were any concerns about evaluating rough consensus. There were no concerns expressed either on or off list. Document Quality The document has not been implemented, as multiple vendors were waiting for IANA assignment of code points. We expect no issues with implementation. Multiple vendors have stated that they plan on implementing it. The 3GPP forum is waiting on this document. Personnel The document Shepherd is Alan DeKok. The responsible area director is Stephen Farrell. RFC Editor Note In section 5.2.1.3 please replace one paragraph as follows: OLD If the reacting node determines that the sequence number has rolled over then the reacting node MUST update the matching OCS entry. This can be determined by recognizing that the number has changed from something close to the maximum value in the OC-Sequence-Number AVP to something close to the minimum value in the OC-Sequence-Number AVP. NEW: If the reacting node determines that the sequence number has rolled over then the reacting node MUST update the matching OCS entry. This can be determined by recognizing that the number has changed from a value within 1% of the maximum value in the OC-Sequence-Number AVP to a value within 1% of the minimum value in the OC-Sequence-Number AVP. From nobody Mon Aug 31 08:26: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 6E53A1B5016; Mon, 31 Aug 2015 08:26:05 -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 qKE5mJQcsN35; Mon, 31 Aug 2015 08:26:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FD31B4FB2; Mon, 31 Aug 2015 08:25:18 -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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150831152518.13599.59456.idtracker@ietfa.amsl.com> Date: Mon, 31 Aug 2015 08:25:18 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-agent-overload-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: Mon, 31 Aug 2015 15:26:05 -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 Agent Overload Author : Steve Donovan Filename : draft-ietf-dime-agent-overload-02.txt Pages : 19 Date : 2015-08-31 Abstract: This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution. The extension addresses the handling of occurrences of overload of a Diameter agent, or more generally, a Diameter peer. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-agent-overload-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-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 Mon Aug 31 08:26:52 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 A0B8B1B50A8; Mon, 31 Aug 2015 08:26:50 -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 L8nfZZlzaEmb; Mon, 31 Aug 2015 08:26:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5582B1B40BA; Mon, 31 Aug 2015 08:25:32 -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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150831152532.18034.46987.idtracker@ietfa.amsl.com> Date: Mon, 31 Aug 2015 08:25:32 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-doic-rate-control-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: Mon, 31 Aug 2015 15:26:50 -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 Overload Rate Control Authors : Steve Donovan Eric Noel Filename : draft-ietf-dime-doic-rate-control-02.txt Pages : 20 Date : 2015-08-31 Abstract: This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution. This extension adds a new overload control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-doic-rate-control-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-doic-rate-control-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 Mon Aug 31 09:54: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 DDE151B3C28 for ; Mon, 31 Aug 2015 09:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-8kb9gPMy7E for ; Mon, 31 Aug 2015 09:54:54 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 303481B5851 for ; Mon, 31 Aug 2015 09:54:54 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:56396 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZWSM6-0006s5-7k for dime@ietf.org; Mon, 31 Aug 2015 09:54:53 -0700 To: "dime@ietf.org" From: Steve Donovan Message-ID: <55E486D9.6090309@usdonovans.com> Date: Mon, 31 Aug 2015 11:54:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: [Dime] New versions of Agent Overload and Rate 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: Mon, 31 Aug 2015 16:54:55 -0000 All, I refreshed these two drafts to keep them from expiring. The date and version number are the only changes. Regards, Steve