Subject: [rtcweb] Request for status update

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Jul 2019 09:23:33 +0200

WG chairs - can you give the WG a status update on the WG's documents?

As far as I can tell from
https://www.rfc-editor.org/cluster_info.php?cid=C238 the critical pieces
not in the RFC Editor queue are still the security documents and FEC,
but -4566bis, -clue-protocol, -rmcat-eval-criteria and -ice-sip-sdp are
also listed.

What is the status of these documents?

Are there others?

At the moment, the responsibility of the chairs is (in my opinion) to
make sure publication happens. It's been a while.

Harald

-- 
Surveillance is pervasive. Go Dark.

---

From: Sean Turner <[email-masked]>
Date: Wed, 3 Jul 2019 19:13:26 -0400

A fair question Harald.  Here’s the status of the WGs as of today:

draft-ietf-rtcweb-ip-handling: New version spun yesterday.  Awaiting Adam’s concurrence on one change, then he will get state moved to approved.

draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch: Held a conference call with Ben, Ted, ekr, and myself to address Ben’s discusses and comments.  ekr filed new issues and needs to generate some PRs.  Once a new version is spun, Ben, Adam, and I will review and hopefully we’re done with these two drafts.

draft-ietf-rtcweb-fec: I am getting emails now from GitHub showing Justin is diligently working through the outstanding comments.  I hope a revised draft will hit tonight or no later than Monday’s submission deadline.

draft-ietf-rtcweb-mdns-ice-candidates: It is my understanding that Adam is going to AD sponsor this one, but not until the other four move on.

spt

> On Jul 3, 2019, at 03:23, Harald Alvestrand <[email-masked]> wrote:
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Jul 2019 19:25:44 -0400

Hi All,

Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? This
entire draft seems to be ICE/SDP specific and not limited to rtcweb. Also,
there are significant interop implications for this draft between browser
and non-browser end points which probably warrant larger discussion outside
of rtcweb group. I would think mmusic would be a much better place for this
draft. I know there is an incentive to complete this draft quickly but this
has a potential to break a lot of things (it already did break interop with
almost every existing ICE implementation).

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Jul 2019 17:28:28 -0700

The problem this draft is trying to solve is fairly RTCWEB-specific. If
there are individual issues to resolve, we can send them out to mmusic for
discussion, but AFAIK no changes to existing ICE specs are needed.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Jul 2019 20:40:02 -0400

Part of the problem is that mmusic have decided to punt on the FQDN
support. In the current mmusic-ice-sip-sdp the final language that was
included:

<connection-address>:  is taken from RFC 4566 [RFC4566].  It is the IP
address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and
fully qualified domain names (FQDNs).  When parsing this field, an agent
can differentiate an IPv4 address and an IPv6 address by presence of a
colon in its value - the presence of a colon indicates IPv6.  *An agent
generating local candidates MUST NOT use FQDN addresses.  An agent
processing remote candidates MUST ignore candidate lines that include
candidates with FQDN *or IP address versions that are not supported or
recognized.  *The procedures for generation and handling of FQDN
candidates, as well as, how agents indicate support for such procedures,
need to be specified in an extension specification.*

So, at this point we have two options:
1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and define
how FQDN candidates generated by mdns are handled
2. write a new draft in mmusic which defines FQDN handling

In any case some sort of mmusic discussion is needed to reconcile this.

Best Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Jul 2019 17:58:28 -0700

Hmm, that's unfortunate. I think this is a mistake, given that we are about
to throw the switch to enable mDNS for 100% of Chrome endpoints; Chrome
(and soon all browsers) will have to ignore ice-sip-sdp until this
extension spec is written.

ice-sip-sdp isn't published yet, so it seems an update to that document
could still be a possibility. If that's not an option, putting forth #1 as
a specific extension that allows FQDN candidates to be generated in certain
situations seems like the right path.

On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount <[email-masked]> wrote:

>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?
>>> This entire draft seems to be ICE/SDP specific and not limited to rtcweb.
>>> Also, there are significant interop implications for this draft
>>> between browser and non-browser end points which probably warrant larger
>>> discussion outside of rtcweb group. I would think mmusic would be a much
>>> better place for this draft. I know there is an incentive to complete this
>>> draft quickly but this has a potential to break a lot of things (it already
>>> did break interop with almost every existing ICE implementation).
>>>
>>> Regards,
>>> _____________
>>> Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Jul 2019 21:15:03 -0400

This direction was taken since mmusic got no feedback regarding the
specifics of FQDN support. I did try to get mdns authors, including you, to
participate in the discussion, since I was afraid this can be a problem,
but no one responded at that time.

As it stands, there are significant issues with just putting FQDN in
candidate. The gist of the issue is that due to things like DNS64 there is
no way to enforce that FQDN will resolve to the same address family to
which FQDN was originally pointed to. So, end points will end up either
with different address families or with multiple addresses for the same
candidate even when FQDN in candidate originally only pointed to a single
IP. Connectivity checks will likely succeed on some of those address pairs,
but figuring out priority for the candidate pairs becomes confusing and
under-specified. No one wanted to discuss or deal with this before
ice-sip-sdp was published so the current language was put in place.

I know the browsers are trying to address what they perceive is a
significant issue, but I would think that current mdns draft is fairly raw
and turning this option on is likely premature. It might lead to multiple,
non-backwards compatible versions of this feature.
_____________
Roman Shpount

On Wed, Jul 3, 2019 at 8:58 PM Justin Uberti <[email-masked]> wrote:

> Hmm, that's unfortunate. I think this is a mistake, given that we are
> about to throw the switch to enable mDNS for 100% of Chrome endpoints;
> Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this
>> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and
>> define how FQDN candidates generated by mdns are handled

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Jul 2019 18:36:51 -0700

I don’t see them as contradictory. ice-sip-sdp requires implementations not suporting rtcweb-mdns-ice to ignore the .local candidates. This combined with ice-pac should enable interop of with implementations of rtcweb-mdns-ice via server reflexive candidates.

The one remaining piece is legacy handling of c= lines with mDNS names. 

> On Jul 3, 2019, at 5:58 PM, Justin Uberti <juberti=[email-masked]> wrote:
> 
> Hmm, that's unfortunate. I think this is a mistake, given that we are about to throw the switch to enable mDNS for 100% of Chrome endpoints; Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this extension spec is written.
> 
> ice-sip-sdp isn't published yet, so it seems an update to that document could still be a possibility. If that's not an option, putting forth #1 as a specific extension that allows FQDN candidates to be generated in certain situations seems like the right path.
> 
> 
> 
>> Part of the problem is that mmusic have decided to punt on the FQDN support. In the current mmusic-ice-sip-sdp the final language that was included:
>> 
>> <connection-address>:  is taken from RFC 4566 [RFC4566].  It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs).  When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6.  An agent generating local candidates MUST NOT use FQDN addresses.  An agent processing remote candidates MUST ignore candidate lines that include candidates with FQDN or IP address versions that are not supported or recognized.  The procedures for generation and handling of FQDN candidates, as well as, how agents indicate support for such procedures, need to be specified in an extension specification.
>> 
>> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and define how FQDN candidates generated by mdns are handled
>>> The problem this draft is trying to solve is fairly RTCWEB-specific. If there are individual issues to resolve, we can send them out to mmusic for discussion, but AFAIK no changes to existing ICE specs are needed.
>>> 
>>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? This entire draft seems to be ICE/SDP specific and not limited to rtcweb. Also, there are significant interop implications for this draft between browser and non-browser end points which probably warrant larger discussion outside of rtcweb group. I would think mmusic would be a much better place for this draft. I know there is an incentive to complete this draft quickly but this has a potential to break a lot of things (it already did break interop with almost every existing ICE implementation).
>>>> 
>>>> Regards,
>>>> _____________
>>>> Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Jul 2019 21:33:19 -0700

> but no one responded at that time.

Sorry, I haven't been reading mmusic regularly lately and missed your
outreach.

> ice-sip-sdp was published so the current language was put in place.

I need to understand the DNS64 issue better, I'm not sure how this would
pose a problem in practice.

> non-backwards compatible versions of this feature.

If anything, I think we've been too slow here. The initial mDNS draft was
posted over a year ago.

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 3 Jul 2019 21:50:20 -0700

Probably not the ideal forum to point this out, but I hope the Chrome team is aware that rolling out this feature, assuming it includes using mDNS in the connection line, will break interop with Firefox.
So I have to concur that rolling this out appears to be premature to me.

Best
  Nils Ohlmeier

