Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 1 Sep 2014 22:09:29 +0000

Dear all,

I share the view presented by Lionel, Nirav, and JJ.
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: jueves, 28 de agosto de 2014 12:26
To: Nirav Salot (nsalot); Steve Donovan; [email-masked]; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Dear all

A long email thread on this topology  hiding topic. I Would like to come back on the use cases.
In the thread, two use cases were mentioned, are there others?

- the SFE case, where a DA in front of a set of servers presents this set of servers as one Diameter node with a unique Diameter Host identity. The reacting nodes only know this Diameter Host identity for their host requests. Regarding DOIC, as the SFE objective is to present the group of servers as one Diameter node it should apply to DOIC, meaning the DA aggregates the different OLRs received from servers to build the OLR associated to the unique Diameter Host identity.  Otherwise  this Diameter node will send inconsistent OLRs, and then we try to find a solution requesting the reacting nodes, that may be in external networks  to solve this DOIC issue internal to the servers and their SFE.   Lionel did  such a remark in his 19/08 mail " a agent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs" on which I agree.
Furthermore the Steve's proposed solution would introduce a non consistent behavior from the reacting node regarding traffic reduction.   

- the external network case where the DA of  the servers network interfacing external networks  is doing topology hiding to present the servers as a unique Diameter node to external networks . I have the same remark as for SFE, where the proposed solution will request the external network to solve the issue of the non DOIC DEA.
There is also the case where the DEA modifies  the Origin-Host but on a 1 to 1 basis, so allocating a different Origin-host identity for each server. In this case, the DOIC works  well without changes. The proposed solution will, I think, here create mismatches, which do not exist. 

I share the comments from several of us, to not consider this case as an actual one to solve. If a DA presents a set of servers as a unique Diameter Host, either this overall entity (servers+DA) supports DOIC and behaves as a reporting node  towards reacting nodes or it does not. If it does not, no OC-Supported-feature AVP should be sent by this entity in answers to reacting nodes, that I think can be achieved. 

Best regards

JJacques

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot)
Envoyé : jeudi 21 août 2014 18:49
À : Steve Donovan; [email-masked]; Ben Campbell
Cc : [email-masked]
Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Steve,

SRD> Which is worse, an operator not being able to turn on DOIC because
of other operators or breaking topology hiding?  I don't know the answer but I do think it is a decision that should be made by the operator.

I am not sure why should operator A not turn on DOIC feature in its own network just because of operator B/C/D does not support it.
This is handled in the same way as operator A and B support the feature but have no agreement to share the overload report. And hence based on configuration host in operator A's network ensures that messages going to operator B does not contain overload report.

Regards,
Nirav. 

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]]
Sent: Thursday, August 21, 2014 9:01 PM
To: Nirav Salot (nsalot); [email-masked]; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Nirav,

Thanks for the detailed response.  Please see my responses inline.

Steve

On 8/20/14, 11:43 AM, Nirav Salot (nsalot) wrote:
> Steve,
>
> You are proposing a change (minor or not) for a problem which does not 
> exist (in my view at least) since the use case is
> - The operator has enabled overload feature in his network and has not 
> upgraded one of the proxy
> - The operator has "forgotten" that the proxy which is not upgraded is 
> doing topology hiding
SRD> It's not just about topology hiding.  It's about anything that
requires changing the origin-host.

>
> Or between two operators, they have entered into the agreement to share the overload reports but have not bothered to upgrade all of their nodes and not done any basic testing before activating the overload feature.
SRD> I don't think we want to get into the situation where Operator A 
has to wait to turn on overload control because Operator B has not yet 
upgraded their network to support DOIC.
>
> So we are defining the solution for the above use cases. And the solution you are suggesting it results in
> - The client ignoring the overload report and thus the operator finds out that "he has forgotten to upgrade one of the proxy (which is doing topology hiding) with the overload feature".
SRD> I'm saying that in the real world strange things happen. Solution 1 
mitigates the effect of mistakes being made.

SRD> I'm not saying the client ignores the overload report.  That is 
clearly one option.  I have suggested the behavior be up to local 
policy.  I see four options, others may see others:

1) Always ignore the overload report
2) Always honor the overload report
3) Conditionally honor the overload report -- Honor anything up to some 
percentage
4) Adjusted percentage - learn the number of servers that exist behind 
the OHMA and adjust the reduction percentage accordingly.
>
> Additionally, the solution breaks topology hiding feature itself and your justification is that "we haven't agreed requirement to not break this feature!".
SRD> As pointed out by Dave, there are likely modifications to solution 
1 that does not break topology hiding, if we think it is a requirement 
to avoid that breakage.

