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

["Miguel A. Garcia" <[e-mail]>]

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