> On 3Jul, 2019, at 17:58, Justin Uberti <juberti=[email-masked]> wrote:
> 
> On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
> Hi All,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Jul 2019 22:41:20 -0700

As I understand it, mdns in the c= line will only occur in edge cases,
i.e., when there are no other candidates. As such I don’t see this as a
showstopper.

We have measured the connectivity impact of this change in significant
detail and feel increasingly confident there are no egregious latent issues.

On Wed, Jul 3, 2019 at 9:50 PM Nils Ohlmeier <[email-masked]> wrote:

> Probably not the ideal forum to point this out, but I hope the Chrome team
> is aware that rolling out this feature, assuming it includes using mDNS in
> the connection line, will break interop with Firefox.
> On 3Jul, 2019, at 17:58, Justin Uberti <
> juberti=[email-masked]> wrote:
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Jul 2019 23:08:38 -0700

Nils said:

"assuming it includes using mDNS in the connection line, will break interop"

[BA]  Can someone provide a legacy citation relating to FQDNs in the
connection line?  I am struggling to find one.

draft-ietf-mmusic-rfc4566bis
<https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis>  Section 5.7
only talks about IPv4 and IPv6 addresses.  I do not see mention of FQDNs.

draft-ietf-mmusic-ice-sip-sdp does not mention FQDNs in the "c=" line and
all examples show IPv4 or IPv6 addresses.

RFC 3264 does not mention FQDNs in c= lines in the text, although it uses
FQDNs within examples (such as Sections 10.1 and 10.2).

JSEP does not mention FQDNs in "c=" lines as far as I can tell.

Also in these documents, I do not see instructions on how a legacy
implementation should gracefully react to FQDNs in the connection line
(e.g. ignoring it).

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 4 Jul 2019 12:54:35 +0200

> draft-ietf-rtcweb-mdns-ice-candidates: It is my understanding that Adam is going to AD sponsor this one, but not until the other four move on.

Thank you! So we're "in progress" on ip-handling, security and fec, and
mdns is waiting for the others (but I don't think it blocks the others,
so while it's needed for Real Life, it's not needed for the formalities).

Can you assure me that -4566bis, -clue-protocol, -rmcat-eval-criteria
and -ice-sip-sdp are not blockers for pushing out the rest of the 238
cluster?

---

From: Justin Uberti <[email-masked]>
Date: Thu, 4 Jul 2019 08:12:25 -0700

https://tools.ietf.org/html/rfc4566#section-9

; sub-rules of 'c='

connection-address =  multicast-address / unicast-address

...

unicast-address =     IP4-address / IP6-address / FQDN / extn-addr

On Wed, Jul 3, 2019 at 11:08 PM Bernard Aboba <[email-masked]>
wrote:

>> Probably not the ideal forum to point this out, but I hope the Chrome
>> team is aware that rolling out this feature, assuming it includes using
>> mDNS in the connection line, will break interop with Firefox.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 4 Jul 2019 14:46:59 -0400

The FQDN in c= line and candidate address where in specs for a really long
time (RFC 4566 and RFC 5245 both define them). This being said, FQDN in c=
line was very infrequently used and FQDN in ICE candidate was never used.
FQDN in ICE candidate was badly under defined and due to limited use there
is no established practice on how it should work. Using FQDN for mDNS ICE
candidates, as far as I know, is the first wide spread use of FQDN in ICE
candidates. Almost every ICE implementation outside of Chrome was never
tested against FQDN in c= lines and ICE candidates and likely would have
issues.

As it stands, ice-sip-sdp does not contradict using FQDN in ICE candidates,
but is specifically leaves a big hole in the document regarding how exactly
offers with FQDN are generated and how FQDN candidates are supposed to be
processed. The only thing current draft defines is absolute minimum of what
end point needs to do when receiving a session description with FQDN
candidates and safely ignoring them.Things like FQDN resolution procedures,
procedures for adding resolution results to the candidate list, and what is
supposed to go into the c= line for FQDN default candidate were
deliberately left out for the future document. If anybody wants to use FQDN
in ICE candidates, these things need to be defined and verified to cause
minimal disruption when deployed against existing end points. Since ICE and
ICE session description related issues are normally discussed in mmusic, it
probably should happen there to reach the proper audience.

I understand that running experiments before proposing a solution is
probably a good thing and this is what Chrome was doing up until this
point. At the same time, rolling this feature into production before at
least documenting it, will definitely cause interop problems. What we have
now is a fairly major feature with a fairly outdated specification where
all the interop issues weren't considered.

