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

[Emil Ivov <[e-mail]>]

+1 for B

Although it might be tricky to classify some of the features you've
listed above as either extensions or enhancements. ICE trickle would be
one of those.

Emil

On 19.09.12, 09: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.
>