From nobody Sun Nov 12 16:34:48 2017 Return-Path: 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 3FA191270B4 for ; Sun, 12 Nov 2017 16:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 DMM4JyYGgdmg for ; Sun, 12 Nov 2017 16:34:43 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC7E127010 for ; Sun, 12 Nov 2017 16:34:43 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id l19so8884078pgo.2 for ; Sun, 12 Nov 2017 16:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:references:to:date; bh=CVYlLzCoHSgD/0y42TNjT7p5do2ZWNku8aZAMZkLWEo=; b=NIMMw2K6PRxk4jMkBk7zM5FNofHsBltJ9R/iVJ91c+bSoFAa5GJYkmXeIRHK1QqPDB KtrmfrDfbpmkCeUxdUPRMW1h0l7ZwSd1dgdvs1jhhH6+mAW3EfEIqJl6qjGDcFtxoKx5 aW9TJpn2MfBrLCmqMYkN29io1Cnf1iXcdpb8GNqMOUqP3h7cjMZ2QxHaqVH+FXIf9QPz C08glR9Sp0/k5IXZj7NRgR0cgH9eIP4OIy3uT/ZXwu8pROAMIOVvia/ihv7qkhkJjB/r LZvdtUm3K1X6M7fFLQZOW0NB2wVR7aRaYTTlA2ORKQ6xILlLT7Ha7cXxL6x+LRzbrdX9 2chw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=CVYlLzCoHSgD/0y42TNjT7p5do2ZWNku8aZAMZkLWEo=; b=MWl1v/T4H5HL5ay381oXfzKxZTDVwRCUQkRTfG1fsw7TZDaciO6jiWjwL4mK4PhE+2 pEz6oZlt6CZUMMox2T1m6khcXfjDfQqBZmQvWqHTTute4DN7juBVffTc86hnQnWzuGO5 gBq//CBryk+7o6bnzGCTXdTSHlPP1DuqwneYlg+vcDceOvczr+sq0Pih4H1V2Ft9tlLO 5y+H/xMwYtMvqMvW5kJ53piEjmWldWkd7pJchAFGsKnUrRgrd7HwpxuDnkBt36YxX26K gAzn99ZkeVhucBDjAkObhqbCWtZqQge5MrQ/DDbv5slQW18fl8YMWXEEzDN99YzQ5F+W aYGA== X-Gm-Message-State: AJaThX72qh69FkN49B9A5Sa5h7xR0/NG7y2WdYUThrKZOoqQAJxP3c2Z JyTypu2eOoi4x3yJyn77mdE8Z7q9leU= X-Google-Smtp-Source: AGs4zMZf+Xm7qtHnS6QIW1n1SyOH9xFNBZrzRue7wM+u8goNluKpsW5UikAGamqZisvLMWizWZiT1Q== X-Received: by 10.99.121.14 with SMTP id u14mr7009555pgc.420.1510533282947; Sun, 12 Nov 2017 16:34:42 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:f423:c00b:4688:1866? ([2001:67c:1232:144:f423:c00b:4688:1866]) by smtp.gmail.com with ESMTPSA id u12sm2999463pfi.87.2017.11.12.16.34.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 16:34:42 -0800 (PST) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_714FFDAB-4ADF-4C1C-9BF4-8D7B2AB594B8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <37D1FFE1-C789-49CB-9255-2DE2C289975E@fugue.com> References: <151053298229.21346.17987756524110530546.idtracker@ietfa.amsl.com> To: dnssd@ietf.org, HOMENET Date: Mon, 13 Nov 2017 08:34:40 +0800 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [dnssd] Fwd: New Version Notification for draft-sctl-dnssd-mdns-relay-02.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 13 Nov 2017 00:34:45 -0000 --Apple-Mail=_714FFDAB-4ADF-4C1C-9BF4-8D7B2AB594B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I've uploaded a new version of the mDNS Discovery Relay document with = the changes from the hackathon. If you are planning to read it and = haven't yet read it, this is the version to read. :) There are no substantive architectural changes; mostly this is = editorial, but we reduced the total number of TLVs and changed behavior = in small ways. If you have an implementation, you will care; = otherwise, perhaps not. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-sctl-dnssd-mdns-relay-02.txt > Date: November 13, 2017 at 8:29:42 AM GMT+8 > To: "Stuart Cheshire" , "Ted Lemon" = >=20 >=20 > A new version of I-D, draft-sctl-dnssd-mdns-relay-02.txt > has been successfully submitted by Ted Lemon and posted to the > IETF repository. >=20 > Name: draft-sctl-dnssd-mdns-relay > Revision: 02 > Title: Multicast DNS Discovery Relay > Document date: 2017-11-12 > Group: Individual Submission > Pages: 18 > URL: = https://www.ietf.org/internet-drafts/draft-sctl-dnssd-mdns-relay-02.txt > Status: = https://datatracker.ietf.org/doc/draft-sctl-dnssd-mdns-relay/ > Htmlized: = https://tools.ietf.org/html/draft-sctl-dnssd-mdns-relay-02 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-sctl-dnssd-mdns-relay-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-sctl-dnssd-mdns-relay-02 >=20 > Abstract: > This document extends the specification of the Discovery Proxy for > Multicast DNS-Based Service Discovery. It describes a lightweight > relay mechanism, a Discovery Relay, which allows Discovery Proxies = to > provide service on multicast links to which they are not directly > attached. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_714FFDAB-4ADF-4C1C-9BF4-8D7B2AB594B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I've uploaded a new version of the mDNS Discovery Relay = document with the changes from the hackathon.   If you are planning = to read it and haven't yet read it, this is the version to read. :)

There are no substantive = architectural changes; mostly this is editorial, but we reduced the = total number of TLVs and changed behavior in small ways.   If you = have an implementation, you will care; otherwise, perhaps not.

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-sctl-dnssd-mdns-relay-02.txt
Date: = November 13, 2017 at 8:29:42 AM = GMT+8
To: = "Stuart Cheshire" <cheshire@apple.com>, = "Ted Lemon" <mellon@fugue.com>


A new version = of I-D, draft-sctl-dnssd-mdns-relay-02.txt
has been = successfully submitted by Ted Lemon and posted to the
IETF = repository.

Name: = draft-sctl-dnssd-mdns-relay
Revision: 02
Title:= = Multicast DNS Discovery Relay
Document date: = 2017-11-12
Group: Individual Submission
Pages:= = 18
URL: =            https://www.ietf.org/internet-drafts/draft-sctl-dnssd-mdns-rela= y-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-sctl-dnssd-mdns-relay/
Htmlized:       https://tools.ietf.org/html/draft-sctl-dnssd-mdns-relay-02<= br class=3D"">Htmlized:       https://datatracker.ietf.org/doc/html/draft-sctl-dnssd-mdns-rel= ay-02
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-sctl-dnssd-mdns-relay= -02

Abstract:
=   This document extends the specification of the Discovery = Proxy for
  Multicast DNS-Based Service = Discovery.  It describes a lightweight
=   relay mechanism, a Discovery Relay, which allows Discovery = Proxies to
  provide service on multicast links = to which they are not directly
  attached.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_714FFDAB-4ADF-4C1C-9BF4-8D7B2AB594B8-- From nobody Mon Nov 13 19:23:23 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52924128DE7 for ; Mon, 13 Nov 2017 19:23:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151062980133.5960.18433875621187656392.idtracker@ietfa.amsl.com> Date: Mon, 13 Nov 2017 19:23:21 -0800 From: IETF Secretariat Archived-At: Subject: [dnssd] Milestones changed for dnssd WG X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 14 Nov 2017 03:23:22 -0000 Changed milestone "Submit wide-area service discovery solution draft to the IESG as Standards Track RFC", resolved as "Done". URL: https://datatracker.ietf.org/wg/dnssd/about/ From nobody Tue Nov 14 02:38:34 2017 Return-Path: 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 844F4127867 for ; Tue, 14 Nov 2017 02:38:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=jV3jzzpT; dkim=pass (1024-bit key) header.d=yitter.info header.b=QUEj7vD4 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 6T92Ty3GMHjL for ; Tue, 14 Nov 2017 02:38:32 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E53D12762F for ; Tue, 14 Nov 2017 02:38:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 85C9ABF56B for ; Tue, 14 Nov 2017 10:38:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510655881; bh=FhIp4VHJUn1dXnNKtOFdx1/Op6OfACE4gRo+SyWS1zc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=jV3jzzpTncl0lhKCH9bENcVTuv3PfqurvgpkU05msSeMQwDn82AgNxAx7Tw0RQLGb HG5MdxYjwhx2oX152PnO1eW4eL+PMmj8lHmMu4sQT8SH1Hwi4V2hCQ3ZXWVLf2JHlZ 2+bkpO2a2qIndnc3Yf1oYx9Ywd501MUkOYWVTv28= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OcyFwVnhtWR for ; Tue, 14 Nov 2017 10:38:00 +0000 (UTC) Date: Tue, 14 Nov 2017 05:37:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510655880; bh=FhIp4VHJUn1dXnNKtOFdx1/Op6OfACE4gRo+SyWS1zc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=QUEj7vD4OsAXZJOap50QQyc68k1V04DVUyqFXVFDXzuQTepeK6BgC8wCCmC8AetXO A56AbvzCQ94YpEcSP5O10uiVNbhzMQyS9fyq//T2sJNKDZmJL+0ll2G0qe/ytARWAJ huxhCtaT51jUQJsaXOkLvsOFXTUuon6ZDrToczQ8= From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20171114103755.cnma7nmeh7cwtro2@anvilwalrusden.com> References: <150937082405.3417.12600700603314212395@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150937082405.3417.12600700603314212395@ietfa.amsl.com> Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-push-13.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 14 Nov 2017 10:38:33 -0000 Hi, I've just been looking at this draft again and, as it happens, I've been struggling over in DNSOP with the question of referrals. So I realised there may be a small wrinkle in section 6.1. There are a few possible (protocol-permitted) responses to a query for _printers._tcp.foo.example.com: 1. An answer. In this case the Answer section is populated, and the client has discovered that there is a zone cut at _printers._tcp.foo.example.com. This seems fantastically unlikely for our case, but it's a possibility. 2. Name Error (NXDOMAIN). This is also an answer, actually. It says the name _printers._tcp.foo.example.com doesn't exist, period, so the client knows that the name doesn't exist. I'm not actually sure why step 3 in the algorithm is needed, though it might be to try to foil broken servers that send NXDOMAIN when they should not. Anyway, if you're looking for a printer and you get NXDOMAIN from the query for _printers._tcp.foo.example.com, then it doesn't exist. 3. NOERROR/NODATA. This actually seems like the most likely case when there is a printer: there won't be a zone cut at _printers._tcp.foo.example.com, but there will be an RR there. 4. A referral. This is the response that is actually desired in step 1, I think ("The goal is to determine the authoritative server for _printers._tcp.foo.example.com."). What we're actually looking for is a referral response, which may well not contain the SOA but instead the NS records in the authority section. I think the wrinkle in step 2 in this section is that (4) won't necessarily return the SOA record as desired, but instead the NS RRset. The section is correct that you want to find the place that can answer with the SOA (such a server really is the authoritative server), but you get there by stumbling across the NS records n the Authority section. I hope that makes sense. There might be a tiny value in adding a sentence to section 3, noting that clients that are too aggressive might find themselves cut off or even locked out by server policies (those policies seem already to be contemplated in draft-ietf-dnsop-session-signal-04). I don't know how useful that would be, though, and it's not a big deal. Other than this, I think the draft looks in pretty good shape, and I like this work. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Nov 14 18:47:02 2017 Return-Path: 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 8439F1205F0 for ; Tue, 14 Nov 2017 18:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PikW2EUA34pY for ; Tue, 14 Nov 2017 18:46:58 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D736120724 for ; Tue, 14 Nov 2017 18:46:58 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id a84so11030731pfl.0 for ; Tue, 14 Nov 2017 18:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=WCF7aPWTGaKNAXbFuBfiF807sp9cbXvWtHVPeEqM6e8=; b=kpPB3Mpf17LbLJRFsESAbzG7H9PKWjah5U9Hvx24qLwzMAm0KjTtGoUQLgXAvlf4CS 8LXnf3J6/qBNfIEZnmd+N/AnS5UfQTHbpad2hYrmIg8BLL4bD7fChikpoMRZE1kWibge MZBZ6iV3nXNJurPY35Jxzp2QRSYMhiaNLLnGyOzgJ6ZVTtzVSWa/5a0Y/Ai11eqQ1dyH pwE9GgEdUnKoLRY1TAkr9JAynjurGxKQ3JVPIa/c/ES/0c67z+rAnuJ4wTY0pUWUD89s rdmw+WXH7czqnpSBbXmOyJzTaSp3Iwl74kShipgy6LgpDI028kbo+r365L9Rr94TmzQt 8o1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=WCF7aPWTGaKNAXbFuBfiF807sp9cbXvWtHVPeEqM6e8=; b=TfldWerpMltPep8GdR+qMbijpyx8oKJ6KYk+P3E7XQ7i18M3FIhKEN5wSB7SEi6weB 39YFxgs4qKYvsyx710s9AX8y+BwMVaocpdSqUy2Cb0vSVDnPVwpz3LbRzSSwShiQhqbA 2TTw3Rk8EKuJ58+f+VwmzuFleZw8ouj46H3ZrtPO8IW4SGjo8GoUB+7dapt6qyEyKRxn Z2qCzO0ajjvM39fHkz78mz9/CZ03OIdS0m2QUASlLiMhBqvpQJ/5x9uM84t/RkmZ7Ei+ sRHPNmD2qBLP9QmAiSEBuWmXvtPtwJvaGQGO+7TH3zZbjhRMITkV9loQUfsLvLnl/Bpc cqwg== X-Gm-Message-State: AJaThX6jQYa84SsIUFlAhQHfy/tKahnVyDDvg1v5GpOeLXcgvi2NzoAi An9npQIG83DsOkCf3Dhzlzbaig== X-Google-Smtp-Source: AGs4zMbmv4QyWmvn+4csa3xCB19p5HyEk5xsJy4f73dzvc9obbc3EpDz5Hm5LJaWB/sClm89zLvCcQ== X-Received: by 10.98.98.132 with SMTP id w126mr15968460pfb.208.1510714017373; Tue, 14 Nov 2017 18:46:57 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c185sm40403316pfb.112.2017.11.14.18.46.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 18:46:56 -0800 (PST) From: Brian E Carpenter To: dnssd@ietf.org Organization: University of Auckland Message-ID: <8e87dfdd-dcfa-9177-ee78-559ed8d2842b@gmail.com> Date: Wed, 15 Nov 2017 15:46:56 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dnssd] Autonomic Networking overview X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 15 Nov 2017 02:46:59 -0000 This may help as background for Toerless's talk in progress: https://github.com/becarpenter/graspy/blob/master/AN-overview.pdf Brian From nobody Tue Nov 14 21:18:20 2017 Return-Path: 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 6C7E4127201 for ; Tue, 14 Nov 2017 21:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 2OyOwghQ4baV for ; Tue, 14 Nov 2017 21:18:18 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA1F127058 for ; Tue, 14 Nov 2017 21:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510723095; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oqQY0sEcZVWvNXgTVK/fLscw4v150y+joLocjB7QS5s=; b=qjOQ1wU0+yq3Quz4AebZq2I3glZLX4NZE5pQ8zlNWJdeXpbRoSxC+SrBjDQ9rE1e /Sby9o7HI3fvnLdWmvKetWqThqrEFfA+6Ocf2VX5Waqqew0LwEiGUXVngGIRdrOm jomqlhBV7j9IySd/LPtYulQpVwT61NbJT62Xz10QRTt1xxKjcB+wCLxgQZbfEHKP xKpTF0PTwCD0oNib7H+cRHRz26KRgj1MnYLno9ejyXk6EOlXvTMDqUF2qJxBAmFf 36ph/g3qyizeZJ7q+Z80125471ehopyFpH0g6zKW45hRxez2KL65j2DU6dhHfh09 HuM47Gr+mgGtB0FVoBeWWw==; Received: from relay1.asia.apple.com ( [17.82.200.18]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id E9.C6.05091.71ECB0A5; Wed, 15 Nov 2017 13:18:15 +0800 (MYT) X-AuditID: 1152fe06-5e5ff700000013e3-5c-5a0bce178e9a Received: from sng-mailphp-s01.asia.apple.com ( [17.84.76.247]) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id D2.72.23340.71ECB0A5; Wed, 15 Nov 2017 13:18:15 +0800 (MYT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_luoC1ysu6qFnEFsEJXHz1w)" Received: from [IPv6:2001:67c:370:1998:c4f3:e9e0:8755:dc6e] (nat64-f0.meeting.ietf.org [31.130.238.240]) by sng-mailphp-s01.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZG00F261EEBA70@sng-mailphp-s01.asia.apple.com> for dnssd@ietf.org; Wed, 15 Nov 2017 13:18:15 +0800 (SGT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <078C3428-4B09-43A8-ADF4-F02C830EDFC2@apple.com> Date: Wed, 15 Nov 2017 13:18:13 +0800 To: dnssd@ietf.org X-Mailer: Apple Mail (2.3445.1.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUiGHRCSFf8HHeUwdSDChbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuJ731kK/vFUNM0/wdLA+IC7i5GDQ0LARGLyk+IuRi4OIYGV TBIXzn5j7WLkBIuvfNzMCGILCexmlNgx0xHE5hUQlPgx+R4LiM0sECaxaesMNojmR0wSl1bM YAJJCAtIS3RduMsKsoBNQEviwBojiLCkRMumaywQc2wkDq3rArNZBFQlzrx8D2aLCAhJLJ17 iB3iBkWJIzPnMIPMlxB4yipx7MEK1gmM/LOQ3DELyR0QtpbE90etQHEOIFte4uB5WYiwpsSz e5/YkYQXMLKtYhTPTczM0c3MM9JLLM5M1EssKMhJ1UvOz93ECA7Zf2w7GBe8NjzEKMDBqMTD W7aNO0qINbGsuDL3EKMEB7OSCG9yP1CINyWxsiq1KD++qDQntfgQozQHi5I4b2/kp0ghgfTE ktTs1NSC1CKYLBMHp1QDY0zE2/rFuxZpBU4SZS3U6asXqf9hK3sn/bb95xPTfYPs9E511V8/ NrF7rx9XWkf24kXb987acP9E73RdibJ9jX/mzNpufvnCFm39VTL7gj0ubEiVP6w00fJD33Nj 3WsZ/70UYl+X3pkXKDYjLn+jbXnZGnXWwpQXU/1K2jj6NuQJ33WMK1WIVGIpzkg01GIuKk4E AKitL5dVAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUiGOLzXVf8HHeUwYrdUhbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuJ731kK/vFUNM0/wdLA+IC7i5GTQ0LARGLl42ZGEFtIYDej xI6ZjiA2r4CgxI/J91hAbGaBMIlNW2ewdTFyAdU8YpK4tGIGE0hCWEBaouvCXdYuRg4ONgEt iQNrjCDCkhItm66xQMyxkTi0rgvMZhFQlTjz8j2YLSIgJLF07iF2iBsUJY7MnMM8gZFnFpLV s5CshrC1JL4/agWKcwDZ8hIHz8tChDUlnt37xI4kvICRbRWjaFFqTmKloV5icWaiXmJBQU6q XnJ+7iZGUJAFnRDawfhxv8EhRgEORiUeXtbt3FFCrIllxZW5hxglOJiVRHiT+4FCvCmJlVWp RfnxRaU5qcWHGKU5WJTEeTWjPkUKCaQnlqRmp6YWpBbBZJk4OKUaGHf83v+rrdthw5e0Y1Ms Nz1wfP+fwdLtgqWa/cqkfJ2vR8OOsP5tOWSeZPdpz9Q1m/N/CboHnb7e2B2u8itJMcZ36d12 Dy0f1tvrn/uLPLjV9+STbsjd040JPK6nk3bsWJOV6PDudWAo91uRffOY3LV5QheIrpaY4yTK 6DG94mlZ64z6tPum7UosxRmJhlrMRcWJALLGd8YuAgAA Archived-At: Subject: [dnssd] IETF 100 Minutes X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 15 Nov 2017 05:18:19 -0000 --Boundary_(ID_luoC1ysu6qFnEFsEJXHz1w) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello everyone, We have uploaded the minutes for today's DNSSD session: https://datatracker.ietf.org/doc/minutes-100-dnssd/ Thanks again to Barbara and Bjoern for taking minutes, and Mikael for Jabber. Please give them a quick read, and send comments or corrections to the chairs: >. Thanks, David Schinazi --Boundary_(ID_luoC1ysu6qFnEFsEJXHz1w) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello everyone,

