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

Tom Pusateri <pusateri@bangj.com> Sun, 17 February 2019 22:30 UTC

Return-Path: <pusateri@bangj.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F6E126F72; Sun, 17 Feb 2019 14:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgicdoE2_lOA; Sun, 17 Feb 2019 14:30:05 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BBA124D68; Sun, 17 Feb 2019 14:30:04 -0800 (PST)
Received: from [172.16.10.124] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id EAFDB27C52; Sun, 17 Feb 2019 17:30:03 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Tom Pusateri <pusateri@bangj.com>
X-Mailer: iPad Mail (16D57)
In-Reply-To: <C069934A-C5ED-48CA-A857-AE457A3566D3@bangj.com>
Date: Sun, 17 Feb 2019 17:30:03 -0500
Cc: dnssd <dnssd@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <68C82424-2406-4DAE-8EB7-59BB0AD78016@bangj.com>
References: <C069934A-C5ED-48CA-A857-AE457A3566D3@bangj.com>
To: draft-ietf-rtcweb-mdns-ice-candidates.authors@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/SaTAYdymAvIrT2CUI2tt4ZvV-YU>
Subject: Re: [dnssd] draft-ietf-rtcweb-mdns-ice-candidates-02 feedback
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Feb 2019 22:30:07 -0000

> On Feb 17, 2019, at 3:13 PM, Tom Pusateri <pusateri@bangj.com> 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.
> 
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> Thanks,
> Tom

Thinking about this a little more, I would suggest splitting this into two documents. One that describes an mDNS alias name registration extension to RFC 6 762 and a second document that uses the first document to create unique RFC 4122 names for rtcweb.

Tom