Re: [Dime] Issue#30 status

[Ben Campbell <[e-mail]>]

We are going around in circles on this one. I don't agree for reasons I have stated before, but will state again for reference (see inline).

On Feb 26, 2014, at 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) <[e-mail]> wrote:

> Steve, Ben, all,
> 
> on 1) we seem to agree that OC-Supported-Features in answers is not required for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up to drafts associated with new abatement algorithms to specify the requirement to include OC-Supported-Features in answers if so needed (I still don't see the need even for rate or other algorithms); that needs to be discussed when discussing those drafts.

I think it's best to keep it there for all algorithms. I'd like to be able to look for a single field and understand wether DOIC is supported, what algorithm is being used, as well as any parameters for that algorithm (even if none.) I don't want to have to look for the field, then if it's not there look other places.

> 
> On 2) I understand the usecase, but I'm not sure whether we have this requirement of selective proactive throttling (see e-mail from Lionel). Anyway, given the conclusion on #31, OLR will be included in all answer messages (exept when the reporting node is aware that the reacting node already knows). Therefore the reacting node can deduce support of DOIC by the reporting node from the presence of OLR (if OLR is present then DOIC is supported by the reporting node; if OLR is absent, then reacting node already knows whether or not DOIC is supported by the reporting node).


We have a requirement to be able to operate effectively in a mixed environment. Working with nodes that do not support DOIC is going to require other strategies. Steve's example is a possible such strategy. Taking away the ability to quickly learn which peers support DOIC makes working effectively in a mixed environment harder.

I'm really surprised people are so opposed to including OC-Supported-Features in every answer. It's very easy and cheap to do it. Leaving it out makes implementations harder and more error prone. Leaving it out makes it hard or impossible to take proactive measures to work with other nodes that don't support DOIC. This should be an easy choice.

We've mentioned several advantages of requiring it in every answer. The only advantage I see for removing it is to save having to insert one more AVP. I don't find that convincing. Are there other reasons for leaving it out?