Subject: Re: [art] [clue] ICE, ICE-bis, and Cluster 238

From: "Roni Even (A)" <[email-masked]>
Date: Tue, 4 Sep 2018 09:16:25 +0000

Hi Adam,

Is there a real need to update draft-ietf-clue-signaling-13

There is an informative reference to RFC5245 and the text is

A CLUE call may involve sending and/or receiving significant numbers
   of media streams.  Conventionally, media streams are sent and
   received on unique ports.  However, each separate port used for this
   purpose may impose costs that a device wishes to avoid, such as the
   need to open that port on firewalls and NATs, the need to collect ICE
   candidates [RFC5245<https://tools.ietf.org/html/rfc5245>], etc.

So since RFC8445b obsolete RFC5245 this is not a major issue.

Anyhow I will ask the authors to update the document

Roni Even

From: clue [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Wednesday, August 29, 2018 9:13 PM
To: Applications and Real-Time Area Discussion
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [clue] ICE, ICE-bis, and Cluster 238

It's been a week; so far there have been no objections to this plan, and several messages in support. I plan to consult with the other ART ADs to evaluate consensus on this proposal next week, and take appropriate action. If you have thoughts to share, please send them to the ART mailing list before September 5th.

Thanks!

/a

On 8/22/18 12:58 PM, Adam Roach wrote:
Members of the ART community interested in real-time communications:

Cluster 238 [1] is a set of inter-related documents dealing with real-time communications. The bulk of these documents relate to WebRTC, either directly or indirectly. They also form the underpinnings of CLUE. As of now, there are 34 documents in the cluster that are not yet published, with 25 of these already in the RFC Editor's queue. The dependency graph among these documents is such that the bulk of them can be published as soon as a specific six of them are handed off to the RFC editor, and we expect this to happen in the upcoming few months.

One long-running complication for this cluster of documents is that each of the documents were developed over the course of seven years, in concert with implementations, while the ICE protocol itself was undergoing significant revision. As a consequence, some documents rely (directly or indirectly) on the older ICE specification (RFC 5245), while some rely on the newer one (RFC 8445). In some cases, documents refer directly to the old version and transitively to the new version.

It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the mechanism described in RFC 8445 has some  changes that break backwards compatibility with the mechanism defined in RFC 5245 (with such behavioral changes controlled by an SDP attribute, allowing clients to transition from one to the other).

Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC protocol in the IETF) refers to directly to RFC 5245, while relying on the behavior defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 handling. JSEP's reference to RFC 5245 is a practical consideration that acknowledges that current deployments of WebRTC implement the older version of ICE. At the same time, these deployed implementations use a somewhat older version of draft-ietf-ice-trickle in concert with the older ICE implementation.

In order to get Cluster 238 published, we need to find some way to rationalize its references to ICE. At a basic level, the ART Area Directors do not believe that it makes sense to publish new documents that refer to an already obsoleted RFC. At the same time, we recognize that there is value in our specifications being informed by running code. For WebRTC, the complexity of the system has led us to a point that we must choose between these principles. Our proposal is to choose the first, while acknowledging the second.

This would result in a request to the RFC editor to update all references to RFC 5245 in the Cluster 238 documents to instead point to RFC 8445. Documents not yet in the RFC editor queue would be updated prior to IESG review. We would further request that the RFC editor add the following text to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep:
While this specification formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245], and use a pre-standard version of the trickle ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one.
RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative.

There is one more minor complication, in that draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 5245) is intended to be an exhaustive list of the SDP attributes defined in the documents it lists, and RFC 8445 adds a new "ice2" attribute that was not present in RFC 5245. For this reason, we would also ask the RFC Editor to add a new row to the table in draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows:

   +-------------------+---------------------------+-------+-----------+

   | Name              | Notes                     | Level | Mux       |

   |                   |                           |       | Category  |

   +-------------------+---------------------------+-------+-----------+

   | ice2              | Not Impacted              | S     | NORMAL    |

   |                   |                           |       |           |

   +-------------------+---------------------------+-------+-----------+

For clarity, the affected documents are as follows.

The following documents would be updated to reference RFC 8445 prior to IESG evaluation:

  *   draft-ietf-clue-datachannel
  *   draft-ietf-clue-signaling
  *   draft-ietf-rtcweb-security
  *   draft-ietf-rtcweb-security-arch

The following documents would be updated to reference RFC 8445 by the RFC Editor:

  *   draft-ietf-mmusic-mux-exclusive
  *   draft-ietf-mmusic-sctp-sdp
  *   draft-ietf-rtcweb-alpn
  *   draft-ietf-rtcweb-data-channel
  *   draft-ietf-rtcweb-rtp-usage

The following documents would be updated to reference RFC 8445 and have the text proposed above added to them:

  *   draft-ietf-rtcweb-jsep
  *   draft-ietf-rtcweb-overview

The following document would be updated to reference RFC 8445 by the RFC Editor, and include a new row for "ice2" in its Section 5.12, as described above:

  *   draft-ietf-mmusic-sdp-mux-attributes

This message is cross-posted to the affected working groups. Because the issue at hand has impact across several different groups, we ask that all follow-up discussion take place on <[email-masked]><mailto:[email-masked]>. Thank you.

/Adam on behalf of the ART Area Directors

____
[1] https://www.rfc-editor.org/cluster_info.php?cid=C238

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 6 Sep 2018 13:24:45 -0700

I object to this plan. 

It is not merely an issue of which document we point out, and they are all the same. The problem is the timing of 8445 is not clearly interoperable with the timing of 5245. ICE relies on both sides to do sequence things at roughly the same order so that suicided packets open pinholes in the reverse direction at the right time. The changes in timing change how this happens and is a problem for the ICE algorithm. 

This was discussed in the WG, and though not everyone agrees it is a problem or not, no one has ever provided a convincing argument that it is not. This is a very substantial change to the on the wire protocol and at a minimum would need to be reviewed and discussed in the WG not slipped through in Auth 48 during a one week period in the summer while everyone is on vacation. We will also need to change other examples and normative text in drafts like JSEP. 

I would propose that instead of the parts of specs that use the trickle mechanism purely reference that part of the new ICE spec that defines the syntax and say to transfer trickle candidates. 

Cisco has implemented stuff that is WebRTC 1.0 compliant without this change. These gratuitous changes, years after the implementation were coded, with no real benefit will ensure that we are not and will not become compliant with the RFC. It's unlikely we will upgrade to the new ICE until it has real befits. It is doubtful Justin will want to implement the 8445 mechanisms of supporting both new and old ICE. Instead, we will move to say "works with Browser X version Y or later." We have watched at W3C as it moved to be that unless chrome does it, it rare that it becomes a standard.  Right here I am watching how the stuff IETF defines will be less relevant than the issue of what chrome implements. 

> On Aug 22, 2018, at 10:58 AM, Adam Roach <[email-masked]> wrote:
> 
> draft-ietf-clue-datachannel
> draft-ietf-clue-signaling
> draft-ietf-rtcweb-security
> draft-ietf-rtcweb-security-arch
> 
> draft-ietf-mmusic-mux-exclusive
> draft-ietf-mmusic-sctp-sdp
> draft-ietf-rtcweb-alpn
> draft-ietf-rtcweb-data-channel
> draft-ietf-rtcweb-rtp-usage
> 
> draft-ietf-rtcweb-jsep
> draft-ietf-rtcweb-overview
> 
> draft-ietf-mmusic-sdp-mux-attributes
> 
> This message is cross-posted to the affected working groups. Because the issue at hand has impact across several different groups, we ask that all follow-up discussion take place on <[email-masked]> <mailto:[email-masked]>. Thank you.
> 
> [1] https://www.rfc-editor.org/cluster_info.php?cid=C238 <https://www.rfc-editor.org/cluster_info.php?cid=C238>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 6 Sep 2018 13:40:59 -0700

On Thu, Sep 6, 2018 at 1:25 PM Cullen Jennings <[email-masked]> wrote:

>
>  It's unlikely we will upgrade to the new ICE until it has real benefits.
>

[BA] Do not worry. Since there are limited benefits in 8445, upgrades will
be slow to arrive at best, except perhaps if they are bundled with Trickle
support.

It is doubtful Justin will want to implement the 8445 mechanisms of
> supporting both new and old ICE.
>

[BA] Yes, the 8445 negotiation mechanism never really made sense (though
Trickle negotiation does make sense).

Right here I am watching how the stuff IETF defines will be less relevant
> than the issue of what chrome implements.
>

[BA] Implementations have always mattered. What has changed is that the
IETF seems to be paying less attention to cost/benefit tradeoffs.

> Cluster 238 [1] is a set of inter-related documents dealing with real-time
> communications. The bulk of these documents relate to WebRTC, either
> directly or indirectly. They also form the underpinnings of CLUE. As of
> now, there are 34 documents in the cluster that are not yet published, with
> 25 of these already in the RFC Editor's queue. The dependency graph among
> these documents is such that the bulk of them can be published as soon as a
> specific six of them are handed off to the RFC editor, and we expect this
> to happen in the upcoming few months.
>
> One long-running complication for this cluster of documents is that each
> of the documents were developed over the course of seven years, in concert
> with implementations, while the ICE protocol itself was undergoing
> significant revision. As a consequence, some documents rely (directly or
> indirectly) on the older ICE specification (RFC 5245), while some rely on
> the newer one (RFC 8445). In some cases, documents refer directly to the
> old version and transitively to the new version.
>
> It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the mechanism
> described in RFC 8445 has some  changes that break backwards compatibility
> with the mechanism defined in RFC 5245 (with such behavioral changes
> controlled by an SDP attribute, allowing clients to transition from one to
> the other).
>
> Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC protocol in
> the IETF) refers to directly to RFC 5245, while relying on the behavior
> defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in turn, is
> based on the newer RFC 8445 handling. JSEP's reference to RFC 5245 is a
> practical consideration that acknowledges that current deployments of
> WebRTC implement the older version of ICE. At the same time, these deployed
> implementations use a somewhat older version of draft-ietf-ice-trickle in
> concert with the older ICE implementation.
>
> In order to get Cluster 238 published, we need to find some way to
> rationalize its references to ICE. At a basic level, the ART Area Directors
> do not believe that it makes sense to publish new documents that refer to
> an already obsoleted RFC. At the same time, we recognize that there is
> value in our specifications being informed by running code. For WebRTC, the
> complexity of the system has led us to a point that we must choose between
> these principles. Our proposal is to choose the first, while acknowledging
> the second.
>
> This would result in a request to the RFC editor to update all references
> to RFC 5245 in the Cluster 238 documents to instead point to RFC 8445.
> Documents not yet in the RFC editor queue would be updated prior to IESG
> review. We would further request that the RFC editor add the following text
> to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep:
>
> While this specification formally relies on [RFC8445], at the time of its
> publication, the majority of WebRTC implementations support the version of
> ICE described in [RFC5245], and use a pre-standard version of the trickle
> ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute
> defined in [RFC8445] can be used to detect the version in use by a remote
> endpoint and to provide a smooth transition from the older specification to
> the newer one.
>
> There is one more minor complication, in that
> draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 5245)
> is intended to be an exhaustive list of the SDP attributes defined in the
> documents it lists, and RFC 8445 adds a new "ice2" attribute that was not
> present in RFC 5245. For this reason, we would also ask the RFC Editor to
> add a new row to the table in draft-ietf-mmusic-sdp-mux-attributes section
> 5.12, as follows:
>
>    - draft-ietf-clue-datachannel
>    - draft-ietf-clue-signaling
>    - draft-ietf-rtcweb-security
>    - draft-ietf-rtcweb-security-arch
>
>
>    - draft-ietf-mmusic-mux-exclusive
>    - draft-ietf-mmusic-sctp-sdp
>    - draft-ietf-rtcweb-alpn
>    - draft-ietf-rtcweb-data-channel
>    - draft-ietf-rtcweb-rtp-usage
>
>
>    - draft-ietf-rtcweb-jsep
>    - draft-ietf-rtcweb-overview
>
>
> The following document would be updated to reference RFC 8445 by the RFC
> Editor, and include a new row for "ice2" in its Section 5.12, as described
> above:
>
>    - draft-ietf-mmusic-sdp-mux-attributes
>
>
> This message is cross-posted to the affected working groups. Because the
> issue at hand has impact across several different groups, we ask that all
> follow-up discussion take place on <[email-masked]> <[email-masked]>. Thank
> you.
>
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 6 Sep 2018 19:54:08 -0500

On 9/6/18 3:24 PM, Cullen Jennings wrote:
> I would propose that instead of the parts of specs that use the 
> trickle mechanism purely reference that part of the new ICE spec that 
> defines the syntax and say to transfer trickle candidates.

Unfortunately, it's not quite so simple. The mismatch with trickle-ice 
is only the most obvious problem. In practice, there are a few dozen 
places where unpublished documents in the cluster refer directly to one 
version of ICE, and indirectly to another, or indirectly to both.

To help wrap our collective minds around this issue, I've put together a 
dependency graph that shows which Cluster 238 documents refer to which 
version of ICE. The red lines indicate references (directly or 
indirectly) to RFC 5245, while the purple lines indicate references to 
RFC 8445. The thickness of the line indicates how many hops away from 
ICE the reference is. Dotted lines are informative references.

https://trac.ietf.org/trac/art/wiki/c238

To put a finer point on this, it took me a couple of hours to pare this 
graph down to something that was small enough to look at and actually 
understand -- there are actually twice as many documents involved in 
this mess, but including them makes the situation too confusing to even 
start to get a grip on.

Everywhere you see a purple document with a red arrow or vice-versa is a 
place we need to figure out how to handle this mismatch. You can push 
the boundaries around, but the count of mismatches is pretty much the 
same no matter how you do that. On a first order estimation, this is 
days -- or, more likely, weeks of work. And I'm talking about 
person-hours, not calendar time. If you can do this, or find someone to 
step up and do it, then your proposal would be a viable alternative to 
the one that the ART ADs have proposed. Short of that, I'm not sure how 
we can do what you want.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2018 07:25:13 +0000

Hi,

> I object to this plan.
>
> It is not merely an issue of which document we point out, and they are all the same. The problem is the timing of 8445 is not clearly interoperable with the timing of 5245. ICE relies on both
> sides to do sequence things at roughly the same order so that suicided packets open pinholes in the reverse direction at the right time. The changes in timing change how this happens and is a problem for the ICE algorithm.
>
> This was discussed in the WG, and though not everyone agrees it is a problem or not, no one has ever provided a convincing argument that it is not. This is a very substantial change to the on the wire protocol and at a minimum
> would need to be reviewed and discussed in the WG not slipped through in Auth 48 during a one week period in the summer while everyone is on vacation. We will also need to change other examples and normative text in drafts like JSEP.

What normative text do you need to change in JSEP?

In fact, I would even claim that the JSEP text is more aligned with 8445 than 5245. For example, JSEP does not talk about aggressive and normative nomination, only about nomination.

> I would propose that instead of the parts of specs that use the trickle mechanism purely reference that part of the new ICE spec that defines the syntax and say to transfer trickle candidates.

It is not only about the syntax. The trickle procedures are based on procedures in 8445.

> Cisco has implemented stuff that is WebRTC 1.0 compliant without this change. These gratuitous changes, years after the implementation were coded, with no real benefit will ensure that we are not
> and will not become compliant with the RFC. It's unlikely we will upgrade to the new ICE until it has real befits.

The main reason we did 8445 was because people had identified issues with 5245. The work was driven mostly by the WebRTC community, including yourself and the Chrome people (or, at least the Google people), and one of the reason it took time to finalize 8445 was because you (among others) wanted to make sure we get things right (by making network measurements etc). Are you now saying all those changes bring no benefit? Did we all waste our time?