We have uploaded the minutes for today's DNSSD session:

Thanks again to Barbara and Bjoern for taking minutes, and Mikael for Jabber.

Please give them a quick read, and send comments or corrections to the chairs: <dnssd-chairs@ietf.org>.

Thanks,
David Schinazi

--Boundary_(ID_luoC1ysu6qFnEFsEJXHz1w)-- From nobody Mon Nov 27 12:47:57 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03952129404; Mon, 27 Nov 2017 12:47:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-dnssd-hybrid@ietf.org, Tim Chown , dnssd-chairs@ietf.org, tim.chown@jisc.ac.uk, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151181567000.30922.837303861217235894.idtracker@ietfa.amsl.com> Date: Mon, 27 Nov 2017 12:47:50 -0800 Archived-At: Subject: [dnssd] Warren Kumari's Discuss on draft-ietf-dnssd-hybrid-07: (with DISCUSS and COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 27 Nov 2017 20:47:50 -0000 Warren Kumari has entered the following ballot position for draft-ietf-dnssd-hybrid-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is (IMO) easily addressed -- I like the document, this DISCUSS is simply to improve it and help prevent foot-shooting. I'd be a YES or NoObj once addressed. There are a number of places where the non-LDH names may be configured on a "normal" DNS server. An example of this is in Section 5.2.1. Domain Enumeration via Unicast Queries: "db._dns-sd._udp.example.com. PTR Building 1.example.com." Putting this in a zonefile and trying to hand it to e.g BIND makes things sad: dns_rdata_fromtext: example.com:18: near '1.example.com.': extra input text zone example.com/IN: loading from master file example.com failed: extra input text zone example.com/IN: not loaded due to errors. Another example is in Section 5.3. Delegated Subdomain for LDH Host Names "For example, a Discovery Proxy could have the two subdomains "Building 1.example.com" and "bldg1.example.com" delegated to it." I think that the document needs to do a better job of explaining that you cannot just include non-LDH in a zonefile without escaping -- Section 5.1. (Format) of RFC1035 may be a good pointer. It may even be a good idea to repeat this (or at least mention the case) whenever there is an example - readers are likely to just cut and paste without reading the full document, leading to unexpected failures (and then gnashing of teeth on forums) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please also see Joel's OpsDir review - it is relevant. Questions: Section 3 - Conventions and Terminology Used in this Document "A set of hosts is considered to be "on the same link" if: ..." I'd suggest "For the purposes of this document a set of hosts..." -- it feels a bit dangerous to be defining what being on a link is more globally, and this probably misses some corner cases and / or conflicts with some other definition. Section 5.1. Delegated Subdomain for Service Discovery Records "In the parent domain, NS records are used to delegate ownership of each defined link name (e.g., "Building 1.example.com")" - can you please provide a pointer here to (I think!) Section 5.5.4. No Text Encoding Translation? Section 5.2.1. Domain Enumeration via Unicast Queries "The "b" ("browse") records tell the client device the list of browsing domains to display for the user to select from and the "db" ("default browse") record tells the client device which domain in that list should be selected by default." What if b.[...] contains "foo" and "bar", and db.[...] contains "baz" (i.e the default browse is not in b)? Should "baz" be automagically added to b, or should it be ignored? The decision is likely implemented on the client, but I think worth noting here - I could see a lazy admin relying on the former and then later getting bitten if this changes. Section 5.4. Delegated Subdomain for Reverse Mapping "For example, in the "/usr/include/dns_sd.h" APIs (available on macOS, iOS, Bonjour for Windows, Linux and Android), ..." Is the API really at /usr/include/dns_sd.h" on Windows? (No idea, and I'm not inclined to go find a Windows box to test, but it sounded wrong so I flagged it!) Section 5.5.2. Suppressing Unusable Records I don't really understand the "MUST NOT" when a Proxy can determine if there are multiple address realms - I get why this is desirable, but if it is important enough to require a MUST NOT, then surely it should be a requirement that all proxies are able to do this (AFAICT, though manual config)? Also, if this is MUST NOT for v4, why is it only SHOULD NOT for v6 ULAs? (please educate me). Section 5.5.3. NSEC and NSEC3 queries "Since a Discovery Proxy only knows what names exist on the local link by issuing queries for them, ..." (specifically the "only") This may be a nit, but couldn't a DP also know that a name exists because a device advertised it? Nits: Section 5.2.2. Domain Enumeration via Multicast Queries "Since a Discovery Proxy exists on many, if not all, the links in an enterprise, it offers an additional way to provide Domain Enumeration data for clients." I think that this should be "many, if not all, *of* the links ..." -- but I'm not sure. From nobody Mon Nov 27 12:49:37 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D728126C0F; Mon, 27 Nov 2017 12:49:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-dnssd-hybrid@ietf.org, Tim Chown , dnssd-chairs@ietf.org, tim.chown@jisc.ac.uk, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151181577550.30906.10149559172837332600.idtracker@ietfa.amsl.com> Date: Mon, 27 Nov 2017 12:49:35 -0800 Archived-At: Subject: [dnssd] Eric Rescorla's No Objection on draft-ietf-dnssd-hybrid-07: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 27 Nov 2017 20:49:35 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-dnssd-hybrid-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Discovery, a compromise is needed that combines the ease-of-use of Multicast DNS with the efficiency and scalability of Unicast DNS. A diagram would help here. one or more others that should be included in the list of automatic browsing domains for legacy clients. It might be clearer to point out that these are defined in 6763. types do and do not exist just the specific name queried, and no others. Nit: I think you mean "for just the" queries, and allow some time for responses to arrive. DNS TTLs in responses are capped to at most ten seconds. Is this text normative? generate authoritative signed data from the local Multicast DNS responses it receives. Off-line signing not applicable to Discovery Proxy. "is not applicable"? 10. Intelectual Property Rights Apple has submitted an IPR disclosure concerning the technique Nit: "intellectual" A mechanism to 'stitch' together multiple ".local." zones so that they appear as one. Such a stitching mechanism will be specified in a future companion document. This stitching mechanism addresses the Not a sentence. From nobody Mon Nov 27 17:48:33 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F531200C1; Mon, 27 Nov 2017 17:48:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-dnssd-hybrid@ietf.org, Tim Chown , dnssd-chairs@ietf.org, tim.chown@jisc.ac.uk, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151183371087.13319.7593098629874408904.idtracker@ietfa.amsl.com> Date: Mon, 27 Nov 2017 17:48:30 -0800 Archived-At: Subject: [dnssd] Warren Kumari's No Objection on draft-ietf-dnssd-hybrid-07: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 28 Nov 2017 01:48:31 -0000 Warren Kumari has entered the following ballot position for draft-ietf-dnssd-hybrid-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This was a DISCUSS, but I have changed to NoObj because I couldn't justify to myself which criteria covered it. I've changed to NoObj, but please address it... Original DISCUSS point: ---- This is (IMO) easily addressed -- I like the document, this DISCUSS is simply to improve it and help prevent foot-shooting. I'd be a YES or NoObj once addressed. There are a number of places where the non-LDH names may be configured on a "normal" DNS server. An example of this is in Section 5.2.1. Domain Enumeration via Unicast Queries: "db._dns-sd._udp.example.com. PTR Building 1.example.com." Putting this in a zonefile and trying to hand it to e.g BIND makes things sad: dns_rdata_fromtext: example.com:18: near '1.example.com.': extra input text zone example.com/IN: loading from master file example.com failed: extra input text zone example.com/IN: not loaded due to errors. Another example is in Section 5.3. Delegated Subdomain for LDH Host Names "For example, a Discovery Proxy could have the two subdomains "Building 1.example.com" and "bldg1.example.com" delegated to it." I think that the document needs to do a better job of explaining that you cannot just include non-LDH in a zonefile without escaping -- Section 5.1. (Format) of RFC1035 may be a good pointer. It may even be a good idea to repeat this (or at least mention the case) whenever there is an example - readers are likely to just cut and paste without reading the full document, leading to unexpected failures (and then gnashing of teeth on forums) ------ Please also see Joel's OpsDir review - it is relevant. Questions: Section 3 - Conventions and Terminology Used in this Document "A set of hosts is considered to be "on the same link" if: ..." I'd suggest "For the purposes of this document a set of hosts..." -- it feels a bit dangerous to be defining what being on a link is more globally, and this probably misses some corner cases and / or conflicts with some other definition. Section 5.1. Delegated Subdomain for Service Discovery Records "In the parent domain, NS records are used to delegate ownership of each defined link name (e.g., "Building 1.example.com")" - can you please provide a pointer here to (I think!) Section 5.5.4. No Text Encoding Translation? Section 5.2.1. Domain Enumeration via Unicast Queries "The "b" ("browse") records tell the client device the list of browsing domains to display for the user to select from and the "db" ("default browse") record tells the client device which domain in that list should be selected by default." What if b.[...] contains "foo" and "bar", and db.[...] contains "baz" (i.e the default browse is not in b)? Should "baz" be automagically added to b, or should it be ignored? The decision is likely implemented on the client, but I think worth noting here - I could see a lazy admin relying on the former and then later getting bitten if this changes. Section 5.4. Delegated Subdomain for Reverse Mapping "For example, in the "/usr/include/dns_sd.h" APIs (available on macOS, iOS, Bonjour for Windows, Linux and Android), ..." Is the API really at /usr/include/dns_sd.h" on Windows? (No idea, and I'm not inclined to go find a Windows box to test, but it sounded wrong so I flagged it!) Section 5.5.2. Suppressing Unusable Records I don't really understand the "MUST NOT" when a Proxy can determine if there are multiple address realms - I get why this is desirable, but if it is important enough to require a MUST NOT, then surely it should be a requirement that all proxies are able to do this (AFAICT, though manual config)? Also, if this is MUST NOT for v4, why is it only SHOULD NOT for v6 ULAs? (please educate me). Section 5.5.3. NSEC and NSEC3 queries "Since a Discovery Proxy only knows what names exist on the local link by issuing queries for them, ..." (specifically the "only") This may be a nit, but couldn't a DP also know that a name exists because a device advertised it? Nits: Section 5.2.2. Domain Enumeration via Multicast Queries "Since a Discovery Proxy exists on many, if not all, the links in an enterprise, it offers an additional way to provide Domain Enumeration data for clients." I think that this should be "many, if not all, *of* the links ..." -- but I'm not sure. From nobody Wed Nov 29 09:58:24 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 369C51288A9; Wed, 29 Nov 2017 09:58:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-dnssd-hybrid@ietf.org, Tim Chown , dnssd-chairs@ietf.org, tim.chown@jisc.ac.uk, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151197830321.8005.13053135592991202256.idtracker@ietfa.amsl.com> Date: Wed, 29 Nov 2017 09:58:23 -0800 Archived-At: Subject: [dnssd] Alexey Melnikov's No Objection on draft-ietf-dnssd-hybrid-07: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 29 Nov 2017 17:58:23 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dnssd-hybrid-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a well written document. I have a few clarifying questions which I think will improve the document. In 5.3: To accomodate this difference in allowable characters, a Discovery Proxy SHOULD support having two separate subdomains delegated to it for each link it serves, one whose name is allowed to contain arbitrary Net-Unicode text [RFC5198], and a second more constrained subdomain whose name is restricted to contain only letters, digits, and hyphens, to be used for host name records (names of 'A' and Am I correct that Punicode encoded A-Labels are still valid here? It would be good to say so. 'AAAA' address records). 5.5.4. No Text Encoding Translation A Discovery Proxy does no translation between text encodings. Specifically, a Discovery Proxy does no translation between Punycode Punycode needs an Informative reference. and UTF-8, From nobody Wed Nov 29 11:51:50 2017 Return-Path: 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 54C0D1270A0; Wed, 29 Nov 2017 11:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 HOh0RNTE9asI; Wed, 29 Nov 2017 11:51:46 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0105.outbound.protection.outlook.com [104.47.41.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130D7128CFF; Wed, 29 Nov 2017 11:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nNtKh78b9Wo0TU3inxQfQJ8S6XtVqZc+9hKDHxZQKXg=; b=YhgdZNhsypaEqaRqsEkEbcuOQy5RdoPwug33hlRVJV6L/C2cgMR5DkS86iqh2Okb+waTBvsRBpEDthI5zaRAL41WJzt+p7vSEAiNSi+edfkSIyiZQNI8ZVpB2ED/DHa4n0eECU9hX6ZOiLwJ/B4bbn3WiCdrY0b/BKEJxAz+yTQ= Received: from CY4PR21MB0856.namprd21.prod.outlook.com (10.173.192.145) by CY4PR21MB0150.namprd21.prod.outlook.com (10.173.189.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.1; Wed, 29 Nov 2017 19:51:41 +0000 Received: from CY4PR21MB0856.namprd21.prod.outlook.com ([10.173.192.145]) by CY4PR21MB0856.namprd21.prod.outlook.com ([10.173.192.145]) with mapi id 15.20.0302.001; Wed, 29 Nov 2017 19:51:41 +0000 From: Dave Thaler To: Alexey Melnikov , "dnssd@ietf.org" CC: "draft-ietf-dnssd-hybrid@ietf.org" Thread-Topic: [dnssd] Alexey Melnikov's No Objection on draft-ietf-dnssd-hybrid-07: (with COMMENT) Thread-Index: AQHTaTup+l4G3TBAcE+HKD7OOtOUKqMrwzXA Date: Wed, 29 Nov 2017 19:51:41 +0000 Message-ID: References: <151197830321.8005.13053135592991202256.idtracker@ietfa.amsl.com> In-Reply-To: <151197830321.8005.13053135592991202256.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [167.220.0.72] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0150; 6:p20DGucEFhjcNRqYFehzRHOTge3Kn/tVUIEfJUjX6DHOLNlMJyR/f8OQ7087S6WGwT2AChdFv8ce+MhgjSVeMVgrF2TbHJJAp6Mke7ydOdBgDz0iUY4PK7qENT8Nqvft9gmWFuK9mSNWywRo+LaThQM/LDrOUKExQwlkS7Zw3X/7MXWOtIV8JZZcV946TVKKVMqDH+nKieU1n+4YKTFhbgyxmdGwfOAWEyJXtp3KWklGqLYBPTKKDgVDF2hGjSoLjkuy2/Td/jxW+TmO0RdSfW0bOYAmVwsa1TgUcO8Cr01JkSAiUL3WVjwSN6lFlYHvYuCFOLXpv3Pa2MAs4l+orBfh9oVgm4a3F2ZhRk0mAlI=; 5:HcZPtnmqqNXKBMHbywa/WZgnjGtHt4R6JI+Vlc2jhOLrUW4Rg+cwC0I8yolGVPFzB+dWsMJSIk0poP0EYhOZnhKDoSZnImrZum3vEc3VuFqwM0aYl9vKDU7FULuFAIet8tUk/dgZlqNlqojAqpikTkpRySwDn9XuB34HmNCP4Bw=; 24:TfbBQyUVWe7dsAMIS/QsQq4yDhAfj7DHZ7wMPHF/vke3jUsVgcH+UP3UEekLcEKjNsxajK2oOU3rSNSYH8mcn2Wf/NasN2oRiwB7nWggh2k=; 7:a0q38E1iX2ANMrqoU+i2GknZzZUvg2MwAA0oUgx3Q+vVv6Sn0camlCJOBv2j+u8LKoX1SPzYa78yl68Itv+b625wW01+IitGggtLvJTp3Vr8oZc/lutIZM8i/B9r7zwguNp8mQjxlgD/zKthucsrWnfY/sCVZep9VF59aXAM6OkiTz924qlKx7I65tMggOrwQWnebGHrJtboXVb5VdCAQamWkUqibYe/R47shgcno/V8KaTPYfu3TqM59yiMFQ0U x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7347c095-9984-417e-a2ac-08d537629c9f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603274); SRVR:CY4PR21MB0150; x-ms-traffictypediagnostic: CY4PR21MB0150: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231022)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0150; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0150; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(366004)(346002)(376002)(47760400005)(199003)(189002)(24454002)(229853002)(2900100001)(5660300001)(101416001)(81156014)(81166006)(2950100002)(8676002)(189998001)(66066001)(6246003)(33656002)(86612001)(2906002)(110136005)(86362001)(316002)(50986010)(76176010)(54356010)(22452003)(230783001)(97736004)(6116002)(3846002)(102836003)(106356001)(105586002)(8936002)(53936002)(9686003)(2501003)(8990500004)(6306002)(3280700002)(3660700001)(7736002)(99286004)(478600001)(55016002)(4326008)(25786009)(14454004)(7696005)(8666007)(10290500003)(68736007)(74316002)(10090500001)(305945005)(6506006)(6436002)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0150; H:CY4PR21MB0856.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7347c095-9984-417e-a2ac-08d537629c9f X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 19:51:41.4948 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0150 Archived-At: Subject: Re: [dnssd] Alexey Melnikov's No Objection on draft-ietf-dnssd-hybrid-07: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 29 Nov 2017 19:51:49 -0000 Alexey wrote:=20 > 5.5.4. No Text Encoding Translation >=20 > A Discovery Proxy does no translation between text encodings. > Specifically, a Discovery Proxy does no translation between Punycode > >Punycode needs an Informative reference. > > and UTF-8, Indeed, and the grammatical use of Punycode in this sentence is actually wr= ong. "Punycode is an Algorithm, Not a Name or Adjective" (https://tools.ietf.org= /html/rfc5890#section-2.3.4) The informative reference would be RFC 3492 but the text should be somethin= g closer to "a Discovery Proxy does no translation between Punycode-encoded strings and= UTF-8 strings", or probably more correctly "a Discovery Proxy does no translation between A-la= bels and U-labels". Dave From nobody Wed Nov 29 13:29:28 2017 Return-Path: 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 48FCD126CD6; Wed, 29 Nov 2017 13:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=xVEfuStn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EkuhRNkY 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 aaYDV-3GnxKS; Wed, 29 Nov 2017 13:29:19 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD034120227; Wed, 29 Nov 2017 13:29:16 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DBDDC206EE; Wed, 29 Nov 2017 16:29:15 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 29 Nov 2017 16:29:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=OqSHejVFOIzCdZo5EMD9lmtDGZlcM ZXfG3kFiCy3nXs=; b=xVEfuStnJiZ+ASnxEE5hfJH+mojBgZFyvwXuG1Z0g0wob ryuTvb60qYS2vBc6bgj2c5rK+9jWwu2ZZglR8dnrjjsjryYlSq5EhUclnBdY6Upt R0xzi3ocjj5jy0ah7l4Qboi/YIpA8YLAuecGR5Sjop8LWO9i7e2mqCZxEf7Zidnt mhu5kkNgUxl6g7W//ul3cDvg0d+AXBomhju3LAPa3m739S0p+g4+3SoJy13TysPF t+VZalQOUgywVROICEpyUcbSG+T6MUuRytDycmerQwi272obERblb/W9vEXJ0xiI +grFETIq11EqhBJZ4iOibSb97BOgR+NieIEn4s4Xg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=OqSHej VFOIzCdZo5EMD9lmtDGZlcMZXfG3kFiCy3nXs=; b=EkuhRNkYt/nCeSl7veoUS3 9ScjygHT6J0UMvQcgGvM4Tct8/qGQalFZ0QZFmi0FaDAxuyuWXVUhfbeTSNyB2fo hDaEhU1XWeISfp2RNnLJcjzSZ6YQuOiinp+zZRE4MFQr+laEaGFfGmJmg4iZGvb5 GTxvM2LVIimk/Gehz7wAWgzJWQYKDgYZ+rpvTwN3rtxLntvMm3OO0ct3+DjpLEOJ LuI+dVBZvnWZl46tlnFXcm+PMP8Ws9uBD5V3xWAX+gAjAY1Gmf3OcWsGqzMTxul1 XgXrK+NN+byi5/uaFA5wWMmhDwPCCjM0C5PIlaA2ABkjVsKcCUwBcXjPYmpT7NHg == X-ME-Sender: Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id DE9B27FAC5; Wed, 29 Nov 2017 16:29:14 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <150741644089.23000.1690410715049859696@ietfa.amsl.com> Date: Wed, 29 Nov 2017 16:29:13 -0500 Cc: gen-art , dnssd@ietf.org, draft-ietf-dnssd-hybrid.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <298CAEC2-EF64-41C5-AEE5-2B0DF9DCA8D1@cooperw.in> References: <150741644089.23000.1690410715049859696@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dnssd] [Gen-art] Genart last call review of draft-ietf-dnssd-hybrid-07 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 29 Nov 2017 21:29:21 -0000 Joel, thank you for your review. I have entered a No Objection ballot. Best, Alissa > On Oct 7, 2017, at 6:47 PM, Joel Halpern wrote: > > Reviewer: Joel Halpern > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-dnssd-hybrid-07 > Reviewer: Joel Halpern > Review Date: 2017-10-07 > IETF LC End Date: 2017-10-12 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is ready for publication as a Proposed Standard > > Major issues: N/A > > Minor issues: N/A > > Nits/editorial comments: > Given the confusion I experienced reading the early portions of the > document, a reference at the end of the introduction to the domain > discovery mechanisms may help readers. > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Nov 29 15:29:19 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D4F12896F; Wed, 29 Nov 2017 15:29:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dnssd-hybrid@ietf.org, Tim Chown , dnssd-chairs@ietf.org, tim.chown@jisc.ac.uk, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151199815719.4772.13128632772825062687.idtracker@ietfa.amsl.com> Date: Wed, 29 Nov 2017 15:29:17 -0800 Archived-At: Subject: [dnssd] Ben Campbell's No Objection on draft-ietf-dnssd-hybrid-07: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 29 Nov 2017 23:29:17 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dnssd-hybrid-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive comments: I support Warren's almost-discuss about non-LDH characters. Editorial Comments: - Abstract: It would be helpful to say this document defines a proxy in the abstract. -3: The draft contains multiple instances of lower-case "should". If that is intentional, please consider using the boilerplate from 8174. From nobody Wed Nov 29 18:15:08 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A40DB126FDC; Wed, 29 Nov 2017 18:15:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-dnssd-hybrid@ietf.org, Tim Chown , dnssd-chairs@ietf.org, tim.chown@jisc.ac.uk, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151200810364.4869.4209640506479245819.idtracker@ietfa.amsl.com> Date: Wed, 29 Nov 2017 18:15:03 -0800 Archived-At: Subject: [dnssd] Adam Roach's Discuss on draft-ietf-dnssd-hybrid-07: (with DISCUSS and COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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, 30 Nov 2017 02:15:03 -0000 Adam Roach has entered the following ballot position for draft-ietf-dnssd-hybrid-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- First, I'd like to say thanks for your work on this document. I find this work exciting, and hope to see it widely deployed in the short term. I do have one major concern that I believe rises to the level of a DISCUSS, although I believe it should be trivial to fix. The reason I believe it to be a barrier to publication is that it makes a broad architectural statement that has implications for all application protocols; which, beyond being outside the remit of the working group per its charter, I seriously doubt received the level of cross-area review appropriate for its scope. The statement of concern is in section 5.5.5: As is the case with NAT ALGs, protocol designers are advised to avoid communicating names and addresses in nonstandard locations, because those "hidden" names and addresses are at risk of not being translated when necessary, resulting in operational failures. I would expect this statement, if evaluated by the IETF community at large, to be extremely controversial: it implies application-layer protocol designs that provide neither confidentiality nor integrity protection for protocol parameters. Architecturally, it's important to distinguish between NAT ALGs, which are not a party to the security context of the protocols they carry, and DNS discovery proxies, which are. This makes the guidance in here appropriate in the context of DNS-SD records, while being problematic in the broader NAT ALG case cited. I would find no problem with a narrowly-scoped statement that pertains to DNS usage in particular, although I wonder whether designers of DNS TXT record usage in the future are likely to become aware of such guidance. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Minor nit: section five's "four DNS subdomains" seems to be predicated on network designs that always assign segments with netmasks evenly divisible by either 8 bits (IPv4) or 4 bits (IPv6). I don't think this is frequently the case any more (e.g., my home network is split into /17 segments, and I have to assume most enterprise deployments are more complex than my house). I believe the reverse delegation records should be described as "one or more per segment." Substantial comment: the text in section 5.4 seems to assume that all addresses on a segment will *either* correspond to mDNS-discovered addresses, *or* to addresses provisioned in a traditional DNS server. If this is the assumption (and a limitation baked into the design), I think it should be documented. If there's some clever work-around that allows both kinds of addresses to be on a single segment, it would be great to describe that in here instead. Question: Section 5.6, bullet one (starting "Not using LLQ or Push Notification; no answer in cache") calls for the proxy to return a unicast result as soon as the first valid mDNS response is received. Unless I've misunderstood something, this means that (for example) a query for "_ipp._tcp" on an empty cache will simply return only the single fastest-to-respond printer to the querying client. Was the tradeoff of "faster response but for only one device" explicitly discussed by the WG? Minor suggestion: Section 5.6, bullet three (starting "Using LLQ or Push Notification; at least one answer in cache") -- this bullet is the only one that is not explicit about whether an mDNS query should be performed by the proxy. I think the intention that it is *not* (due to the RRSet TTL harmonization discussed above), but it would probably help implementors out if you explicitly repeated that no mDNS queries are performed. Major issue: Section 10 needs to be removed. See https://tools.ietf.org/html/rfc8179#section-10 From nobody Wed Nov 29 20:17:34 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B29127868; Wed, 29 Nov 2017 20:17:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-dnssd-hybrid@ietf.org, Tim Chown , dnssd-chairs@ietf.org, tim.chown@jisc.ac.uk, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151201545220.4829.10756194635711660556.idtracker@ietfa.amsl.com> Date: Wed, 29 Nov 2017 20:17:32 -0800 Archived-At: Subject: [dnssd] Kathleen Moriarty's No Record on draft-ietf-dnssd-hybrid-07: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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, 30 Nov 2017 04:17:32 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-dnssd-hybrid-07: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I might be missing it, but I don't see a response to the concern raised by the SecDir reviewer: https://mailarchive.ietf.org/arch/msg/secdir/LUereu5JMsOJrfbIT0TFMBdmRlw I haven't read this draft yet, but plan to prior to the telechat. I just thought it was important to ask this question now in case I am missing the response or the authors did not see the review question. From nobody Thu Nov 30 05:45:15 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 724B012946A; Thu, 30 Nov 2017 05:45:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-dnssd-hybrid@ietf.org, Tim Chown , dnssd-chairs@ietf.org, tim.chown@jisc.ac.uk, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151204950946.4805.3294338547542368383.idtracker@ietfa.amsl.com> Date: Thu, 30 Nov 2017 05:45:09 -0800 Archived-At: Subject: [dnssd] Spencer Dawkins' No Objection on draft-ietf-dnssd-hybrid-07: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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, 30 Nov 2017 13:45:09 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dnssd-hybrid-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for doing this work (and of course resolving Discusses :-) ... From nobody Thu Nov 30 06:40:23 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 697FF12948D; Thu, 30 Nov 2017 06:40:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-dnssd-hybrid@ietf.org, Tim Chown , dnssd-chairs@ietf.org, tim.chown@jisc.ac.uk, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151205281642.4857.14078498565974850297.idtracker@ietfa.amsl.com> Date: Thu, 30 Nov 2017 06:40:16 -0800 Archived-At: Subject: [dnssd] Kathleen Moriarty's No Objection on draft-ietf-dnssd-hybrid-07: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 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, 30 Nov 2017 14:40:16 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-dnssd-hybrid-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I might be missing it, but I don't see a response to the concern raised by the SecDir reviewer and I am interested to see how the points can be addressed in this draft: https://mailarchive.ietf.org/arch/msg/secdir/LUereu5JMsOJrfbIT0TFMBdmRlw Thank you.