Re: [rtcweb] WG adoption call: draft-mdns-ice-candidates

[Justin Uberti <[e-mail]>]

On Wed, Aug 1, 2018 at 7:37 AM Jonathan Lennox <[e-mail]> wrote:

> RTCWeb may mandate one IP address per FQDN, but a WebRTC implementation
> can’t guarantee that the author of its remote description is always a
> WebRTC implementation.
>
> The other complexity of DNS resolution is that you don’t want to require
> that all DNS lookups be complete before connectivity checking is started.
>
> RTCWeb mandates trickle so you can treat DNS resolution completing as
> though the candidate was trickled in at that point, but this will need to
> be specified somewhere.  Again, I think MMusic is the right place.
>
> I think an MMusic or ICE draft on FQDN handling in ICE, and an RTCWeb
> draft recommending mDNS, should proceed in parallel. I don’t see them
> taking appreciably different amounts of time.
>

Agreed on this distribution of work.

>
> On Jul 31, 2018, at 8:03 PM, Justin Uberti <
> juberti=[e-mail]> wrote:
>
> Regarding DNS resolution and associated complexity, I think we can
> sidestep most of that here in rtcweb given that we will be mandating 1:1
> mapping between foo.local names and IP addresses.
>
> IOW, the mDNS name is simply an alias for the IP, and therefore the
> questions noted below are answered easily for this particular situation.
>
> We can continue to discuss the general case of this problem in mmusic.
>
> On Sat, Jul 28, 2018 at 3:10 AM Christer Holmberg <
> [e-mail]> wrote:
>
>> Hi,
>>
>> In Montreal this was discussed in MMUSIC, and the outcome was that this
>> will require more work, in MMUSIC or ICE.
>>
>> I have also given some input why I think ICE support of FQDNs in general
>> (not specific to mDNS) requires more work.
>>
>> For example, as an FQDN can be associated with multiple IP addresses,
>> does that mean that the endpoint providing the FQDN will create separate
>> "sub candidates" for each IP address that the FQND can resolve to (as a
>> candidate per definition is associated with ONE transport (IP address +
>> port + protocol))?. If so, each of those local candidates may end up in
>> different foundations, some may be pruned (or removed because of other
>> reasons). In addition, is the endpoint supposed to send checks on each of
>> these candidates? For how long will it maintain them? Etc etc etc.
>>
>> The concept of "multi-address candidates" is a new thing, currently not
>> covered by the ICE specifications.
>>
>> Now, IF we assume a "FQDN candidate" will only resolve to one IP address,
>> the issue is easier to solve, but based on comments from others we cannot
>> make that assumption.
>>
>> So, while I do not object to working on support of mDNS in ICE, my
>> suggestion would be that the ADs, and the RTCWEB/MMUSIC/ICE chairs, discuss
>> on how to move forward, before we adopt this draft.
>>
>> Regards,
>>
>> Christer
>>
>>
>> -----Original Message-----
>> From: rtcweb [mailto:[e-mail]] On Behalf Of Sean Turner
>> Sent: 28 July 2018 03:43
>> To: RTCWeb IETF <[e-mail]>
>> Subject: [rtcweb] WG adoption call: draft-mdns-ice-candidates
>>
>> The consensus in the RFCWEB@IETF102 room was that the WG should adopt
>> https://datatracker.ietf.org/doc/draft-mdns-ice-candidates/ as a WG
>> item. But, we need to confirm this on list.  If you would like for this
>> draft to become a WG document and you are willing to review it as it moves
>> through the process, then please let the list know by 2359UTC 20180810.  If
>> you are opposed to this being a WG document, please say so (and say why).
>>
>> Note that the draft has been marked as a “Call for Adoption by WG Issued”
>> in the datatracker.
>>
>> Thanks - spt
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>