> It is doubtful Justin will want to implement the 8445 mechanisms of supporting both new and old ICE. Instead, we will move to say "works with Browser X version Y or later." We have watched at W3C as it moved to be that unless chrome does it, it rare that it becomes a standard.
> Right here I am watching how the stuff IETF defines will be less relevant than the issue of what chrome implements.

What exactly would Justin have to change?

Regards,

Christer

On Aug 22, 2018, at 10:58 AM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

   |                   |                           |       | Category  |

   |                   |                           |       |           |

  *   draft-ietf-rtcweb-jsep

[email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2018 07:31:17 +0000

Hi,

>> It is doubtful Justin will want to implement the 8445 mechanisms of supporting both new and old ICE. 
>
> [BA] Yes, the 8445 negotiation mechanism never really made sense (though Trickle negotiation does make sense). 

Exactly what 8445 negotiation mechanism does not make sense, compared to 5245?

> [BA] Implementations have always mattered. What has changed is that the IETF seems to be paying less attention to cost/benefit tradeoffs.

I can't of course speak for everyone, but some implementers I talked to during the years of work on 8445 told me that the way they implemented 5245 was actually more 8445 than 5245.

Regards,

Christer

On Aug 22, 2018, at 10:58 AM, Adam Roach <mailto:[email-masked]> wrote:

For clarity, the affected documents are as follows.
The following documents would be updated to reference RFC 8445 prior to IESG evaluation:
• draft-ietf-clue-datachannel
• draft-ietf-clue-signaling 
• draft-ietf-rtcweb-security 
• draft-ietf-rtcweb-security-arch 

The following documents would be updated to reference RFC 8445 by the RFC Editor:
• draft-ietf-mmusic-mux-exclusive
• draft-ietf-mmusic-sctp-sdp 
• draft-ietf-rtcweb-alpn 
• draft-ietf-rtcweb-data-channel 
• draft-ietf-rtcweb-rtp-usage 

The following documents would be updated to reference RFC 8445 and have the text proposed above added to them:
• draft-ietf-rtcweb-jsep 
• draft-ietf-rtcweb-overview 

The following document would be updated to reference RFC 8445 by the RFC Editor, and include a new row for "ice2" in its Section 5.12, as described above:
• draft-ietf-mmusic-sdp-mux-attributes 

This message is cross-posted to the affected working groups. Because the issue at hand has impact across several different groups, we ask that all follow-up discussion take place on mailto:[email-masked]. Thank you.
mailto:[email-masked]

mailto:[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Sep 2018 10:24:40 -0600

That’s a very useful graph but when I look at the what is actually used in the purple links, most of them seem they could trivial work with any version of ICE with the exception of the few places trickle is used and need the explicit stuff around how to deal with trickle. 

> On Sep 6, 2018, at 6:54 PM, Adam Roach <[email-masked]> wrote:
> 
> Unfortunately, it's not quite so simple. The mismatch with trickle-ice is only the most obvious problem. In practice, there are a few dozen places where unpublished documents in the cluster refer directly to one version of ICE, and indirectly to another, or indirectly to both.
> 
> To help wrap our collective minds around this issue, I've put together a dependency graph that shows which Cluster 238 documents refer to which version of ICE. The red lines indicate references (directly or indirectly) to RFC 5245, while the purple lines indicate references to RFC 8445. The thickness of the line indicates how many hops away from ICE the reference is. Dotted lines are informative references.
> 
> To put a finer point on this, it took me a couple of hours to pare this graph down to something that was small enough to look at and actually understand -- there are actually twice as many documents involved in this mess, but including them makes the situation too confusing to even start to get a grip on.
> 
> Everywhere you see a purple document with a red arrow or vice-versa is a place we need to figure out how to handle this mismatch. You can push the boundaries around, but the count of mismatches is pretty much the same no matter how you do that. On a first order estimation, this is days -- or, more likely, weeks of work. And I'm talking about person-hours, not calendar time. If you can do this, or find someone to step up and do it, then your proposal would be a viable alternative to the one that the ART ADs have proposed. Short of that, I'm not sure how we can do what you want.
> 
> /a
> 
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Sep 2018 10:36:35 -0600

> On Sep 7, 2018, at 1:25 AM, Christer Holmberg <[email-masked]> wrote:
> 

Our testing, which we do not share, dig not indicate an improvement of connectivity rates. I did not see results from others that did. Some of the early test results from others that drove this work were not reproducible in our testing. The one thing I think most people did find is that the more out of sync the pacing of the two agents was, the worse the connectivity was. But all of this is water under the bridge, we have old and new ice, people can use either. What we are talking about here is what is the minimum bar for WebRTC 1.0 

> What exactly would Justin have to change?

For us, the largest part is having to test for both old and new - it’s not easy to do good automated testing for ICE.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2018 18:25:56 +0000

Hi,

>>> Cisco has implemented stuff that is WebRTC 1.0 compliant without this change. These gratuitous 
>>> changes, years after the implementation were coded, with no real benefit will ensure that we are not
>> The main reason we did 8445 was because people had identified issues with 5245. The work was driven 
>> mostly by the WebRTC community, including yourself and the Chrome people (or, at least the Google people), 
>> and one of the reason it took time to finalize 8445 was because you (among others) wanted to make sure we get 
>> things right (by making network measurements etc). Are you now saying all those changes bring no benefit? Did 
>> we all waste our time?
>
>Our testing, which we do not share, 

I am talking about the test results that were shared (by Google, if I remember correctly) at one of the IETF meetings, which we used to modify some timer values. I'd have to dig in the archives for the details, but you said we can't move the draft forward before we get those results, and I think we waited 1-2 meeting cycles from them.

Note that I am not blaming you for wanting to set values based on real-life experience - that's a good thing. I am just surprised that everything we did now seems like a waste of time.

> dig not indicate an improvement of connectivity rates. I did not see results from others that did. Some of the early test results from 
> others that drove this work were not reproducible in our testing. The one thing I think most people did find is that the more out of 
> sync the pacing of the two agents was, the worse the connectivity was. But all of this is water under the bridge, we have old and 
> new ice, people can use either. What we are talking about here is what is the minimum bar for WebRTC 1.0 

Correct me if I'm wrong, but WebRTC 1.0 does use trickle, and does not use aggressive nomination. Trickle is based on 8445, and aggressive nomination was deprecated in 8445. So, what exactly are you suggesting the minimum bar for WebRTC 1.0 should be? Some "profile" of 5245?
 
>>> It is doubtful Justin will want to implement the 8445 mechanisms of supporting both new and old ICE. Instead, we will move 
>>> to say "works with Browser X version Y or later." We have watched at W3C as it moved to be that unless chrome does it, it rare 
>>> that it becomes a standard.  

So, against what spec do you test trickle? 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2018 18:28:54 +0000

Hi,

>That’s a very useful graph but when I look at the what is actually used in the purple links, >most of them seem they could trivial work with any version of ICE with the exception of the >few places trickle is used and need the explicit stuff around how to deal with trickle. 

Trickle is based on "Emil's table", which is one of the major things we did in 8445. So, if you implement that for trickle, you've implemented most of 8445 :)

The other major thing we did in 8445 was the removal of aggressive nomination, which many seem to have done in their current implementations anyway...

Regards,

Christer

_______________________________________________
Ice mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ice

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 Sep 2018 12:49:17 -0700

On Sep 7, 2018, at 11:25 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Correct me if I'm wrong, but WebRTC 1.0 does use trickle, and does not use aggressive nomination. Trickle is based on 8445, and aggressive nomination was deprecated in 8445. So, what exactly are you suggesting the minimum bar for WebRTC 1.0 should be?

[BA] I am wary of attempts to support too many variations in the matrix of “Full Trickle”/“Half Trickle” and 8445/5245.

IMHO, the most likely variants are “Full Trickle”/8445 and perhaps “Half Trickle”/5245 although I would hope the later will be quickly superceded by the former.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 7 Sep 2018 13:55:36 -0600

[paring back to the distribution lists originally requested by ADs]

On 9/7/18 12:25 PM, Christer Holmberg wrote:

> Correct me if I'm wrong, but WebRTC 1.0 does use trickle, and does not use aggressive nomination. Trickle is based on 8445, and aggressive nomination was deprecated in 8445.

One clarification: the trickle technique has been in use since 2005 and
interoperated with ICE all that time (at least in Jingle/XMPP). However,
draft-ietf-ice-trickle is indeed specified in terms of 8445.

Peter

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 7 Sep 2018 12:56:02 -0700

> On Sep 7, 2018, at 11:25, Christer Holmberg <[email-masked]> wrote:
> Correct me if I'm wrong, but WebRTC 1.0 does use trickle, and does not use aggressive nomination.

Sorry but that is not correct. Firefox does use aggressive nomination. Chrome (and everyone who copies their full stack including their ICE implementation) does not. I’m not aware of any normative language for any of the WebRTC specs demanding to use full nomination only.

Best
  Nils Ohlmeier

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 7 Sep 2018 13:01:09 -0700

> On Sep 6, 2018, at 13:24, Cullen Jennings <[email-masked]> wrote:
> 
> 
> Cisco has implemented stuff that is WebRTC 1.0 compliant without this change. These gratuitous changes, years after the implementation were coded, with no real benefit will ensure that we are not and will not become compliant with the RFC. It's unlikely we will upgrade to the new ICE until it has real befits. It is doubtful Justin will want to implement the 8445 mechanisms of supporting both new and old ICE. Instead, we will move to say "works with Browser X version Y or later.”

Obviously I’m not Justin.
But the current plan for Firefox is to implement support for 8845 some time in 2019 and then have support for 5245 and 8845 going forward.

Best regards
  Nils Ohlmeier

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 8 Sep 2018 07:48:34 +0000

Hi Nils,

>> Cisco has implemented stuff that is WebRTC 1.0 compliant without this change. These 
>> gratuitous changes, years after the implementation were coded, with no real benefit 
>> will ensure that we are not and will not become compliant with the RFC. It's unlikely we 
>> will upgrade to the new ICE until it has real befits. It is doubtful Justin will want to implement 
>> the 8445 mechanisms of supporting both new and old ICE. Instead, we will move to say "works 
>> with Browser X version Y or later.”
>

Do you have any ideas, on a high level, how big the differences will be?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 8 Sep 2018 07:56:46 +0000

Hi,

>>> dig not indicate an improvement of connectivity rates. I did not see 
>>> results from others that did. Some of the early test results from 
>>> others that drove this work were not reproducible in our testing. The 
>>> one thing I think most people did find is that the more out of sync 
>>> the pacing of the two agents was, the worse the connectivity was. But 
>>> all of this is water under the bridge, we have old and new ice, 
>>> people can use either. What we are talking about here is what is the 
>>> minimum bar for WebRTC 1.0
>> 
> Sorry but that is not correct. Firefox does use aggressive nomination. Chrome (and everyone who copies their 
> full stack including their ICE implementation) does not. I’m not aware of any normative language for any of the 
> WebRTC specs demanding to use full nomination only.

With "full nomination" I assume you mean regular nomination (as defined in 5245)?

My point was that WebRTC defines the usage of "nomination", which is the terminology 8445 uses. I am not saying it's forbidden to use aggressive nomination, but as far as I know (I may be wrong) usage of it is not mentioned anywhere. 

Regards,

Christer

---

From: John C Klensin <[email-masked]>
Date: Sun, 09 Sep 2018 11:31:09 -0400

--On Thursday, September 6, 2018 19:54 -0500 Adam Roach
<[email-masked]> wrote:

>> I would propose that instead of the parts of specs that use
>> the  trickle mechanism purely reference that part of the new
>> ICE spec that  defines the syntax and say to transfer trickle
>> candidates.
> 
> 
> Unfortunately, it's not quite so simple. The mismatch with
> trickle-ice is only the most obvious problem. In practice,
> there are a few dozen places where unpublished documents in
> the cluster refer directly to one version of ICE, and
> indirectly to another, or indirectly to both.
>...
> To put a finer point on this, it took me a couple of hours to
> pare this graph down to something that was small enough to
> look at and actually understand -- there are actually twice as
> many documents involved in this mess, but including them makes
> the situation too confusing to even start to get a grip on.

Adam,

Largely from a procedural standpoint, some observations:

(1) The graph is very useful, at least to illustrate the
complexity of the situation we have gotten ourselves into.  My
sense as an outsider to RTC work is that your proposed way to
handle the situation is the least-bad of a number of bad
choices.   I hope the ART ADs, and the IESG in general, are
looking at way to prevent similar situations in the future as
the very fact that this discussion is necessary strongly
suggests bad choices in the past.

(2) One of the things the discussion, the graph, and comments by
Cullen and others point out is that the classification of 5245
as obsolete when 8445 was published was aspirational rather than
a reflection of contemporary practice or reasonable expectations
for the near future (aka "running code").  It might not help
with the dependency graph, but the procedural issue would
perhaps be at least mitigated if, instead of obsoleting 5245,
8445 had simply updated it and included (or been supplemented
by) a carefully-written Applicability Statement discussing the
implementation choices, the IETF's recommendations, the reasons
for them, and, if those recommendations did not have significant
(not just rough) consensus, a discussion of the other positions.
The situation also reflects a view that some of us have been
expressing for some years, which is that the IETF should be
using "obsoletes" (and, btw, "historic") only very carefully
until and unless those terms are defined much more precisely.

It is interesting that, while it is stated in different
language, 8445 appears to me to contain most of what would be
needed in an A/S about its relationship to STUN (in Sections 17
and 18) but not for the relationship to the RFC 5245 version of
ICE

(3) Several people have suggested that these changes in
references could actually have substantive implications for at
least some of the protocols of which the references contain
normative information.  Given that, having the RFC Editor make
these changes at the direction of the ART ADs as part of the
AUTH48 process seems to me to be inappropriate.  The changes
should be proposed, new I-Ds generated, and those I-Ds referred
back to the originating WGs for consideration followed by an
IETF Last Call on those changes.  If nothing else, look at it
this way: if an error were made or a change turned out to be
controversial, it would be far better if those situations
occurred only after there was a formal opportunity for community
review and for all materially concerned parties to check the
results rather than having them produced (and hidden) by an
administrative procedure.  

regards,
    john

---

From: Adam Roach <[email-masked]>
Date: Sun, 9 Sep 2018 14:10:56 -0500

John --

Thanks for weighing in with your perspective. Your first point is one 
that the IESG has been aware of for some time, and I plan to conduct a 
post-mortem of some kind once Cluster 238 has finally been published. I 
appreciate that your second point has lessons to teach us as well, and 
note that the IESG has specifically been pondering the meaning of 
"Updates" recently.

Your third point is the one that bears on the topic at hand (rather than 
pointing to opportunities for lessons learned for future endeavors), so 
I leave it quoted below.

> administrative procedure.

We (the ART ADs) agree that this is a matter that needs discussion in 
the impacted working groups, which is precisely why this thread exists. 
I'm glad that you spoke up on this point, though, since it points out 
that this course of action might look like a late surprise to those 
parties who have not been involved in the impacted documents and working 
groups.

The initial plan for dealing with this situation was announced by the 
RTCWEB chairs en bloc in October of 2017: "The chairs and AD believe 
that this issue will be addressed as cluster 238... gets untangled" [1], 
a plan which one of the ART ADs reiterated in May of this year [2].

Later that month, the RTCWEB chairs made it explicit, at least to their 
working group, that this untangling was expected to take place as an 
administrative matter during AUTH48: "instead of arguing about whether 
to refer ICE or ICE-bis now when [draft-ietf-rtcweb-]overview is going 
to get stuck anyway let’s let the process run it’s course: if 
trickle-ICE is going to get done about the same time as ICE-bis then 
great we can update the references in AUTH48 and if not we can figure 
out plan B." [3]

To be clear, if this proposal were a late surprise sprung on the 
relevant working groups, then I agree with you that the issue would 
require more than the actions contained in the thread to date. The plan 
that led to the proposal at the top of this thread has been known to the 
relevant working groups for nearly a year, which is a somewhat different 
situation. Again, I'm glad that you raised the issue so that I could 
clarify that these actions are not being taken in a vacuum.

Thanks again,

/a

____
[1] https://mailarchive.ietf.org/arch/msg/rtcweb/IJj0EGeFAZmDCK03sReZFbC24_M
[2] https://mailarchive.ietf.org/arch/msg/rtcweb/KxZHcCbn-U3Fzyn6OZi3l9N1wc0
[3] https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8

---

From: John C Klensin <[email-masked]>
Date: Sun, 09 Sep 2018 18:00:49 -0400

Adam,

Thanks for the kind words and clarification... I think we may
still have a difference of opinion, so let me attempt to clarify
further on that point...

--On Sunday, September 9, 2018 14:10 -0500 Adam Roach
<[email-masked]> wrote:

>...
> We (the ART ADs) agree that this is a matter that needs
> discussion in the impacted working groups, which is precisely
> why this thread exists. I'm glad that you spoke up on this
> point, though, since it points out that this course of action
> might look like a late surprise to those parties who have not
> been involved in the impacted documents and working groups.

Agreed and understood.  However, standards track documents are
supposed to represent IETF [rough] consensus, not just WG
consensus, so there may still be an issue.  Moreover...

> The initial plan for dealing with this situation was announced
> by the RTCWEB chairs en bloc in October of 2017: "The chairs
> and AD believe that this issue will be addressed as cluster
> 238... gets untangled" [1], a plan which one of the ART ADs
> reiterated in May of this year [2].

I assume, or at least hope, that the announcement of that plan
was followed by a WG discussion, an opportunity for any dissents
to be aired, and by some sense of WG consensus that the plan was
ok.    A situation in which the WG Chairs and ADs were making a
decision and imposing it on the WG would be very bad news, so I
assume it did not occur.

> Later that month, the RTCWEB chairs made it explicit, at least
> to their working group, that this untangling was expected to
> take place as an administrative matter during AUTH48: "instead
> of arguing about whether to refer ICE or ICE-bis now when
> [draft-ietf-rtcweb-]overview is going to get stuck anyway
> let's let the process run it's course: if trickle-ICE is
> going to get done about the same time as ICE-bis then great we
> can update the references in AUTH48 and if not we can figure
> out plan B." [3]
> 
> To be clear, if this proposal were a late surprise sprung on
> the relevant working groups, then I agree with you that the
> issue would require more than the actions contained in the
> thread to date. The plan that led to the proposal at the top
> of this thread has been known to the relevant working groups
> for nearly a year, which is a somewhat different situation.
> Again, I'm glad that you raised the issue so that I could

This seems fine modulo a distinction that takes us back to that
"updates" versus "obsoletes" question.   

If RFC 8445 were a strict, forward-compatible, replacements for
5245, i.e., if all of the changes were either clarifications or
new features that were independent of the older ones with no
semantic changes to any old feature, then replacing older
references with new ones during AUTH48 should be a fairly
routine matter.  I note that have been done many times.    In
that context, I would applaud you going out of your way to alert
the WG about the intention of doing that and giving anyone who
sees a problem with it the opportunity to object; there have
certainly been cases where the reference changes have been
without that added notification and courtesy.

However, based on the discussion on this list, my sense of RFC
8845 after quickly looking through it. and your dependency
graph, that strict relationship does not hold and some other
issues become important:

(i) When a change of reference can have substantive protocol
implications, it is not clear to me that a WG can, in advance of
the final documents being available, appoint a group and say "we
trust you to sort these details out without involving us" even
if that group is, e.g., the WG Chairs and ADs.  It is quite
clear to me that neither the WG Chairs, ADs, or both can tell
the WG they they are taking those decisions away from the WG,
but I assume that did not happen in this case.

(ii) The approval of IETF standards track documents is supposed
to be by, and represent, IETF consensus, not just consensus
within a WG.  A WG or its leadership (including relevant ADs)
might reasonably conclude that a particular set of changes,
however substantive, do not require an additional WG Last Call
(and your comments about late surprises are quite relevant in
that regard).  However, none of that eliminates the requirement
for an IETF Last Call if substantive changes are being made to
the document(s) and, unless there have been announcements or
documents I haven't seen so far (e.g., as part of the IETF Last
Call on 8445), this is a surprise, and a late one, as far as the
IETF is concerned.  

Now, if you and your colleagues on the IESG conclude that the
changes implied by the changes in references are non-substantive
and therefore that an IETF Last Call is not needed, please make
that announcement and see if someone is concerned enough to
appeal (for planning, it won't be me -- I don't have enough skin
in this game to get the IESG even more irritated with me).
Otherwise, I think you are stuck with a requirement for either
an IETF Last Call on the document or invoking the variance
procedure to approve the documents without it.

YMMD... Because my main concern is about the principle of making
substantive changes at AUTH48, if no one else sees that as an
issue in this case, I will drop the subject.

best,
    john

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 9 Sep 2018 23:14:56 +0000

Hi,

I think the dependency graph gives a good overview. However, in the mmusic-ice-sip-sdp it is misleading.

The draft does contains a normative reference to RFC 5245, but is used only in a statement describing how can determine that the peer is 5245 compliant:

   "If an agent receives an SDP offer or answer with ICE attributes but without the
   "ice2" ice-options attribute value, the agent assumes that the peer
   is compliant to [RFC5245]."
 
Otherwise, the draft actually *obsoletes* RFC 5245, and the *procedures* in the draft are based on RFC 8445. Now, as the draft hasn't been updated for a while, the reference is still to the pre-8445-draft, which I guess is the reason there is no dependency to RFC 8445 in the graph?

Regards,

Christer

-----Original Message-----
From: art [mailto:[email-masked]] On Behalf Of John C Klensin
Sent: 09 September 2018 17:01
To: Adam Roach <[email-masked]>
Cc: Applications and Real-Time Area Discussion <[email-masked]>; Cullen Jennings <[email-masked]>
Subject: Re: [art] [clue] ICE, ICE-bis, and Cluster 238

Adam,

Thanks for the kind words and clarification... I think we may still have a difference of opinion, so let me attempt to clarify further on that point...

--On Sunday, September 9, 2018 14:10 -0500 Adam Roach <[email-masked]> wrote:

>the impacted working groups, which is precisely  why this thread 
>exists. I'm glad that you spoke up on this  point, though, since it 
>points out that this course of action  might look like a late surprise 
>to those parties who have not  been involved in the impacted documents 
>and working groups.

Agreed and understood.  However, standards track documents are supposed to represent IETF [rough] consensus, not just WG consensus, so there may still be an issue.  Moreover...

> that this issue will be addressed as cluster 238... gets untangled" 
> [1], a plan which one of the ART ADs reiterated in May of this year 
> [2].

I assume, or at least hope, that the announcement of that plan was followed by a WG discussion, an opportunity for any dissents to be aired, and by some sense of WG consensus that the plan was
ok.    A situation in which the WG Chairs and ADs were making a
decision and imposing it on the WG would be very bad news, so I assume it did not occur.

> Later that month, the RTCWEB chairs made it explicit, at least to 
> their working group, that this untangling was expected to take place 
> as an administrative matter during AUTH48: "instead of arguing about 
> whether to refer ICE or ICE-bis now when [draft-ietf-rtcweb-]overview 
> is going to get stuck anyway let's let the process run it's course: if 
> require more than the actions contained in the thread to date. The 
> plan that led to the proposal at the top of this thread has been known 
> to the relevant working groups for nearly a year, which is a somewhat 
> different situation.
> Again, I'm glad that you raised the issue so that I could clarify that 
> these actions are not being taken in a vacuum.

If RFC 8445 were a strict, forward-compatible, replacements for 5245, i.e., if all of the changes were either clarifications or new features that were independent of the older ones with no semantic changes to any old feature, then replacing older references with new ones during AUTH48 should be a fairly
routine matter.  I note that have been done many times.    In
that context, I would applaud you going out of your way to alert the WG about the intention of doing that and giving anyone who sees a problem with it the opportunity to object; there have certainly been cases where the reference changes have been without that added notification and courtesy.

However, based on the discussion on this list, my sense of RFC
8845 after quickly looking through it. and your dependency graph, that strict relationship does not hold and some other issues become important:

(i) When a change of reference can have substantive protocol implications, it is not clear to me that a WG can, in advance of the final documents being available, appoint a group and say "we trust you to sort these details out without involving us" even if that group is, e.g., the WG Chairs and ADs.  It is quite clear to me that neither the WG Chairs, ADs, or both can tell the WG they they are taking those decisions away from the WG, but I assume that did not happen in this case.

(ii) The approval of IETF standards track documents is supposed to be by, and represent, IETF consensus, not just consensus within a WG.  A WG or its leadership (including relevant ADs) might reasonably conclude that a particular set of changes, however substantive, do not require an additional WG Last Call (and your comments about late surprises are quite relevant in that regard).  However, none of that eliminates the requirement for an IETF Last Call if substantive changes are being made to the document(s) and, unless there have been announcements or documents I haven't seen so far (e.g., as part of the IETF Last Call on 8445), this is a surprise, and a late one, as far as the IETF is concerned.  

Now, if you and your colleagues on the IESG conclude that the changes implied by the changes in references are non-substantive and therefore that an IETF Last Call is not needed, please make that announcement and see if someone is concerned enough to appeal (for planning, it won't be me -- I don't have enough skin in this game to get the IESG even more irritated with me).
Otherwise, I think you are stuck with a requirement for either an IETF Last Call on the document or invoking the variance procedure to approve the documents without it.

YMMD... Because my main concern is about the principle of making substantive changes at AUTH48, if no one else sees that as an issue in this case, I will drop the subject.

best,
    john

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

---

From: "Roni Even" <[email-masked]>
Date: Mon, 10 Sep 2018 08:25:51 +0300

Hi,
Reading the discussion and it looks to me that RFC8445 neither obsolete nor updates RFC5245 I think that maybe the right way is to have a  RFC5245bis draft that will obsolete RFC5245 and this bis draft will recommend using RFC8445 and explain the issues.  

Roni Even

> From: art [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: Sunday, September 09, 2018 10:11 PM
> To: John C Klensin
> Cc: Applications and Real-Time Area Discussion; Cullen Jennings
> Thanks for weighing in with your perspective. Your first point is one that the
> IESG has been aware of for some time, and I plan to conduct a post-mortem of
> some kind once Cluster 238 has finally been published. I appreciate that your
> second point has lessons to teach us as well, and note that the IESG has
> specifically been pondering the meaning of "Updates" recently.
> 
> Your third point is the one that bears on the topic at hand (rather than pointing
> to opportunities for lessons learned for future endeavors), so I leave it quoted
> below.
> 
> > (3) Several people have suggested that these changes in references
> > could actually have substantive implications for at least some of the
> > protocols of which the references contain normative information.
> > Given that, having the RFC Editor make these changes at the direction
> > of the ART ADs as part of the
> > AUTH48 process seems to me to be inappropriate.  The changes should be
> > proposed, new I-Ds generated, and those I-Ds referred back to the
> > originating WGs for consideration followed by an IETF Last Call on
> > those changes.  If nothing else, look at it this way: if an error were
> > made or a change turned out to be controversial, it would be far
> > better if those situations occurred only after there was a formal
> > opportunity for community review and for all materially concerned
> > parties to check the results rather than having them produced (and
> > hidden) by an administrative procedure.
> 
> 
> We (the ART ADs) agree that this is a matter that needs discussion in the
> impacted working groups, which is precisely why this thread exists.
> I'm glad that you spoke up on this point, though, since it points out that this
> course of action might look like a late surprise to those parties who have not
> The initial plan for dealing with this situation was announced by the RTCWEB
> chairs en bloc in October of 2017: "The chairs and AD believe that this issue will
> be addressed as cluster 238... gets untangled" [1], a plan which one of the ART
> ADs reiterated in May of this year [2].
> 
> Later that month, the RTCWEB chairs made it explicit, at least to their working
> group, that this untangling was expected to take place as an administrative
> matter during AUTH48: "instead of arguing about whether to refer ICE or ICE-bis
> now when [draft-ietf-rtcweb-]overview is going to get stuck anyway let’s let the
> process run it’s course: if trickle-ICE is going to get done about the same time as
> ICE-bis then great we can update the references in AUTH48 and if not we can
> figure out plan B." [3]
> 
> To be clear, if this proposal were a late surprise sprung on the relevant working
> groups, then I agree with you that the issue would require more than the actions
> contained in the thread to date. The plan that led to the proposal at the top of
> this thread has been known to the relevant working groups for nearly a year,
> which is a somewhat different situation. Again, I'm glad that you raised the issue
> so that I could clarify that these actions are not being taken in a vacuum.
> 
> Thanks again,
> 
> /a
> 
> ____
> [1]
> https://mailarchive.ietf.org/arch/msg/rtcweb/IJj0EGeFAZmDCK03sReZFbC24_
> M
> [3]
> https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY
> 8
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Sep 2018 01:15:04 -0500

Roni —

Can you clarify what you mean? RFC 8445 does indicate that it obsoletes RFC 5245. It spent its draft life being called “5245bis”. 

/a

> On Sep 10, 2018, at 00:25, Roni Even <[email-masked]> wrote:
> 
> Hi,

---

From: Jefsey <[email-masked]>
Date: Mon, 10 Sep 2018 10:35:50 +0200

>issue in this case, I will drop the subject.

John,

As you know, on the premises of RFC 6852 and NTIA Transition I 
down-scaled my interest in the IETF as it became the ICANN global 
community's technological arm over the four lower network layers 
while embracing "a modern paradigm for standards where the economics 
of global markets, fueled by technological advancements, drive global 
deployment of standards regardless of their formal status." - while 
RFC 1958 says that the "everything else" I am mostly interested in 
"should be done at the fringes" (hence on a fringe to fringe basis).

I support this paradigm because "In this paradigm standards support 
interoperability, foster global competition, are developed through an 
open participatory process, and are voluntarily adopted 
globally.  These voluntary standards serve as building blocks for 
products and services targeted at meeting the needs of the market and 
consumer, thereby driving innovation. Innovation in turn contributes 
to the creation of new markets and the growth and expansion of 
existing markets."

However, I appealed RFC 6852 - actually twice - because it lacks a 
"compatibility compendium" that internet users (IUsers) could use as 
reference, and a global appeal procedure to permit that. As I 
reported it two years ago, I have introduced the exploratory concept 
of an experimental and free global community (XLib.re). It is a 
lengthy process as most of everything is to rethink in view of the 
RFC 6852 "agoric" modern paradigm.

Experience shows that:
1) the IETF proven working TAO is quite efficient but needs some mail 
system usage/extensions based improvements (I hope they will be 
helped by the WG/JMAP work).
2) the real IUser and Startupper needs for an "extended Internet 
technology compendium" are of the essence for long term stability. 
The idea is not a revolution: it would only be a "documentation 
super-IANA", an "Internet Good Book".  I introduced the concept at a 
'French Tech" meeting and proposed to label it as the "FriendsTech" 
reference manual (people at "French Tech" said they would sue me: 
this would have made good advertising for the concept). 
<https://www.meetup.com/FRIENDSTECH/>https://www.meetup.com/FRIENDSTECH/.

The first suggestion would be that the content of all the existing 
standards is compacted by a university secretary work and further on 
maintained through the inputs from every new standardization document 
as the IANA is. Unfortunately we do not have a networking technology 
section at Montpellier University.

This way:
- everyone in the world, including press, would be consistently noticed,
- the gatherers' group would be in a good position to catalyze final 
consensuses (in jointly publishing the elements of discrepancy).

We are too small to take the lead in such a move, it might help to 
keep the compendium published by the IANA: it would be great if the 
IAB assumed the concept and published an RFC calling for a 
"super-IANA" section in RFCs to that end.

The risk of cases like this one would probably be reduced, and a 
global process be easily manageable (I do not think the need would be 
for a formal "Supreme Global IAB": a simple appendix to RFC 6852 
could include general lines about technical compromising along with 
the existing RFC principles - I suppose also that replacing the 
reference to "market" by a reference to the "multitude" would help. 
This in reference to the pre-Westphalia (Hobbes/Spinoza) and the 
current debate on Nation-States + RFC's "global communities"  in the 
XXIth century)

jfc

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Sep 2018 11:06:06 +0000

Hi,

First, regarding “update” vs “obsolete”, the reason the work on 8445 began was to clarify the 5245 procedures, and to make the spec protocol independent by moving the SIP/SDP specific parts into a separate MMUSIC document.

