Re: [Dime] DOIC: Self-Contained OLRs

"Shishufeng (Susan)" <susan.shishufeng@huawei.com> Mon, 09 December 2013 09:51 UTC

Return-Path: <susan.shishufeng@huawei.com>
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 27DA11A1F48 for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 01:51:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level:
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 467xOf3jjH5X for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 01:51:23 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E3BD71ADBF7 for <dime@ietf.org>; Mon, 9 Dec 2013 01:51:20 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD89710; Mon, 09 Dec 2013 09:51:15 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 09:51:09 +0000
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 09:51:12 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 17:51:04 +0800
From: "Shishufeng (Susan)" <susan.shishufeng@huawei.com>
To: "Nirav Salot (nsalot)" <nsalot@cisco.com>, Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO8cJSot3HeYq6iU+vru+Aq+dgEZpLoYvQ
Date: Mon, 9 Dec 2013 09:51:03 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1C7D8@SZXEMA512-MBX.china.huawei.com>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <A9CA33BB78081F478946E4F34BF9AAA014D1F867@xmb-rcd-x10.cisco.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CA930.4030006@usdonovans.com> <13482_1386001111_529CB2D7_13482_11387_1_6B7134B31289DC4FAF731D844122B36E311068@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AB88923-E019-4EAF-9512-E677D5798DB3@nostrum.com> <17146_1386112679_529E66A7_17146_16391_1_6B7134B31289DC4FAF731D844122B36E31A900@PEXCVZYM11.corporate.adroot.infra.ftgroup> <C86346CB-2D05-44C1-8ED6-2ABB15711671@nostrum.com> <E194C2E18676714DACA9C3A2516265D201CB3EC6@FR712WXCHMBA12.zeu.alcatel-lucent.com> <52A07A1E.5060502@usdonovans.com> <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52A084FA.7000803@usdonovans.com> <A9CA33BB78081F478946E4F34BF9AAA014D258B1@xmb-rcd-x10.cisco.com>
In-Reply-To: <A9CA33BB78081F478946E4F34BF9AAA014D258B1@xmb-rcd-x10.cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C1C7D8SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [Dime] DOIC: Self-Contained OLRs
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 09:51:37 -0000

Hello all,

I'm trying to follow up all these discussions.


Firstly quick answer to Steve's following question, "Strongly No" to have self-contained OC-OLR. Apart from that I agree with the arguments from Nirav and Lionel, it is not needed anyway at this stage. Extension is allowed and can be defined if needed in the future. I don't even see the need to have the report-type for 3GPP applications usage if considering the realm in 3GPP is with PLMN granularity, but I'm not going to kick off again the discussion on it. I could live with it as an optional AVP and the OC-OLR applies to the Origin-Host of the Answer when the report type is absent, exactly as what Lionel suggested.



I'll come up with other threads.

Best Regards,
Susan

From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: Thursday, December 05, 2013 10:00 PM
To: Steve Donovan; dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Steve,

> If we are to pose a question at this point I would suggest -- Can everyone live with self-contained overload reports?
Strongly NO.

I can make the same arguments as you are making - "I have yet to see a single STRONG argument to justify the use of self-contained OC-OLR".

All the arguments related to software layering, easy for the developers etc. are very specific to the implementation and I don't agree to define protocol solution suitable to a specific architecture.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 7:22 PM
To: dime@ietf.org<mailto:dime@ietf.org>
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Lionel,

I strongly disagree with your conclusion that there is little support for self-contained OLRs.

I also object to your assessment that there are strong arguments against self-contained reports.  I have yet to see a single STRONG argument.

I also object to your attempting to call the question at this point in the discussion.

The only arguments I see for the implicit approach is complexity, which I just sent an email refuting and schedule, about which I also just sent an email.

Self contained reports work just as well and has advantages both short term in support for non application specific software layering and in the long term in allowing for the same overload report to be transported using multiple DOC solutions.

I also don't agree that this has been a particularly long thread.  There are multiple topics being discussed under the same subject line.

If we are to pose a question at this point I would suggest -- Can everyone live with self-contained overload reports?