As far as connectivity impact of Chrome experiment goes, we do see it
causing issues with at least two scenarios:

1. Listen only connections to SBC/Media servers on public IP: We have a set
of services which run SBC or Media Servers on public IPs with ICE TCP
enabled. These services did not use STUN or TURN servers, since all the
communications are between the browser end point and the server on public
IP. In cases when microphone is not present on the client computer or
client denies microphone access, client is still offered to connect in
listen only mode. In this scenario, we ended up with FQDN in the c= line
and only FQDN based candidates. As a quick work around we added STUN
server, but this, in addition to slowing down the connection time, still
prevented connections from hosts where UDP was blocked. We had to update
software used to run our hosted services to support FQDN in c= line and ICE
candidates (which was actually done as a regex replacement). Our software
which is installed at client premises is still not updated and will likely
take our clients another 6 months to a year to update. As far as we could
see, before update, 2-3% of all listen only connections where affected.
This is not a huge number but caused customer complaints from clients who
were able to connect before the experiment started.

2. Peer-to-peer connections within enterprise: We are working with a
peer-to-peer web casting solution for webinars. We see the connectivity
rate reduction within large enterprises, where IP based connection between
two private IP is allowed but client browsers are not withing the same
broadcast domain. In this case mDNS connectivity check fails when direct IP
connectivity check would succeed. In these cases webcast client switches to
streaming from the server, so this does no result in total failure but does
decrease the P2P network efficiency. Having an ability to ask for
Peer-to-Peer connectivity permission would really help in this case.

Best Regards,
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 4 Jul 2019 23:23:50 +0200

Den 04.07.2019 20:46, skrev Roman Shpount:
> least documenting it, will definitely cause interop problems. What we
> have now is a fairly major feature with a fairly outdated specification
> where all the interop issues weren't considered.
> 

To be precise, we have documentation for the feature
(draft-ietf-rtcweb-mdns-ice-candidates), it's been largely unchanged for
quite some time, and it's what Chrome is in the process of shipping.