Initially the main technical change was to remove one of the candidate pair nomination alternatives (called aggressive nomination).

Later, it was claimed that there was a bug in the candidate pair unfreezing procedures. The issue was brought to IETF by Emil Ivov, where he presented the issue, and a suggested solution. So, we did that change, and also clarified the unfreezing procedures (using a table, sometimes unofficially referred to as "Emil's table").

In addition, we modified some of the timer values and timer value calculation formulas, based on input from real-life deployments.

So, to me “obsolete” is the right way to do, and as far as I remember nobody aver raised and issues with this.

Second, regarding what impact a reference update would have on the other content, and the features defined, in a spec. The changes in 8445 are quite "low level", so in most cases updating the reference from 5245 to 8445 in a spec will not impact the other content in the spec, or the features defined in those specs. ICE trickle is an exception, where the procedures are based on the 8445 procedures. Some claim that updating the reference in rtcweb-jsep would impact other parts of the spec, but so far nobody (afaik) has indicated exactly what would be impacted.
 
Regards,

Christer

Sent from my iPhone

> On 9 Sep 2018, at 17.01, John C Klensin <[email-masked]> wrote:
> 
> Adam,
>

---

From: "Roni Even" <[email-masked]>
Date: Mon, 10 Sep 2018 18:52:27 +0300