SRD> Which is worse, an operator not being able to turn on DOIC because 
of other operators or breaking topology hiding?  I don't know the answer 
but I do think it is a decision that should be made by the operator.
>
> I am sorry, but I don't see why we need any protocol based solution here.
SRD> This is where the difference of opinion exists.  You are of the 
opinion that operators never make mistakes and, as a result, we don't 
need a protocol based solution.  I am of the opinion that in the real 
world strange things happen and a little bit of extra resiliency in the 
protocol is a good thing.
> It is simple matter operator knowing its network/deployment/nodes and existing features and enabling new feature based on "this" knowledge. And doing some basic testing/dry run before going live.
> 3GPP or IETF, if we start defining solution assuming that "but the operator may have forgotten to do this or that", we are adding solutions in our product which are simply overhead.
>
> Finally, we should be looking at the justification to have some solution and not add some change just because it is minor.
SRD> No one is making that argument.  I have articulated the 
justification.  I also pointed out that the cost of the solution is very 
small.  Cost benefit analysis is a valid aspect of any design process.
>
> Regards,
> Nirav.
>
> -----Original Message-----
> From: Steve Donovan [mailto:[email-masked]]
> Sent: Wednesday, August 20, 2014 9:56 PM
> To: Nirav Salot (nsalot); [email-masked]; Ben Campbell
> Cc: [email-masked]
> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis
>
> Nirav,
>
> Can you please be more specific about which of the explanations you don't agree with?
>
> I agree we can't completely ignore the way that Diameter is being used.
>
> We should also be avoiding a solution that leaves open the possibility of significant under utilization of Diameter network resources.  We have a stated requirement that the solution must not result in under utilization.
>
> I must admit I'm surprised at the response the proposal is getting. It is a very minor change that makes the protocol more resilient.
>
> Steve
>
> On 8/20/14, 10:59 AM, Nirav Salot (nsalot) wrote:
>> Steve,
>>
>> I don't agree with your explanations.
>>
>> Additionally, we may not have explicit requirement to make DOIC work in the face of topology hiding but that does not mean that "DOIC can break any existing feature - be it topology hiding - and that's fine!".
>>
>> Regards,
>> Nirav.
>>
>> -----Original Message-----
>> From: Steve Donovan [mailto:[email-masked]]
>> Sent: Wednesday, August 20, 2014 9:24 PM
>> To: Nirav Salot (nsalot); [email-masked]; Ben Campbell
>> Cc: [email-masked]
>> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives
>> analysis
>>
>> Nirav,
>>
>> Please see my comments inline.
>>
>> Steve
>>
>> On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote:
>>> I agree with Lionel on multiple accounts.
>>> I don't see any value in alternative 1. In fact, as I had already indicated, the alternative 1 breaks one or more of existing feature and hence it is not a solution by itself.
>> SRD> The value is that, through a protocol solution, we can make it
>> possible to prevent a complete shutdown of all traffic through a OHMA.
>> It might be a small probability, but it is > 0, the impact is significant and the cost of the proposed protocol solution is extremely small.
>>
>> SRD> I'm assuming that the breakage you are talking about is that the
>> proposal does allow for topology information to leak across operator boundaries.  This is true, however, we do not, however, have a requirement to make DOIC work in the face of topology hiding.  Are there other existing features that you are concerned about?
>>> Additionally, like any other feature, the operator does not simply enable this feature in their network without considerable planning, lab and field testing. And this is true for between two operators as well - where the bigger issue is whether to expose the overload information between two PLMNs or not.
>> SRD> We are designing DOIC for Diameter usage in general, not just
>> 3GPP.  I agree that this scenario is unlikely in a 3GPP environment, at least for well disciplined operators that have extensive testing as you point out.  I don't, however, think we can make that assumption across all uses of Diameter.  That's one of the reasons why we have requirements stating that the solution should not rely on configuration.
>>> So I don't see the need to have protocol based solution to help operator debug "what they have forgotten about their network".
>> SRD> As has been pointed out multiple times, this is not just about
>> SRD> the
>> operator's own network.  The negative impacts can result from another operator not upgrading their agents to support DOIC.
>>
>> SRD> I look at this as a low cost insurance policy.  It doesn't hurt
>> anything to add this small change and it helps prevent would could be a major outage.
>>> Regards,
>>> Nirav.
>>>
>>> -----Original Message-----
>>> From: DiME [mailto:[email-masked]] On Behalf Of
>>> [email-masked]
>>> Sent: Tuesday, August 19, 2014 8:57 PM
>>> To: Steve Donovan; Ben Campbell
>>> Cc: [email-masked]
>>> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives
>>> analysis
>>>
>>> Hi Steve,
>>>
>>> If you decide to deploy a proxy modifying the origin-host, it would be for some specific purposes in a given context. If the context has changed, you will have to reconsider the whole mechanism. And it is not only related to DOIC.
>>> If not done, this is what I'm calling a bad design: it is not only about the implementation of the product itself, it is also about how this product is used in the operational network.
>>> And I don't buy the argument that an operator might have forgotten that a proxy modifying origin-host would have been deployed in the network before the introduction of DOIC.
>>>
>>> About alt 1:
>>>
>>>>>>>>> 1) Attribution of overload reports.
>>>>>>>>>       - Add diameter-id of the node that is overloaded into the OC-OLR AVP.
>>>>>>>>>       - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic.
>>>>>>>>>       - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP.  When there is a difference, the reacting node should report on the condition (event/alarm).  Local policy would determine if the reacting node honors the overload report or ignores the overload report.
>>> The following question still remain not answered: if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR?
>>>
>>> Regards,
>>>
>>> Lionel
>>>
>>> -----Message d'origine-----
>>> De : Steve Donovan [mailto:[email-masked]] Envoyé : mardi
>>> 19 août 2014 16:46 À : MORAND Lionel IMT/OLN; Ben Campbell Cc :
>>> [email-masked] Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent
>>> alternatives analysis
>>>
>>> Lionel,
>>>
>>> More inline.
>>>
>>> Steve
>>>
>>> On 8/19/14, 8:40 AM, [email-masked] wrote:
>>>> Hi Steve,
>>>>
>>>> See below.
>>>>
>>>> Regards,
>>>>
>>>> Lionel
>>>>
>>>> -----Message d'origine-----
>>>> De : Steve Donovan [mailto:[email-masked]] Envoyé : mardi
>>>> 19 août 2014 13:41 À : MORAND Lionel IMT/OLN; Ben Campbell Cc :
>>>> [email-masked] Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent
>>>> alternatives analysis
>>>>
>>>> Lionel,
>>>>
>>>> There are two primary reasons that I think option 1 is important:
>>>>
>>>> 1) This scenario can result in significant under utilization of resources, to the extreme of completely shutting down all traffic to the servers behind the Origin-Host Munging Agent (OHMA).
>>>>
>>>> 2) It gives operates a way to detect the unplanned or forgotten instance of the OHMA.
>>>>
>>>> Being able to prevent number 1 is enough reason for me to add the very small amount of additional protocol machinery we are talking about.
>>>>
>>>> [LM] And I disagree.
>>>>
>>>> More inline.
>>>> [LM] same
>>>>
>>>> Steve
>>>>
>>>> On 8/19/14, 4:48 AM, [email-masked] wrote:
>>>>> Because a a gent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs, everything else is out of scope of the standardization.
>>>> SRD> I don't understand this argument.  It is perfectly valid for a
>>>> client or server to advertise support for an application and not also support DOIC.  Why do you imply that it would be different for an agent?
>>>> [LM] A proxy that would modify the origin-host without taking into account the possible use of this origin-host at the application would be a badly-designed proxy and should not be used in operational network.
>>> SRD2> Consider the following timeline:
>>>
>>> Date - Event:
>>>
>>> Sometime in 2011 - Operator installs an agent to do topology hiding or load balancing or some other function and the agent modifies the origin-host AVP as part of its logic.  In 2011 this works perfectly well for all applications handled by the agent.
>>>
>>> Sometime in 2015 - The IETF publishes the DOIC specification.
>>>
>>> Are you asserting that the agent deployed in 2011 was badly designed because it did not anticipate the DOIC solution published four years later?
>>>>> Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear.
>>>> SRD> See above.
>>>> [LM] still unclear
>>> SRD2> Detection of the fact that an OHMA exists so that something
>>> intelligent can be done before it results in a total shutdown of the Diameter network.
>>>>> Finally, we have agreed that the basic mechanism proposed in the draft may not cover all the use cases (existing or future) and can be enhanced if required, with or without the need for a IETF standard action.
>>>> SRD> The reasons so far for deferring functionality was because it
>>>> SRD> would
>>>> add risk to the schedule for finishing the core DOIC solution.  That is not the case here.  We have a very small change to the specification that  addresses multiple requirements.
>>>> [LM] is there any clear description of what will be the use of this info by the reacting node? if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR?
>>> SRD> Scroll down an look at the details behind alternative 1.
>>>>> For all these reasons, I would recommend not to add this Diameter-id in the OLR and to assume that the Origin-host is not changed by agent in the path of the Diameter messages. Some extra text could also be added to clarify that proxies modifying the Origin-host would have to be upgraded to manage consistently the OLR received in Diameter application messages.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Lionel
>>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : DiME [mailto:[email-masked]] De la part de Ben Campbell
>>>>> Envoyé : mardi 19 août 2014 03:42 À : Steve Donovan Cc :
>>>>> [email-masked] Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent
>>>>> alternatives analysis
>>>>>
>>>>> I support Alternative 1, but I'm not sure it's a complete solution.
>>>>>
>>>>> As Nirav pointed out, it has the potential to leak topology information past a topology hiding proxy. (Unless we can come up with some attribution scheme that is not based on Diameter Identity or IP Address.) It may be reasonable, to do this, but we would need some guidance to warn operators that this may happen if they enable DOIC across a non-supporting, topology-hiding proxy. It would become the operator's choice to decide which is more important.
>>>>>
>>>>> The part I find unsatisfying, is what would happen if you had some paths that supported DOIC (or did not do topology hiding), and some paths that don't support DOIC also do topology hiding. This could become a pretty big administrative hit, and violates the spirit and letter of our requirement to avoid adding lots of configuration work.
>>>>>
>>>>> OTOH, if we had a mechanism where servers could detect the existence of a non-DOIC, topology-hiding proxy, this could be at least partially automated. I can think of multiple ways we could make it possible to tell if an immediate peer supports DOIC, but not so much for non-adjacent nodes.
>>>>>
>>>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan <[email-masked]> wrote:
>>>>>
>>>>>> All,
>>>>>>
>>>>>> My recommendation on this alternative 1 as it give operators the ability to discover when there is an issue associated with "Origin-Host Munging" agents.  The operators can then take any administrative action necessary to fix the issue.  It is also a more general solution that does not rely on one industries interop procedures.
>>>>>>
>>>>>> If we can get agreement on this then we can start making progress on the remainder of the document.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote:
>>>>>>> Are there other thoughts on the pros and cons of the three proposals for resolution of issue #66?
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote:
>>>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan <[email-masked]> wrote:
>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> The issue with pre-DOIC agents changing origin-host was been discussed in this thread:
>>>>>>>>>
>>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html
>>>>>>>>>
>>>>>>>>> One example of the impact of the issue is defined in this message:
>>>>>>>>>
>>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html
>>>>>>>>>
>>>>>>>>> So far three solutions have been discussed for this issue:
>>>>>>>>>
>>>>>>>>> 1) Attribution of overload reports.
>>>>>>>>>       - Add diameter-id of the node that is overloaded into the OC-OLR AVP.
>>>>>>>>>       - Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic.
>>>>>>>>>       - Reacting node detects when there is a difference between the diameter-id in the OC-OLR report and in the Origin-Host AVP.  When there is a difference, the reacting node should report on the condition (event/alarm).  Local policy would determine if the reacting node honors the overload report or ignores the overload report.
>>>>>>>> I think the last entry is worth further discussion, but it's probably more important to make a high level decision first. But, at risk of getting ahead of myself: I have trouble imagining a situation where honoring the overload report will be harmful, since if there is an intervening OHMA, the reacting node will not likely have any host-routed requests to the diameter-id from the OLR. OTOH, I have trouble imagining where honoring the report would be useful, for the same reason.
>>>>>>>>
>>>>>>>>> 2) Configuration in operator's networks to turn off origin-host munging behavior until the agent is upgraded to support DOIC.
>>>>>>>>>
>>>>>>>>> 3) Configuration of reporting nodes to not send overload reports, either universally or for transactions that cross the origin-host munging agent.
>>>>>>>>>
>>>>>>>>> I've compiled a starting point for a pros and cons analysis of the three approaches.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Steve
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>> Option 1 Pros:
>>>>>>>>> ------------
>>>>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC origin-host-munging agent in the path of a transaction.
>>>>>>>>> - Gives operators ability to manage the under utilization issue caused by the non-DOIC agent.
>>>>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out.
>>>>>>>>> - Leaves the determination of which action to take in this scenario (honor or ignore overload reports) to operator policy.
>>>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of configuration required.
>>>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a single node overload on the traffic handled by other nodes in the network.
>>>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of overload in a mixed DOIC environment on the overall capacity of the network.
>>>>>>>> Specifically, it complies with the MUST NOT make things worth clause, but does not comply with the SHOULD reduce overload clause.
>>>>>>>>
>>>>>>>>> Option 1 Cons:
>>>>>>>>> -------------
>>>>>>>>> - Requires additional protocol machinery (minimal)
>>>>>>>>> - Does not completely fix the effects of non-DOIC agent on
>>>>>>>>> overload control
>>>>>>>> One additional con is that, if the OHMA is there for the purposes of true topology hiding, the identity in the OLR may leak topology information.
>>>>>>>>
>>>>>>>>> Option 2 Pros:
>>>>>>>>> ------------
>>>>>>>>> - Does not require additional protocol machinery
>>>>>>>>> - Does the best job of three alternatives in allowing for
>>>>>>>>> management of overload conditions
>>>>>>>>>
>>>>>>>>> Option 2 Cons:
>>>>>>>>> ------------
>>>>>>>>> - Requires the operator to lose any functionality enabled by
>>>>>>>>> the non-DOIC agent until all agents have been upgraded to
>>>>>>>>> support DOIC
>>>>>>>>> - Requires extra configuration (against requirement #6)
>>>>>>>>> - There is not way to determine if all non-DOIC origin-host munging behavior has been turned off until an overload event happens, with potential to have significant negative effects until the offending agent can be found and the behavior turned off.
>>>>>>>>> - Not always possible, as operator doesn't always have control over non-DOIC agent as it might be in another operators network. Proposal to address this through interop agreements but while this might work in 3GPP scenarios, not all Diameter deployments are 3GPP driven.
>>>>>>>> Since you mentioned the 7068 requirements in the cons for option
>>>>>>>> 1, it makes sense to mention them for others. This one misses on
>>>>>>>> 6, but seems okay for 12 and 17.  (I guess we should have had a
>>>>>>>> requirement about not interfering with existing network features.
>>>>>>>> If we had that, Option 2 would not comply.)
>>>>>>>>
>>>>>>>>> Option 3 Pros:
>>>>>>>>> ------------
>>>>>>>>> - Does not require additional protocol machinery
>>>>>>>>> - Gives operators the ability to keep features requiring origin-host munging turned on while DOIC is rolled out.
>>>>>>>> For very limited definitions of "rolled out."
>>>>>>>>
>>>>>>>>> Option 3 Cons:
>>>>>>>>> ------------
>>>>>>>>> - Requires extra configuration (against requirement #6)
>>>>>>>>> - Likely requires extra development in the reporting node that
>>>>>>>>> would not otherwise be needed (ability to limit where overload
>>>>>>>>> reports are sent)
>>>>>>>>> - Not necessarily easy to determine in advance where which
>>>>>>>>> requests will traverse a the non-DOIC agent
>>>>>>>>> - Limits ability of operator to fully control overload
>>>>>>>>>
>>>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a similar way as option 1.  Partially misses 34.
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> DiME mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>>
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>
>>>>> ___________________________________________________________________
>>>>> _ _ _ ___________________________________________________
>>>>>
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>>>> Thank you.
>>>>>
>>>>>
>>>> ____________________________________________________________________
>>>> _ _ ___________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>>> Thank you.
>>>>
>>>>
>>> _____________________________________________________________________
>>> _ ___________________________________________________
>>>
>>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Wed, 03 Sep 2014 08:48:55 -0500

JJ,

Apologies for my delayed response.  I won't go through things in detail, 
as this is ground that has been covered.

I will reiterate that we are talking about a backwards compatibility 
issue here.  We are talking about agents that are running today and 
doing functions that require changing the origin-host in answer 
messages.  There is no way that these existing agents can be expected to 
support DOIC, as DOIC doesn't exist yet.

For reasons that have already been expressed, I don't consider it 
sufficient to address this by saying to operators "make sure all agents 
in your network and your partners networks support DOIC before turning 
on DOIC."  This, however, looks to be the direction this discussion is 
taking.

Steve