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

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 19 Sep 2012 09:23:09 +0200

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
+34-91-339-3608
Ericsson Spain

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 19 Sep 2012 16:50:45 +0000

On Sep 19, 2012, at 1:23 AM, Miguel A. Garcia <[email-masked]> wrote:

> a) Create a revision of ICE (i.e., a document what will obsolete RFC 5245), including all the extensions and corrections that
> 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.
> 

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

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 19 Sep 2012 18:08:08 +0000

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

> 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…
I think one of the things that slows down the adoption rate of ICE is that people still seems to have this feeling that ICE is still unstable and not proven.  The different flavours of ICE out in the wild might suggest that they are right. 

Developing a ICE stack is also a fair amount of work and have a minimum set of features described in a core specification  would help developers focus on the right things. And then add the extensions later. Would make interop testing at SipIT easier as well.

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

I would favour B then C and at last  A.

.-.
Pål-Erik

> Cullen
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Sep 2012 09:29:13 +0200

Hi,

My preference is for ensuring something is done, and I would prefer the
method B.

cheers

Magnus Westerlund

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Sep 2012 12:32:14 +0200

My personal 2 cents:

The most wrong thing here is doing nothing at all, blocking progress on 
ICE refinement/extension work. This will result in people doing private 
extensions without findable, publicly reviewed documentation. Luckily, 
that's not a proposed alternative.

The second most wrong thing is to make everything depend on everything 
else, so that nothing comes out of the process until everything's 
finished. Given our collective experience with finishing ICE specs, this 
could easily become indistinguishable from the most wrong thing.
This is what I'm afraid will happen if we choose alternative a) below.

Looking at the alternatives:

> people have enough cycles to devote to this activity.
As should be clear from the above, I do not prefer this.
> extension in a separate RFC. Extensions will depend and refer to the
(Tangent: I would like to extend this to one more task: If any piece or 
aspect of RFC 5245 can be isolated from the base spec and made into a 
separate document, it should be. RFC 5245, at 117 pretty dense pages, is 
a mouthful.)

This is the approach that's been taken with, for instance, SMTP (RFC 822 
/ 2822 / 5322).
> bug fixes and corrections (will also update RFC 5245). 
This is the approach taken with the DNS, leading to these wonderfully 
transparent protocol definitions from the RFC index:

1034 Domain names - concepts and facilities. P.V. Mockapetris.
      November 1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973,
      RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876,
      RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034,
      RFC4035, RFC4343, RFC4035, RFC4592, RFC5936) (Also STD0013) (Status:
      STANDARD)

1035 Domain names - implementation and specification. P.V.
      Mockapetris. November 1987. (Format: TXT=125626 bytes) (Obsoletes
      RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348,
      RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181,
      RFC2137, RFC2308, RFC2535, RFC2845, RFC3425, RFC3658, RFC4033,
      RFC4034, RFC4035, RFC4343, RFC5936, RFC5966) (Also STD0013) (Status:
      STANDARD)

Both B and C are approaches we have experience with, and neither has 
been abandoned by the people who used them.

However, I have a strong preference for the document structure that 
comes out of doing B.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 20 Sep 2012 07:11:38 -0700

On 09/19/2012 12:23 AM, Miguel A. Garcia wrote:
> 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.
> 
> 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.".
> 
> 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.
> 
> 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.

> 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: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Sep 2012 07:13:28 -0700

I'm in favor of option B.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 20 Sep 2012 16:23:13 +0200

+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

---

From: Ari Keranen <[email-masked]>
Date: Fri, 21 Sep 2012 16:43:25 +0300

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 27 Sep 2012 15:16:24 +0200

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:

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

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 28 Sep 2012 14:38:28 +0000

I like this plan and thank you Ari. 

On Sep 27, 2012, at 7:16 AM, Miguel A. Garcia <[email-masked]> wrote:

> We have seen a significant amount of people leaning towards option b. I reproduce hereby the selected option:
> 
> 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.
> 
> 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
> 
> 
>

---

From: Ari Keranen <[email-masked]>
Date: Mon, 01 Oct 2012 00:33:30 +0300

Thanks Cullen and Miguel.

Everyone, now is a good time to start thinking and discussing what are 
the bugs we want to fix and what kind of extension hooks are needed for 
ICE. The current drafts provide a good starting point for that, but 
probably there are other issues worth taking into consideration too.

I will be out of office without e-mail access for the next 4 weeks, but 
looking forward to discuss these issues with you all at Atlanta.

Cheers,
Ari