Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?

[Roman Shpount <[e-mail]>]

On Thu, Jul 4, 2019 at 5:24 PM Harald Alvestrand <[e-mail]>
wrote:

> Den 04.07.2019 20:46, skrev Roman Shpount:
> > 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.
> >
>
> 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.
>

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.

It addresses a quite substantive issue (as in "millions of occurences
> 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.

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

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.

Given mmusic's traditional processing speed, I am not sure there's any
> 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