It addresses a quite substantive issue (as in "millions of occurences
per day" of the behavior we want to prevent).

The fact that we're only getting the interoperability issues discovered
as we roll out the feature to stable is sad; I don't know how to get
other people's software tested earlier in the cycle, which is what would
have given us more time to work through these issues.

Given mmusic's traditional processing speed, I am not sure there's any
point in formally moving the document at this point.

Harald

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 5 Jul 2019 10:43:11 +0200

Am 04.07.19 um 23:23 schrieb Harald Alvestrand:
> quite some time, and it's what Chrome is in the process of shipping

Where has the plan to ship this in M75 been communicated? It doesn't 
even seem to be using the blink launch process?

> It addresses a quite substantive issue (as in "millions of occurenes

I think 3.5% of pageloads (from chromestatus' metric 1054) is a bit more 
than "millions".

> have given us more time to work through these issues.

Have you tried talking to said other people? (this is rhetorical. I 
remember the dtls 1.0 deprecation and many other cases)

in this particular case I reported that the previous choice of putting 
an empty string into c= was broken back in January:
   https://bugs.chromium.org/p/chromium/issues/detail?id=927309
I find it quite sad that this was fixed without verifying that Firefox 
(which I indicated as 'throws' in the second comment) is ok with this.
(yes, I could have tested this myself; OTOH this isn't part of my job)

I suspect the interop issue with Firefox is restriced to non-trickle 
usage where no stun/turn servers are used. Which might be uncommon in 
general (for P2P) but might be a highly relevant deployment scenario for 
some applications that talk to servers.

This is a pattern that has broken things in the past (see for example 
the "unified plan breaks my cma" episode) because errors in those apps 
are not visible in the very noisy system that "chrome as a whole" 
represents.

---

From: Roman Shpount <[email-masked]>
Date: Sat, 6 Jul 2019 16:15:53 -0400

> quite some time, and it's what Chrome is in the process of shipping.

Are you saying that draft-ietf-rtcweb-mdns-ice-candidates provides an
accurate description of what is being shipped in Chrome? As far as I know
this document is outdated. It also has implementation issues  like stating "An
ICE agent SHOULD ignore candidates where the hostname resolution returns
more than one IP address". There are platforms which return both IPv6 and
IPv4 for a DNS record which points to a single IPv4 address. There are two
fundamental problems with FQDN in ICE candidates. First being legacy
interop. Second being that handling FQDN is under-specified and  FQDN in
ICE candidate line is likely missing necessary information required to
resolve it (address family). Dealing with the default candidate which is a
FQDN is another are which has no existing specification leading to FQDN
with unknown address family in the c= line.

> per day" of the behavior we want to prevent).

I understand the desire to block one of the client fingerprinting methods.
After all, there are few hundred others that will need to blocked after.

> have given us more time to work through these issues.

The software was tested and issues were identified and fixed. Unfortunately
not everyone has a luxury of simply pushing the software update to all
customer. When dealing with telecom, it is common for them to deploy new
software every 3-6 months and only after running a limited deployment for a
few months before hand. It literally takes a year to push a new version to
them, which is not usually a problem, unless some breaking protocol change
is introduced, like unified plan or mdns.

> point in formally moving the document at this point.

It is especially slow when none of the people interested in the specific
feature (FQDN in ICE candidates) participate in the discussion. So far this
looks like this feature is going to be shipped regardless of what anybody
thinks about it and without even attempting to discuss it in the group
which is responsible for this functionality.

Best Regards,
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 7 Jul 2019 09:47:07 +0200

On 7/6/19 10:15 PM, Roman Shpount wrote:
> It is especially slow when none of the people interested in the
> specific feature (FQDN in ICE candidates) participate in the
> discussion. So far this looks like this feature is going to be shipped
> regardless of what anybody thinks about it and without even attempting
> to discuss it in the group which is responsible for this functionality.

My favorite examples are -msid (initial version May 2012, IESG
evaluation June 2016); -sdp-simulcast (initial version April 2015, IESG
evaluation May 2018); -bundle-negotiation (initial version October 2011,
IESG evaluation February 2018).

Each of these has its own history, but when a group is capable of
discussing a draft for seven years before it is IESG-ready, I question
the effectieness of moving drafts into that group.

---

From: Adam Roach <[email-masked]>
Date: Fri, 12 Jul 2019 17:59:40 -0500

> and -ice-sip-sdp are not blockers for pushing out the rest of the 238

As that's a bit outside a single WG's area, I'll answer this as AD.

First, I'll discuss the CLUE subcluster:

  * The CLUE documents (both protocol and signaling) have dependencies
    into the cluster, but nothing outside of CLUE refers to them. They
    will remain in the cluster, but not block publication of anything
    except for other CLUE documents.
  * draft-ietf-mmusic-rfc4566bis only blocks
    draft-ietf-mmusic-data-channel-sdpneg, which is a part of the
    cluster by virtue of it being a CLUE dependency.

The documents draft-rmcat-eval-criteria and draft-rmcat-wireless-tests 
are  dependencies for draft-ietf-rmcat-eval-test. That document, in 
turn, is part of the cluster because it has dependencies pointing into 
the cluster. No dependencies point outward towards 
draft-ietf-rmcat-eval-test, so these two documents do not block 
publication of the WebRTC portion of the cluster.

Draft-ietf-mmusic-ice-sip SDP is a blocker for most documents in Cluster 
238, as it is a strictly necessary normative dependency for BUNDLE [1]. 
It is on the August 8th IESG formal telechat.

/a

____
[1] This structure may seem odd at first, and it is almost certainly not 
how one would have structured documents if one were to have designed the 
whole cluster up front. However, the current structure has been debated 
at length, with a conclusion that unwrapping this specific part of the 
Gordian knot would take substantial effort for little real long-term 
gain. Based on those conversations, my estimate is that an attempt to 
refactor documents to avoid this dependency would add 24 to 36 months to 
the effort, if begun today.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 15 Jul 2019 12:01:14 +0100

> On 12 Jul 2019, at 23:59, Adam Roach <[email-masked]> wrote:
...
> The documents draft-rmcat-eval-criteria and draft-rmcat-wireless-tests are  dependencies for       draft-ietf-rmcat-eval-test. That document, in turn, is part of the cluster because it has dependencies pointing into the cluster. No dependencies point outward towards draft-ietf-rmcat-eval-test, so these two documents do not block publication of the WebRTC portion of the cluster.

Also, the RMCAT drafts are in WG last call, and should be ready to go to the IESG shortly. 

Colin (as RMCAT co-chair)