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

["Cullen Jennings (fluffy)" <[e-mail]>]

On Sep 19, 2012, at 1:23 AM, Miguel A. Garcia <[e-mail]> 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.

First of all, I think it is critical we do one of these and which one we choose is not as critical. 

>From the point of view of what would be best for folks implementing ICE, that would be a complete rewrite that fixed the problems and added in the new stuff. However that would be the most work to create at IETF. 

If some experienced editor has the time and energy to take on "A" I would be in favor of A. But if we don't have someone willing to step up to do that, then I would favor "B". 

Cullen