Re: [rtcweb] IP handling: Using mDNS names for host candidates

Yeah, I think we just need to emphasize that the FQDN can be a mDNS name.
Here's my current suggestion for updates to S 4.1 in ice-sip-sdp
<https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-21#section-4.1>:

>
>
>
>
>
>
> *<connection-address>:  is taken from RFC 4566 [RFC4566].  It is theIP
address of the candidate.  When parsing this field, an agentcan
differentiate an IPv4 address and an IPv6 address by presenceof a colon in
its value -- the presence of a colon indicates IPv6.An agent MUST ignore
candidate lines that include candidates withIP address versions that are
not supported or recognized.  An IPaddress SHOULD be used, but an FQDN
(including a mDNS [RFC6762] name) MAY be used in place of an IP address. *

In the case of receiving an candidate containing a FQDN, the hostname is
> looked up via DNS or mDNS as appropriate, first using an AAAA record
> (assuming the agent
> supports IPv6), and if no result is found or the agent only
> *supports IPv4, using an A record.  *

On Tue, Jul 17, 2018 at 3:11 PM Ted Hardie <ted.ietf@gmail.com> wrote:

> On Tue, Jul 17, 2018 at 4:46 PM, Peter Thatcher <
> pthatcher=40google.com@dmarc.ietf.org> wrote:
>
>> Where is the right place to comment on draft-mdns-ice-candidates?
>>
>
>
>> I looked at it from an ICE WG perspective, and it seems to be that since
>> (in RFC 5245), the candidate address can be a FQDN (section 15.1) you don't
>> need the special steps you have in section 3.2, because a .local address is
>> a FQDN (isn't it?).
>>
>
> The use of a .local signals that this is a special use name within the
> context of multicast DNS (RFC 6762).  One key difference there is that the
> uniqueness of a standard DNS name is derived from the hierarchical
> delegation of the DNS.  Uniqueness in MDNS is achieved using a local probe
> and announce method.  As Harald pointed out in the room, there are some
> latency consequences to that; those might be avoided by generating probable
> uniqueness in names via the UUID mechanism, but that still need to be
> worked out.  That, I think means the work in 3.1 is definitely needed.
>
>
>> I think the only novel thing would be to perhaps make it clear that mDNS
>> should be used for the name resolution.
>>
>>
> You might treat the special steps as redundant (since .local should signal
> mDNS), but I personally think it is helpful, because it discourages
> coalescing with standard DNS responses (which is permitted by 6762).
>
> Just my personal opinion.
>
> Ted
>
>
>
>
>
>> On Fri, Jun 29, 2018 at 6:07 PM youenn fablet <youennf@gmail.com> wrote:
>>
>>> A draft describing the Safari/WebKit approach is available at
>>> https://www.ietf.org/id/draft-mdns-ice-candidates-00.txt
>>>
>>> Eric, can you precise the kind of information you would like to have?
>>> Some testing has been done to validate the approach but I do not think
>>> this is representative of the actual state of the affair. Safari/WebKit is
>>> not gathering any related statistic..
>>>
>>>    Y
>>>
>>> Le ven. 29 juin 2018 à 11:10, Justin Uberti <juberti=
>>> 40google.com@dmarc.ietf.org> a écrit :
>>>
>>>> I believe such data will be forthcoming from the Safari team. We are
>>>> also working on this.
>>>>
>>>> On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla <ekr@rtfm..com
>>>> <ekr@rtfm.com>> wrote:
>>>>
>>>>> It seems like this is something one could A/B test and measure
>>>>> connection rates. Has someone done so?
>>>>>
>>>>> -Ekr
>>>>>
>>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>