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

[Ari Keranen <[e-mail]>]

Hi,

The option B is probably the best in the long run, albeit C would likely 
have much faster time-to-market. If we do B, Marc's idea about splitting 
the SDP parts away sounds worth looking into.


Cheers,
Ari

On 9/19/12 10:23 AM, 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.