Subject: Re: [MMUSIC] ICE Dual Stack Fairness

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 3 Nov 2014 12:45:03 +0000

> On 23 Oct 2014, at 23:46, Ari Keränen <[email-masked]> wrote:
> 
> On 10/23/14 10:53 AM, Pal Martinsen (palmarti) wrote:
>> 
>> On 21 Oct 2014, at 16:53, Simon Perreault <[email-masked]
>> <mailto:[email-masked]>> wrote:
>> 
>>> 
>>> On Tue, Oct 21, 2014 at 4:11 AM, Pal Martinsen (palmarti)
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>    We submitted a new draft that we believe cover the new milestone.
>>> 
>>>    https://tools.ietf.org/html/draft-martinsen-mmusic-ice-dualstack-fairness-00
>>> 
>>> 
>>> I just read this for the first time. Forgive me if this has been
>>> discussed before... As an implementer I would prefer if there was "the
>>> one true" algorithm that I can go and implement and not have to think.
>>> Having an example algorithm in an appendix makes me uneasy. If the
>>> algorithm is not contentious, why not make it normative?
>>> 
>> 
>> This have been briefly discussed. Some ICE implementations already do
>> similar tricks to solve this problem. The main purpose of the draft is
>> to make implementers aware that their might be a problem and hint that
>> there is a solution they can use.
>> 
>> That said, I completely agree that the algorithm should be normative.
>> 
>> The algorithm in the draft already has wording in there to allow for
>> implementation specific modifications. And should be able to handle any
>> old ICE implementations without braking anything.
>> 
>> Anyone with objections regarding making the proposed algorithm normative
>> in the draft?
> 
> We discussed this topic at #89 IETF:
> http://www.ietf.org/proceedings/89/minutes/minutes-89-mmusic#h.caj5s2i38ck0
> 
Thanks for the pointer. MMUSIC minutes are very detailed and helpful. 

> The algorithm as such is not, to best of my knowledge, contentious, but making it something mandatory to follow was considered a bad idea.
> 
Agree, definitely not mandatory. 

Wish I was clever enough to build a mathematical prof of the correctness of the algorithm. 

> As individual, I think one (RFC 2119) MAY/OPTIONAL default algorithm would make sense, but having it as MUST would not be a good idea.
> 

I would like it stronger than MAY. Something like: “Implementations SHOULD use the algorithm in Section xxx, but MAY user their own following the guidelines in Section yyy to ensure interoperability” 

I will rewrite the draft to ensure the guidelines for not breaking interoperability stands out more clearly, and move the algorithm from appendix into main. 

Thanks for input.

.-.
Pål-Erik

> Cheers,
> Ari

---

From: Simon Perreault <[email-masked]>
Date: Mon, 3 Nov 2014 08:58:59 -0500

On Mon, Nov 3, 2014 at 7:45 AM, Pal Martinsen (palmarti) <[email-masked]
> wrote:

> I would like it stronger than MAY. Something like: “Implementations SHOULD
> use the algorithm in Section xxx, but MAY user their own following the
> guidelines in Section yyy to ensure interoperability”
>
> I will rewrite the draft to ensure the guidelines for not breaking
> interoperability stands out more clearly, and move the algorithm from
> appendix into main.
>

Works for me! Prescriptive enough to make clueless implementers like me go
ahead and do it, with enough wiggle room to allow for engineering tweaks
while doing it.

Thanks,
Simon