Re: [dnssd] draft-ietf-rtcweb-mdns-ice-candidates-02 feedback

youenn fablet <> Thu, 07 March 2019 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94F1013120F; Thu, 7 Mar 2019 14:45:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OeCwpX7McLUm; Thu, 7 Mar 2019 14:45:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 060A51311C4; Thu, 7 Mar 2019 14:45:29 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id x27MfpqG050650; Thu, 7 Mar 2019 14:45:28 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=0fclr87PGexqcaRVanmgXaJDa5ikxTMtBAkWvGJ4E6c=; b=CSaqc7RvV18X6d7N42SK5Et84PXP2ap1GC3TlYHo7BifS5o9iXFzi4yxFSwWGDUj+8K9 sAAO+FvzdzvE9M+SsppVIwXwg+5YyzZphG7sV0qLoy4q8aFQgbAEc1EnQg1tK64GfJ// d6Z788VeIbWF1jI0SJjGwbZmlLlvlbFjUD1HVPrEKfSFqokQZDlmR4qDVkgOHscOjD5r N0lJ+NjPFMWuLlHzxajTWCZhEJ/T0KUOnHuAWQwjRU27qw3HC1for15prbAr4qOwYK6+ 46v/MRnSNWxd2bXCs1Ehav3bL32fj8kKCNfqPLa/isi7IMF3x0Xzlh5/cozf2LPgZlOA uw==
Received: from ( []) by with ESMTP id 2qyqd46egv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 07 Mar 2019 14:45:28 -0800
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_1BgXPFzxl0lZrxmPhPdJuQ)"
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Oct 24 2018)) with ESMTPS id <>; Thu, 07 Mar 2019 14:45:28 -0800 (PST)
Received: from by (Oracle Communications Messaging Server 64bit (built Oct 24 2018)) id <>; Thu, 07 Mar 2019 14:45:27 -0800 (PST)
X-Va-T-CD: 46089963636650ba3f6b170c8994862d
X-Va-E-CD: 171740ecac2ad434e37d98dc99469f23
X-Va-R-CD: c86a0762f803f6ca7b13bd98680e1e43
X-Va-CD: 0
X-Va-ID: a15d0df0-33ad-4ff7-bf34-99bc54fe0a79
X-V-T-CD: 46089963636650ba3f6b170c8994862d
X-V-E-CD: 171740ecac2ad434e37d98dc99469f23
X-V-R-CD: c86a0762f803f6ca7b13bd98680e1e43
X-V-CD: 0
X-V-ID: 9e1d72a6-f920-4003-8b69-0b0fc356fcd8
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-07_14:,, signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Oct 24 2018)) with ESMTPSA id <>; Thu, 07 Mar 2019 14:45:25 -0800 (PST)
From: youenn fablet <>
Message-id: <>
Date: Thu, 07 Mar 2019 14:45:24 -0800
In-reply-to: <>
Cc:, dnssd <>
To: Tom Pusateri <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_14:, , signatures=0
Archived-At: <>
Subject: Re: [dnssd] draft-ietf-rtcweb-mdns-ice-candidates-02 feedback
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Mar 2019 22:45:33 -0000

> On Mar 7, 2019, at 2:35 PM, Tom Pusateri <> wrote:
> To be more clear, by “why use mDNS?” if the announcing host and the resolving host are the same, I really mean it would be wasteful to use mDNS for inter process communication and wake up every mobile device radio on the same link, but if you think this is still your best option, you should spell it out.

The common case is for the two to be different.
Nothing prevents the two to be the same though and it should equally work.

> Thanks,
> Tom
>> On Mar 7, 2019, at 5:04 PM, Tom Pusateri < <>> wrote:
>> Ok, it was not obvious from all the components that the IP addresses were owned. In that case, I agree that normal mDNS applies and no extension to RFC 6762 is required.
>> Maybe a better description of which host is announcing the name and which host is resolving the name would help? Unless it’s all on the same host and then, why use mDNS?
>> Thanks,
>> Tom
>>> On Mar 7, 2019, at 4:51 PM, youenn fablet < <>> wrote:
>>> Hi Tom,
>>> Thanks for the feedback.
>>> Please find some comments inline,
>>> 	Y
>>>> On Feb 17, 2019, at 12:13 PM, Tom Pusateri < <>> wrote:
>>>> While this document is an RTCWEB document, it’s more about mDNS and so I’m going to give feedback directly to the authors and the DNS-SD group instead of the RTCWEB group (which I’m not a member). If the authors want to replicate this discussion on RTCWEB, please do so.
>>> It is at a RTCWeb/ICE/DNS-SD crossing point.
>>> Wherever that document goes, I think it is good to get feedback from all groups.
>>>> Overall, it’s an interesting idea and I think it could work ok. However, I think presentation around ICE, while motivating the idea, is not necessary for a general purpose third party mDNS name aliasing mechanism. I would remove all references to ICE, WebRTC, TURN, etc. and just make a simple mDNS third party name alias registration document.
>>> I think the scope of this proposal is narrower than your interpretation.
>>> A device may want to not expose its own private IP address to a web page.
>>> In that case, it will register a MDNS name for its own private IP address and disclose the MDNS name to the web page instead of its IP address.
>>> While the idea is interesting and potentially useful, I think the ability of a device to register names for other device IP addresses is out of scope of this particular document.
>>>> As part of that, you need to discuss defending the name and responding to queries for the name since the owner of the IP address will not do this.
>>>> Section 3.1
>>>> ===========
>>>> List Item 1:
>>>> Someone familiar with mDNS would interpret this as an existing registered mDNS host name. I don’t think that’s what this means. I think this means an existing RFC 4122 unique name as described further down in the document.
>>>> List Item 3:
>>>> This makes it seem like normal mDNS is occurring here when it’s really a 3rd party form of mDNS. So you’re not really following RFC 6762. I don’t think there’s necessarily a problem with 3rd party registrations but don’t point people to RFC 6762 for that. In fact, you’re extending RFC 6762 and you need to describe in more detail how you’re extending it.
>>> This document might need clarification on that point: the IP address that is registered is always from the device doing the MDNS registration.
>>> Discussion is ongoing at <> on how to best clarify this.
>>>> 3rd last paragraph:
>>>> "with both IPv4 and IPv6 addresses MUST expose a different mDNS name for each address."
>>>> Again, you’re talking about RFC 4122 unique names, not regular mDNS names as provided by a host. This should be made more clear since it would be common for an mDNS host to use the same name for IPv4 and IPv6.
>>>> Section 4
>>>> =========
>>>> 2nd paragraph:
>>>> When more than one IPv4 or more than one IPv6 address is present, it seems like it would be better to first prefer an address that is on a shared network instead of always taking the first one (which doesn’t mean anything in DNS). If you want others to use the same address you should prefer the lowest one or the highest one or something sortable instead of the first one which could be different depending on hashing in a cache.
>>> Right, we could try to make a better suggestion here, as long as it remains simple.
>>> Discussion is ongoing at <>.
>>>> Thanks,
>>>> Tom
>>> _______________________________________________
>>> dnssd mailing list
>>> <>
>>> <>
>> _______________________________________________
>> dnssd mailing list
>> <>