Hi Adam,
Sorry , my mistake.  I looked again at the definition of obsolete which is not historic so RFC8445 does obsolete RFC5245  still both implementations can exist
Roni

> From: Adam Roach [mailto:[email-masked]]
> Sent: Monday, September 10, 2018 9:15 AM
> To: Roni Even
> Cc: John C Klensin; Applications and Real-Time Area Discussion; Cullen Jennings
> Can you clarify what you mean? RFC 8445 does indicate that it obsoletes RFC
> 5245. It spent its draft life being called “5245bis”.
> 
> /a
> 
> > Reading the discussion and it looks to me that RFC8445 neither obsolete nor
> updates RFC5245 I think that maybe the right way is to have a  RFC5245bis draft
> that will obsolete RFC5245 and this bis draft will recommend using RFC8445 and
> explain the issues.
> >
> > Roni Even
> >
> >> that the IESG has been aware of for some time, and I plan to conduct
> >> a post-mortem of some kind once Cluster 238 has finally been
> >> published. I appreciate that your second point has lessons to teach
> >> us as well, and note that the IESG has specifically been pondering the
> meaning of "Updates" recently.
> >>
> >> Your third point is the one that bears on the topic at hand (rather
> >> than pointing to opportunities for lessons learned for future
> >> endeavors), so I leave it quoted below.
> >>
> >>> could actually have substantive implications for at least some of
> >>> the protocols of which the references contain normative information.
> >>> Given that, having the RFC Editor make these changes at the
> >>> direction of the ART ADs as part of the
> >>> AUTH48 process seems to me to be inappropriate.  The changes should
> >>> be proposed, new I-Ds generated, and those I-Ds referred back to the
> >>> those changes.  If nothing else, look at it this way: if an error
> >>> were made or a change turned out to be controversial, it would be
> >>> far better if those situations occurred only after there was a
> >>> formal opportunity for community review and for all materially
> >>> concerned parties to check the results rather than having them
> >>> produced (and
> >> [1], a plan which one of the ART ADs reiterated in May of this year [2].
> >>
> >> is going to get stuck anyway let’s let the process run it’s course:
> >> if trickle-ICE is going to get done about the same time as ICE-bis
> >> then great we can update the references in AUTH48 and if not we can
> >> figure out plan B." [3]
> >>
> >> plan that led to the proposal at the top of this thread has been
> >> known to the relevant working groups for nearly a year, which is a
> >> somewhat different situation. Again, I'm glad that you raised the issue so that
> I could clarify that these actions are not being taken in a vacuum.
> >>
> >> Thanks again,
> >>
> >> /a
> >>
> >> ____
> >> [1]

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Sep 2018 11:06:24 -0500

> Sorry , my mistake.  I looked again at the definition of obsolete which is not historic so RFC8445 does obsolete RFC5245  still both implementations can exist

Right. SIP had to go through the same transition between RFC 2543 and 
RFC 3261 (in which 3261 obsoleted 2543). In the same way that it used a 
number of special indicators (e.g. the Via header field branch parameter 
magic cookie) to adjust behavior to work with older implementations, RFC 
8445 uses an "a=ice2" attribute to do the same thing.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Sep 2018 11:24:26 -0500

John --

Thanks. Your point that substantive changes past IETF last call requires 
buy-in from the larger IETF community is well taken. I think reasonable 
people can disagree whether the changes under discussion are substantive 
in the context of the IETF writ large, especially given that the RFC 
editor frequently updates obsoleted references mechanically. In any 
case, I'll be certain to raise this point in my conversations with the 
IESG once the ART-area discussion comes to a conclusion, and we will 
factor it into our conclusions about what next steps are appropriate.

/a

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Sep 2018 19:10:24 -0400

Adam,

Thanks.  I agree with you about reasonable people disagreeing
about what is substantive or not and ask only that the question
be examined in a reasonable, open, and transparent way.  

As far as the RFC Editor mechanically updating obsoleted
references, I (and I assume many other authors and editors) have
needed to push back on that practice during AUTH48 when the RFC
Editor staff or their tools have gotten some of those
"corrections" wrong because references to earlier documents have
been deliberately included for historical purposes. More
recently, I've sometimes included comments in the XML and/or
written notes to the RFC Editor at handoff time from the Stream
to indicate references that are deliberately to obsolete
documents.  That seems to save everyone time.  I've even
wondered whether we should have markup provisions for
information of that type.   It is, of course, yet another reason
why we should be very careful about application of the
"obsoletes" category.

Clearly all of that falls into the category of issues to think
about and consider approaching differently in the future rather
than specific issues with this collection of documents.

best,
   john

--On Monday, September 10, 2018 11:24 -0500 Adam Roach
<[email-masked]> wrote:

> John --
> 
> Thanks. Your point that substantive changes past IETF last
> call requires buy-in from the larger IETF community is well
> taken. I think reasonable people can disagree whether the
> changes under discussion are substantive in the context of the
> IETF writ large, especially given that the RFC editor
> frequently updates obsoleted references mechanically. In any
> case, I'll be certain to raise this point in my conversations
> with the IESG once the ART-area discussion comes to a
> conclusion, and we will factor it into our conclusions about
> what next steps are appropriate.

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 Sep 2018 00:43:47 -0400

Christer,

Thanks for the explanation.  I assume you know that, at least
from the perspective of someone who has not been actively
involved in the work (and who does not find comparing the
technical content of a pair of 100+ page documents especially
easy), your comments do not appear to be completely consistent
with what some others have said.  That brings us back to a
recent comment of Adam's: reasonable people can disagree about
whether the differences are significant.

I hope it has been clear that my concern about this is largely
procedural, especially that we be as sure as possible that IETF
standards are clear, consistent, and comprehensible and that
they interoperate both across implementations and with other
IETF work.  From that perspective, I am unhappy about 100+ page
specifications (even though I understand that they are sometimes
necessary) and large clusters of documents with complex
interrelationships make me anxious (even though I recognize that
might sometimes be the best option). Our best protection against
getting those things wrong is wide and careful review across the
IETF, not just in a specific WG, so steps that appear to bypass
or shortcut around that level of review concern me.   I also get
concerned when I hear things like "the WG Chairs and ADs
decided..." unless they are really just a way to say "the WG was
consulted and the WG Chairs and ADs concluded that the WG
consensus was...".  

I am satisfied that Adam understands those issues and will
communicate them to the IESG and others as needed.  About all I
can do about the more substantive details is to hope that those
with a better understanding of the specific issues involved,
including yourself, have discussed and will continue to discuss
them.  My goal is to try to be sure there are adequate
opportunities for that discussion and community evaluation of it.
 
best,
   john

--On Monday, September 10, 2018 11:06 +0000 Christer Holmberg
<[email-masked]> wrote:

> Hi,
> 
> First, regarding "update" vs "obsolete", the reason
> the work on 8445 began was to clarify the 5245 procedures, and
> to make the spec protocol independent by moving the SIP/SDP
> specific parts into a separate MMUSIC document.
> 
> Initially the main technical change was to remove one of the
> candidate pair nomination alternatives (called aggressive
> nomination).
> 
> Later, it was claimed that there was a bug in the candidate
> pair unfreezing procedures. The issue was brought to IETF by
> Emil Ivov, where he presented the issue, and a suggested
> solution. So, we did that change, and also clarified the
> unfreezing procedures (using a table, sometimes unofficially
> referred to as "Emil's table").
> 
> In addition, we modified some of the timer values and timer
> value calculation formulas, based on input from real-life
> deployments.
> 
> So, to me "obsolete" is the right way to do, and as far as
> I remember nobody aver raised and issues with this.
> 
> Second, regarding what impact a reference update would have on
> the other content, and the features defined, in a spec. The
> changes in 8445 are quite "low level", so in most cases
> updating the reference from 5245 to 8445 in a spec will not
> impact the other content in the spec, or the features defined
> in those specs. ICE trickle is an exception, where the
> procedures are based on the 8445 procedures. Some claim that
> updating the reference in rtcweb-jsep would impact other parts
> of the spec, but so far nobody (afaik) has indicated exactly
> what would be impacted.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 17 Sep 2018 12:00:52 -0500

Hi, John,

On Mon, Sep 10, 2018 at 11:44 PM John C Klensin <[email-masked]> wrote:

On this point ...

> communicate them to the IESG and others as needed.

Adam, Ben Campbell, and I talked about this topic last Friday at lunch, so
at least one non-ART AD is being communicated with.

> About all I

Spencer, who is aware that
https://www.rfc-editor.org/internet-drafts/draft-ietf-tsvwg-rtcweb-qos-18.txt
is also part of https://www.rfc-editor.org/cluster_info.php?cid=C238, so
this conversation is of more than personal interest to me!

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Sep 2018 21:52:20 -0700

I'm late to the discussion, and reading through it, it seems that we have a
lot of back and forth without addressing Cullen's root issue.  Let me see
if I understand Cullen's root issue correctly.  I think it's something like:

1.  Cisco has existing code that it wants to call "WebRTC 1.0 compliant"
without changing to be compliant with 8445.

2.  Cisco has existing code that it wants to continue to interoperate with
endpoints, especially Chrome, even as they make changes to become 8445
compliant.  And they don't want to have to test against old and new
versions.

Cullen, is that accurate?

OK, so some of my thoughts:

1.  I don't think there is any interop risk here at all related to
timings.  If you're worried about the drop in minimum check interval going
from 20ms to 5ms, don't.  Just because the spec allows for going that low
doesn't mean endpoints will.  And if they do, they'll do it carefully.
Endpoints can and should still choose a value that works best regardless of
the min in the spec.  For example, Chrome is still using an interval of
48ms (we're not in a rush to lower it, but we have non-browser endpoints
that do go lower).  And if we roll out a lower value, it will be via
experiments or opt-ins and carefully tracked to make sure connectivity
rates don't drop.  If any problem were found in practice, it would be
quickly reverted.

2.  I don't think there is any interop risk here related to nomination
either.
Chrome's default behavior has never been compliant to any spec anyway, and
it's never been an issue.  And like with ping intervals, any changes to
implementations will be done slowly and carefully.

3.  I don't think it really matters to major implementations what the
dependency graph looks like.  Whether some point to 5245 and others to 8445
or if all of them point to 8445, it doesn't matter, implementations will
behave the same either way.  Chrome, for example will adjust timings as
works well in practice (perhaps someday to below 20ms interval) regardless
of which RFCs point to 8445 and which point to 5245.  If interop issues
ever do come up, then they can be fixed.  And that has nothing to do with
which RFCs point to 5245 and which point to 8445.

5.  You're going to need to test against different versions of different
browser no matter what the RFC references are.  ICE timings and nominations
seem like the least of your testing problems.  But on the flip side, Chrome
(and I assume other browsers) have been very slow and careful when making
changes to the ICE code.

6.  FlexICE should go a long way to putting the web app in control of the
ICE behavior.  So if you are worried about what browsers will do with ICE,
I suggest supporting the FlexICE effort.  In fact, it's the result of your
proposal at TPAC in 2017 for wanting to have lower-level of control of
ICE.  If we get that into all the browsers, you won't have to worry any
more about any of this because you'll be in control (assuming you control
the web app).

Altogether, I don't see any reason to not reference 8445 everywhere, at
least not any related to interop risk and web browsers.

On Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings <[email-masked]> wrote:

> > Cisco has implemented stuff that is WebRTC 1.0 compliant without this
> change. These gratuitous changes, years after the implementation were
> coded, with no real benefit will ensure that we are not
> > and will not become compliant with the RFC. It's unlikely we will
> upgrade to the new ICE until it has real befits.
>
> The main reason we did 8445 was because people had identified issues with
> 5245. The work was driven mostly by the WebRTC community, including
> yourself and the Chrome people (or, at least the Google people), and one of
> the reason it took time to finalize 8445 was because you (among others)
> wanted to make sure we get things right (by making network measurements
> etc). Are you now saying all those changes bring no benefit? Did we all
> waste our time?
>
>
> Our testing, which we do not share, dig not indicate an improvement of
> connectivity rates. I did not see results from others that did. Some of the
> early test results from others that drove this work were not reproducible
> in our testing. The one thing I think most people did find is that the more
> out of sync the pacing of the two agents was, the worse the connectivity
> was. But all of this is water under the bridge, we have old and new ice,
> supporting both new and old ICE. Instead, we will move to say "works with
> Browser X version Y or later." We have watched at W3C as it moved to be
> that unless chrome does it, it rare that it becomes a standard.
> > Right here I am watching how the stuff IETF defines will be less
> relevant than the issue of what chrome implements.
>
> For us, the largest part is having to test for both old and new - it’s not
> easy to do good automated testing for ICE.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 27 Sep 2018 16:20:47 -0700

I agree with Peter. Chrome's implementation is already closer to 8445 than
5245, so I don't see any issues associated with snapping this cluster to
8445 (aside from the work involved).

On that topic, note that JSEP will need a few more changes than just the
addition of the 8445 reference and note; the examples will have to be
updated, as will the logic regarding generation of offers and answers and
their parsing (to deal with the new ice-option). These changes will be
modest but probably will need to be done by the authors.

On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher <pthatcher=
[email-masked]> wrote:

> I'm late to the discussion, and reading through it, it seems that we have
> a lot of back and forth without addressing Cullen's root issue.  Let me see
> ICE..  If we get that into all the browsers, you won't have to worry any
>> supporting both new and old ICE. Instead, we will move to say "works
>> with Browser X version Y or later." We have watched at W3C as it moved to
>> be that unless chrome does it, it rare that it becomes a standard.
>> For us, the largest part is having to test for both old and new - it’s
>> not easy to do good automated testing for ICE.