Steve
On 12/5/13 7:28 AM, lionel.morand@orange.com<mailto:lionel.morand@orange.com> wrote:
All,

After this LONG thread, it seems that there are strong arguments against the self-contained OLRs and little support.
In the contrary, it seems that the principle of OLR related to the application in use is technically OK for everyone.

So the question is quite simple:

Could everyone live/survive with the "implicit approach" with the extensibility mechanism allowing future extensions if needed?

If yes, please focus on the finalization of the current draft.
If no, let go on the discussion.

Regards,

Lionel


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 14:06
À : dime@ietf.org<mailto:dime@ietf.org>
Objet : Re: [Dime] DOIC: Self-Contained OLRs

On the schedule question mentioned by JJacques -- any schedule concerns can go away if everyone agrees to self contained overload reports.  This discussion would end and we could move on to other things.  :-)

I say that somewhat in jest but please don't make the argument that this discussion should be ended because of schedule.  Or if you make that argument, please don't assert that the person who disagrees with you is putting the schedule at risk.

We are striving for the best technical solution.  We all understand the schedule pressures.  We need to balance the two.

Steve
On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:

Hi



A lot of mails on this topic...I would suggest to introduce an overload control on the Dime email threads:)





On my side, I rely on what we have written in the  draft for the "baseline" mechanism and that we have to keep as it is simple and efficient, here I join Lionel, Nirav and MCruz' positions.



This thread then addresses extensions  cases, I agree that we will have to address such extensions:   Nirav mentioned the example with APN that if relevant would  a 3GGP application case, I would add the Session Group about which we had some discussion a while ago and  which is a more generic IETF case. There is also the agent overload case. Have you others? Always good to have some use cases in mind.



What is important for me is that adding extensions should not modify the baseline and making it more complex when used alone.  I also make a difference between principles and protocol tuning where we may have to choose between various protocol solution but addressing the same functionality or principle.



About piggybacking, in the baseline,  the principle is that OLRs  which  are addressed  to sources of traffic are put in answer messages towards this traffic sources (origin Host) (even if these messages  may be processed by intermediate DAs), which is simple and the OLR can be kept unchanged in the same message  up to the origin Host if no specific process in intermediate DAs.  To have a piggybacking allowing to put any OLR in any message (as it was in draft roach)  is adding complexity that is not justified for the baseline and we have not retained it in the existing draft .



About extensions, the APN or session group  examples address  parts of the traffic between a server and a client (so a higher granularity in the throttling than the baseline one), related OLRs are conveyed in the messages towards the origin Host so with an implicit reference to the Application, the  Origin and Destination Host as for the baseline, so not requiring self contained OLRs. I also  do not see the interest to send these new extensions OLR only in answers directly related to this OLR (as Ulrich proposed), eg only in an answer dealing with an APN if the OLR is related to APN throttling.  The main point is that the OLR takes a direct "train" towards the right destination for a given application (as for baseline).



This does not exclude that we may have other cases not entering the above examples characteristics, but as Nirav mentioned, we  have to remain pragmatic and see this when such new use cases will be addressed. The extensibility possibilities of  current draft give us a lot of flexibility, e.g. if some extensions need more self contained AVPs, why not, but this is outside the current draft.



About extensions, I also think that they may need to be identified in the capability part, as the related OLRs should not be sent by a reacting node if the extension is not supported.



Last important point, as  Lionel mentioned, we have to finalize the draft soon, to be able to start Rel12 3GGP work relying on this draft. My position is that the current draft is currently well suited for the baseline and that extensions will be addressed separately



Best regards



JJacques





-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell

Envoyé : mercredi 4 décembre 2013 22:55

À : ext lionel.morand@orange.com<mailto:lionel.morand@orange.com>

Cc : dime@ietf.org<mailto:dime@ietf.org>

Objet : Re: [Dime] DOIC: Self-Contained OLRs



On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com<mailto:lionel.morand@orange.com> wrote:



Hi Ben,



I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious.



We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs.



I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs?



And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements.





It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise.



This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.)





Regards,



Lionel



-----Message d'origine-----

De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre

2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org<mailto:dime@ietf.org>

Objet : Re: [Dime] DOIC: Self-Contained OLRs





On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com<mailto:lionel.morand@orange.com> wrote:



Hi Steve,



I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far:

·         the current need is for an OLR bound to the application in use

·         the OLR is received from the node targeted in the request.

·         the OLR is defined per application



I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs?



All I see from these are restrictions in the flexibility of the solution, with very little in return.



So all the implicit information (application, origin-host, origin-realm) are meaningful in this context.

And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us.



Regards,



Lionel



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

Envoyé : lundi 2 décembre 2013 16:37

À : dime@ietf.org<mailto:dime@ietf.org>

Objet : Re: [Dime] DOIC: Self-Contained OLRs



I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism.  Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism.



I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex.  And what do we gain from this optimization?  A few bites in answer messages.



Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution.



Steve



On 11/29/13 8:31 AM, lionel.morand@orange.com<mailto:lionel.morand@orange.com> wrote:

I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction".



Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism.



Regards,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)

Envoyé : vendredi 29 novembre 2013 12:24

À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org<mailto:dime@ietf.org> list

Cc : Ben Campbell

Objet : Re: [Dime] DOIC: Self-Contained OLRs



Jouni, Ben,



I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.

Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).



Besides, I am not convinced with the other reasons provided here:

- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info

  Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.

  In summary, it is node's internal software design issue and we need not optimize that at protocol level.



- Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR

 What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?

 So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.



- The agent needs to wait for the answer generated by the server and the right context

  The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.

  Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.



- For sending OC-OLR in dedicated Diameter application???

 Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.



Regards,

Nirav.



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

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen

Sent: Friday, November 29, 2013 2:50 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org<mailto:dime@ietf.org> list

Cc: Ben Campbell

Subject: Re: [Dime] DOIC: Self-Contained OLRs







So, are we reaching any level of consensus here?



- JOuni



(as a note.. that we are converging back to where we started with OLRs ;)







On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com><mailto:ulrich.wiehe@nsn.com> wrote:



Hi,



another question:



If we go for explicit self contained OLRs, why would we then need the ReportType?



The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.



Ulrich







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

From: ext lionel.morand@orange.com<mailto:lionel.morand@orange.com> [mailto:lionel.morand@orange.com]

Sent: Thursday, November 28, 2013 10:31 AM

To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell

Cc: dime@ietf.org<mailto:dime@ietf.org> list

Subject: RE: [Dime] DOIC: Self-Contained OLRs



Hi,



There is no assumption on which entity is providing the realm overload status. It could be provided an agent inserting this info in answers received from a server behind but also from a server that would know this info by some internal magic.

But in any case, if we assume that the client will received a successful answer from the server for an initial request with only Dest-Realm AVP, it should be possible to have both report types in the answer: one for the server itself, one for the realm for new request sent to the realm with only Dest-Realm AVP.



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich

(NSN - DE/Munich) Envoyé : jeudi 28 novembre 2013 10:26 À : ext Jouni

Korhonen; Ben Campbell Cc : dime@ietf.org<mailto:dime@ietf.org> list Objet : Re: [Dime]

DOIC: Self-Contained OLRs



Hi,



I don't see how the possibility to send more than one OLR in an answer is aligned with the "endpoint principle". If the ReportType is "realm" this indicates to the reacting end point that the reporting end point is an agent (e.g. SFE) rather than a server. If the ReportType is "host" this indicates to the reacting end point that the reporting end point is a server. How can the reporting end point be both agent and server?



Ulrich



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

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni

Korhonen

Sent: Wednesday, November 27, 2013 11:44 PM

To: Ben Campbell

Cc: dime@ietf.org<mailto:dime@ietf.org> list

Subject: Re: [Dime] DOIC: Self-Contained OLRs





On Nov 28, 2013, at 12:27 AM, Ben Campbell <ben@nostrum.com><mailto:ben@nostrum.com> wrote:



Hi,



I mentioned in another thread that I prefer putting an explicit

ReportType AVP in an OLR, rather than



The more I spent time thinking/writing the actual procedures on the

