Re: [MMUSIC] ietf-mmusic-mdns-ice-candidates new draft: Christer's comments

Hi,

I have been asked to review the mdns-ice-candidates draft. Below are some comments.

Q1:

I think it needs to be more clear that mDNS domain names (.local) can only be resolved by remote peers within the same local network.

Section 5.1 does talk about this, and it may be an implicit assumption, but I think it should be pointed out in the beginning of the document.

---

Q2:

Related to Q1, think it needs to be more clear that the mechanism prevents IP address leaking to peers outside the local network. Inside the local network I assume that web apps can still find out about the local address simply by performing an mDNS lookup on the mDNS domainname.

---

Q3:

The draft makes an assumption that the mDNS domain names are unique. Why making that assumption? If the local network supports multicast, there may even be non-WebRTC applications using mDNS, which increases the risk for collision.

Doesn't that mean that there is no need for other ICE agents to cache the mDNS domain name:IP address mapping for "future use", because the mDNS domain name won't be used in future anyway?

Also, I am not sure whether ICE implementations should cache mappings to begin with. That's the task of the mDNS client of the host.

---

Q4:

Section 3.1.1 says that an ICE agent, when it gathers candidates, generates a UNIQUE mDNS domain name. I assume that means that the mDNS domain name will only be valid for the duration of the ICE session.

---

Q5:

Section 5.3 says:

   "When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy
   endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, 
   even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint."

Please make it more clear that the legacy endpoint is the one that does not support mDNS. Something like:

    "When an endpoint that supports mDNS communicates with a legacy endpoint that does not, the..."

---

Q6:

If I remember correctly, people have raised issues with legacy parsers not being able to parse non-IP-addresses. If so, shouldn't that be mentioned in Section 5.3?

(NOTE: Eventhough the draft updates RFC 8839, to support mDNS domain names, it does not solve the issue for legacy parsers.)

---

Q7:

The draft does not give any guidance regarding how long an ICE agent can safely cache an mDNS 

---

Regards,

Christer

-----Original Message-----
From: mmusic <mmusic-bounces@ietf.org> On Behalf Of Youenn Fablet
Sent: keskiviikko 19. toukokuuta 2021 12.11
To: mmusic WG <mmusic@ietf.org>
Subject: [MMUSIC] ietf-mmusic-mdns-ice-candidates new draft

Hi all,

Qingsi, Justin and I submitted a new version of the draft at https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-mdns-ice-candidates-01.
We processed and closed all issues raised so far and updated the draft accordingly.

We are reaching out to ask for review or feedback on this draft as a step towards going to LC.
In addition to feedback directly sent on this mailing list, issues can also be filed in the GitHub repository directly (https://protect2.fireeye.com/v1/url?k=ad45afe9-f2de970b-ad45ef72-86073b36ea28-42080504ba850fde&q=1&e=6e18bacf-1948-4d3d-adcd-9b5a379bde5f&u=https%3A%2F%2Fgithub.com%2Frtcweb-wg%2Fmdns-ice-candidates%2Fissues).

Thanks,
	Y
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic