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

Ulrich,

Please see my comments inline

Steve

On 7/16/14, 11:00 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> 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.
SRD> I  do not agree that algorithm negotiation is end-to-end. In 
addition, we should not preclude the case discussed in section 5.2.2.
>
> 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.
SRD> There are clearly options in how to design agent overload. My 
preference is to use the same mechanisms for transport of agent overload 
AVPs as are used for other report types.  Others might have different 
opinions.  We should not, however, assume a solution at this point.  In 
addition, we should not limit the options for future extensions.
>
> 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
>>>
>