Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections

[Ari Keranen <[e-mail]>]

Thanks Cullen and Miguel.

Everyone, now is a good time to start thinking and discussing what are 
the bugs we want to fix and what kind of extension hooks are needed for 
ICE. The current drafts provide a good starting point for that, but 
probably there are other issues worth taking into consideration too.

I will be out of office without e-mail access for the next 4 weeks, but 
looking forward to discuss these issues with you all at Atlanta.


Cheers,
Ari

On 9/28/12 5:38 PM, Cullen Jennings (fluffy) wrote:
>
> I like this plan and thank you Ari.
>
>
>
> On Sep 27, 2012, at 7:16 AM, Miguel A. Garcia <[e-mail]> wrote:
>
>> Let me try to conclude this poll.
>>
>> We have seen a significant amount of people leaning towards option b. I reproduce hereby the selected option:
>>
>> b) Create a revision of ICE (obsoleting RFC 5245), but only addressing
>> bug fixing and opening hooks to extensions, with the idea that
>> extensions won't need to violate 5245bis. Additionally, document each
>> extension in a separate RFC. Extensions will depend and refer to the
>> 5245bis draft.
>>
>>
>> Then there were some comments indicating that we can go one step further and make ICE independent of the SDP Offer/answer, and document the SDP offer/answer for ICE in a different document.
>>
>> So, we should work with the assumption that there will be a kind of ICE framework, and the usages and extensions to it, of which, the SDP O/A usage will be one.
>>
>> To do this work, the chairs have been looking for a volunteer who has enough spare cycles and expertise to drive this work. We have recruited Ari Keranen to edit ICE-bis according to what we just described.
>>
>> Let's welcome Ari on board and thank him for committing to this effort.
>>
>> Due to other Ari's commitments and the current schedule, we expect the first version of 5245bis to be available after the IETF meeting in Atlanta.
>>
>>
>> /Miguel
>>
>>
>>
>> On 19/09/2012 9:23, Miguel A. Garcia wrote:
>>> Hi all,
>>>
>>> This mail relates to ICE [RFC 5245].
>>>
>>> In the past few months, we have seen a number of documents that are
>>> trying to improve the usage of ICE in different ways. The list of
>>> documents include at least the following drafts:
>>>
>>> - draft-keranen-mmusic-ice-address-selection-01
>>> - draft-petithuguenin-mmusic-ice-attributes-level-03
>>> - draft-wing-mmusic-ice-mobility-01
>>> - draft-elwell-mmusic-ice-updated-offer-02
>>>
>>> There is, in addition, a long discussion in the RTCWEB mailing list
>>> about "trickle ICE", and a couple of other ICE-related drafts
>>> and discussions in RTCWEB.
>>>
>>> Most likely, we can categorize these documents in two big classes:
>>>
>>> a) Documents that identify underspecified areas or errors in the spec,
>>> which are often driven by implementation experience
>>>
>>> b) Documents that update or extend ICE with new functionality, such as
>>> "tricke ICE" (see e.g. the e-mail thread at
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) .
>>> Such documents may involve normative updates to the ICE specification or
>>> they may simply be ICE extensions.".
>>>
>>> Assuming that we would get consensus to adopt some or all of these
>>> documents as work to proceed on, the MMUSIC chairs and RAI ADs would
>>> like to get some sense of how should we aim at documenting it. Below
>>> are some options, please comment on them or add alternatives.
>>>
>>> a) Create a revision of ICE (i.e., a document what will obsolete RFC
>>> 5245), including all the extensions and corrections that
>>> we want to choose from the list. This sounds like a big effort in
>>> time, and presumably will create a big spec. We should make sure that
>>> people have enough cycles to devote to this activity.
>>>
>>> b) Create a revision of ICE (obsoleting RFC 5245), but only addressing
>>> bug fixing and opening hooks to extensions, with the idea that
>>> extensions won't need to violate 5245bis. Additionally, document each
>>> extension in a separate RFC. Extensions will depend and refer to the
>>> 5245bis draft.
>>>
>>> c) Leave the current ICE core spec as is. Document each extension
>>> separately (referring to 5245). Create open or more documents listing
>>> bug fixes and corrections (will also update RFC 5245).
>>>
>>> Needless to say, at this point in time, there is no decision as for
>>> which of the ICE-related drafts will proceed or not. We are just
>>> trying to get consensus of how to document ICE-related drafts, and in
>>> particular if the WG believes we should do a revision of RFC 5245. If so,
>>> we also need to hear who is willing to work on such a revision.
>>>
>>> Now, it is your time to express your opinion.
>>>
>>> Kindly regards,
>>>
>>>           Flemming and Miguel.
>>>
>>
>> --
>> Miguel A. Garcia
>> [phone]
>> Ericsson Spain
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>