From nobody Tue Oct 13 19:26:41 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18551A905F; Tue, 13 Oct 2015 19:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 rckYp1nABz-E; Tue, 13 Oct 2015 19:26:36 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 E33931A9054; Tue, 13 Oct 2015 19:26:35 -0700 (PDT) Received: by padcn9 with SMTP id cn9so7769648pad.2; Tue, 13 Oct 2015 19:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=j+WSr3ODDETvEvEuoKdYaroZJ9fOxhYdsjjAvoXKQCo=; b=w1lj8nbIs01Br/neYEPcPyvGQhINVx7blDIFUuuSKHTJRsb0VovnvxL5zPtLzYVVkX 1KScjGEHawRkRg0R729NINi4B7e7K/IlD7PnhPOv7T07pv1iNtMm0I+iHOiywx+lJ3KV QhzCQXC4OVv7bsVvGJV5MzKjWpbmgKab8PpetsdX2bXnZosmWDlGwxKnPOBy8LSAW4pp 8d+qh2bE58GLag3Xb4oP+Bf4fRghpsiGu0N79ZLyx56a41S0J2UbA6VW6Qn6YVa2/3gm 38tpz+J6JgXiAfWjnwfFORmpA0pgpXfgWsCj6YlbWlgD8+NDix273kERMlZCiIyfBb6j IiTA== X-Received: by 10.68.238.69 with SMTP id vi5mr860188pbc.29.1444789595622; Tue, 13 Oct 2015 19:26:35 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by smtp.googlemail.com with ESMTPSA id qp5sm6286404pbc.43.2015.10.13.19.26.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Oct 2015 19:26:35 -0700 (PDT) To: ietf dnssd From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <561DBDBE.5060406@gmail.com> Date: Tue, 13 Oct 2015 19:28:14 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: homenet@ietf.org Subject: [dnssd] https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 02:26:37 -0000 Dear dnssd wg. draft-otis-dnssd-scalable-dns-sd-threats-01 has been updated to better track changes with DNSOP and HOMENET. One minor nit in this latest version is a reference to RFC6195 rather than the newer RFC6895 which mostly cleaned up in progress references. There are still a few days remaining, so if someone finds something else needing corrected, the RFC6195 reference will be fixed as well. Regards, Douglas Otis From nobody Mon Oct 19 12:10:08 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6934E1B2C10 for ; Mon, 19 Oct 2015 12:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 j1ZhqGk1JUnL for ; Mon, 19 Oct 2015 12:10:06 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 735AD1B2C0F for ; Mon, 19 Oct 2015 12:10:05 -0700 (PDT) Received: by pabrc13 with SMTP id rc13so198892770pab.0 for ; Mon, 19 Oct 2015 12:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=WpBnlN4dXD/lJcACUtt5y6PKi/AiIIaNAxDc5yDPdUo=; b=z703YkLwSmwE+esH5qiOj4P4Utz7tcrFjlIqhTEBN8ns1RwSEYCpaZXUGI0+4JoOys MhT+iP6vS7xn+xjJEg/WyHBrdnplaqxnsAAYl5mNyA9fu232dAdJTNgJjdKcYWt63Rax 6zk2kKfAXoY3UoiHbRV2L7EIlNDwphr3qrcpat8MDO/Gyz8U5v67AS1bMXEkTybBX1Ms 220139f5bCr+RbUYzyEZP8EiiMSntd8+SabhW+9LaIKsbbI4BApAWf62bmb+pqtVbZ7z kqmQt4Q3XarRLzaU92foot2g50tUjZTRe+lFIlT8Zf2Wwz4bSTdZ0r54HSO/hSz/2DoL aUTg== X-Received: by 10.68.185.67 with SMTP id fa3mr24964761pbc.113.1445281805099; Mon, 19 Oct 2015 12:10:05 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by smtp.googlemail.com with ESMTPSA id fb1sm37994846pab.9.2015.10.19.12.10.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Oct 2015 12:10:04 -0700 (PDT) To: ietf dnssd From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <56254083.7080706@gmail.com> Date: Mon, 19 Oct 2015 12:12:03 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dnssd] minor update of https://tools.ietf.org/pdf/draft-otis-dnssd-scalable-dns-sd-threats-02 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 19:10:07 -0000 Dear dnssd wg, Sadly, mailing list has been inactive on document review. Nevertheless, it seemed important to track changes occurring in other work groups and to correct minor nits affecting readability. Some of which were repaired by addition of white-space within the underlying XML document. The issues seem related to xml2rfc.tcl script currently offered in mac ports. If you have already read version 1, then version 2 will likely seem unchanged. https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-02 Regards, Douglas Otis From nobody Mon Oct 19 13:45:52 2015 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 A66751ACD32; Mon, 19 Oct 2015 13:45:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019204534.16630.60174.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 13:45:34 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:45:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery Working Group of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-01.txt Pages : 18 Date : 2015-10-19 Abstract: The Domain Name System (DNS) was designed to efficiently return matching records for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 15:49:42 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1653A1B2D34; Mon, 19 Oct 2015 15:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 GHqhcfO3X6vb; Mon, 19 Oct 2015 15:49:39 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED6A1AD365; Mon, 19 Oct 2015 15:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1709; q=dns/txt; s=iport; t=1445294964; x=1446504564; h=from:to:cc:subject:date:message-id:mime-version; bh=JYfElrJEZOl9tIj6BaveCjINuXNQgfliFaLxnuQk2rs=; b=ZGdP7lVB/2bb86hwJjQ1ZVH54Bk0NP6x0ryc7sHKkuh1vBG+QQu23ajm v8nbvnwBTBfC/2XO6pvNsopZgeGSRzcyZJyB/MhIgs/t+Val7wwZ7gy2W LpYB9OpHkNl9+P61dK5YBC8wfZzf/8tmewktMIqm+BCx34lCCjh4c8fjz c=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DHAgC8ciVW/4MNJK1egzaBSblphCEOgVqGHoE/OBQBAQEBAQEBfwuEMAR5EgGBACcEDhOIIsRxAQEBAQEBAQEBAQEBAQEBAQEBAQEBDwmGd4IQh3uDIYEUBZYjAYJNgWGIboFYhDyWAwEfAUOEA4VTgQYBAQE X-IronPort-AV: E=Sophos;i="5.17,704,1437436800"; d="asc'?scan'208";a="199591623" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 19 Oct 2015 22:49:24 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9JMnNQn032004 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 22:49:23 GMT Received: from xch-rtp-016.cisco.com (64.101.220.156) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 18:49:05 -0400 Received: from xch-rtp-016.cisco.com ([64.101.220.156]) by XCH-RTP-016.cisco.com ([64.101.220.156]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 18:49:05 -0400 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: dnssd WG meeting at IETF 94 Thread-Index: AQHRCsBbibdt2g8KGUWdZOiVFhgetw== Date: Mon, 19 Oct 2015 22:49:05 +0000 Message-ID: <9440F960-C332-43D8-930B-66345A158104@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.40.220] Content-Type: multipart/signed; boundary="Apple-Mail=_B201F9B3-25AA-4113-B89B-835D041D5EE1"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "dnssd-chairs@ietf.org" Subject: [dnssd] dnssd WG meeting at IETF 94 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 22:49:41 -0000 --Apple-Mail=_B201F9B3-25AA-4113-B89B-835D041D5EE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The dnssd WG is scheduled to meet in Yokohama 1520-1650 on Monday, = 2-11-2015. Meeting at the same time are: bfcpbis, netvc, cfrg, lime, = ccamp, rtgwg, rmcat. Please get in touch with the chairs if you want a slot in the agenda. We're looking for volunteers to take notes (is "etherpad" a verb yet?) = and act as jabber scribe during the meeting. - Ralph --Apple-Mail=_B201F9B3-25AA-4113-B89B-835D041D5EE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWJWV/AAoJEINeeBNmFjV58HcP/RHxszpAeXXL5DSwwf9mbzQe xlTcmLp+Na7Iczz6lIQrqnrkD2B5L5gfJBEC6I0fyC6zO4//E3I17tWRvuJOpj7D D4WR5168ALQu5s/AhzAHqmiMdbLXyE8+soueBazmHh94oXCXVLaj3AyV9JI4OB2E q79qutdrVKp9JWVkEon2ZRqQwOAVihMzhQK2WSxfYemK8AnCl9J3jI7Sz0UoxOeY 7Pq0poyc9EsI/XJtDTej0MVjLnpIP9lmZ5lNJHA2wqJLMANNatcn5G9y+F7W+nqT 9wWxVL6yZ3gnPIoH1Hn8ZkkhNl7RM0HekyywwidFPiIHfPKhF6ZPWh80ZP+h3Y3z jYGAYyDjH+fWqGy8EaibYcynC5KA4R+Z82qa3Wnw98btGR0bB6uueyrjOp4NNgqx roAg8I+UAgCHOH0WjpkVwZ/6McFFqYUCAoRarGEfP48vxZ+QA81QJehPHMmNJx+x BOvfrcwmRfNJcoel9vn8NwSoYI1xD3z/WiQk+dttIUOoSmEYjvFVoygj1fl+M5AE uTDZC/DoyRo6waKUsBnNarGBzAclJIkSWNy8ZSp8wpOckQPsPT1KEeuE7EOkSC7d /gefTL6b99IIedNkCK0VVK11oHlVipnfmkv/m8d5bP604jdTKBREDxQ2yiJoAy3q xIZgHi9xiGI6LawjvPQv =7Ft3 -----END PGP SIGNATURE----- --Apple-Mail=_B201F9B3-25AA-4113-B89B-835D041D5EE1-- From nobody Mon Oct 19 16:41:31 2015 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 493F81B2ED1; Mon, 19 Oct 2015 16:41:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019234130.1944.27627.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 16:41:30 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-02.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 23:41:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery Working Group of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-02.txt Pages : 24 Date : 2015-10-19 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 16:43:29 2015 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 8F74B1B2ED6; Mon, 19 Oct 2015 16:43:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019234326.3265.19158.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 16:43:26 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-hybrid-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 23:43:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery Working Group of the IETF. Title : Hybrid Unicast/Multicast DNS-Based Service Discovery Author : Stuart Cheshire Filename : draft-ietf-dnssd-hybrid-01.txt Pages : 23 Date : 2015-10-19 Abstract: Performing DNS-Based Service Discovery using purely link-local Multicast DNS enables discovery of services that are on the local link, but not (without some kind of proxy or similar special support) discovery of services that are outside the local link. Using a very large local link with thousands of hosts facilitates service discovery, but at the cost of large amounts of multicast traffic. Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient and doesn't require excessively large multicast domains, but requires that the relevant data be available in the Unicast DNS namespace. This can be achieved by manual DNS configuration (as has been done for many years at IETF meetings to advertise the IETF Terminal Room printer) but this is labor intensive, error prone, and requires a reasonable degree of DNS expertise. The Unicast DNS namespace can be populated with the required data automatically by the devices themselves, but that requires configuration of DNS Update keys on the devices offering the services, which has proven onerous and impractical for simple devices like printers and network cameras. Hence a compromise is needed, that combines the ease-of-use of Multicast DNS with the efficiency and scalability of Unicast DNS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-hybrid-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 19:33:38 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40451AD2C4 for ; Mon, 19 Oct 2015 19:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.311 X-Spam-Level: X-Spam-Status: No, score=-104.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 oWUc3veapMii for ; Mon, 19 Oct 2015 19:33:35 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F0D1AD36F for ; Mon, 19 Oct 2015 19:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1445308415; x=2309222015; 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=SSvh6FFoRRHaSJ0aSqV/hqhRnVhcCxp3EALdeJb3SX8=; b=mUN/9U5bH8sNh4Yagsj4qTbrU/z03HXgxrELClYIB5wRFVVL9ofiiN0pSinlQLDS P6CF60F9BxMrpuQsNwaT+xbnAamOsq2GzQc95eE96bxZRqaH6gv5iXw092iBq02u aOCbNPsV0fpmeEVZofOM3b7lrP2UNpYEAzfO1F3BFSRRgj3k+2gLHLOHLrKpKJJ4 rvrzkmRlZPjqMTugMM6qcM86bkYoluydlDID9lPPCkoAy3vWI7mPBn1K73i5Nu7I 7LJcVFQAdD23Fhe9K43S9jz9Rkrb52lswDX0vP7h+DyONOkKWeWyBBbcfkByTwo+ PKphdaBAv9vo4jknBNBmrQ==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id C0.B4.15870.FF7A5265; Mon, 19 Oct 2015 19:33:35 -0700 (PDT) X-AuditID: 11973e13-f798c6d000003dfe-7f-5625a7ff7e27 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 08.6F.29028.EF7A5265; Mon, 19 Oct 2015 19:33:35 -0700 (PDT) Received: from [10.0.1.9] (50-197-138-101-static.hfc.comcastbusiness.net [50.197.138.101]) by kencur.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NWH00C6GZ3YMT80@kencur.apple.com>; Mon, 19 Oct 2015 19:33:34 -0700 (PDT) Sender: cheshire@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Stuart Cheshire In-reply-to: <9440F960-C332-43D8-930B-66345A158104@cisco.com> Date: Mon, 19 Oct 2015 19:33:34 -0700 Content-transfer-encoding: quoted-printable Message-id: <30D5931B-1E74-48C8-9B32-8C9890F0CE0E@apple.com> References: <9440F960-C332-43D8-930B-66345A158104@cisco.com> To: "Ralph Droms (rdroms)" X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUi2FCYpvt/uWqYQfdiNosr7/qYLd4vncXo wOSxZMlPpgDGKC6blNSczLLUIn27BK6MM5fzC/5zVixa2MvcwDiBo4uRk0NCwESidfUTRghb TOLCvfVsXYxcHEIC+xgl2pZMZIcpuvboGTtEop1JYtHPwywQzkImie8z3oNVCQtISbxa+Zm5 i5GDg1lAXWLKlFyQMK+AnsTf3lVsIGFhAQOJfQc9QcJsAloSLz5fYQOxOQVsJV6ceApmswio SvzrfQV2BLPAG0aJu+8fMoMkmAW0JZ68u8AKMdNG4sTaOewgM4WA7O+HqkHCIgK6Eoc+3WKF uFlWYvfvR0wgcyQENrBJ/P8zjWUCo8gshOtmIbluFpINCxiZVzEK5SZm5uhm5pnqJRYU5KTq JefnbmIEBfl0O+EdjKdXWR1iFOBgVOLhvRCpGibEmlhWXJl7iFGag0VJnNfvt0qYkEB6Yklq dmpqQWpRfFFpTmrxIUYmDk6pBkbvb67Lb4hpBv7I4A2ZxWg1e9b55blGnmUbdVICvOJSChvT nTSedp0o8F14d8mhj349L9m84s4Wcni3Lvz17JjGt/+Sp4UNL/c8v87NvNtR8aDsgrL5j8O0 WDsXc1XmpSo8mlPx1GhTkOiPt/PPzt4/78a+jkN5hs7vucM1/v9siFI3jzTcaKLEUpyRaKjF XFScCADVxlVsUwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUiON1OTff/ctUwgxcvmC2uvOtjtni/dBaj A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyzlzOL/jPWbFoYS9zA+MEji5GTg4JAROJa4+esUPY YhIX7q1n62Lk4hASaGeSWPTzMAuEs5BJ4vuM92BVwgJSEq9WfmbuYuTgYBZQl5gyJRckzCug J/G3dxUbSFhYwEBi30FPkDCbgJbEi89X2EBsTgFbiRcnnoLZLAKqEv96X4HtYhZ4wyhx9/1D ZpAEs4C2xJN3F1ghZtpInFg7hx1kphCQ/f1QNUhYREBX4tCnW6wQN8tK7P79iGkCo+AshINm ITloFpKhCxiZVzEKFKXmJFZa6CUWFOSk6iXn525iBAVlQ2HaDsam5VaHGAU4GJV4eDViVMOE WBPLiitzDzFKcDArifBq9ACFeFMSK6tSi/Lji0pzUosPMSYD/TKRWUo0OR8YMXkl8YYmJgYm xsZmxsbmJuakCSuJ895RBVohkJ5YkpqdmlqQWgSzhYmDU6qBcQvf4dszu1rfp02Yw5j/Z9P+ aWkcaxfLXotqv5I77fNO8X6x9T+el5VOvHo+YtfU+/yq7wP0TrnPklpu1zc3X9uCl0/OWPvb U/+XwRcmycRfm9YpxXNO7PjyVrGMf/qhqz4uFPGZFfhs8SobMZf/gZJS5UGreNYFx8gdsV53 e8GuRXsn8jzQKFViKc5INNRiLipOBAD4g7MYjgIAAA== Archived-At: Cc: "dnssd-chairs@ietf.org" , Vividh Siddha , "dnssd@ietf.org" , Manju Shankar Rao , Marc Krochmal , Olivier Mardinian Subject: Re: [dnssd] dnssd WG meeting at IETF 94 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 02:33:37 -0000 On 19 Oct 2015, at 15:49, Ralph Droms (rdroms) wrote: > The dnssd WG is scheduled to meet in Yokohama 1520-1650 on Monday, = 2-11-2015. Meeting at the same time are: bfcpbis, netvc, cfrg, lime, = ccamp, rtgwg, rmcat. >=20 > Please get in touch with the chairs if you want a slot in the agenda. I submitted these updated Internet Drafts today: I expect we=E2=80=99ll want to discuss these at the DNSSD meeting in = Yokohama. I think dnssd-hybrid is pretty mature at this stage and ready for WGLC. I have made substantial additions to dnssd-push in response to WG = discussions, and I think that may be close to being ready. I think the = document may actually be ready for WGLC, but we still don=E2=80=99t have = a client implementation to validate the ideas in the document, and I=E2=80= =99m skeptical of any specification that=E2=80=99s not validated by = running code. We=E2=80=99re working on an implementation at Apple of = both client side and server side for dnssd-push, and hope to have it = done by the end of the year, so let=E2=80=99s plan on WGLC for = dnssd-push in January 2016. Stuart Cheshire From nobody Mon Oct 26 05:34:44 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E281B3CB3; Mon, 26 Oct 2015 05:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 y91dGS5veA2f; Mon, 26 Oct 2015 05:34:42 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2211B3CB7; Mon, 26 Oct 2015 05:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2685; q=dns/txt; s=iport; t=1445862881; x=1447072481; h=from:to:cc:subject:date:message-id:mime-version; bh=KZg/IwCL/JIzAizmfZxS7IlFWaOk25xke2TC8FI82gw=; b=BhVSYy4nMIIbrO6TeuD/PSPmL9hL7CyJ/bKHUdN5vgd0fzQdxQigyvyI BFpZIsr2CJsvnQONN5K4uq4Z2lQvh1jKxJUPCbf7V7Cm2c8yiMFW0DqLS 9Zbi+UCIViFOMuJXxwq83QahxDt4x+iLpTNHbKVFqFNi+lwD1H/qyC4vy U=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DBAgDVHC5W/4ENJK1egzZUdb47DoFaIYV8gTA4FAEBAQEBAQF/C4Q1BHkSAYEAJwQOE4giDcQ1AQEBAQEBAQEBAQEBAQEBAQEBAQEBDwUEhneCEId7gyGBFAWHPgSHBoduAXqBVoFhaogGnC4BHwFDhAOHBIEGAQEB X-IronPort-AV: E=Sophos;i="5.20,201,1444694400"; d="asc'?scan'208";a="41091090" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 26 Oct 2015 12:34:40 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t9QCYedU000745 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2015 12:34:40 GMT Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 26 Oct 2015 07:34:17 -0500 Received: from xch-aln-016.cisco.com ([173.36.7.26]) by XCH-ALN-016.cisco.com ([173.36.7.26]) with mapi id 15.00.1104.000; Mon, 26 Oct 2015 07:34:17 -0500 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: Agenda for dnssd WG meeting in Yokohama Thread-Index: AQHRD+qhQQw9PdHrpECRUpNueblzbQ== Date: Mon, 26 Oct 2015 12:34:17 +0000 Message-ID: <06FAAB6B-86A2-4EDB-B51F-EDD6171423A2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.40.213] Content-Type: multipart/signed; boundary="Apple-Mail=_17230174-8946-4514-A25E-2567D88C4E5A"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "dnssd-chairs@ietf.org" Subject: [dnssd] Agenda for dnssd WG meeting in Yokohama X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 12:34:44 -0000 --Apple-Mail=_17230174-8946-4514-A25E-2567D88C4E5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We've posted the draft agenda: = https://datatracker.ietf.org/meeting/94/agenda/dnssd dnssd WG Agenda - IETF 94 1520-1650JST 2015-11-02 (Last revised 2015-10-26 08:27 ET) ---------------------------------- Administrivia Chown/Droms 10 = minutes Introduction and NoteWell Agenda bashing; blue sheets; scribe; Jabber scribe DNS Long-Lived Queries Pusateri/Cheshire 20 = minutes draft-ietf-dnssd-push-02 Review of revisions; ready for WG last call? Scalable DNS-SD (SSD) Threats Otis/Rafiee 20 = minutes draft-otis-dnssd-scalable-dns-sd-threats-02 Review of updates Hybrid Unicast/Multicast DNS-Based SD Cheshire 20 = minutes draft-ietf-dnssd-hybrid-01 Review of revisions; ready for WG last call? Optimizing DNS-SD query using TXT records Thaler 20 = minutes draft-aggarwal-dnssd-optimize-query-00 Current state of AllSeen Alliance code and future work Note that draft-aggarwal-dnssd-optimize-query-00 has expired = ----------- 90 = minutes --Apple-Mail=_17230174-8946-4514-A25E-2567D88C4E5A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWLh3fAAoJEINeeBNmFjV5jx8P/3Rk3PlACy3HCNR1awKO+I5Z lxrps3oF7fmjcJK7SMmvPpQA4K752UK0cRRKVb/9IRjNTb5NUUZqqoYgye5jFw0q i06bjMiT3BqD02I185qQpQYcm4j/geP5QG0uXvgMR6k7rozMjWs2EWpXxqws3Pst +uy6UAqMCeo/Dg6NsQpD8/dTHUNFGruzat+w3/lTsDjIXni1q5rHJgFSiJpybeO/ UpBwimQ1N/3YU4wvliX5uC9W5U6UgLieYLzSfsYSx51fhpz0kECyVCENBkaEGI/I QqF9ITq+mOdqg76+2FB3Cw9SrWfKcZG3B0XPiYq9cWkOolomtqPMwgZ933xijF0E 0jkaOe9FwwKKNMURQ89h3WygSTIy75ecda6BcN/QQpenqLp36qvoUvJnJiqpvMUb g0z0i4Zdg4UK/We1Wzc7iC3NFfwxCtIpyd5G7qAO9bYL8cTeTAtIAOzh31M9hnIl yzPpfZnZyqoQxBczDsxybrjsEvKLRQ2iRj9dIYvhwVuEQZf03The2mKuMQqR4ay+ XQfZ49u2iJlv87odcVLeQR3BXEuJGs012/u0lOa3RdoVXdLnbJLBiOnzT7sEDz6V GJXTwn08PN4E8N7xxiTTavOkCCYdmwrEcHVwzrgbwU01Dhwx236NNM7UquDr1GvA fqKzpbTEhQM+HEsOhD50 =VXHC -----END PGP SIGNATURE----- --Apple-Mail=_17230174-8946-4514-A25E-2567D88C4E5A-- From nobody Tue Oct 27 10:57:07 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CDC1ACD87; Tue, 27 Oct 2015 10:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 gxmEMEKn8ik5; Tue, 27 Oct 2015 10:57:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A391ACD83; Tue, 27 Oct 2015 10:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3714; q=dns/txt; s=iport; t=1445968622; x=1447178222; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GsX/HDbB4nEI/MjIvaDf5KatWNEKluP8mxwXA+iVDYg=; b=bjNClHuKbUtb1YEMVaDWmvDYOW0PFHqKaokTDvTJSfiYHLxfPJDM09JZ 5MdIxKi+wo61AYh+79dzxL1l9BRW97u+IZ9ccC2agY4QND9qKEFZYIZlR 8AYtW5eVOuopZR5xheX+JKmTcPMpWj5+D7diNhxUF+k2kJQfTWJ6KT7Wu c=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DiAgC2ui9W/51dJa1egzZUbwa/AQ6BWiGFeQKBQTgUAQEBAQEBAX8LhDIBAQEDAXkFCwIBCBguMiUCBA4FDogaCA3FdAEBAQEBAQEBAQEBAQEBAQEBAQEBAQ8FBIZ3ghCCboUNB4MagRQFhz8EhwaHbwGCUIFhaogIgVmHY48Gg28BHwFDhARyhGiBBgEBAQ X-IronPort-AV: E=Sophos;i="5.20,206,1444694400"; d="asc'?scan'208";a="45053326" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 27 Oct 2015 17:56:32 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t9RHuWNt024582 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Oct 2015 17:56:32 GMT Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 27 Oct 2015 12:56:08 -0500 Received: from xch-aln-016.cisco.com ([173.36.7.26]) by XCH-ALN-016.cisco.com ([173.36.7.26]) with mapi id 15.00.1104.000; Tue, 27 Oct 2015 12:56:08 -0500 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: Agenda for dnssd WG meeting in Yokohama Thread-Index: AQHRD+qhOc8LEUiaeEqiEU3UdBHOIp5/9ZiA Date: Tue, 27 Oct 2015 17:56:08 +0000 Message-ID: References: <06FAAB6B-86A2-4EDB-B51F-EDD6171423A2@cisco.com> In-Reply-To: <06FAAB6B-86A2-4EDB-B51F-EDD6171423A2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.118.33] Content-Type: multipart/signed; boundary="Apple-Mail=_6461277B-081F-465F-9A83-CBE0D91E53C1"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "dnssd-chairs@ietf.org" Subject: Re: [dnssd] Agenda for dnssd WG meeting in Yokohama X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 17:57:05 -0000 --Apple-Mail=_6461277B-081F-465F-9A83-CBE0D91E53C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here are some more details about the agenda... We will discuss whether draft-ietf-dnssd-push-02 and = draft-ietf-dnssd-hybrid-01 are ready for WG last call. There will be a = short presentation about the changes in the most recent revision of each = draft, and the remainder of each slot will be available for discussion = of the drafts. *Read these drafts* prior to the meeting and be ready to = participate in the discussion. The contents of draft-rafiee-dnssd-mdns-threatmodel-03 and = draft-otis-dnssd-mdns-xlink-06 have been merged together into = draft-otis-dnssd-scalable-dns-sd-threats-02. The authors will review = the new draft and the WG will consider whether = draft-otis-dnssd-scalable-dns-sd-threats-02 is ready for WG adoption. = *Read this draft* prior to the meeting and be ready to express your = opinion about WG adoption. - Ralph > On Oct 26, 2015, at 8:34 AM 10/26/15, Ralph Droms (rdroms) = wrote: >=20 > We've posted the draft agenda: = https://datatracker.ietf.org/meeting/94/agenda/dnssd >=20 > dnssd WG Agenda - IETF 94 > 1520-1650JST 2015-11-02 > (Last revised 2015-10-26 08:27 ET) > ---------------------------------- >=20 > Administrivia Chown/Droms 10 = minutes > Introduction and NoteWell > Agenda bashing; blue sheets; scribe; Jabber scribe >=20 > DNS Long-Lived Queries Pusateri/Cheshire 20 = minutes > draft-ietf-dnssd-push-02 > Review of revisions; ready for WG last call? >=20 > Scalable DNS-SD (SSD) Threats Otis/Rafiee 20 = minutes > draft-otis-dnssd-scalable-dns-sd-threats-02 > Review of updates >=20 > Hybrid Unicast/Multicast DNS-Based SD Cheshire 20 = minutes > draft-ietf-dnssd-hybrid-01 > Review of revisions; ready for WG last call? >=20 > Optimizing DNS-SD query using TXT records Thaler 20 = minutes > draft-aggarwal-dnssd-optimize-query-00 > Current state of AllSeen Alliance code and future work > Note that draft-aggarwal-dnssd-optimize-query-00 has expired > = ----------- > 90 = minutes --Apple-Mail=_6461277B-081F-465F-9A83-CBE0D91E53C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWL7rOAAoJEINeeBNmFjV5pdUP+wTP0HIcFjd/0AMb3JqgiYms 9q+VybiTcAYPNFDIYOhPMH8gdtBx9ORLSD5PSOl8cpMlJKhvPp0aqdbiCI+exZTk fMLRbSj7u97WPhVmAOnPIB8T1YAwerjOv+k4DN0AjihCpHtmXUslTI890YDNPdwu PLBJUCm6alC02Ng1U6lqC23Y52u8wzqBgbSbToB7zC3PZqZ9Ypp+n7y3yEiWFdsT YJFbD63VQ2tBAiF+ZbmIOG4K0wkLffwZLmhnMQqO9zuyRJSq2KICRJeR0tuuR7pF ET40YBJafe4TT7hqFduW3+uugq723rhcZaYWaw557GCgAz3ZmMWiLYafQ735o0Om rsOe4EPq4VtzqAJXqaMKWWxlXeIaAqEMGrAiQC9Hc3Fxo1wS4LKZbAUl4RBG9AFk MYNbQtqI2Gg7AmrY2WddoXpnY/DKPdrAw3AzMaI9qTYToOTzzhW/L17n8pp5oKDd 6H+vTqwimQcWLqL/T4GRsr03NMouVMaQOk8kvGsXGF1a4oVKw9YAlNPZSYhf9fM/ Tu4OtO7MuJWhdyhPayqdejkke5g3ryvRsT6Wvor5XJWGD8krC5FF6dHE95hz9fZ3 avV319pTNidhwaM+O6idytahXUn7QsyV+WwxDELhTUDEuF14K2m7Um87SIwCvCqQ pjLt4LHPKx7i+WpY2hM5 =gC6a -----END PGP SIGNATURE----- --Apple-Mail=_6461277B-081F-465F-9A83-CBE0D91E53C1-- From nobody Tue Oct 27 12:12:35 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57661ACE59; Tue, 27 Oct 2015 12:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 aBo3k92Fb1gT; Tue, 27 Oct 2015 12:12:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B501ACE4B; Tue, 27 Oct 2015 12:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2699; q=dns/txt; s=iport; t=1445973152; x=1447182752; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cPS6AqKhfpUev2SFnscRNueIVEDdSUSOz8a7RuCaqMk=; b=MQ5isMNu7GWUTKUQ994YNqHzzv0gpIPqp1m9FTvxjddLGUhbR/qdOu3a 2kNV8eZ7N3y8Sm8BzPskzJdtG7gMw6q0XsKwTnFlJzRDN797kNJbGEyIq EjMNUrIQSw5pXEnHJPRWj5A6Bqq2KnzCk1H7qM/FbMGaX3zs9HeBWxhF9 g=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DhAgARzC9W/40NJK1egzaBSb8DDoFag0OCVwKBQzgUAQEBAQEBAX8LhDMBAQR5EAIBCEYyJQIEDhOIIsYCAQEBAQEBAQEBAQEBAQEBAQEBAQEBDwmGd4IQgm6FDQeDGoEUAQSHPwSHBodvAYJQgWGIcpwxAR8BQ4QEhVqBBgEBAQ X-IronPort-AV: E=Sophos;i="5.20,206,1444694400"; d="asc'?scan'208";a="39456186" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 27 Oct 2015 19:12:31 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9RJCVTD003150 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Oct 2015 19:12:31 GMT Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 27 Oct 2015 14:12:07 -0500 Received: from xch-aln-016.cisco.com ([173.36.7.26]) by XCH-ALN-016.cisco.com ([173.36.7.26]) with mapi id 15.00.1104.000; Tue, 27 Oct 2015 14:12:06 -0500 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: Agenda for dnssd WG meeting in Yokohama Thread-Index: AQHRD+qhOc8LEUiaeEqiEU3UdBHOIp6ACtSA Date: Tue, 27 Oct 2015 19:12:06 +0000 Message-ID: <7244A568-2790-43F8-910E-FD9F8830592A@cisco.com> References: <06FAAB6B-86A2-4EDB-B51F-EDD6171423A2@cisco.com> In-Reply-To: <06FAAB6B-86A2-4EDB-B51F-EDD6171423A2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.118.66] Content-Type: multipart/signed; boundary="Apple-Mail=_65F02E25-D8FD-433C-8F9D-EEC66E2ABFE0"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "dnssd-chairs@ietf.org" Subject: Re: [dnssd] Agenda for dnssd WG meeting in Yokohama X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 19:12:34 -0000 --Apple-Mail=_65F02E25-D8FD-433C-8F9D-EEC66E2ABFE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Turns out I included the wrong title for draft-ietf-dnssd-push-02. = Here's the corrected agenda: dnssd WG Agenda - IETF 94 1520-1650JST 2015-11-02 (Last revised 2015-10-27 13:58 ET) ---------------------------------- Administrivia Chown/Droms 10 = minutes Introduction and NoteWell Agenda bashing; blue sheets; scribe; Jabber scribe DNS Push Notifications Pusateri/Cheshire 20 = minutes draft-ietf-dnssd-push-02> Review of revisions; ready for WG last call? Scalable DNS-SD (SSD) Threats Otis/Rafiee 20 = minutes draft-otis-dnssd-scalable-dns-sd-threats-02 Review of updates Hybrid Unicast/Multicast DNS-Based SD Cheshire 20 = minutes draft-ietf-dnssd-hybrid-01 Review of revisions; ready for WG last call? Optimizing DNS-SD query using TXT records Thaler 20 = minutes draft-aggarwal-dnssd-optimize-query-00 Current state of AllSeen Alliance code and future work Note that draft-aggarwal-dnssd-optimize-query-00 has expired = ----------- 90 = minutes --Apple-Mail=_65F02E25-D8FD-433C-8F9D-EEC66E2ABFE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWL8yeAAoJEINeeBNmFjV55jsP/iNs7QbSjCUUD0WoUc0PHnMz T4FsSKqWlzDTes8K2O0L95khl5cIOFEARjlpEv9DDqx8GvFX27CQZdYPwRWck0Ug vH/X0wGXnopkAu6V8zgHmO58OXAIw1QlbYGuzYDEgQ2abINjI/W5DfaSxyHdskP/ 0CMP1h3B4jNRTW0PjO6fvzoehPjlNI123VDA5LfFnZaaFlGwiOZDZT5NC4fMB49K wcb4Z/hcnx6OaUKasxmCBMqbuYPPG8KUPOzlar9OC9ZRdg0C4zi+/LPfjYJDSpaq PBfNjnTMKFxJKa5WdytGLMgzZZhEtYRcXPij9qzJRCePa7NI3dGKxvjvoBh7/F9k OPRINfYfNv4ROBxDzdMIPjzgOB0FpSDo5uXKrRMrw11sJE73dFxLe8pdsL1Jdlf0 uOTR1zl66O+a+6pmhHDrY4L/QxhOshl2qLXhRV9hrhE0xVk3Ia6qGtAN+IX2zLsi yV7L/vb3DUyvpiFfznCfOfvW3oqPyUrYMBbQKcDc+jo3bQ8JtLKkCoCkIqnk/4K0 AKBWf6aF4piJ2c8pqCs2JDxUQW6xYwdt6hwv/M4PsZM5q95XubCwV9XR0dE/P85v 1N/OqM85y9cVw7cUaWB2gp/BvTYRjoEioq4BvomVSO0/C25JbKkhrWelpbtWfCWS XgHGZKrnQ8sgwHXpKZMa =HeN/ -----END PGP SIGNATURE----- --Apple-Mail=_65F02E25-D8FD-433C-8F9D-EEC66E2ABFE0-- From nobody Fri Oct 30 03:14:44 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CD01B2AC1 for ; Fri, 30 Oct 2015 03:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 CvV0NUblAqvb for ; Fri, 30 Oct 2015 03:14:42 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE8F1B2AC0 for ; Fri, 30 Oct 2015 03:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1088; q=dns/txt; s=iport; t=1446200081; x=1447409681; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=37S/+uSw6eLSaS24eiV2UWthGSvi4EPiOXaKAAS4NNE=; b=EID4V8IaxU0n+a0vRGxGG9lkj7xqe/yc0O0jHHidUKYbzu+N3Bab2PJk +Ghi9UNe7/mAn+M3WxBGjedcehf+F+ZS86ynyXU+JT8K196LUQBvuKD70 KOD+wgeorqbaMaRkZLj+pX8erZVPcRR+ZlxnMkhrxRwCD1P97auvHOt45 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APAgC1QjNW/4wNJK1egztTbwa/KgENgVoXCoV4AoE1OBQBAQEBAQEBgQqENQEBAQMBAQEBNzQLBQsCAQgOCh4QIQYLJQIEAQ0FiBsDCggNv2wNhEUBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZ3ghCCboJTggmDUIEUAQSWQwGLLoF2gVmEP45Rg1+DcQEfAQFCghEdgVZyhHeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,217,1444694400"; d="scan'208";a="202861822" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Oct 2015 10:14:41 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t9UAEe75027745 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Oct 2015 10:14:40 GMT Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 30 Oct 2015 05:14:14 -0500 Received: from xch-aln-016.cisco.com ([173.36.7.26]) by XCH-ALN-016.cisco.com ([173.36.7.26]) with mapi id 15.00.1104.000; Fri, 30 Oct 2015 05:14:14 -0500 From: "Ralph Droms (rdroms)" To: Tim Wicinski , "dnssd@ietf.org" Thread-Topic: [dnssd] dnssd WG meeting at IETF 94 Thread-Index: AQHRCsBn9FLj8k7Y/EG7YMLTkfiFqZ5z1NMAgA9rRQA= Date: Fri, 30 Oct 2015 10:14:14 +0000 Message-ID: References: <9440F960-C332-43D8-930B-66345A158104@cisco.com> <562585AA.4090900@gmail.com> In-Reply-To: <562585AA.4090900@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.208.197] Content-Type: text/plain; charset="us-ascii" Content-ID: <93FF89DE04B51947A7E238EEEE8E93D6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [dnssd] dnssd WG meeting at IETF 94 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 10:14:43 -0000 Thanks, Tim, for volunteering to take notes; your notes from the last metin= g were great. We're still looking for a jabber scribe. And, Tim won't be in Yokohama, so I'm looking for someone who can help me r= un the meeting by managing slides, etc. - Ralph > On Oct 19, 2015, at 8:07 PM 10/19/15, Tim Wicinski w= rote: >=20 >=20 > I did notes last time, and if you were satisfied I can do them again. >=20 > tim >=20 > On 10/19/15 11:49 PM, Ralph Droms (rdroms) wrote: >> The dnssd WG is scheduled to meet in Yokohama 1520-1650 on Monday, 2-11-= 2015. Meeting at the same time are: bfcpbis, netvc, cfrg, lime, ccamp, rtg= wg, rmcat. >>=20 >> Please get in touch with the chairs if you want a slot in the agenda. >>=20 >> We're looking for volunteers to take notes (is "etherpad" a verb yet?) a= nd act as jabber scribe during the meeting. >>=20 >> - Ralph >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >>=20 From nobody Sat Oct 31 06:39:45 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB3F1B2D4B for ; Sat, 31 Oct 2015 06:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_14=0.6] autolearn=ham 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 YDRTBfRhF6IZ for ; Sat, 31 Oct 2015 06:39:39 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 28A831B2C5E for ; Sat, 31 Oct 2015 06:39:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id C3B1A10744 for ; Sat, 31 Oct 2015 13:39:38 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr9GoMcPijh3 for ; Sat, 31 Oct 2015 13:39:37 +0000 (UTC) Received: from mx2.yitter.info (t20010c400000308000899124e9c3a6cb.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3080:89:9124:e9c3:a6cb]) by mx2.yitter.info (Postfix) with ESMTPSA id 5C07D10743 for ; Sat, 31 Oct 2015 13:39:36 +0000 (UTC) Date: Sat, 31 Oct 2015 09:39:38 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20151031133936.GA9576@mx2.yitter.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [dnssd] Apologies & planned upload when queue opens X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 13:39:44 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, After Prague I updated draft-ietf-dnssd-mdns-dns-interop but apparently forgot to upload it, which I didn't realise until Ralph poked me about it tonight. A thousand apologies. I just now fixed the references again (to bring the reference up to date) and plan to upload the attached as soon as the queue opens again. I think I addressed the issues raised in Prague in a way that allows this to go ahead without parking for ages to wait for implementations. Here's the change list: o Altered the title to make it more generic than mDNS. o Addressed issues raised by Dave Thaler in review on 2015-07-18. o Added a note to Section 7 about visual confusion. I don't know whether this will satisfy Doug Otis but it is the only thing I can see that could possibly be relevant. o Added discussion of finding "boundary" in Section 4.3. The last bullet is the attempt to deal with the issues that came up in the meeting in Prague. If someone has something they really want to be differennt in here before I upload, please send me a note. Otherwise, on the assumption that integers are free and I'll probably forget again if I don't do it quickly, I'll send this in on Monday. A -- Andrew Sullivan ajs@anvilwalrusden.com --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-dnssd-mdns-dns-interop-02.txt" DNSSD A. Sullivan Internet-Draft Dyn Intended status: Informational October 31, 2015 Expires: May 3, 2016 On Interoperation of Labels Between DNS and Other Resolution Systems draft-ietf-dnssd-mdns-dns-interop-02 Abstract Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Moreover, when it uses the DNS, DNS-Based Service Discovery uses the full capability of DNS, rather than using a subset of available octets. In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Sullivan Expires May 3, 2016 [Page 1] Internet-Draft Multi-resolution Interop October 2015 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and terms used in this document . . . . . . . 3 2. Why there could be a problem at all . . . . . . . . . . . . . 4 3. Requirements for a profile for label interoperation . . . . . 5 4. DNS-SD portions . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. The Portion of the Service Instance Name . . . . . . . . . . . . . . . . . . . . . . 6 4.2. The Portion of the Service Instance Name . . . . . . . . . . . . . . . . . . . . . . 7 4.3. The Portion of the Service Instance Name . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Informative References . . . . . . . . . . . . . . . . . . . 9 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10 A.1. draft-ietf-dnssd-mdns-dns-interop-02 . . . . . . . . . . 10 A.2. draft-ietf-dnssd-mdns-dns-interop-01 . . . . . . . . . . 11 A.3. draft-ietf-dnssd-mdns-dns-interop-00 . . . . . . . . . . 11 A.4. draft-sullivan-dnssd-mdns-dns-interop-01 . . . . . . . . 11 A.5. draft-sullivan-dnssd-mdns-dns-interop-00 . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction DNS-Based Service Discovery (DNS-SD, [RFC6763]) specifies a mechanism for discovering services using queries to the Domain Name System (DNS, [RFC1034], [RFC1035]); and to any other system that uses domain names, such as Multicast DNS (mDNS, [RFC6762]). Conventional use of the DNS generally follows the host name rules [RFC0952] for labels -- the so-called LDH rule. That convention is the reason behind the development of Internationalized Domain Names for Applications (IDNA2008, [RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894], [RFC5895]). It is worth noting that the LDH rule is a convention, and not a rule of the DNS; this is made entirely plain by [RFC2181], section 11. Nevertheless, there is a widespread belief that in many circumstances domain names cannot be used in the DNS unless they cleave to the LDH rule. Sullivan Expires May 3, 2016 [Page 2] Internet-Draft Multi-resolution Interop October 2015 At the same time, mDNS requires that labels be encoded in UTF-8, and permits a range of characters in labels that are not permitted by IDNA2008 or the LDH rule. For example, mDNS encourages the use of spaces and punctuation in mDNS names (see [RFC6763], section 4.1.3). It does not restrict which Unicode code points may be used in those labels, so long as the code points are UTF-8 in Net-Unicode [RFC5198] format. Users of applications are, of course, frequently unconcerned with (not to say oblivious to) the name-resolution system(s) in service at any given moment, and are inclined simply to use the same domain names in different contexts. As a result, the same domain name might be tried using different name resolution technologies. If DNS-SD is to be used in an environment where multiple resolution systems (such as mDNS and DNS) are to be queried for services, then some parts of the domain names to be queried will need to be compatible with the rules and conventions for all the relevant technologies. One approach to interoperability under these circumstances is to use a single operational convention (a "profile") for domain names under the different naming systems. This memo assumes such a use profile, and attempts to outline what is necessary to make it work without specifying any particular technology. It does assume, however, that the global DNS is eventually likely to be implicated. Given the general tendency of all resolution eventually to fall through to the DNS, that assumption does not seem controversial. It is worth noting that users of DNS-SD do not use the service discovery names in the same way that users of other domain names might. Domain names often might as easily be entered as direct user input as by any other method. But the service discovery context generally assumes users are picking a service from a list. As a result, the sorts of application considerations that are appropriate to the general-purpose DNS name, and that resulted in the A-label/ U-label split (see below) in IDNA2008, are not entirely the right approach for DNS-SD. 1.1. Conventions and terms used in this document Wherever appropriate, this memo uses the terminology defined in Section 2 of [RFC5890]. In particular, the reader is assumed to be familiar with the terms "U-label", "LDH label", and "A-label" from that document. Similarly, the reader is assumed to be familiar with the U+NNNN notation for Unicode code points used in [RFC5890] and other documents dealing with Unicode code points. In the interests of brevity and consistency, the definitions are not repeated here. Sullivan Expires May 3, 2016 [Page 3] Internet-Draft Multi-resolution Interop October 2015 Sometimes this memo refers to names in the DNS as though the LDH rule and IDNA2008 are strict requirements. They are not. DNS labels are, in principle, just collections of octets, and therefore in principle the LDH rule is not a constraint. In practice, applications sometimes intercept labels that do not conform to the LDH rule and apply IDNA and other transformations. The DNS, perhaps unfortunately, has produced its own jargon. Unfamiliar DNS-related terms in this memo should be found in [I-D.ietf-dnsop-dns-terminology]. The term "owner name" (common to the DNS vernacular; see above) is used here to apply not just to the domain names to be looked up in the DNS, but to any name that might be looked up either in the DNS or using other technologies. It therefore includes names that might not actually exist anywhere. In addition, what follows depends on the idea that not every domain name may be looked up in the DNS. For instance, names ending in "local." (in the presentation format) are not ordinarily looked up in the DNS, but instead by querying mDNS. DNS-SD specifies three portions of the owner name for a DNS-SD resource record. These are the portion, the portion, and the . The owner name made of these three parts is called the Service Instance Name. It is worth observing that a portion may be more than one label long. See [RFC6763], section 4.1. Further discussion of the parts is found in Section 4. Throughout this memo, mDNS is used liberally as the alternative resolution mechanism to DNS. This is for convenience rather than rigour: any alternative name resolution to DNS could present the same friction with the prevailing operational conventions of the global DNS. It so happens that mDNS is the overwhelmingly successful alternative as of this writing, so it is used in order to make the issues plainer to the reader. Other alternative resolution mechanisms may in general be read wherever mDNS appears in the text, except where details of the mDNS specification appear. 2. Why there could be a problem at all One might reasonably wonder why there is a problem to be solved at all. After all, DNS labels permit any octet whatsoever, and anything that can be useful with DNS-SD cannot use any names that are outside the protocol strictures of the DNS. The reason for the trouble is twofold. First, and least troublesome, is the possibility of resolvers that are attempting to offer IDNA service system-wide. Given the design of IDNA2008, it is reasonable to suppose that on some systems high-level name resolution libraries Sullivan Expires May 3, 2016 [Page 4] Internet-Draft Multi-resolution Interop October 2015 will perform the U-label/A-label transformation automatically, saving applications from these details. If this were the main problem, however, it would presumably be self-correcting; for the right answer would be, "Don't use those libraries for DNS-SD," and DNS-SD would not work reliably in cases where such libraries were in use. This would be unfortunate; but given that DNS-SD in Internet contexts is as of this writing not in ubiquitous use, it should not represent a fatal issue. The greater problem is that the "infrastructure" types of DNS service -- the root zone, the top-level domains, and so on -- have embraced IDNA and refuse registration of raw UTF-8 into their zones. As of this writing there is (perhaps unfortunately) no reliable way to discover where these sorts of DNS services end. Nevertheless, some client programs (notably web browsers) have adopted a number of different policies about how domain names will be looked up and presented to users given the policies of the relevant DNS zone operators. None of these policies permit raw UTF-8. Since it is anticipated that DNS-SD when used with the DNS will be inside domain names beneath those kinds of "infrastructure" domains, the implications of IDNA2008 must be a consideration. For further exploration of issues relating to encoding of domain names generally, the reader should consult [RFC6055]. 3. Requirements for a profile for label interoperation Any interoperability between DNS (including prevailing operational conventions) and other resolution technologies will require interoperability across the portions of a DNS-SD Service Instance Name that are implicated in regular DNS lookups. Only some portions are implicated. In any case, if a given portion is implicated, the profile will need to apply to all labels in that portion. In addition, because DNS-SD Service Instance Names can be used in a domain name slot, care must be taken by DNS-SD-aware resolvers to handle the different portions as outlined here, so that DNS-SD portions that do not use IDNA2008 will not be treated as U-labels and will not accidentally undergo IDNA processing. Because the profile will need to apply to names that might need to interoperate with names in the public DNS, and because other resolution mechanisms (such as mDNS) could permit labels that IDNA does not, the profile might reduce the labels that could be used with those other resolution mechanisms. One consequence of this is that some recommendations from [RFC6763] will not really be possible to implement using names subject to the profile. In particular, [RFC6763], section 4.1.3 recommends that labels always be stored and Sullivan Expires May 3, 2016 [Page 5] Internet-Draft Multi-resolution Interop October 2015 communicated as UTF-8, even in the DNS. Because of the way the public DNS is currently operated (see Section 2), the advice to store and transmit labels as UTF-8 in the DNS is likely either to encounter problems or result in unnecessary traffic to the public DNS (or both). In particular, many labels in the part of a Service Instance Name is unlikely to be found in its UTF-8 form in the public DNS tree for zones that are using IDNA2008. By contrast, for example, mDNS normally uses UTF-8. U-labels cannot contain upper case letters. That restriction extends to ASCII-range upper case letters that work fine in LDH-labels. It may be confusing that the character "A" works in the DNS when none of the characters in the label has a diacritic, but does not work when there is such a diacritic in the label. Labels in mDNS names (or other resolution technologies) may contain upper case characters, so the profile will need either to restrict the use of upper case or come up with a reliable and predictable (to users) convention for case folding even in the presence of diacritics. 4. DNS-SD portions Service Instance Names are made up of three portions. 4.1. The Portion of the Service Instance Name [RFC6763] is clear that the portion of the Service Instance Name is intended for presentation to users, and therefore virtually any character is permitted in it. There are two ways that a profile might address this portion. The first way would be to treat this portion as likely to be intercepted by system-wide IDNA-aware resolvers, or likely subject to strict IDNA conformance requirements for publication in the relevant zone. In this case, the portion would need to be made subject to the profile, thereby curtailing what characters may appear in this portion. This approach permits DNS-SD to use any standard system resolver but presents inconsistencies with the DNS-SD specification and with DNS-SD that is exclusively mDNS-based. Therefore, this strategy is rejected. Instead, DNS-SD implementations can intercept the portion of a Service Instance Name and ensure that those labels are never handed to IDNA-aware resolvers that might attempt to convert these labels into A-labels. Under this approach, the DNS-SD portion works as it always does, but at the cost of using special resolution code built into the DNS-SD system. A practical consequence of this is that zone operators need to be prepared not to apply the LDH rule to all labels, and may need to make special Sullivan Expires May 3, 2016 [Page 6] Internet-Draft Multi-resolution Interop October 2015 concessions to ensure that the portion can contain spaces, upper and lower case, and any UTF-8 code point; or else to prepare a user interface to handle the exceptions that would otherwise be generated. Automatic conversion to A-labels is not acceptable. 4.2. The Portion of the Service Instance Name DNS-SD includes a component in the Service Instance Name. This component is not really user-facing data, but is instead control data embedded in the Service Instance Name. This component includes so-called "underscore labels", which are labels prepended with U+005F (_). The underscore label convention was established by DNS SRV ([RFC2782]) for identifying metadata inside DNS names. A system-wide resolver (or DNS middlebox) that cannot handle underscore labels will not work with DNS-SD at all, so it is safe to suppose that such resolvers will not attempt to do special processing on these labels. Therefore, the portion of the Service Instance Name will not be subject to the profile. By the same token, it should be noted that underscore labels are never subject to IDNA processing (they're formally incompatible), and therefore concerns about IDNA are irrelevant for these labels. 4.3. The Portion of the Service Instance Name The portion of the Service Instance Name forms an integral part of the owner name submitted for DNS resolution. A system-wide resolver that is IDNA2008-aware is likely to interpret labels with UTF-8 in the owner name as candidates for IDNA2008 processing. More important, operators of internationalized domain names will frequently publish such names in the DNS as A-labels; certainly, the top-most labels will always be A-labels. Therefore, these labels will need to be subject to the profile. DNS-SD implementations ought to identify the portion of the Service Instance Name and treat it subject to IDNA2008 in case the domain is to be queried from the global DNS. In the event that the portion of the Service Instance Name fails to resolve, it is acceptable to substitute labels with plain UTF-8, starting at the lowest label in the DNS tree and working toward the root. This approach differs from the rule for resolution published in [RFC6763], because it privileges IDNA2008-compatible labels over UTF-8 labels. One might argue against this restriction on either of two grounds: 1. It is possible the names may be in the DNS in UTF-8, and RFC 6763 already specifies a fallback strategy of progressively attempting first the UTF-8 label lookup (it might not be a U-label) and then if possible the A-label lookup. Sullivan Expires May 3, 2016 [Page 7] Internet-Draft Multi-resolution Interop October 2015 2. Zone administrators that wish to support DNS-SD can publish a UTF-8 version of the zone along side the A-label version of the zone. The first of these is rejected because it represents a potentially significant increase in DNS lookup traffic for no value. It is possible for a DNS-SD application to identify the portion of the Service Instance Name. The standard way to publish IDNs on the Internet uses IDNA. Therefore, additional lookups should not be encouraged. When [RFC6763] was published, the bulk of IDNs were lower in the tree. Now that there are internationalized labels in the root zone, it is desirable to minimize queries to the Internet infrastructure if they are sure to be answered in the negative. The second reason depends on the idea that it is possible to maintain two names in sync with one another. This is not strictly speaking true, although in this case the domain operator could simply create a DNAME record [RFC6672] from the UTF-8 name to the IDNA2008 zone. This still, however, relies on being able to reach the (UTF-8) name in question, and it is unlikely that the UTF-8 version of the zone will be delegated from anywhere. Moreover, in many organizations the support for DNS-SD and the support for domain name delegations are not performed by the same department, and depending on a co- ordination between the two will make the system more fragile, or slower, or both. Some resolvers -- particularly those that are used in mixed DNS and non-DNS environments -- may be aware of different operational conventions in different parts of the DNS tree. For example, it may be possible for implementations to use hints about the boundary of an organization's domain name infrastructure, in order to tell (for instance) that example.com. is part of the Example Organization while com. is a large delegation-centric zone on the public Internet. In such cases, the resolution system might reverse its preferences to prefer plain UTF-8 labels when resolving names below the boundary point in the DNS tree. The result would be that any lookup past the boundary point and closer to the root would use LDH-labels first, falling back to UTF-8 only after a failure; but a lookup below the boundary point would use UTF-8 labels first, and try other strategies only in case of negative answers. The mechanism to learn such a boundary is beyond the scope of this document. 5. Acknowledgements The author gratefully acknowledges the insights of Joe Abley, Stuart Cheshire, Paul Hoffman, Kerry Lynn, and Dave Thaler. Kerry Lynn deserves special gratitude for his energy and persistence in pressing Sullivan Expires May 3, 2016 [Page 8] Internet-Draft Multi-resolution Interop October 2015 unanswered questions. Doug Otis sent many comments about visual confusability. 6. IANA Considerations This memo makes no requests of IANA. 7. Security Considerations This memo presents some requirements for future development, but does not specify anything. It makes no additional security-specific requirements. Issues arising due to visual confusability of names apply to this case as well as to any other case of internationalized names, but interoperation between different resolution systems and conventions does not alter the severity of those issues. 8. Informative References [I-D.ietf-dnsop-dns-terminology] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", draft-ietf-dnsop-dns-terminology-05 (work in progress), September 2015. [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. Sullivan Expires May 3, 2016 [Page 9] Internet-Draft Multi-resolution Interop October 2015 [RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010. [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010. [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010. [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, September 2010. [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011. [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June 2012. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. Appendix A. Change History Note to RFC Editor: this section should be removed prior to publication. A.1. draft-ietf-dnssd-mdns-dns-interop-02 o Altered the title to make it more generic than mDNS. o Addressed issues raised by Dave Thaler in review on 2015-07-18. o Added a note to Section 7 about visual confusion. I don't know whether this will satisfy Doug Otis but it is the only thing I can see that could possibly be relevant. o Added discussion of finding "boundary" in Section 4.3. Sullivan Expires May 3, 2016 [Page 10] Internet-Draft Multi-resolution Interop October 2015 A.2. draft-ietf-dnssd-mdns-dns-interop-01 Alter text to make clear that the main issue is the way the public DNS is currently administered, not system resolvers. I suppose this should have been clear before, but I didn't do that. Many thanks to Kerry Lynn for penetrating questions that illuminated what I'd left out. A.3. draft-ietf-dnssd-mdns-dns-interop-00 1st WG version Add text to make clear that fallback from A-label lookup to UTF-8 label lookup ok, per WG comments at IETF 91 A.4. draft-sullivan-dnssd-mdns-dns-interop-01 o Decided which portions would be affected o Explained the difference in user interfaces between DNS-SD and usual DNS operation o Provided background on why the Domain portion should be treated differently A.5. draft-sullivan-dnssd-mdns-dns-interop-00 Initial version. Author's Address Andrew Sullivan Dyn 150 Dow St. Manchester, NH 03101 U.S.A. Email: asullivan@dyn.com Sullivan Expires May 3, 2016 [Page 11] --YZ5djTAD1cGYuMQK--