Re: [Dime] DOIC: Self-Contained OLRs

<lionel.morand@orange.com> Thu, 05 December 2013 15:14 UTC

Return-Path: <lionel.morand@orange.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 E6E451AE093 for <dime@ietfa.amsl.com>; Thu, 5 Dec 2013 07:14:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9Vwm4Cdxq4K for <dime@ietfa.amsl.com>; Thu, 5 Dec 2013 07:13:58 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E81661AE092 for <dime@ietf.org>; Thu, 5 Dec 2013 07:13:57 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D837A2DC2E0; Thu, 5 Dec 2013 16:13:53 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B74584C063; Thu, 5 Dec 2013 16:13:53 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 16:13:53 +0100
From: lionel.morand@orange.com
To: Steve Donovan <srdonovan@usdonovans.com>, "Nirav Salot (nsalot)" <nsalot@cisco.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO8HrXo7y6FFeeaEmQ38aKczpYQJpDChOAgAF7IoCAAC7igIAAKrUQgABohICAADmQAIAADvuAgAAFTgCAAATPgIAABekAgAAWtWA=
Date: Thu, 05 Dec 2013 15:13:52 +0000
Message-ID: <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF731D844122B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <A9CA33BB78081F478946E4F34BF9AAA014D24EFF@xmb-rcd-x10.cisco.com> <52A077CC.3000004@usdonovans.com> <A9CA33BB78081F478946E4F34BF9AAA014D2582D@xmb-rcd-x10.cisco.com> <52A088D0.2020406@usdonovans.com> <A9CA33BB78081F478946E4F34BF9AAA014D25A08@xmb-rcd-x10.cisco.com> <52A091CE.2000104@usdonovans.com>
In-Reply-To: <52A091CE.2000104@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.5]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E32B6EBPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.5.143019
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: Thu, 05 Dec 2013 15:14:14 -0000

Hi Steve,

"I also don't think I agree this is a special architecture requirement, but this requires some thought."

I repeat one of my comments... being able to receive an OLR for another application that the one carrying the report implies that there is functional link between the functions, either a direct link or through a kind of centralized overload control function (or any equivalent function). And here is the reason for my "STRONG NO" for the self-contained OLRs, based on the existing requirements regarding Diameter overload control.

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 15:47
À : Nirav Salot (nsalot); dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Nirav,

Thanks for clarifying.  This is obviously one area we have been making different assumptions.  It's a good thing  this thread went on this long. :-)

One question, maybe for Maria Cruz.  If it is never ok for an overload report to apply to an application other than the application carrying the message then how does the "all applications" extension proposed by Maria Cruz work?

I will come back to address the "special architectural requirement" question in a separate email.  I think I understand the point you are making.  I also don't think I agree this is a special architecture requirement, but this requires some thought.

Steve
On 12/5/13 8:25 AM, Nirav Salot (nsalot) wrote:
Steve,

We assumed that "self-contained OC-OLR" contains the same information as the message containing this AVP and hence we (me, JJ, Maria-Cruz) were saying that consistency check is needed.

But now I understand that "self-contained OC-OLR" can contain information of any context since the AVP itself defines the context explicitly. So application-X message can carry application-Y's OC-OLR and I do not agree to this.
In my view, this is totally against the existing principles of Diameter based applications. And hence this requires special support at the receiving node as well as the sending node since today the nodes are designed to handle only application specific data.

In summary, "self-contained OC-OLR" puts a special architectural requirement on Diameter nodes - to handle one application's data from other application's message - and hence this is a strong reason for me to object to "self-contained OC-OLR".

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 05, 2013 7:38 PM
To: Nirav Salot (nsalot); dime@ietf.org<mailto:dime@ietf.org>
Subject: Re: [Dime] DOIC: Self-Contained OLRs

I must admit that I don't understand the need for consistency.

Why is it necessary to compare implicit and explicit data?  If we use self contained reports then the contents of the report are what should be used, independent of the message that carries the report.

Steve
On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote:
Steve,

While gauging the complexity of "using the self-contained OC-OLR" It seems you have overlooked the aspect identified by Maria-Cruz below (and JJ earlier).
> Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data.

Regards,
Nirav.

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

If we equating "complexity" with work done by a Diameter node, then there is added "complexity" for both proposals.

The extra work that needs to be done for the self contained report approach is that the reporter needs to add additional AVPs to the report.  This is hardly difficult but it is extra work.

The extra work in the implicit approach is that the reactor needs to gather information from multiple AVPs to understand the context of the AVP.  Again, hardly difficult but more work that can be avoided in a well layered software architecture.

My conclusion is that the complexity argument does not apply.  There is complexity in both, its just a matter of where the work is done.

Steve
On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:

Agree with Lionel's view and Maria-Cruz's arguments below.



The "self-contained OC-OLR" - which I assume contains the same information as present in the message containing the OC-OLR - adds extra complexity as highlighted by Maria-Cruz.

The benefit highlighted can be achieved in an implementation specific way by the receiver duplicating the information into OC-OLR before passing it to the layer processing the OC-OLR.



Regards,

Nirav.



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

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome

Sent: Thursday, December 05, 2013 7:53 AM

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

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



Dear all,



I agree with Lionel argumentation below.



A part from that,  one concern with "self-contained OLRs" is that some data is duplicated. Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data.



Also, I think this is a pure implementation proposal. Regardless how the data is transported it could be packed in a "self-contained OLRs" within the diameter application, if for any implementation this is preferred.



Regards

/MCruz





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

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com<mailto:lionel.morand@orange.com>

Sent: jueves, 05 de diciembre de 2013 1:43

To: Ben Campbell

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

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



Hi Ben,



3GPP operational requirements have triggered and driven this work, and 3GPP will be the main client for this solution (if not the only for a while...). Main parties involved in the discussions are 3GPP vendors and 3GPP operators. So instead trying to keep private preserve, we should welcome and enforce cooperative work with 3GPP on this task if we want that the solution defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait for IETF and develop its own solution, as done in the past (e.g. developing 3GPP-specific Cx application instead of adopting the IETF-standard Diameter SIP application).



About the technical discussion, the Req31 says:



   REQ 31: There are multiple situations where a Diameter node may be

           overloaded for some purposes but not others.  For example,

           this can happen to an agent or server that supports multiple

           applications, or when a server depends on multiple external

           resources, some of which may become overloaded while others

           are fully available.  The solution MUST allow Diameter nodes

           to indicate overload with sufficient granularity to allow

           clients to take action based on the overloaded resources

           without unreasonably forcing available capacity to go unused.

           The solution MUST support specification of overload

           information with granularities of at least "Diameter node",

           "realm", and "Diameter application" and MUST allow

           extensibility for others to be added in the future.



The "MUST" part says: enough granularity with at least host/realm and application.

And the existing solution is compliant with this requirement. If a node is supporting N applications, an OLR can be sent "per application" with a report type indicating if it is for the host or the realm. And the extensibility capability is provided by the base solution.



So my technical argument is that the existing proposal fulfills the basic requirements for an overload control without compromising future extension for further granularity.



Regards,



Lionel



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

De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mercredi 4 décembre 2013 22:55 À : MORAND Lionel IMT/OLN 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





_________________________________________________________________________________________________________________________



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.