endpoints, the more it makes sense to me to keep the ReportType in the

OC-OLR. Even if the baseline does not have agent overload etc, the

ReportType fits well to the "endpoint principle" we have in the draft.

It indeed gives more tools to make a host vs. realm base decision on the reacting node and is plain more clear.



I skip the rest of the mail.. too much text ;-)





- Jouni











making a responding node infer the type or meaning of the OLR from a Diameter request that corresponds to the answer containing the OLR. My reasons for that go beyond just ReportType, so I'm starting a separate thread.



As currently described, a consumer of an OLR must infer several things from other context. In most cases, that context is in the Diameter answer that carries the OLR. For example, the OLR implicitly refers to the application identified by the Application-Id field of the enclosing answer, the realm identified by Origin-Realm, and so on. This means that the "meaning" of an OLR cannot be determined from the OLR contents alone; OLRs only have meaning in the context of the enclosing answer. If you moved an OLR from one answer to another, it's meaning may change completely.



I think this approach is a mistake. I would greatly prefer that we explicitly include such values in the OLR itself, for multiple reasons:



1) It's more complex to interpret implicit, contextual values than explicit values. The consumer cannot simply look at the OLR; it must look in various other AVPs to find all the information it needs. For example, I think a common software design for overload control processing to be separated from application processing. The consumer cannot simply hand the OLR to that module and expect things to work. The OC module must not only parse the OLR, but parse any other AVPs that are relevant. As OLR contents get extended (assumedly following the same strategy as the base spec), the number of "context" avps that must be interpreted can grow large. This approach is error prone, and will likely encourage brittle, hard-to-maintain code. Self-contained OLRs would keep all the information related to overload in one place. making for simpler implementations.



2) It's more complex for the reporting node to send implicit values than explicit values. The sender cannot simply set the context to match the OLR--all those other AVPs have application or protocol layer meanings. Once a reporting node realizes that it is overloade, it has to wait for the right answer that contains the right context before it can send the OLR. This is particularly troublesome for agents, since they will typically have to insert OLRs into answers created by other nodes.



If the reporting node screws this up, the meaning of the OLR may change significantly. So again, implicit meaning gives us error prone implementations. Self-contained OLRs are simpler to create and send.



3) Implicit values don't work at all for certain problems. For

example, if an agent needs to originate an OLR, it typically needs to

insert that OLR into an existing Diameter answer created by a server.

It can't create its own answer without affecting the application

state. If the responding node assumes the OLR comes from or refers to

the node identified by the Origin-Host AVP in the enclosing answer,

things break. (For examples of when an agent needs to send OLRs that

are distinct from those sent by a server, see Steve's agent overload

draft, or my dh/dr example.)



OTOH, explicit values will work for all cases where we need to associate some arbitrary value with an OLR.



4) Implicit values seriously constrain the future evolution of Diameter OC standards. For example, lets say we find a good reason to allow OLRs to be sent out of band, or be sent in a dedicated Diameter application. If overload reports were self-contained, one could just reuse the report format we specify here. But if the meaning of an OLR depends on the way it's transported, this won't work. We would have to create a new or significantly modified OLR format if we found a need to transport OLRs in different ways. Self-contained OLRs would allow much greater flexibility.



So, in summary, I think that self-contained OLRs would lead to simpler implementations, less brittle deployments, and more flexibility for future evolution of standards.



Thanks!



Ben.

_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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

_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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



______________________________________________________________________

___________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations

confidentielles ou privilegiees et ne doivent donc pas etre diffuses,

exploites ou copies sans autorisation. Si vous avez recu ce message

par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or

privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

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

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

Thank you.





_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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

_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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



_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

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

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

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



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

they should not be distributed, used or copied without authorisation.

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

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

Thank you.



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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





_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

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

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

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



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

they should not be distributed, used or copied without authorisation.

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

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

Thank you.



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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





_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

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

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

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



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

they should not be distributed, used or copied without authorisation.

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

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

Thank you.



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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

_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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




_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

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

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

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



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

they should not be distributed, used or copied without authorisation.

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

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

Thank you.



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

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