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

From: Sean Turner <[email-masked]>
Date: Fri, 27 Jul 2018 20:42:49 -0400

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

---

From: Shivan <[email-masked]>
Date: Fri, 27 Jul 2018 17:48:01 -0700

Support adoption, and would be willing to review.

On Fri, Jul 27, 2018 at 5:42 PM, Sean Turner <[email-masked]> wrote:

> 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).
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 27 Jul 2018 20:59:22 -0700

I support adoption as a WG document and I’m willing to review.

  Nils Ohlmeier

> On Jul 27, 2018, at 17:42, Sean Turner <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 28 Jul 2018 10:10:05 +0000

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:[email-masked]] On Behalf Of Sean Turner
Sent: 28 July 2018 03:43
To: RTCWeb IETF <[email-masked]>
Subject: [rtcweb] WG adoption call: draft-mdns-ice-candidates

Thanks - spt

---

From: Justin Uberti <[email-masked]>
Date: Tue, 31 Jul 2018 16:57:21 -0700

I agree that we should take on this work.

I believe that we will need a separate doc that updates rtcweb/ip-handling
(either as n extension, or a -bis) to include support for mDNS candidates.
Do we expect that draft-mdns-ice-candidates will become that doc, or that
it will stay as an independent item devoted specifically to the mDNS
technique?

---

From: Justin Uberti <[email-masked]>
Date: Tue, 31 Jul 2018 17:03:29 -0700

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 <
[email-masked]> 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.
>
> 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
>
>