Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt

Steve,

with regard to extensions introducing new algorithms like rate I do not see what is wrong with the A-F principles: Algorithm negotiation is end-to-end and it is irrelevant whether and which algorithms are supported by an agent in the middle.

With regard to agent overload, many things are unclear and my understanding is that nothing has been agreed so far. Please see my comments to your agent overload draft I sent earlier.
Principle here seems to be that agent overload information (capabilities and reports) is only relevant for the next hop and must not be forwarded further by the next hop (and if the next hop does not support agent overload, must not be sent at all to the next hop). Piggibacking this information on (end-to-end) application messages therefore may not be the best choice. Rather CER and WDR should be used for agent overload.  

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
Sent: Wednesday, July 16, 2014 9:16 AM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt

Ulrich,

The mismatched capabilities use case is required for extensibility.

We have at least two cases where the use case is required.  First is 
agent overload and the second is the rate abatement algorithm.

Consider the  agent overload feature.  This feature requires knowledge 
of whether or not the adjacent nodes support the feature. This cannot be 
achieved if the transaction client does not support the feature and the 
agent is not allowed to change the OC-S-F AVP.

As I indicated in my initial response, I do not agree with the A-F 
principles.  The DOIC solution needs to support required use cases. The 
behavior specified needs to be based on those use cases.

Steve

On 7/15/14, 10:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> e.g.the use case shown in figure 7 where the agent modifies the OC-S-F within the xxR no matter whether the xxR is host-routed or realm-routed. If xxR is host routed, A) is not followed.
>
> Ulrich
>
>
> -----Original Message-----
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> Sent: Tuesday, July 15, 2014 4:30 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt
>
> Ulrich,
>
> Which of the use cases in the draft do not follow A) to F)?
>
> Steve
>
> On 7/15/14, 4:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve,
>>
>> all use cases that do not follow A) to F),
>> e.g. where
>>
>> C and S both supports DOIC, C sends a host-routed request to S and A in the path modifies OC-xxx AVPs (see figure 7).
>>
>> Ulrich
>>
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>> Sent: Tuesday, July 15, 2014 2:16 PM
>> To: dime@ietf.org
>> Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt
>>
>> Ulrich,
>>
>> Can you be specific on which of the use cases in the specification do
>> not need to be supported by the DOIC solution?
>>
>> Thanks,
>>
>> Steve
>>> Do I understand correctly that you mean that an agent MUST NOT remove or modify the OC-S-F from host routed requests? If so, I disagree. There are real world scenarios that will require that modification or removal. (For example, those in section 5.2)
>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, you understand correctly, and no I do not agree with your "real world scenarios".
>>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>