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

[Youenn Fablet <[e-mail]>]

Thanks for the review,

Based on your review, I filed two issues at https://github.com/rtcweb-wg/mdns-ice-candidates <https://github.com/rtcweb-wg/mdns-ice-candidates>
Please see below for some answers.

> On 21 May 2021, at 19:49, Christer Holmberg <christer.holmberg=[e-mail]> wrote:
> 
> It seems like I added some of the Q4 text to Q3. Here is a corrected version of my question:
> 
> 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.

Right, this is a (useful) restriction from mDNS though mDNS extensions could potentially alleviate this.
We might want to say this explicitly and detail that host candidates are useful for peers in the same local network as well.
I filed https://github.com/rtcweb-wg/mdns-ice-candidates/issues/133 <https://github.com/rtcweb-wg/mdns-ice-candidates/issues/133>.

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

Web apps cannot do mDNS lookups for privacy reasons.
It is a good thing for privacy reasons that a web page does not have access to its local address without some form of user opt-in.

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

mDNS is supposed to handle name collision.
This spec relies on the mDNS specification to handle such cases, which I think is the correct layering.

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

For the lifetime of the ICE agent, this may be more than the ICE session.
Though there is no hard requirement, section 3.3.3 states that mDNS domain name lifetime should be scoped by the lifetime of the web page (agents are free to be stricter than that).

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

The idea is for ICE agents to keep alive their own mDNS name as long as needed.
ICE agents should not try to buffer other ICE candidate mDNS:IP mapping. This is an optimization that should be left to the mDNS layer.

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

Agreed.

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

I filed https://github.com/rtcweb-wg/mdns-ice-candidates/issues/134 <https://github.com/rtcweb-wg/mdns-ice-candidates/issues/134>.

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

In practice, deployment has not seen this issue, maybe because legacy parsers are not widely used in mode 3 applications, i.e. applications that do not access to any camera/microphone.
It seems fine mentioning legacy parsers in the document.
Let’s handle it in the same issue as above, https://github.com/rtcweb-wg/mdns-ice-candidates/issues/134 <https://github.com/rtcweb-wg/mdns-ice-candidates/issues/134>.

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

Are you referring to remote mDNS mapping? If so, I think we want to leave caching to the mDNS layer.

> 
> ---
> 
> Regards,
> 
> Christer

Thanks again for the review.

> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic