Subject: [MMUSIC] Milestones changed for mmusic WG

From: IETF Secretariat <[email-masked]>
Date: Fri, 17 Oct 2014 15:28:26 -0700

Changed milestone "Submit Dual-stack Fairness with ICE as Proposed
Standard ", set state to active from review, accepting new milestone.

URL: http://datatracker.ietf.org/wg/mmusic/charter/

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 21 Oct 2014 10:11:53 +0000

Hi mmusic,

We submitted a new draft that we believe cover the new milestone.

https://tools.ietf.org/html/draft-martinsen-mmusic-ice-dualstack-fairness-00

It is a renamed version of the ICE Happy Eyeballs draft. We move away from what people usually regard as happy eyeball functionality so a name change seemed to be appropriate.

Also added the following text:

Implementations are encouraged to prioritize IPv6 candidates by
putting some of them first in the the intermingled checklist.  This
increases the chance of a IPv6 connectivity checks to complete first
and be ready for nomination or usage.

Seems like a good idea to at least hint that IPv6 is coming and we should do what we can to help adoption.

.-.
Pål-Erik

On 18 Oct 2014, at 00:28, IETF Secretariat <[email-masked]> wrote:

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 21 Oct 2014 08:53:47 -0600

> 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?

Thanks,
Simon

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 23 Oct 2014 07:53:33 +0000

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.

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?

.-.
Pål-Erik

Thanks,
Simon

---

From: Ari Keränen <[email-masked]>
Date: Fri, 24 Oct 2014 00:46:24 +0300

On 10/23/14 10:53 AM, Pal Martinsen (palmarti) wrote:
>> On Tue, Oct 21, 2014 at 4:11 AM, Pal Martinsen (palmarti)
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> 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.
>
> 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.
>

We discussed this topic at #89 IETF:
http://www.ietf.org/proceedings/89/minutes/minutes-89-mmusic#h.caj5s2i38ck0

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

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.

Cheers,
Ari