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

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/19/2012 12: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.

I support b), but I think that we should go one step further in this idea of
adding hooks for extensions.  ICE, as a general mechanism, is also used
outside of RFC3264/SDP, i.e in HIP (RFC 5770) and in RELOAD
(draft-ietf-p2psip-base).  So why not split RFC 5245 in two specs, one which
contains ICE without RFC3264/SDP but with the extension hooks (and bug
corrections), and an ICE over RFC3264/SDP extension, which itself will be
referred by other extensions.  We can then have RFC5770bis and p2psip-base
referring the first of these spec.

This is equivalent to what Jonathan Rosenberg tried to do with
draft-rosenberg-mmusic-ice-nonsip, but with -ice-nonsip becoming the base
draft, and RFC5245bis an extension of -ice-nonsip.

There is in my future an implementation of -ice-nonsip or equivalent (for
RELOAD), so I'll probably will be able to provide useful reviews to such document.

> 
> 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.

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQWyQYAAoJECnERZXWan7ENPoQAJdL65O8ALej8kivnOpynJ9T
G74fpc18KcsAWXRo88uvEpdtxpCmbiSfdor7tL21X9pOiaAuVi+I23VelxjcUV7v
ve9RgynPjtJXDkDGEyVy89epJ18Y4VtKTmrVr+9WPMfP4BcKqv03E3CrvmhzQ0BJ
dVqXOsNP9mjMou0fKIK0oth3pPzSgfKn9UTaPBYnLECRsuMieeBDB4CqSQy5B/ZH
2mt2rDF64Rn01EUaHWFjKefsyJzzjBtrlL19nY9D8AjKculOlcGa4JsuN1jB71BH
bSdjOrVRAADUUNGJowxmAPHM3hOir+XsSaqpLUBvvKX0GBZ9/R1Wt9mmmR7FNbUl
HptxKl1m4uG9+K5ALJ6QoFRQ6cSeIBlGDT48tqiiGL4dlhPyg5aEkk8nJLfefRro
ivnyYt8FsW06UrguosJl4SM5Feer1WRxNNTqErhED2uC3nicGnpruW2MGXWnga8f
hFCjsDCZX/F4zg213K7vjPoU4ky2vHHMSTJG5ErhPRLTQbMmc1r5KLjubPHh7Yxp
yiwtsjtJKtIbKvCl4G46rPnw2y9QwK0eGRcfN8voQmdRXhf3PiE1+CZYQPqbD1ze
i8JcHwTLA6VRwEdz5jrCynAedH2pTyzasY57/u4VFNkTRstz2aAKsr4ZRBb1FgZR
bedNmwA4arMHEdHX/+so
=g+hf
-----END PGP SIGNATURE-----