From nobody Fri Mar 3 16:00:43 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 71077129A28; Fri, 3 Mar 2017 15:55:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533345.15846.10881168215404998032.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:33 -0800 Archived-At: Cc: dnssd@ietf.org, terry.manderson@icann.org Subject: [dnssd] dnssd - Requested session has been scheduled for IETF 98 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 03 Mar 2017 23:55:34 -0000 Dear Tim Chown, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnssd Session 1 (1:30:00) Tuesday, Afternoon Session III 1640-1840 Room Name: Zurich B size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Tim Chown Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: dane intarea 6lo dbound dprive homenet dnsop 6man saag Second Priority: dhc People who must be present: Ralph Droms Tim Chown Terry Manderson Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Tue Mar 7 14:49:11 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 2B7D11294A2; Tue, 7 Mar 2017 14:49:09 -0800 (PST) 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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148892694914.17539.8180937245567385581@ietfa.amsl.com> Date: Tue, 07 Mar 2017 14:49:09 -0800 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-pairing-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 07 Mar 2017 22:49:09 -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 of the IETF. Title : Device Pairing Using Short Authentication Strings Authors : Christian Huitema Daniel Kaiser Filename : draft-ietf-dnssd-pairing-01.txt Pages : 22 Date : 2017-03-07 Abstract: This document proposes a device pairing mechanism that establishes a relationship between two devices by agreeing on a secret and manually verifying the secret's authenticity using an SAS (short authentication string). Pairing has to be performed only once per pair of devices, as for a re-discovery at any later point in time, the exchanged secret can be used for mutual authentication. The proposed pairing method is suited for each application area where human operated devices need to establish a relation that allows configurationless and privacy preserving re-discovery at any later point in time. Since privacy preserving applications are the main suitors, we especially care about privacy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-pairing-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-pairing-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 Wed Mar 8 03:54:51 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 01F0A129587 for ; Wed, 8 Mar 2017 03:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=jisc.ac.uk header.b=dJX/j7yS; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com header.b=eGImcmFj 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 cd6hwVIJ37mc for ; Wed, 8 Mar 2017 03:54:46 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F14129579 for ; Wed, 8 Mar 2017 03:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1488974084; bh=2umHrW0qo/b3l2FzVefe+kXXHOrtoIcxnxFPet4Td2I=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=dJX/j7ySt1FBEp6ZDo6BaJCWjgVoA8T8XQLS/H/KLWQkahqhO8eIChhte6QOcMMaKlUeYo+nbIMvLH8fSgoWTBUxIQUlCylJA8Y2F0rNhXa+coWrZrpR6c2AaZFByG84BeRFF4bIIrMDDPnU+/rLpfoB3AXbhp2kz6iChBUJ8+o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=++4N8no10js4Pjv4J4RlFOKzdVaJ9fnmXFrTDPM1Ehs=; b=eGImcmFjgcwU5dQlEWMUOBkLZpm3BIGYNISlKg8SgdCqk/KnhARXmn2W8KUh4vLPqtNBaxRqv9RAhoFnWwcQTy8/FN4UKYHnf7A5yuAn46FKFy1Mmy4Mtn9Laq5pwE1/n/e7L1QMsmD/i7h0m5PlUrxGZnJhM7tpNhx9mtL5kZI= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0151.outbound.protection.outlook.com [213.199.180.151]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-82-gysO0V-0OlGy1Fj2w6EQOQ-1; Wed, 08 Mar 2017 11:54:38 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Wed, 8 Mar 2017 11:54:38 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0961.014; Wed, 8 Mar 2017 11:54:37 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: DNS-SD session at IETF98, Chicago Thread-Index: AQHSmALCpMy75OTb10uii1NQgqhjaw== Date: Wed, 8 Mar 2017 11:54:37 +0000 Message-ID: <0609A0EA-0C93-419C-ADF4-5C76200B6689@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: d43d1a8d-6af4-4f16-44b7-08d46619e5ac x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1137; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:HO0rB+HwkRtKVI4fZsXc3rJG8/tVRHWNaA66TKK2pYfMXuc3fsDMF+WJ7dWTBtkC+gi4X5PVJ85a23HIC+dl/C00prRhVj281OTxDaX2nndZMjoFFYSR2CZxw2h/mLbTg1fhQ8XAmFbDPD5CaQkSmActwTf4r5TlGwGshs5gZBlmw/HfmJ5AtgYDFe2HeDd/xsndbIxyuHr7KVmjusvTMmXYA2cfhSnm/oTfzbCQuqfU8iffzNLgpXuEUVUC82vEIDHQW0yaEa6T+hR0NdOM/+P1q8Mc0BxWjunAh2xvy+P6rH+sA6NMAeZTwpa1bk4KSBIBmUCZBa2IhYSVkpJVGQ==; 20:pI36fQBzwgoDalG6/y3SkNPo/9hC9tUzFgoiD+0iX+bKewVw8KEutsiL1P5UIF+3xhF3R2y2WpDJo+ySF0zWcrZ5BusStqDU6zUvLNtFB8LPcVqo5C4QNtl015eGtaBgeqZWpqoM11Q4VDlzZnTid2P4+/PllaozpWi0A12scV8= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(189998001)(5660300001)(6506006)(7736002)(606005)(6916009)(102836003)(38730400002)(74482002)(54896002)(99286003)(8936002)(50986999)(6116002)(6306002)(81166006)(50226002)(3846002)(6486002)(5640700003)(86362001)(8676002)(236005)(6512007)(1730700003)(106116001)(2351001)(7906003)(6436002)(110136004)(33656002)(66066001)(82746002)(53936002)(83716003)(3280700002)(36756003)(2900100001)(3660700001)(5250100002)(2906002)(2501003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 11:54:37.8476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: gysO0V-0OlGy1Fj2w6EQOQ-1 Content-Type: multipart/alternative; boundary="_000_0609A0EA0C93419CADF45C76200B6689jiscacuk_" Archived-At: Subject: [dnssd] DNS-SD session at IETF98, Chicago X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 11:54:50 -0000 --_000_0609A0EA0C93419CADF45C76200B6689jiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi, As you may have seen, the IETF 98 final agenda has now been published. See= https://datatracker.ietf.org/meeting/98/agenda.html. Our session is at 16:40 local time (21:40 UTC) on Tuesday March 28th in Zur= ich B. If you have material you would like to present, please let me know off-list= , so we can build the meeting agenda. We will request MeetEcho presence in the room. Best wishes, Tim --_000_0609A0EA0C93419CADF45C76200B6689jiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: <2736270FD1557245B4ED15E2929D4BD5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi,

As you may have seen, the IETF 98 final agenda has now been= published.  See https://datatracker.ietf.org/meeting/98/agenda.h= tml.

Our session is at 16:40 local time (21:40 UTC) on Tuesday M= arch 28th in Zurich B.

If you have material you would like to present, please let = me know off-list, so we can build the meeting agenda.

We will request MeetEcho presence in the room.

Best wishes,
Tim 



--_000_0609A0EA0C93419CADF45C76200B6689jiscacuk_-- From nobody Wed Mar 8 04:24:30 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 F41E812965A; Wed, 8 Mar 2017 04:24:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148897586598.20191.8422735308130046248@ietfa.amsl.com> Date: Wed, 08 Mar 2017 04:24:25 -0800 Archived-At: Cc: dnssd@ietf.org, draft-ietf-dnssd-mdns-dns-interop.all@ietf.org Subject: [dnssd] Partial review of draft-ietf-dnssd-mdns-dns-interop-04 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 12:24:26 -0000 Review is partially done. Another review request has been registered for completing it. Reviewer: Jürgen Schönwälder Review result: Not Ready Disclaimer: I regret that DNS does not use UTF-8 in its labels, to me , as an outside observer, it seems IDNA was a big mistake. But given the IETF standards we have, it seems one has to properly IDNA encode UTF-8 in DNS labels. (As an outsider, I am puzzled by documents that say that for some portions of the DNS name hierarchy this is not true and it is left vague how to precisely determine where in the namespace IDNA has to be used and where not.) So now that you understand my ignorance, I hope you understand what follows below may just be plain wrong... In section 2, I do not understand this statement: 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. Not sure what this is trying to convey. Are you saying that using plain UTF in DNS labels is OK if it is far enough from the root? Why would that be? I looked up RFC 6055 and I am surprised to read text about 'intelligent (stub) resolver' there as this seems to be asking for trouble. To me, it sounds like you are saying 'some portions of the name hierarchy may use raw UTF-8 labels while other portions may not and we do not tell you how to set them appart in a reliable way'. If this is the approach, then the approach is in my personal view broken. (And please recall the disclaimer above.) In section 3, what does the term 'implicated' mean? What I do not understand: Why is it desirable to treat DNS labels that carry DNS-SD Service Instance Names different than any other labels that may contain UTF-8 characters? If the IETF believes IDNA is the solution for the DNS, why do we then not also use IDNA for UTF-8 DNS-SD Service Instance Names? Yes, there will be some names that will be impossible to use but then services in the DNS (as opposed to mDNS) are likely more infrastructure services and less so end use provided services. And at the end, the limitation is the result of the DNS / IDNA approach, so you get what you asked for. (Again, please recall the disclaimer). Back to my role as ops-dir reviewer: This document is more a kind of a problem statement document, I do not see direct operational impact. The trouble with DNS labels is more likely a user facing issues than it is a network operational issue (except perhaps for helpdesk functions, in particular in enterprise networks). Bottom line: I am the wrong reviewer for this document. I think the authors should specifically seek reviews and comments from people active in the DNSOP working group. From nobody Wed Mar 8 05:32:57 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 EB6C5129697 for ; Wed, 8 Mar 2017 05:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=jisc.ac.uk header.b=ITiCJXrG; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com header.b=V4PZmF9J 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 C5Mj3w-c9cx0 for ; Wed, 8 Mar 2017 05:32:53 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E33129691 for ; Wed, 8 Mar 2017 05:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1488979971; bh=zQV7ERGj+QDepV3Q6llTwEiraU70NnVrXwd9/XBeGf4=; h=From:To:Subject:Date:Message-ID:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ITiCJXrGZOBM47EzV0hA+NUyaK7Nxl5y4zkQJuAdtA2FH1fJYcS5nZc6ncAXL7ImJdF8GAEjUaAthlyGqabAZVN0XJzFWT9KCzq8Dndwk4dO3eOd8gS1knBtIRcj++jSdSWC4P0t3oFe5fzTlBIX6bKkbgmY3KgN7YMMH0tIHlo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zQV7ERGj+QDepV3Q6llTwEiraU70NnVrXwd9/XBeGf4=; b=V4PZmF9J/I2yXldqud5HOSPVZPLMDqRhaY136svF2MD6YBeDEJoQu2XkMVFZIpZmiHJPqWYbYHYYPd3Z5+wcbe9MRsYJUTtUCA00OaL9A5O5ycwmtCQC6pcomf+LBJ4vdrMflQJUkvjTnrEamg0exWU5dwLpMfbUUDNHa24TrfU= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0177.outbound.protection.outlook.com [213.199.180.177]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-84-q-mt0DOLMgyHdkghdrQ8Kg-1; Wed, 08 Mar 2017 13:32:48 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Wed, 8 Mar 2017 13:32:47 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0961.014; Wed, 8 Mar 2017 13:32:47 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: DNS-SD, remote presentations at Chicago? Thread-Index: AQHSmBB5E+kKsKGHLUuFzk6bS03YTQ== Date: Wed, 8 Mar 2017 13:32:47 +0000 Message-ID: <349B87EF-BAEE-40B0-9590-48A2034E8DA7@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 7f1e3f9e-20c7-4d23-3ad6-08d466279c05 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1138; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:eeDI5pOikk4hF26OjFpI54ILvKHRUZtUrGvn5GQgFiNFMlxq5IsqmMXpfzP4qP/qwi6iUSRvZ3woEw2dSHYX/yy360csOm1m0vpFd9Wge35oU5joKyuxPFkMYyoP46TIX/2NehWXXn6+vdBIBNmrYHHlOpfqAoijJ2BEO4aaCAHVdgPAPwakLGzJbv3FEAPHzzgyoy7Fon5A3kY2ivrcgP6US+qy9Z+ovJFkO/Y+csH8LMCkWKEIaxW6Lr0Ybwnyhd9m3o7OTrxU1A+lQlesr69UiIY0zrIduAtWzVmkHf8+ISEFqnqfvcUFHiv9DP2bpCWaqNTzNbRXVVWjfSH0YQ==; 20:sjo5QEMA7WMHrt/KSF7Dn/rccTegxB60Qg3zIyKCyTr5RMhEoXD2uBtqFqGNpvmDsEonBacbZu8VthgQ+2+zwSd2KlFMx337Iojv3c+B2qKUkU8jORSD7pWk7l55vanj3TRJ/8GnWuLIRMX3IcC21i1GpKcnGiJtaV2f10bvpvo= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(66654002)(50226002)(5660300001)(83716003)(8936002)(74482002)(2351001)(36756003)(38730400002)(110136004)(82746002)(2501003)(189998001)(8676002)(1730700003)(66066001)(81166006)(6486002)(6512007)(99286003)(86362001)(3846002)(2900100001)(305945005)(33656002)(3660700001)(5250100002)(558084003)(6916009)(53936002)(50986999)(3280700002)(5640700003)(6506006)(2906002)(6436002)(106116001)(6116002)(7736002)(102836003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <9999FDFD0CC81B4ABC51B18C730591EC@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 13:32:47.3116 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138 X-MC-Unique: q-mt0DOLMgyHdkghdrQ8Kg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: [dnssd] DNS-SD, remote presentations at Chicago? X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 13:32:56 -0000 SGksDQoNCkZvbGxvd2luZyBvbiBmcm9tIG15IHByZXZpb3VzIGVtYWlsLCB0aGUgcXVlc3Rpb24g Zm9yIE1lZXRFY2hvIGlzIHdoZXRoZXIgYW55b25lIHdpc2hlcyB0byBwcmVzZW50IHJlbW90ZWx5 IGF0IElFVEY5OC4gDQoNCklmIHlvdSBrbm93IHRoYXQgeW91IHdpbGwsIHBsZWFzZSBsZXQgUmFs cGggb3IgSSBrbm93IHNvIHdlIGNhbiBlbnN1cmUgaXTigJlzIGFsbCBib29rZWQgaW4gd2l0aCB0 aGUgTWVldEVjaG8gdGVhbS4NCg0KTWFueSB0aGFua3MsDQpUaW0gDQoNCg== From nobody Wed Mar 8 07:45:09 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 D720C1294C7 for ; Wed, 8 Mar 2017 07:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 wTv_IzYMXQ-E for ; Wed, 8 Mar 2017 07:45:04 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 23B821296EA for ; Wed, 8 Mar 2017 07:45:04 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id g138so39358865itb.0 for ; Wed, 08 Mar 2017 07:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=rOPdM8kWukoky0KayCaoVyo7/mGSiQPWvgg9qlrjgUk=; b=vr/GgHdjWXCvc0DY2TcX+8KzE1Ls1fRJly6EmIQCC2P6P7z23xEo5a0c/f2/3k7N8C NZyVBCE5bw7xBBwleujTt+93aLBwLwV8serNpgo8PhSOFcXwrOH0Qqtp5wTlMhIZtQ3O CZBZEII6cQ8tVO3dHQkjTpWwrZ0qB5RIVV32M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=rOPdM8kWukoky0KayCaoVyo7/mGSiQPWvgg9qlrjgUk=; b=hj18GK05QsBNcziS3YVHHURlEo5U4VNM9bykP7ljV6KU79/Y0Xl7VYc6TzF1Y9HNOd gZ+tUYKw6g0Z87qyx+4TpSvtImwxYZ72XvigP7XjTn6lRHzLR75+cnGm/LZjtXyx0hRy 5tU6Mlzt1hu27EvIPOTYc6z+f60HfZVaWbCDnkgaB1z9K23LeIB+1Pe1lrqb7N26Z4hN alNJSoPMBTxAthUn+2195gNewdRASTxGWxOk+ZeTld9s6+s5pdMawyKSPfSVXn0P1p1V HTukt69B5MoDg9RFuTja9HWnh0hCvRjUNnZjP7QSCTKDlUq2qDDU9FD76FrRz3c9Okwo nXVQ== X-Gm-Message-State: AMke39l+BXwz8dl9ZyTZv2PQsV1xdJl8/bjjyqmnDINf5h+G8UdYYKFgZ/Kk/UmiQu1rfmai X-Received: by 10.107.191.67 with SMTP id p64mr6557569iof.236.1488987903195; Wed, 08 Mar 2017 07:45:03 -0800 (PST) Received: from dyn.com (192-0-220-231.cpe.teksavvy.com. [192.0.220.231]) by smtp.gmail.com with ESMTPSA id g103sm1652338iod.44.2017.03.08.07.45.01 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 08 Mar 2017 07:45:02 -0800 (PST) Date: Wed, 8 Mar 2017 10:44:59 -0500 From: Andrew Sullivan To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Message-ID: <20170308154458.GU9646@dyn.com> References: <148897586598.20191.8422735308130046248@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <148897586598.20191.8422735308130046248@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: ops-dir@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-mdns-dns-interop.all@ietf.org Subject: Re: [dnssd] Partial review of draft-ietf-dnssd-mdns-dns-interop-04 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 15:45:08 -0000 Hi, Thanks for the review. I think there is an issue here that is apparently not clear enough to you as a reader, so it's really helpful to learn that. I'd like to figure out how to make it clearer. On Wed, Mar 08, 2017 at 04:24:25AM -0800, Jürgen Schönwälder wrote: > Disclaimer: I regret that DNS does not use UTF-8 in its labels, to me > , as an outside observer, it seems IDNA was a big mistake. But given > the IETF standards we have, it seems one has to properly IDNA encode > UTF-8 in DNS labels. This isn't exactly correct, and I think that it may be the source of the problem you had with the document. DNS as such makes literally no restrictions on what "characters" can appear in a label, except for length. A label can have 63 octets. Any octet is permitted. Perhaps unfortunately, however, in the original specification ASCII was treated specially in two ways. First, labels are matched "case insensitively" in ASCII. Second, STD 13 recommended the letter,digit,hyphen rule for labels to maximise compatibility with deployed hostnames. Because STD 13 was written before RFC 2119 keywords were in use, the distinctions among good operational practice and protocol restrictions was not always clear to every reader, so many people understood LDH to be a DNS restriction, but it wasn't. Apart from the special treatment of ASCII, DNS also makes no rules about character sets. So, there's no way to tell, for a given label, what its encoding scheme is -- UTF-8, JIS, ISO-8859-n, or what all. It is because of the above that we ended up with IDNA. Nothing about IDNA prevents other schemes for labels (including using characters outside the ASCII range). The possibilities are discussed at some length in RFC 6055. At the same time, we know that the root zone and a very large number of TLDs (maybe all, but I bet not) restrict delegations to LDH, and that they use some variation of IDNA (including non-IETF IDNA variants based on UTS#46 -- this is how some TLDs allow registering emoji, since they weren't "emoji" when IDNA2003 came out and many of the code points were undefined under Unicode 3.2. Emoji are DISALLOWED under IDNA2008 because they're not "letters or digits" in any writing system). So, given the distributed administration of the DNS, there is no way to be sure how a given octet sequence ought to be interpreted, but we can be fairly sure that some administrators of some zones will definitely not permit UTF-8 labels in their zones. This is the problem the I-D is intending to highlight, and it sounds like it wasn't clear to you. Is any of the above clearer? Would any more introductory material help to make this plain? > would that be? I looked up RFC 6055 and I am surprised to read text > about 'intelligent (stub) resolver' there as this seems to be asking > for trouble. Yes :) That's the trouble I think we're in, and it's why I worked on this I-D in the first place. > To me, it sounds like you are saying 'some portions of > the name hierarchy may use raw UTF-8 labels while other portions may > not and we do not tell you how to set them appart in a reliable > way'. If this is the approach, then the approach is in my personal > view broken. (And please recall the disclaimer above.) It may be broken, but it is the reality in a distributed system with distributed administration. One cannot make rules about what other people put in their zones, and the DNS is already clear that any octet at all is permitted in the DNS. > In section 3, what does the term 'implicated' mean? Would "involved" make it clearer to you? The point is that different portions of a DNS-SD name have different properties, and only some of those are going to have potentially ambiguous i18n encodings in the DNS. > What I do not understand: Why is it desirable to treat DNS labels > that > carry DNS-SD Service Instance Names different than any other labels > that may contain UTF-8 characters? Because DNS-SD says that the labels should be raw UTF-8 in the DNS, and because of IDNA some zones have a policy where raw UTF-8 is not permitted (and some resolvers may automatically convert U-labels to A-labels). > If the IETF believes IDNA is the > solution for the DNS, why do we then not also use IDNA for UTF-8 > DNS-SD Service Instance Names? Yes, there will be some names that > will > be impossible to use but then services in the DNS (as opposed to > mDNS) > are likely more infrastructure services and less so end use provided > services. The WG discussed that approach and came down hard against it. In particular, such an approach definitely disallows certain characters that some people apparently want, and it disallows spaces whenever the rest of the label is an IDNA label. (Spaces are allowed in DNS labels as a general rule, but they're DISALLOWED under IDNA2008.) > Back to my role as ops-dir reviewer: This document is more a kind of > a > problem statement document, I do not see direct operational impact. > The trouble with DNS labels is more likely a user facing issues than > it is a network operational issue (except perhaps for helpdesk > functions, in particular in enterprise networks). One of the reasons this document has been difficult to get done is because it lies at the intersection of protocols and operations. There are operational policies (such as restriction of i18n in zones to IDNA) that have consequences for how DNS-SD can work. I'm aware that you think you're the wrong reviewer, but actually this review has been terribly helpful to me in understanding the degree to which it's too hard to understand for part of the target audience. So anything we can do to improve that would, in my view as editor, be a big help. Thanks! A -- Andrew Sullivan Dyn asullivan@dyn.com From nobody Fri Mar 10 12:57:22 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 294DD1295F4; Fri, 10 Mar 2017 12:57:20 -0800 (PST) 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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148917944013.3045.12928775040243531631@ietfa.amsl.com> Date: Fri, 10 Mar 2017 12:57:20 -0800 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-privacy-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 10 Mar 2017 20:57:20 -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 of the IETF. Title : Privacy Extensions for DNS-SD Authors : Christian Huitema Daniel Kaiser Filename : draft-ietf-dnssd-privacy-01.txt Pages : 23 Date : 2017-03-10 Abstract: DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. We propose to solve this problem by a two-stage approach. In the first stage, hosts discover Private Discovery Service Instances via DNS-SD using special formats to protect their privacy. These service instances correspond to Private Discovery Servers running on peers. In the second stage, hosts directly query these Private Discovery Servers via DNS-SD over TLS. A pairwise shared secret necessary to establish these connections is only known to hosts authorized by a pairing system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-privacy/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-privacy-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 Sun Mar 12 04:25:38 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 4D1611298A8; Sun, 12 Mar 2017 04:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCb8sAn0bQmD; Sun, 12 Mar 2017 04:25:31 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6881298B1; Sun, 12 Mar 2017 04:25:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E50337BB; Sun, 12 Mar 2017 12:25:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LedZY_BcSS15; Sun, 12 Mar 2017 12:25:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 12 Mar 2017 12:25:29 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9DFD20038; Sun, 12 Mar 2017 12:25:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SZsufhA22sW0; Sun, 12 Mar 2017 12:25:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6A1B20036; Sun, 12 Mar 2017 12:25:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 69C1D3EB7296; Sun, 12 Mar 2017 12:25:32 +0100 (CET) Date: Sun, 12 Mar 2017 12:25:31 +0100 From: Juergen Schoenwaelder To: Andrew Sullivan Message-ID: <20170312112531.GC50035@elstar.local> Mail-Followup-To: Andrew Sullivan , ops-dir@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-mdns-dns-interop.all@ietf.org References: <148897586598.20191.8422735308130046248@ietfa.amsl.com> <20170308154458.GU9646@dyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <20170308154458.GU9646@dyn.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: ops-dir@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-mdns-dns-interop.all@ietf.org Subject: Re: [dnssd] Partial review of draft-ietf-dnssd-mdns-dns-interop-04 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder 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: Sun, 12 Mar 2017 11:25:33 -0000 Andrew, your response is helpful for me to understand things better. The situation indeed seems complicated. On Wed, Mar 08, 2017 at 10:44:59AM -0500, Andrew Sullivan wrote: > Hi, > > Thanks for the review. I think there is an issue here that is > apparently not clear enough to you as a reader, so it's really helpful > to learn that. I'd like to figure out how to make it clearer. > > On Wed, Mar 08, 2017 at 04:24:25AM -0800, Jürgen Schönwälder wrote: > > > Disclaimer: I regret that DNS does not use UTF-8 in its labels, to me > > , as an outside observer, it seems IDNA was a big mistake. But given > > the IETF standards we have, it seems one has to properly IDNA encode > > UTF-8 in DNS labels. > > This isn't exactly correct, and I think that it may be the source of > the problem you had with the document. > > DNS as such makes literally no restrictions on what "characters" can > appear in a label, except for length. A label can have 63 octets. > Any octet is permitted. Perhaps unfortunately, however, in the > original specification ASCII was treated specially in two ways. > First, labels are matched "case insensitively" in ASCII. Second, STD > 13 recommended the letter,digit,hyphen rule for labels to maximise > compatibility with deployed hostnames. Because STD 13 was written > before RFC 2119 keywords were in use, the distinctions among good > operational practice and protocol restrictions was not always clear to > every reader, so many people understood LDH to be a DNS restriction, > but it wasn't. This was clear to me since I am well aware that the DNS protocol ships octets. > Apart from the special treatment of ASCII, DNS also makes no rules > about character sets. So, there's no way to tell, for a given label, > what its encoding scheme is -- UTF-8, JIS, ISO-8859-n, or what all. Yes, but historically (if I understand things right), the character set was effectively restricted to LDH (ASCII) - the restriction was not part of the protocol but imposed by other 'recommendations'. > It is because of the above that we ended up with IDNA. Nothing about > IDNA prevents other schemes for labels (including using characters > outside the ASCII range). The possibilities are discussed at some > length in RFC 6055. With a time machine available, we should probably have moved from LDH (ASCII) to UTF-8 (or a subset of UTF-8). Multiple different character _encodings_ in the label space can't really be a feature. Note that I consider further restrictions (i.e., use of white space) something separate from the encoding scheme used. I think I recall that people said back in a day that moving from LDH to UTF-8 may be risky since we do not know whether all DNS implementations got the "DNS ships octets" thing right. And there may be situations where entering a UTF-8 name correctly may not be feasible on certain devices. Looking back in time, these may have been valid concerns back then but they are likely less so today and instead of having a transition plan to have UTF-8 encoded labels we went for a solution that gives us complexity forever. [And yes, I do not know all the details of the discussions and so I am likely summarizing things up very wrongly.] But from an outsider perspective, it seems that having (i) a transition plan to UTF-8 encoding of labels and (ii) a clear separation of further label restrictions from the encoding aspects would have been desirable. > At the same time, we know that the root zone and a very large number > of TLDs (maybe all, but I bet not) restrict delegations to LDH, and > that they use some variation of IDNA (including non-IETF IDNA variants > based on UTS#46 -- this is how some TLDs allow registering emoji, > since they weren't "emoji" when IDNA2003 came out and many of the code > points were undefined under Unicode 3.2. Emoji are DISALLOWED under > IDNA2008 because they're not "letters or digits" in any writing > system). So, given the distributed administration of the DNS, there > is no way to be sure how a given octet sequence ought to be > interpreted, but we can be fairly sure that some administrators of > some zones will definitely not permit UTF-8 labels in their zones. Well, obviously, this is the clunky result we have now. > This is the problem the I-D is intending to highlight, and it sounds > like it wasn't clear to you. Is any of the above clearer? Would any > more introductory material help to make this plain? For me personally, it would have been good to know more about what is out there. I understand traditional LDH labels and I understand IDNA2003 and IDNA2008 labels. I understand that mDNS says UTF-8 and pretty much no restrictions on instance portion of a service name. Are there significant deployments out there that use other encodings or restrictions? > > would that be? I looked up RFC 6055 and I am surprised to read text > > about 'intelligent (stub) resolver' there as this seems to be asking > > for trouble. > > Yes :) That's the trouble I think we're in, and it's why I worked on > this I-D in the first place. > > > To me, it sounds like you are saying 'some portions of > > the name hierarchy may use raw UTF-8 labels while other portions may > > not and we do not tell you how to set them appart in a reliable > > way'. If this is the approach, then the approach is in my personal > > view broken. (And please recall the disclaimer above.) > > It may be broken, but it is the reality in a distributed system with > distributed administration. One cannot make rules about what other > people put in their zones, and the DNS is already clear that any octet > at all is permitted in the DNS. The protocol ships octets. The question is how to interpret them. If there would be agreement that the octets by default represent UTF-8 encoded characters life would start to be somewhat simpler. This would solve the encoding part, it does not solve the 'which restrictions apply to this label part'. OK, I am ignorant of the complexity of deploying this but a decent transition plan to something simpler may be better long term than more layeres of things that do not play well together. > > In section 3, what does the term 'implicated' mean? > > Would "involved" make it clearer to you? The point is that different > portions of a DNS-SD name have different properties, and only some of > those are going to have potentially ambiguous i18n encodings in the > DNS. > > > What I do not understand: Why is it desirable to treat DNS labels > > that > > carry DNS-SD Service Instance Names different than any other labels > > that may contain UTF-8 characters? > > Because DNS-SD says that the labels should be raw UTF-8 in the DNS, > and because of IDNA some zones have a policy where raw UTF-8 is not > permitted (and some resolvers may automatically convert U-labels to > A-labels). Yes, sounds like a decent conflict asking for surprises. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 13 16:53:26 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 4DB64129A19; Mon, 13 Mar 2017 16:53:24 -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.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944920430.20312.4091390207668238868@ietfa.amsl.com> Date: Mon, 13 Mar 2017 16:53:24 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-10.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 23:53:24 -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 of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-10.txt Pages : 36 Date : 2017-03-13 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-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-10 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 Mar 13 16:55: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 A0655129C41; Mon, 13 Mar 2017 16:55:21 -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.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944932164.20284.1756144644700710236@ietfa.amsl.com> Date: Mon, 13 Mar 2017 16:55:21 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-hybrid-06.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 23:55:21 -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 of the IETF. Title : Discovery Proxy for Multicast DNS-Based Service Discovery Author : Stuart Cheshire Filename : draft-ietf-dnssd-hybrid-06.txt Pages : 37 Date : 2017-03-13 Abstract: This document specifies a mechanism that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-hybrid-06 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 Tue Mar 14 06:41: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 B59B41295A5 for ; Tue, 14 Mar 2017 06:41:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148949888273.12647.11525736678553980134.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 06:41:22 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] Milestones changed for dnssd WG X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 13:41:23 -0000 Changed milestone "Confirm long-lived queries draft as WG document", resolved as "Done", added draft-ietf-dnssd-push to milestone. Deleted milestone "Adopt threat model draft as WG document". Changed milestone "Submit the zeroconf and unicast DNS "problems and challenges" draft to the IESG as Informational", resolved as "Done", added draft-ietf-dnssd-mdns-dns-interop to milestone. Changed milestone " Submit wide-area service discovery solution draft to the IESG as Standards Track RFC", set due date to May 2017 from September 2015, added draft-ietf-dnssd-hybrid to milestone. Changed milestone "Adopt hybrid-proxy implementation draft as WG document", set due date to July 2017 from November 2015. URL: https://datatracker.ietf.org/wg/dnssd/about/ From nobody Tue Mar 14 06:44:04 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 9DF16128DE8 for ; Tue, 14 Mar 2017 06:44:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148949904364.12769.7725670230764908339.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 06:44:03 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] Milestones changed for dnssd WG X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 13:44:03 -0000 Changed milestone "Adopt requirements draft as WG document", added draft-ietf-dnssd-requirements to milestone. Changed milestone "Submit requirements draft to the IESG as an Informational RFC", added draft-ietf-dnssd-requirements to milestone. Changed milestone "Adopt wide-area service discovery solution draft as WG document ", added draft-ietf-dnssd-hybrid to milestone. Changed milestone "Adopt Informational document on the problems and challenges arising for zeroconf and unicast DNS name services", added draft-ietf-dnssd-mdns-dns-interop to milestone. URL: https://datatracker.ietf.org/wg/dnssd/about/ From nobody Tue Mar 14 09:21:05 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 7C375132946 for ; Tue, 14 Mar 2017 09:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=jisc.ac.uk 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 m4EnsIXAIytB for ; Tue, 14 Mar 2017 09:21:01 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A77C12975C for ; Tue, 14 Mar 2017 09:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1489508459; bh=vky7BHXjj7sLx6HH4hn8jP0DyegTTa229DLt7z7UAhA=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Oygzw2TBbVuAcpjLScZxyp5H4WRPLvbPjXz2NiL5mMTBw09XUOXUKmx+NOmBVSsFprkhbQw5GmiofwnMuUkqklFsyDYlDmzWWycW10D2DtG5bHfhmC+kOpLEk93YUxU1qSBvFiEmhgjM4ckJSbHos5uZGi5qNU/WqBfkTyS7LXo= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0239.outbound.protection.outlook.com [213.199.154.239]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-11-F6z__WMUNI6-LHcTHU-XQQ-1; Tue, 14 Mar 2017 16:20:49 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 16:20:48 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0977.010; Tue, 14 Mar 2017 16:20:48 +0000 From: Tim Chown To: "dnssd@ietf.org" CC: Ralph Droms Thread-Topic: Provisional agenda for IETF98 Thread-Index: AQHSnN7wKXPuZrTO5EGyKCp9DDWR4Q== Date: Tue, 14 Mar 2017 16:20:48 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.62.83.230] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:1R/NurQjGh/fSVlTCnsdiEadAceppmnR7fzd38hb0PD5/9xa9TnoL2uSad6nl80r1QBP/K+KPMsohsQmXDm6YYVMl6gTjxpb2vy/y7UUoU64BvH8Kv3BkmipEWJjooCwvtDaS3Gs9s7TJPRQHJNQkYGkv08stQObiTI0tXGixP/gKTyO2sb1bze8hUFcThV/WGTgWjUkfFtSBMbRmUBi818Wv/C6T0g+9lU2LRP5pF/pZ8/6MuLg5TBrzU/VU30OIOhzwzwW+6x8MVq7pFCmHCRpzPhLGtNlkt0jjaKPfxulaZaByTJ5aixN1GpHfF8v0axWLB8U7HI+o0jnS2u9Vw==; 20:e9ID+v727+fNBH3QVySLf1LbffWXsLj5BJ3IMSAHs0Y/cc2rsPQtxEBWBaLs01dPRvO4YyoksYNfUfNBISI3Ip4mE+g5/YDL9ZiEbCvV0c4wxrtL/2qAJc0qyEgYAfmY3oO5V7AuRofB5IZxzMckAj25U/hAOPcRmRTycG7DRbQ= x-ms-office365-filtering-correlation-id: a9256b42-0a45-4dc5-df89-08d46af6135b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(8936002)(106116001)(50226002)(33656002)(8676002)(3280700002)(2906002)(81166006)(1730700003)(3660700001)(86362001)(2501003)(110136004)(189998001)(4326008)(38730400002)(39060400002)(57306001)(53936002)(36756003)(66066001)(50986999)(2351001)(83716003)(5640700003)(6506006)(54896002)(6512007)(606005)(6436002)(99286003)(236005)(68736007)(6486002)(5250100002)(6916009)(42882006)(74482002)(5660300001)(7906003)(6306002)(82746002)(6116002)(3846002)(7736002)(102836003)(2900100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 16:20:48.4028 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: F6z__WMUNI6-LHcTHU-XQQ-1 Content-Type: multipart/alternative; boundary="_000_DCC07B2D2F034B9BB1C482BD442AD4BEjiscacuk_" Archived-At: Subject: [dnssd] Provisional agenda for IETF98 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.21 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 Mar 2017 16:21:03 -0000 --_000_DCC07B2D2F034B9BB1C482BD442AD4BEjiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNClRoZSBwcm92aXNpb25hbCBhZ2VuZGEgZm9yIElFVEY5OCBpcyBpbmNsdWRlZCBiZWxv dy4gUGxlYXNlIGxldCBSYWxwaCBvciBJIGtub3cgaWYgeW91IGhhdmUgc3VnZ2VzdGlvbnMgZm9y IGNoYW5nZXMgb3IgYWRkaXRpb25zLg0KDQpUaGVyZSBoYXZlIGJlZW4gbmV3IHZlcnNpb25zIG9m IGVhY2ggZHJhZnQgcG9zdGVkIC0gdGhhbmtzIGF1dGhvcnMhIC0gc28gaXQgd291bGQgYmUgZ3Jl YXQgdG8gZ2V0IFdHIHJldmlldyBvZiB0aGUgZG9jdW1lbnRzIGluIGFkdmFuY2Ugb2YgdGhlIG1l ZXRpbmcuDQoNClRoZSBjaGFpcnMgYmVsaWV2ZSB0aGF0IHRoZSBETlMtU0QgRGlzY292ZXJ5IFBy b3h5IGlzIHJlYWR5IHRvIHByb2dyZXNzIHRvIHRoZSBJRVNHLCBhbmQgdGhhdCBETlMgUHVzaCBz aG91bGQgYmUgcmVhZHkgZm9yIFdHTEMuIFRoZSBETlMgc2Vzc2lvbiBzaWduYWxsaW5nIHdvcmsg aXMgcHJvZ3Jlc3NpbmcgaW4gdGhlIGRuc29wIFdHLCBhbmQgd2UgYmVsaWV2ZSB0aGF0IGlzIGFs c28gY2xvc2UgdG8gV0dMQy4gU28gd2Ugc2hvdWxkIHNvb24gaGF2ZSB0aGUga2V5IHBpZWNlcyBv ZiBvdXIgV0cgY2hhcnRlciBwdWJsaXNoZWQuDQoNCk91ciBvbmdvaW5nL2Z1dHVyZSB3b3JrIHRo ZW4gaW5jbHVkZXM6DQotIGRldGVybWluaW5nIHRoZSBuYXR1cmUgb2YgdGhlIHByb3Bvc2VkIERO Uy1TRCBBZHZlcnRpc2luZyBQcm94eSwgZm9yIHdoaWNoIHdlIGhhdmUgYW4gb3BlbiBkaXNjdXNz aW9uIHNsb3Q7IHRoZXJlIGlzIG5vIGRyYWZ0IGFzIHlldDsNCi0gY29udGludWluZyB3b3JrIG9u IHRoZSBETlMtU0QgUHJpdmFjeSBhbmQgZGV2aWNlIHBhaXJpbmcgZHJhZnRzOyBDaHJpc3RpYW4g d2lsbCBwcmVzZW50IG9uIHRoZXNlOw0KLSBwdWxsaW5nIHRvZ2V0aGVyIGEgQkNQIG9uIEROUy1T RCBkZXBsb3ltZW50IGZvciBjYW1wdXMvZW50ZXJwcmlzZSBuZXR3b3Jrczsgd2UgaGF2ZSBzb21l IG1hdGVyaWFsIGFscmVhZHksIGJ1dCBubyBkcmFmdCBhcyB5ZXQ7DQotIGRldGVybWluaW5nIGhv dyBiZXN0IHRvIGFwcGx5IEROUy1TRCBpbiB1bm1hbmFnZWQgaG9tZSBuZXR3b3JrczsgVGVkIGhh cyBhIGNvdXBsZSBvZiBlYXJseSBkcmFmdHMgaW4gdGhpcyBzcGFjZSB3aGljaCB3aWxsIGhvcGVm dWxseSBoZWxwIGRyaXZlIHByb2R1Y3RpdmUgZGlzY3Vzc2lvbi4NCg0KWW914oCZbGwgYWxzbyBo YXZlIG5vdGljZWQgdGhhdCB3ZeKAmXZlIHVwZGF0ZWQgdGhlIFdHIG1pbGVzdG9uZXM7IGFwb2xv Z2llcyBmb3IgdGhlIHJlc3VsdGluZyBsaXN0IHNwYW0hDQoNCkJlc3Qgd2lzaGVzLA0KVGltIGFu ZCBSYWxwaA0KDQrigJQNCg0KRE5TU0QgV0cgUHJvdmlzaW9uYWwgQWdlbmRhDQoNCklFVEY5OCwg Q2hpY2Fnbw0KVHVlc2RheSAyOHRoIE1hcmNoIDIwMTcNCjE2OjQwIC0gMTg6NDAgbG9jYWwgdGlt ZQ0KDQpDaGFpcnPigJkgSW50cm9kdWN0aW9uIChpbmMuIHVwZGF0ZWQgbWlsZXN0b25lcykgQ2hh aXJzLCA1IG1pbnMNCg0KRE5TIFB1c2ggTm90aWZpY2F0aW9ucyBTdHVhcnQgQ2hlc2hpcmUsIDUg bWlucw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zc2QtcHVzaC0x MA0KKGFuZCBhY2NvbXBhbnlpbmcgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZG5zb3Atc2Vzc2lvbi1zaWduYWwtMDIgaW4gZG5zb3AgV0cpDQoNCkROUy1TRCBEaXNjb3Zl cnkgUHJveHkgU3R1YXJ0IENoZXNoaXJlLCA1IG1pbnMNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWRuc3NkLWh5YnJpZC0wNg0KDQpETlMtU0QgQWR2ZXJ0aXNpbmcgUHJv eHkgLSBkaXNjdXNzaW9uIDIwIG1pbnMNCg0KUHJpdmFjeSBFeHRlbnNpb25zIGZvciBETlMtU0Qg Q2hyaXN0aWFuIEh1aXRlbWEsIDE1IG1pbnMNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWRuc3NkLXByaXZhY3ktMDENCg0KRGV2aWNlIFBhaXJpbmcgVXNpbmcgU2hvcnQg QXV0aGVudGljYXRpb24gU3RyaW5ncyBDaHJpc3RpYW4gSHVpdGVtYSwgMTUgbWlucw0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zc2QtcGFpcmluZy0wMQ0KDQpETlMt U0QgRGVwbG95bWVudCBmb3IgY2FtcHVzL2VudGVycHJpc2UgbmV0d29ya3MgLSBCQ1AgZG9jdW1l bnQgZGlzY3Vzc2lvbiAyMCBtaW5zDQpodHRwczovL2dpdGh1Yi5jb20vcHVzYXRlcmkvZHJhZnQt cHVzYXRlcmktaHlicmlkcHJveHktaW1wbC9ibG9iL21hc3Rlci9kcmFmdC1wdXNhdGVyaS1kbnNz ZC1oeXAtaW1wbC50eHQNCg0KDQpTaW1wbGUgSG9tZW5ldCBOYW1pbmcgYW5kIFNlcnZpY2UgRGlz Y292ZXJ5IEFyY2hpdGVjdHVyZSBUZWQgTGVtb24sIDE1IG1pbnMNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC10bGRtLXNpbXBsZS1ob21lbmV0LW5hbWluZy0wMA0KDQoNClN0YXRl ZnVsIE11bHRpLUxpbmsgRE5TIFNlcnZpY2UgRGlzY292ZXJ5IFRlZCBMZW1vbiwgMTAgbWlucw0K DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVtb24tc3RhdGVmdWwtZG5zc2Qt MDANCg0KDQpTdW1tYXJ5IG9mIGFjdGlvbnMgYW5kIGNsb3NlIENoYWlycywgMTAgbWlucw0KDQoN Cg== --_000_DCC07B2D2F034B9BB1C482BD442AD4BEjiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgcHJvdmlzaW9uYWwgYWdlbmRh IGZvciBJRVRGOTggaXMgaW5jbHVkZWQgYmVsb3cuIFBsZWFzZSBsZXQgUmFscGggb3IgSSBrbm93 IGlmIHlvdSBoYXZlIHN1Z2dlc3Rpb25zIGZvciBjaGFuZ2VzIG9yIGFkZGl0aW9ucy48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZXJl IGhhdmUgYmVlbiBuZXcgdmVyc2lvbnMgb2YgZWFjaCBkcmFmdCBwb3N0ZWQgLSB0aGFua3MgYXV0 aG9ycyEgLSBzbyBpdCB3b3VsZCBiZSBncmVhdCB0byBnZXQgV0cgcmV2aWV3IG9mIHRoZSBkb2N1 bWVudHMgaW4gYWR2YW5jZSBvZiB0aGUgbWVldGluZy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBjaGFpcnMgYmVsaWV2ZSB0aGF0 IHRoZSBETlMtU0QgRGlzY292ZXJ5IFByb3h5IGlzIHJlYWR5IHRvIHByb2dyZXNzIHRvIHRoZSBJ RVNHLCBhbmQgdGhhdCBETlMgUHVzaCBzaG91bGQgYmUgcmVhZHkgZm9yIFdHTEMuIFRoZSBETlMg c2Vzc2lvbiBzaWduYWxsaW5nIHdvcmsgaXMgcHJvZ3Jlc3NpbmcgaW4gdGhlIGRuc29wIFdHLCBh bmQgd2UgYmVsaWV2ZSB0aGF0IGlzIGFsc28gY2xvc2UgdG8gV0dMQy4gU28gd2Ugc2hvdWxkDQog c29vbiBoYXZlIHRoZSBrZXkgcGllY2VzIG9mIG91ciBXRyBjaGFydGVyIHB1Ymxpc2hlZC4gJm5i c3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5PdXIgb25nb2luZy9mdXR1cmUgd29yayB0aGVuIGluY2x1ZGVzOjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4tIGRldGVybWluaW5nIHRoZSBuYXR1cmUgb2YgdGhlIHByb3Bvc2VkIEROUy1TRCBB ZHZlcnRpc2luZyBQcm94eSwgZm9yIHdoaWNoIHdlIGhhdmUgYW4gb3BlbiBkaXNjdXNzaW9uIHNs b3Q7IHRoZXJlIGlzIG5vIGRyYWZ0IGFzIHlldDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBjb250 aW51aW5nIHdvcmsgb24gdGhlIEROUy1TRCBQcml2YWN5IGFuZCBkZXZpY2UgcGFpcmluZyBkcmFm dHM7IENocmlzdGlhbiB3aWxsIHByZXNlbnQgb24gdGhlc2U7PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pi0gcHVsbGluZyB0b2dldGhlciBhIEJDUCBvbiBETlMtU0QgZGVwbG95bWVudCBmb3IgY2FtcHVz L2VudGVycHJpc2UgbmV0d29ya3M7IHdlIGhhdmUgc29tZSBtYXRlcmlhbCBhbHJlYWR5LCBidXQg bm8gZHJhZnQgYXMgeWV0OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tIGRldGVybWluaW5nIGhvdyBi ZXN0IHRvIGFwcGx5IEROUy1TRCBpbiB1bm1hbmFnZWQgaG9tZSBuZXR3b3JrczsgVGVkIGhhcyBh IGNvdXBsZSBvZiBlYXJseSBkcmFmdHMgaW4gdGhpcyBzcGFjZSB3aGljaCB3aWxsIGhvcGVmdWxs eSBoZWxwIGRyaXZlIHByb2R1Y3RpdmUgZGlzY3Vzc2lvbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPllvdeKAmWxsIGFsc28gaGF2ZSBu b3RpY2VkIHRoYXQgd2XigJl2ZSB1cGRhdGVkIHRoZSBXRyBtaWxlc3RvbmVzOyBhcG9sb2dpZXMg Zm9yIHRoZSByZXN1bHRpbmcgbGlzdCBzcGFtITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QmVzdCB3aXNoZXMsPGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+VGltIGFuZCBSYWxwaDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQ8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+ RE5TU0QgV0cgUHJvdmlzaW9uYWwgQWdlbmRhPC9iPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PC9zcGFuPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFz cz0iIj5JRVRGOTgsIENoaWNhZ288L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5p bmc6IG5vbmUiIGNsYXNzPSIiPlR1ZXNkYXkgMjh0aCBNYXJjaCAyMDE3PC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj4xNjo0MCAtIDE4OjQwIGxv Y2FsIHRpbWU8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+Q2hhaXJz4oCZIEludHJvZHVj dGlvbjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+ DQo8L3NwYW4+KGluYy4gdXBkYXRlZCBtaWxlc3RvbmVzKTxzcGFuIGNsYXNzPSJBcHBsZS10YWIt c3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+DQo8L3NwYW4+Q2hhaXJzLCA1IG1pbnM8L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg bWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5v bmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+RE5TIFB1c2ggTm90aWZpY2F0aW9uczxzcGFuIGNs YXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+DQo8L3NwYW4+U3R1 YXJ0IENoZXNoaXJlLCA1IG1pbnM8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5p bmc6IG5vbmUiIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWRuc3NkLXB1c2gtMTAiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWRuc3NkLXB1c2gtMTA8L2E+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj4oYW5kIGFjY29tcGFueWluZw0KPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zb3Atc2Vzc2lvbi1z aWduYWwtMDIiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZG5zb3Atc2Vzc2lvbi1zaWduYWwtMDI8L2E+IGluIGRuc29wIFdHKTwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0 OiAxNHB4OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9 IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5n OiBub25lIiBjbGFzcz0iIj5ETlMtU0QgRGlzY292ZXJ5IFByb3h5PHNwYW4gY2xhc3M9IkFwcGxl LXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4NCjwvc3Bhbj5TdHVhcnQgQ2hlc2hp cmUsIDUgbWluczxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNl OnByZSI+DQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBu b25lIiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1kbnNzZC1oeWJyaWQtMDYiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWRuc3NkLWh5YnJpZC0wNjwvYT48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdo dDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xh c3M9IiI+RE5TLVNEIEFkdmVydGlzaW5nIFByb3h5IC0gZGlzY3Vzc2lvbjxzcGFuIGNsYXNzPSJB cHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+DQo8L3NwYW4+MjAmbmJzcDtt aW5zPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJu aW5nOiBub25lIiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPlByaXZhY3kgRXh0ZW5zaW9ucyBmb3Ig RE5TLVNEPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl Ij4NCjwvc3Bhbj5DaHJpc3RpYW4gSHVpdGVtYSwgMTUgbWluczxzcGFuIGNsYXNzPSJBcHBsZS10 YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+DQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1wcml2YWN5LTAxIiBjbGFzcz0i Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1wcml2YWN5LTAx PC9hPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDog bm9ybWFsOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2Vy bmluZzogbm9uZSIgY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj5EZXZpY2UgUGFpcmluZyBVc2luZyBT aG9ydCBBdXRoZW50aWNhdGlvbiBTdHJpbmdzPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlIj4NCjwvc3Bhbj5DaHJpc3RpYW4gSHVpdGVtYSwgMTUgbWlu czwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9y bWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zc2QtcGFp cmluZy0wMSIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt ZG5zc2QtcGFpcmluZy0wMTwvYT48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIg Y2xhc3M9IiI+RE5TLVNEIERlcGxveW1lbnQgZm9yIGNhbXB1cy9lbnRlcnByaXNlIG5ldHdvcmtz IC0gQkNQIGRvY3VtZW50IGRpc2N1c3Npb248c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPg0KPC9zcGFuPjIwIG1pbnM8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L3B1c2F0ZXJpL2RyYWZ0LXB1c2F0ZXJpLWh5YnJpZHByb3h5LWltcGwvYmxvYi9tYXN0ZXIvZHJh ZnQtcHVzYXRlcmktZG5zc2QtaHlwLWltcGwudHh0IiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5j b20vcHVzYXRlcmkvZHJhZnQtcHVzYXRlcmktaHlicmlkcHJveHktaW1wbC9ibG9iL21hc3Rlci9k cmFmdC1wdXNhdGVyaS1kbnNzZC1oeXAtaW1wbC50eHQ8L2E+PC9zcGFuPjwvZGl2Pg0KPHAgc3R5 bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0OiAxNHB4OyIg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PHNwYW4g Y2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+PC9z cGFuPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvcD4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5 bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+U2ltcGxlIEhvbWVuZXQgTmFtaW5nIGFu ZCBTZXJ2aWNlIERpc2NvdmVyeSBBcmNoaXRlY3R1cmU8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPg0KPC9zcGFuPlRlZCBMZW1vbiwgMTUgbWluczwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRsZG0tc2ltcGxlLWhvbWVu ZXQtbmFtaW5nLTAwIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dGxkbS1zaW1wbGUtaG9tZW5ldC1uYW1pbmctMDA8L2E+PC9zcGFuPjwvZGl2Pg0KPHAgc3R5bGU9 Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+PC9zcGFu PjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvcD4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+U3RhdGVmdWwgTXVsdGktTGluayBETlMgU2Vy dmljZSBEaXNjb3Zlcnk8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1z cGFjZTpwcmUiPg0KPC9zcGFuPlRlZCBMZW1vbiwgMTAgbWluczwvc3Bhbj48L2Rpdj4NCjxwIHN0 eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsi IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZW1vbi1zdGF0ZWZ1bC1kbnNz ZC0wMCIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxlbW9uLXN0 YXRlZnVsLWRuc3NkLTAwPC9hPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7IiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJr aXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBu b25lIiBjbGFzcz0iIj5TdW1tYXJ5IG9mIGFjdGlvbnMgYW5kIGNsb3NlPHNwYW4gY2xhc3M9IkFw cGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4NCjwvc3Bhbj5DaGFpcnMsIDEw IG1pbnM8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5p bmc6IG5vbmUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DCC07B2D2F034B9BB1C482BD442AD4BEjiscacuk_-- From nobody Tue Mar 14 10:17:43 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 E80CC1329C6 for ; Tue, 14 Mar 2017 10:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 ZJBoyUxkeVSO for ; Tue, 14 Mar 2017 10:17:40 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0E11329C3 for ; Tue, 14 Mar 2017 10:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1489511858; bh=rUQ/45XPuchdykRgAQizvcwyzml9OxVjQrNwtnP0p6c=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=U3p7hY6fupY2BTlRyboeHUE4JcpbshSZ2f2OnJckL9t76brViKgwCrlg1X+boQD6MxMH1rD2PCHT+uRNLm3tcwJXbQi4s12zJPxLwNdtHGMl1AjjgqzDFXuhwL752bxGo4N5imQstRf2bIT/bpW/uvKT8OOXonntG3fzkUKEEr8= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0152.outbound.protection.outlook.com [213.199.180.152]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-63-POq7Ns0HN1yKQuKztN0_8A-1; Tue, 14 Mar 2017 17:17:34 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 17:17:33 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0977.010; Tue, 14 Mar 2017 17:17:32 +0000 From: Tim Chown To: Juergen Schoenwaelder CC: Andrew Sullivan , ops-dir , "dnssd@ietf.org" , "draft-ietf-dnssd-mdns-dns-interop.all@ietf.org" Thread-Topic: Partial review of draft-ietf-dnssd-mdns-dns-interop-04 Thread-Index: AQHSmAbyl0qojN3MA0i/ibIoNwSKcqGLFdSAgAYA1YCAA4cEAA== Date: Tue, 14 Mar 2017 17:17:32 +0000 Message-ID: <05AEC091-9D61-4064-90D3-BC89654940AE@jisc.ac.uk> References: <148897586598.20191.8422735308130046248@ietfa.amsl.com> <20170308154458.GU9646@dyn.com> <20170312112531.GC50035@elstar.local> In-Reply-To: <20170312112531.GC50035@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:T1KazxERbqUu3rzGmIaAqATPGhpZ7ktfezNiPUxx+UGz5C1TFU/aBfvVI/f4kFHXgGQSCV3RmLem+Exuf6zG30NM4USCJWp6kquyXVIQUnTU9OXSyubv3whFKRA+lc+K+No+ahQbfpFApi/vfwe9zTLz1cRHiOQCsBj4FTG11CKLq89mvEKbbNCE0FnY5g4060ao+UtfFw8ydwnZld2GIrfXeK5bBuTJHWUBfKLTftQ9Mn664pmhVqAD9yuU2DG5oMVKWt/55vSQhezitJcUfZJYv4ZcQrC3V6Yv6jyWxKkUTbVlEhWrFrawDhqimo4JRZdgpZwcOrXuz/5L13ueZw==; 20:1N5wwGPawcAJN86wE3ILW0dHgc1/zWCRPIqaJxEZ1SVk1Qiu4p0pEUkCAj58sT2uVERdPWrXIIQ+xnV17eJ0dTYNbO3AxXv5waCaaDH10boASmkWH0OeCAnCQgwwuFlls+D5QgBeLdIIqYHsICiWusosVWGlJgatMBBAWo7rnxA= x-ms-office365-filtering-correlation-id: 67d920bd-1410-4af8-a74e-08d46afe008d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1137; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(51444003)(24454002)(51914003)(8936002)(54906002)(3846002)(189998001)(3660700001)(3280700002)(106116001)(99286003)(81166006)(5660300001)(2906002)(4326008)(6512007)(8676002)(86362001)(229853002)(102836003)(2900100001)(50226002)(57306001)(230783001)(33656002)(7736002)(82746002)(6246003)(38730400002)(6116002)(6916009)(6436002)(83716003)(42882006)(74482002)(2950100002)(6486002)(36756003)(76176999)(50986999)(53936002)(53546007)(305945005)(6506006)(66066001)(110136004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <394FDFCFCFD70F48AC5519F7E8D5823C@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 17:17:32.7061 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: POq7Ns0HN1yKQuKztN0_8A-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [dnssd] Partial review of draft-ietf-dnssd-mdns-dns-interop-04 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.21 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 Mar 2017 17:17:42 -0000 SGksDQoNCj4gT24gMTIgTWFyIDIwMTcsIGF0IDExOjI1LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg PGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+IA0KPiBBbmRy ZXcsDQo+IA0KPiB5b3VyIHJlc3BvbnNlIGlzIGhlbHBmdWwgZm9yIG1lIHRvIHVuZGVyc3RhbmQg dGhpbmdzIGJldHRlci4gVGhlDQo+IHNpdHVhdGlvbiBpbmRlZWQgc2VlbXMgY29tcGxpY2F0ZWQu DQoNCg0KVGhlIGRpc2N1c3Npb24gYmVsb3cgaXMgdXNlZnVsLCBhbmQgSSBzdXNwZWN0IG1hbnkg cGVvcGxlIHdpbGwgaGF2ZSBzaW1pbGFyIGNvbW1lbnRzIHRvIEp1ZXJnZW4ncy4gT25lIHF1ZXN0 aW9uIGlzIHRoZXJlZm9yZSB3aGV0aGVyIGFkZGl0aW9uYWwgb3IgZGlmZmVyZW50IHdvcmRpbmcg d291bGQgaGVscCBiZXR0ZXIgc2V0IHRoZSBjb250ZXh0IG9mIHRoZSBkb2N1bWVudC4gSSB0aGlu ayB0aGUgbWVhdCBvZiB0aGUgdGV4dCBpcyBnb29kLCBhbmQgQW5kcmV3IGhhcyBkb25lIGEgZ3Jl YXQgam9iIGluIHB1bGxpbmcgdG9nZXRoZXIgdGhlIGlucHV0IHRoYXTigJlzIGJlZW4gbWFkZSwg YnV0IHdl4oCZdmUgYmVlbiBzdGFyaW5nIGF0IGl0IGZvciBzb21lIHRpbWUgbm93IGluIGRuc3Nk LCBhbmQgYXJlIHBlcmhhcHMgb3Zlcmx5IGZhbWlsaWFyIHdpdGggaXQuIA0KDQpBbnkgc3VnZ2Vz dGlvbnMgYXJlIHZlcnkgd2VsY29tZSENCg0KPiBPbiBXZWQsIE1hciAwOCwgMjAxNyBhdCAxMDo0 NDo1OUFNIC0wNTAwLCBBbmRyZXcgU3VsbGl2YW4gd3JvdGU6DQo+PiBIaSwNCj4+IA0KPj4gVGhh bmtzIGZvciB0aGUgcmV2aWV3LiAgSSB0aGluayB0aGVyZSBpcyBhbiBpc3N1ZSBoZXJlIHRoYXQg aXMNCj4+IGFwcGFyZW50bHkgbm90IGNsZWFyIGVub3VnaCB0byB5b3UgYXMgYSByZWFkZXIsIHNv IGl0J3MgcmVhbGx5IGhlbHBmdWwNCj4+IHRvIGxlYXJuIHRoYXQuICBJJ2QgbGlrZSB0byBmaWd1 cmUgb3V0IGhvdyB0byBtYWtlIGl0IGNsZWFyZXIuDQo+PiANCj4+IE9uIFdlZCwgTWFyIDA4LCAy MDE3IGF0IDA0OjI0OjI1QU0gLTA4MDAsIErDvHJnZW4gU2Now7Zud8OkbGRlciB3cm90ZToNCj4+ IA0KPj4+IERpc2NsYWltZXI6IEkgcmVncmV0IHRoYXQgRE5TIGRvZXMgbm90IHVzZSBVVEYtOCBp biBpdHMgbGFiZWxzLCB0byBtZQ0KPj4+ICwgYXMgYW4gb3V0c2lkZSBvYnNlcnZlciwgaXQgc2Vl bXMgSUROQSB3YXMgYSBiaWcgbWlzdGFrZS4gQnV0IGdpdmVuDQo+Pj4gdGhlIElFVEYgc3RhbmRh cmRzIHdlIGhhdmUsIGl0IHNlZW1zIG9uZSBoYXMgdG8gcHJvcGVybHkgSUROQSBlbmNvZGUNCj4+ PiBVVEYtOCBpbiBETlMgbGFiZWxzLiANCj4+IA0KPj4gVGhpcyBpc24ndCBleGFjdGx5IGNvcnJl Y3QsIGFuZCBJIHRoaW5rIHRoYXQgaXQgbWF5IGJlIHRoZSBzb3VyY2Ugb2YNCj4+IHRoZSBwcm9i bGVtIHlvdSBoYWQgd2l0aCB0aGUgZG9jdW1lbnQuDQo+PiANCj4+IEROUyBhcyBzdWNoIG1ha2Vz IGxpdGVyYWxseSBubyByZXN0cmljdGlvbnMgb24gd2hhdCAiY2hhcmFjdGVycyIgY2FuDQo+PiBh cHBlYXIgaW4gYSBsYWJlbCwgZXhjZXB0IGZvciBsZW5ndGguICBBIGxhYmVsIGNhbiBoYXZlIDYz IG9jdGV0cy4NCj4+IEFueSBvY3RldCBpcyBwZXJtaXR0ZWQuICBQZXJoYXBzIHVuZm9ydHVuYXRl bHksIGhvd2V2ZXIsIGluIHRoZQ0KPj4gb3JpZ2luYWwgc3BlY2lmaWNhdGlvbiBBU0NJSSB3YXMg dHJlYXRlZCBzcGVjaWFsbHkgaW4gdHdvIHdheXMuDQo+PiBGaXJzdCwgbGFiZWxzIGFyZSBtYXRj aGVkICJjYXNlIGluc2Vuc2l0aXZlbHkiIGluIEFTQ0lJLiAgU2Vjb25kLCBTVEQNCj4+IDEzIHJl Y29tbWVuZGVkIHRoZSBsZXR0ZXIsZGlnaXQsaHlwaGVuIHJ1bGUgZm9yIGxhYmVscyB0byBtYXhp bWlzZQ0KPj4gY29tcGF0aWJpbGl0eSB3aXRoIGRlcGxveWVkIGhvc3RuYW1lcy4gIEJlY2F1c2Ug U1REIDEzIHdhcyB3cml0dGVuDQo+PiBiZWZvcmUgUkZDIDIxMTkga2V5d29yZHMgd2VyZSBpbiB1 c2UsIHRoZSBkaXN0aW5jdGlvbnMgYW1vbmcgZ29vZA0KPj4gb3BlcmF0aW9uYWwgcHJhY3RpY2Ug YW5kIHByb3RvY29sIHJlc3RyaWN0aW9ucyB3YXMgbm90IGFsd2F5cyBjbGVhciB0bw0KPj4gZXZl cnkgcmVhZGVyLCBzbyBtYW55IHBlb3BsZSB1bmRlcnN0b29kIExESCB0byBiZSBhIEROUyByZXN0 cmljdGlvbiwNCj4+IGJ1dCBpdCB3YXNuJ3QuDQo+IA0KPiBUaGlzIHdhcyBjbGVhciB0byBtZSBz aW5jZSBJIGFtIHdlbGwgYXdhcmUgdGhhdCB0aGUgRE5TIHByb3RvY29sIHNoaXBzDQo+IG9jdGV0 cy4NCj4gDQo+PiBBcGFydCBmcm9tIHRoZSBzcGVjaWFsIHRyZWF0bWVudCBvZiBBU0NJSSwgRE5T IGFsc28gbWFrZXMgbm8gcnVsZXMNCj4+IGFib3V0IGNoYXJhY3RlciBzZXRzLiAgU28sIHRoZXJl J3Mgbm8gd2F5IHRvIHRlbGwsIGZvciBhIGdpdmVuIGxhYmVsLA0KPj4gd2hhdCBpdHMgZW5jb2Rp bmcgc2NoZW1lIGlzIC0tIFVURi04LCBKSVMsIElTTy04ODU5LW4sIG9yIHdoYXQgYWxsLg0KPiAN Cj4gWWVzLCBidXQgaGlzdG9yaWNhbGx5IChpZiBJIHVuZGVyc3RhbmQgdGhpbmdzIHJpZ2h0KSwg dGhlIGNoYXJhY3Rlcg0KPiBzZXQgd2FzIGVmZmVjdGl2ZWx5IHJlc3RyaWN0ZWQgdG8gTERIIChB U0NJSSkgLSB0aGUgcmVzdHJpY3Rpb24gd2FzDQo+IG5vdCBwYXJ0IG9mIHRoZSBwcm90b2NvbCBi dXQgaW1wb3NlZCBieSBvdGhlciAncmVjb21tZW5kYXRpb25zJy4NCj4gDQo+PiBJdCBpcyBiZWNh dXNlIG9mIHRoZSBhYm92ZSB0aGF0IHdlIGVuZGVkIHVwIHdpdGggSUROQS4gIE5vdGhpbmcgYWJv dXQNCj4+IElETkEgcHJldmVudHMgb3RoZXIgc2NoZW1lcyBmb3IgbGFiZWxzIChpbmNsdWRpbmcg dXNpbmcgY2hhcmFjdGVycw0KPj4gb3V0c2lkZSB0aGUgQVNDSUkgcmFuZ2UpLiAgVGhlIHBvc3Np YmlsaXRpZXMgYXJlIGRpc2N1c3NlZCBhdCBzb21lDQo+PiBsZW5ndGggaW4gUkZDIDYwNTUuDQo+ IA0KPiBXaXRoIGEgdGltZSBtYWNoaW5lIGF2YWlsYWJsZSwgd2Ugc2hvdWxkIHByb2JhYmx5IGhh dmUgbW92ZWQgZnJvbSBMREgNCj4gKEFTQ0lJKSB0byBVVEYtOCAob3IgYSBzdWJzZXQgb2YgVVRG LTgpLiBNdWx0aXBsZSBkaWZmZXJlbnQgY2hhcmFjdGVyDQo+IF9lbmNvZGluZ3NfIGluIHRoZSBs YWJlbCBzcGFjZSBjYW4ndCByZWFsbHkgYmUgYSBmZWF0dXJlLiBOb3RlIHRoYXQgSQ0KPiBjb25z aWRlciBmdXJ0aGVyIHJlc3RyaWN0aW9ucyAoaS5lLiwgdXNlIG9mIHdoaXRlIHNwYWNlKSBzb21l dGhpbmcNCj4gc2VwYXJhdGUgZnJvbSB0aGUgZW5jb2Rpbmcgc2NoZW1lIHVzZWQuDQo+IA0KPiBJ IHRoaW5rIEkgcmVjYWxsIHRoYXQgcGVvcGxlIHNhaWQgYmFjayBpbiBhIGRheSB0aGF0IG1vdmlu ZyBmcm9tIExESA0KPiB0byBVVEYtOCBtYXkgYmUgcmlza3kgc2luY2Ugd2UgZG8gbm90IGtub3cg d2hldGhlciBhbGwgRE5TDQo+IGltcGxlbWVudGF0aW9ucyBnb3QgdGhlICJETlMgc2hpcHMgb2N0 ZXRzIiB0aGluZyByaWdodC4gQW5kIHRoZXJlIG1heQ0KPiBiZSBzaXR1YXRpb25zIHdoZXJlIGVu dGVyaW5nIGEgVVRGLTggbmFtZSBjb3JyZWN0bHkgbWF5IG5vdCBiZQ0KPiBmZWFzaWJsZSBvbiBj ZXJ0YWluIGRldmljZXMuIExvb2tpbmcgYmFjayBpbiB0aW1lLCB0aGVzZSBtYXkgaGF2ZSBiZWVu DQo+IHZhbGlkIGNvbmNlcm5zIGJhY2sgdGhlbiBidXQgdGhleSBhcmUgbGlrZWx5IGxlc3Mgc28g dG9kYXkgYW5kIGluc3RlYWQNCj4gb2YgaGF2aW5nIGEgdHJhbnNpdGlvbiBwbGFuIHRvIGhhdmUg VVRGLTggZW5jb2RlZCBsYWJlbHMgd2Ugd2VudCBmb3IgYQ0KPiBzb2x1dGlvbiB0aGF0IGdpdmVz IHVzIGNvbXBsZXhpdHkgZm9yZXZlci4gW0FuZCB5ZXMsIEkgZG8gbm90IGtub3cgYWxsDQo+IHRo ZSBkZXRhaWxzIG9mIHRoZSBkaXNjdXNzaW9ucyBhbmQgc28gSSBhbSBsaWtlbHkgc3VtbWFyaXpp bmcgdGhpbmdzDQo+IHVwIHZlcnkgd3JvbmdseS5dIEJ1dCBmcm9tIGFuIG91dHNpZGVyIHBlcnNw ZWN0aXZlLCBpdCBzZWVtcyB0aGF0DQo+IGhhdmluZyAoaSkgYSB0cmFuc2l0aW9uIHBsYW4gdG8g VVRGLTggZW5jb2Rpbmcgb2YgbGFiZWxzIGFuZCAoaWkpIGENCj4gY2xlYXIgc2VwYXJhdGlvbiBv ZiBmdXJ0aGVyIGxhYmVsIHJlc3RyaWN0aW9ucyBmcm9tIHRoZSBlbmNvZGluZw0KPiBhc3BlY3Rz IHdvdWxkIGhhdmUgYmVlbiBkZXNpcmFibGUuDQo+IA0KPj4gQXQgdGhlIHNhbWUgdGltZSwgd2Ug a25vdyB0aGF0IHRoZSByb290IHpvbmUgYW5kIGEgdmVyeSBsYXJnZSBudW1iZXINCj4+IG9mIFRM RHMgKG1heWJlIGFsbCwgYnV0IEkgYmV0IG5vdCkgcmVzdHJpY3QgZGVsZWdhdGlvbnMgdG8gTERI LCBhbmQNCj4+IHRoYXQgdGhleSB1c2Ugc29tZSB2YXJpYXRpb24gb2YgSUROQSAoaW5jbHVkaW5n IG5vbi1JRVRGIElETkEgdmFyaWFudHMNCj4+IGJhc2VkIG9uIFVUUyM0NiAtLSB0aGlzIGlzIGhv dyBzb21lIFRMRHMgYWxsb3cgcmVnaXN0ZXJpbmcgZW1vamksDQo+PiBzaW5jZSB0aGV5IHdlcmVu J3QgImVtb2ppIiB3aGVuIElETkEyMDAzIGNhbWUgb3V0IGFuZCBtYW55IG9mIHRoZSBjb2RlDQo+ PiBwb2ludHMgd2VyZSB1bmRlZmluZWQgdW5kZXIgVW5pY29kZSAzLjIuICBFbW9qaSBhcmUgRElT QUxMT1dFRCB1bmRlcg0KPj4gSUROQTIwMDggYmVjYXVzZSB0aGV5J3JlIG5vdCAibGV0dGVycyBv ciBkaWdpdHMiIGluIGFueSB3cml0aW5nDQo+PiBzeXN0ZW0pLiAgU28sIGdpdmVuIHRoZSBkaXN0 cmlidXRlZCBhZG1pbmlzdHJhdGlvbiBvZiB0aGUgRE5TLCB0aGVyZQ0KPj4gaXMgbm8gd2F5IHRv IGJlIHN1cmUgaG93IGEgZ2l2ZW4gb2N0ZXQgc2VxdWVuY2Ugb3VnaHQgdG8gYmUNCj4+IGludGVy cHJldGVkLCBidXQgd2UgY2FuIGJlIGZhaXJseSBzdXJlIHRoYXQgc29tZSBhZG1pbmlzdHJhdG9y cyBvZg0KPj4gc29tZSB6b25lcyB3aWxsIGRlZmluaXRlbHkgbm90IHBlcm1pdCBVVEYtOCBsYWJl bHMgaW4gdGhlaXIgem9uZXMuDQo+IA0KPiBXZWxsLCBvYnZpb3VzbHksIHRoaXMgaXMgdGhlIGNs dW5reSByZXN1bHQgd2UgaGF2ZSBub3cuDQo+IA0KPj4gVGhpcyBpcyB0aGUgcHJvYmxlbSB0aGUg SS1EIGlzIGludGVuZGluZyB0byBoaWdobGlnaHQsIGFuZCBpdCBzb3VuZHMNCj4+IGxpa2UgaXQg d2Fzbid0IGNsZWFyIHRvIHlvdS4gIElzIGFueSBvZiB0aGUgYWJvdmUgY2xlYXJlcj8gIFdvdWxk IGFueQ0KPj4gbW9yZSBpbnRyb2R1Y3RvcnkgbWF0ZXJpYWwgaGVscCB0byBtYWtlIHRoaXMgcGxh aW4/DQo+IA0KPiBGb3IgbWUgcGVyc29uYWxseSwgaXQgd291bGQgaGF2ZSBiZWVuIGdvb2QgdG8g a25vdyBtb3JlIGFib3V0IHdoYXQgaXMNCj4gb3V0IHRoZXJlLiBJIHVuZGVyc3RhbmQgdHJhZGl0 aW9uYWwgTERIIGxhYmVscyBhbmQgSSB1bmRlcnN0YW5kDQo+IElETkEyMDAzIGFuZCBJRE5BMjAw OCBsYWJlbHMuIEkgdW5kZXJzdGFuZCB0aGF0IG1ETlMgc2F5cyBVVEYtOCBhbmQNCj4gcHJldHR5 IG11Y2ggbm8gcmVzdHJpY3Rpb25zIG9uIGluc3RhbmNlIHBvcnRpb24gb2YgYSBzZXJ2aWNlIG5h bWUuDQo+IEFyZSB0aGVyZSBzaWduaWZpY2FudCBkZXBsb3ltZW50cyBvdXQgdGhlcmUgdGhhdCB1 c2Ugb3RoZXIgZW5jb2RpbmdzDQo+IG9yIHJlc3RyaWN0aW9ucz8NCj4gDQo+Pj4gd291bGQgdGhh dCBiZT8gSSBsb29rZWQgdXAgUkZDIDYwNTUgYW5kIEkgYW0gc3VycHJpc2VkIHRvIHJlYWQgdGV4 dA0KPj4+IGFib3V0ICdpbnRlbGxpZ2VudCAoc3R1YikgcmVzb2x2ZXInIHRoZXJlIGFzIHRoaXMg c2VlbXMgdG8gYmUgYXNraW5nDQo+Pj4gZm9yIHRyb3VibGUuIA0KPj4gDQo+PiBZZXMgOikgVGhh dCdzIHRoZSB0cm91YmxlIEkgdGhpbmsgd2UncmUgaW4sIGFuZCBpdCdzIHdoeSBJIHdvcmtlZCBv bg0KPj4gdGhpcyBJLUQgaW4gdGhlIGZpcnN0IHBsYWNlLg0KPj4gDQo+Pj4gVG8gbWUsIGl0IHNv dW5kcyBsaWtlIHlvdSBhcmUgc2F5aW5nICdzb21lIHBvcnRpb25zIG9mDQo+Pj4gdGhlIG5hbWUg aGllcmFyY2h5IG1heSB1c2UgcmF3IFVURi04IGxhYmVscyB3aGlsZSBvdGhlciBwb3J0aW9ucyBt YXkNCj4+PiBub3QgYW5kIHdlIGRvIG5vdCB0ZWxsIHlvdSBob3cgdG8gc2V0IHRoZW0gYXBwYXJ0 IGluIGEgcmVsaWFibGUNCj4+PiB3YXknLiBJZiB0aGlzIGlzIHRoZSBhcHByb2FjaCwgdGhlbiB0 aGUgYXBwcm9hY2ggaXMgaW4gbXkgcGVyc29uYWwNCj4+PiB2aWV3IGJyb2tlbi4gKEFuZCBwbGVh c2UgcmVjYWxsIHRoZSBkaXNjbGFpbWVyIGFib3ZlLikNCj4+IA0KPj4gSXQgbWF5IGJlIGJyb2tl biwgYnV0IGl0IGlzIHRoZSByZWFsaXR5IGluIGEgZGlzdHJpYnV0ZWQgc3lzdGVtIHdpdGgNCj4+ IGRpc3RyaWJ1dGVkIGFkbWluaXN0cmF0aW9uLiAgT25lIGNhbm5vdCBtYWtlIHJ1bGVzIGFib3V0 IHdoYXQgb3RoZXINCj4+IHBlb3BsZSBwdXQgaW4gdGhlaXIgem9uZXMsIGFuZCB0aGUgRE5TIGlz IGFscmVhZHkgY2xlYXIgdGhhdCBhbnkgb2N0ZXQNCj4+IGF0IGFsbCBpcyBwZXJtaXR0ZWQgaW4g dGhlIEROUy4NCj4gDQo+IFRoZSBwcm90b2NvbCBzaGlwcyBvY3RldHMuIFRoZSBxdWVzdGlvbiBp cyBob3cgdG8gaW50ZXJwcmV0IHRoZW0uIElmDQo+IHRoZXJlIHdvdWxkIGJlIGFncmVlbWVudCB0 aGF0IHRoZSBvY3RldHMgYnkgZGVmYXVsdCByZXByZXNlbnQgVVRGLTgNCj4gZW5jb2RlZCBjaGFy YWN0ZXJzIGxpZmUgd291bGQgc3RhcnQgdG8gYmUgc29tZXdoYXQgc2ltcGxlci4gVGhpcyB3b3Vs ZA0KPiBzb2x2ZSB0aGUgZW5jb2RpbmcgcGFydCwgaXQgZG9lcyBub3Qgc29sdmUgdGhlICd3aGlj aCByZXN0cmljdGlvbnMNCj4gYXBwbHkgdG8gdGhpcyBsYWJlbCBwYXJ0Jy4gT0ssIEkgYW0gaWdu b3JhbnQgb2YgdGhlIGNvbXBsZXhpdHkgb2YNCj4gZGVwbG95aW5nIHRoaXMgYnV0IGEgZGVjZW50 IHRyYW5zaXRpb24gcGxhbiB0byBzb21ldGhpbmcgc2ltcGxlciBtYXkNCj4gYmUgYmV0dGVyIGxv bmcgdGVybSB0aGFuIG1vcmUgbGF5ZXJlcyBvZiB0aGluZ3MgdGhhdCBkbyBub3QgcGxheSB3ZWxs DQo+IHRvZ2V0aGVyLg0KPiANCj4+PiBJbiBzZWN0aW9uIDMsIHdoYXQgZG9lcyB0aGUgdGVybSAn aW1wbGljYXRlZCcgbWVhbj8NCj4+IA0KPj4gV291bGQgImludm9sdmVkIiBtYWtlIGl0IGNsZWFy ZXIgdG8geW91PyAgVGhlIHBvaW50IGlzIHRoYXQgZGlmZmVyZW50DQo+PiBwb3J0aW9ucyBvZiBh IEROUy1TRCBuYW1lIGhhdmUgZGlmZmVyZW50IHByb3BlcnRpZXMsIGFuZCBvbmx5IHNvbWUgb2YN Cj4+IHRob3NlIGFyZSBnb2luZyB0byBoYXZlIHBvdGVudGlhbGx5IGFtYmlndW91cyBpMThuIGVu Y29kaW5ncyBpbiB0aGUNCj4+IEROUy4gIA0KDQpQZXJoYXBzIOKAnGluY2x1ZGVk4oCdIHdvcmtz IGJldHRlciB0aGFuIOKAnGltcGxpY2F0ZWQiLCBidXQgdGhhdOKAmXMgcHVyZSBwZXJzb25hbCBw cmVmZXJlbmNlLg0KDQo+Pj4gV2hhdCBJIGRvIG5vdCB1bmRlcnN0YW5kOiBXaHkgaXMgaXQgZGVz aXJhYmxlIHRvIHRyZWF0IEROUyBsYWJlbHMNCj4+PiB0aGF0DQo+Pj4gY2FycnkgRE5TLVNEIFNl cnZpY2UgSW5zdGFuY2UgTmFtZXMgZGlmZmVyZW50IHRoYW4gYW55IG90aGVyIGxhYmVscw0KPj4+ IHRoYXQgbWF5IGNvbnRhaW4gVVRGLTggY2hhcmFjdGVycz8gDQo+PiANCj4+IEJlY2F1c2UgRE5T LVNEIHNheXMgdGhhdCB0aGUgbGFiZWxzIHNob3VsZCBiZSByYXcgVVRGLTggaW4gdGhlIEROUywN Cj4+IGFuZCBiZWNhdXNlIG9mIElETkEgc29tZSB6b25lcyBoYXZlIGEgcG9saWN5IHdoZXJlIHJh dyBVVEYtOCBpcyBub3QNCj4+IHBlcm1pdHRlZCAoYW5kIHNvbWUgcmVzb2x2ZXJzIG1heSBhdXRv bWF0aWNhbGx5IGNvbnZlcnQgVS1sYWJlbHMgdG8NCj4+IEEtbGFiZWxzKS4NCj4gDQo+IFllcywg c291bmRzIGxpa2UgYSBkZWNlbnQgY29uZmxpY3QgYXNraW5nIGZvciBzdXJwcmlzZXMuDQoNCkJl c3Qgd2lzaGVzLA0KVGltIChkbnNzZCBjby1jaGFpcikgDQoNCg== From nobody Tue Mar 14 12:09:30 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 8C988129665; Tue, 14 Mar 2017 12:09:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles To: Cc: dnssd@ietf.org, ietf@ietf.org, draft-ietf-dnssd-mdns-dns-interop.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148951856846.2289.9860804626640095928@ietfa.amsl.com> Date: Tue, 14 Mar 2017 12:09:28 -0700 Archived-At: Subject: [dnssd] Review of draft-ietf-dnssd-mdns-dns-interop-04 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 Mar 2017 19:09:28 -0000 Reviewer: Ines Robles Review result: Ready Hi, I have read the draft. The document provides a description of the requirements for a profile for label interoperation. In IoT, networks and nodes, in general, have constrained resources. Related to the topic of the draft in review, several aspects should be considered from IoT point of view, such as: - Type of devices that have insufficient resources to run DNS-SD/mDNS [1] (Some running code [7]). The work in [2][3] depicts an autoconfiguration scheme for the global (or local) DNS names of IoT devices. It uses an specific DNS Name Format (unique_id.object_identifier.OID.domain_name). - Resource Directory (RD): A web entity that stores information about web resources and implements the REST interfaces for registration and lookup of resources. A mapping between CoRE Link Format attributes and DNS-Based Service Discovery aspects (mapping ins to , Mapping rt to and Domain mapping) is descripted in version 9 of RD draft [4]. - Optimization of DNS-SD: A proposal for an optimization of DNS-SD query using TXT records is descripted in [5]. - DNS Message Compression [6], implemented in uBonjour Contiki. Thus, new work (or updates) is needed to set the requirements for label interoperation in this type of environments. I understand that this is out of scope of dns-interop draft. So, what about to add in the dns-interop draft some text like: "Related to constrained environments, work is ongoing such as autoconfiguration[2], optimization of DNS-SD [5] and DNS message compression [6] that would help to get an efficient selection of labels for DNS and other resolution systems." Hope that it helps. Cheers, Ines. [1] https://www.ietf.org/mail-archive/web/dnssd/current/msg00589.html [2] https://tools.ietf.org/html/draft-jeong-its-iot-dns-autoconf-01 [3] Lee, Sejun, Jaehoon Paul Jeong, and Jung-Soo Park. "DNSNA: DNS name autoconfiguration for Internet of Things devices." Advanced Communication Technology (ICACT), 2016 18th International Conference on. IEEE, 2016. [4] https://tools.ietf.org/html/draft-ietf-core-resource-directory-09 [5] https://tools.ietf.org/html/draft-aggarwal-dnssd-optimize-query-00 [6] Klauck, Ronny, and Michael Kirsche. "Enhanced DNS message compression-Optimizing mDNS/DNS-SD for the use in 6LoWPANs." Pervasive Computing and Communications Workshops (PERCOM Workshops), 2013 IEEE International Conference on. IEEE, 2013. [7] https://github.com/Agile-IoT/awesome-open-iot#mdns--bonjour From nobody Wed Mar 15 03:32:26 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 BB0AE129A9F; Wed, 15 Mar 2017 03:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk 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 roeHxj5Ex1Cs; Wed, 15 Mar 2017 03:32:22 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F44129AAA; Wed, 15 Mar 2017 03:32:21 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id v2FAWGBN024369; Wed, 15 Mar 2017 10:32:16 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk v2FAWGBN024369 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1489573937; bh=22tYXeBBj4WhjWt778H1NPIDgEY=; h=From:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; b=ARbIlG6+NnbTaXErwuFV/STMNrnSaJyMwsBVmf5cIw4Od+SdF12AXgEPLD7UlPpwP QyXasVr3GOAFgHVThpsCCygK/1mfarqo2EG5HU8djnedScwX9KfEUYFUdYX0EHJWSm L5bv5RxCcw7dxBQF52w7K4F/zPOcoIKc1pc2uAK0= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id y2EAWG1640403462z3 ret-id none; Wed, 15 Mar 2017 10:32:16 +0000 Received: from [10.1.11.164] (firewall-lho-ext.management.janet.ac.uk [194.82.140.195]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id v2FAWB4D002316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Mar 2017 10:32:11 GMT From: Tim Chown Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_A8FB0ECA-1BD9-4521-9700-E6CFD83556CA" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Mar 2017 10:32:11 +0000 In-Reply-To: <148951856846.2289.9860804626640095928@ietfa.amsl.com> Cc: Iot-dir@ietf.org, dnssd@ietf.org, ietf@ietf.org, draft-ietf-dnssd-mdns-dns-interop.all@ietf.org To: Ines Robles , Ralph Droms References: <148951856846.2289.9860804626640095928@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=y2EAWG164040346200; tid=y2EAWG1640403462z3; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: v2FAWGBN024369 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-mdns-dns-interop-04 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 Mar 2017 10:32:25 -0000 --Apple-Mail=_A8FB0ECA-1BD9-4521-9700-E6CFD83556CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ines, Many thanks for this review. As you=E2=80=99ve implictly noted, the focus of = draft-ietf-dnssd-mdns-dns-interop-04 is interoperability of the labels = used, primarily between unicast and multicast DNS. You raise some very good points about the efficiency of mDNS/DNS-SD, = particularly in constrained environments. This isn=E2=80=99t something = we=E2=80=99ve covered in any detail as yet in the dnssd WG, aside from = draft-aggarwal-dnssd-optimize-query-00 being presented a few IETFs ago, = but DNS-SD in mesh networks is in our charter = (https://datatracker.ietf.org/wg/dnssd/charter/ = ). To date we=E2=80=99ve = focused on enterprise and home networks as managed and unmanaged = multi-link IP environments.=20 It would be useful to explore potential issues with DNS-SD in = constrained environments further. Is there someone who might be at = Chicago and able to raise this issue in our meeting, briefly? We could = make some time for this topic. That might then help seed further work. Tim (dnssd co-chair) > On 14 Mar 2017, at 19:09, Ines Robles = wrote: >=20 > Reviewer: Ines Robles > Review result: Ready >=20 > Hi, >=20 > I have read the draft. The document provides a description of the > requirements for a profile for label interoperation. >=20 > In IoT, networks and nodes, in general, have constrained resources. > Related to the topic of the draft in review, several aspects should be > considered from IoT point of view, such as: >=20 > - Type of devices that have insufficient resources to run DNS-SD/mDNS > [1] (Some running code [7]). The work in [2][3] depicts an > autoconfiguration scheme for the global (or local) DNS names of IoT > devices. It uses an specific DNS Name Format > (unique_id.object_identifier.OID.domain_name). >=20 > - Resource Directory (RD): A web entity that stores information about > web resources and implements the REST interfaces for registration and > lookup of resources. A mapping between CoRE Link Format attributes and > DNS-Based Service Discovery aspects (mapping ins to , > Mapping rt to and Domain mapping) is descripted in > version 9 of RD draft [4].=20 >=20 > - Optimization of DNS-SD: A proposal for an optimization of DNS-SD > query using TXT records is descripted in [5]. >=20 > - DNS Message Compression [6], implemented in uBonjour Contiki. >=20 > Thus, new work (or updates) is needed to set the requirements for > label interoperation in this type of environments. I understand that > this is out of scope of dns-interop draft. So, what about to add in > the dns-interop draft some text like: >=20 > "Related to constrained environments, work is ongoing such as > autoconfiguration[2], optimization of DNS-SD [5] and DNS message > compression [6] that would help to get an efficient selection of > labels for DNS and other resolution systems." >=20 > Hope that it helps. >=20 > Cheers, >=20 > Ines. >=20 >=20 > [1] https://www.ietf.org/mail-archive/web/dnssd/current/msg00589.html > [2] https://tools.ietf.org/html/draft-jeong-its-iot-dns-autoconf-01 > [3] Lee, Sejun, Jaehoon Paul Jeong, and Jung-Soo Park. "DNSNA: DNS > name autoconfiguration for Internet of Things devices." Advanced > Communication Technology (ICACT), 2016 18th International Conference > on. IEEE, 2016. > [4] https://tools.ietf.org/html/draft-ietf-core-resource-directory-09 > [5] > https://tools.ietf.org/html/draft-aggarwal-dnssd-optimize-query-00 > [6] Klauck, Ronny, and Michael Kirsche. "Enhanced DNS message > compression-Optimizing mDNS/DNS-SD for the use in 6LoWPANs." Pervasive > Computing and Communications Workshops (PERCOM Workshops), 2013 IEEE > International Conference on. IEEE, 2013. > [7] https://github.com/Agile-IoT/awesome-open-iot#mdns--bonjour >=20 --Apple-Mail=_A8FB0ECA-1BD9-4521-9700-E6CFD83556CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Ines,

Many thanks for this review.

As you=E2=80=99ve implictly noted, the = focus of draft-ietf-dnssd-mdns-dns-interop-04 is interoperability = of the labels used, primarily between unicast and multicast = DNS.

You raise = some very good points about the efficiency of mDNS/DNS-SD, particularly = in constrained environments. This isn=E2=80=99t something we=E2=80=99ve = covered in any detail as yet in the dnssd WG, aside from = draft-aggarwal-dnssd-optimize-query-00 being presented a few IETFs ago, = but DNS-SD in mesh networks is in our charter (https://datatracker.ietf.org/wg/dnssd/charter/). To date = we=E2=80=99ve focused on enterprise and home networks as managed and = unmanaged multi-link IP environments. 

It would be useful to explore potential = issues with DNS-SD in constrained environments further. Is there someone = who might be at Chicago and able to raise this issue in our meeting, = briefly?  We could make some time for this topic. That might then = help seed further work.

Tim (dnssd co-chair)

On 14 Mar 2017, at 19:09, Ines Robles <maria.ines.robles@ericsson.com> wrote:

Reviewer: Ines Robles
Review result: Ready

Hi,

I have read = the draft. The document provides a description of the
requirements for a profile for label interoperation.

In IoT, networks and nodes, in general, have = constrained resources.
Related to the topic of the draft = in review, several aspects should be
considered from IoT = point of view, such as:

- Type of devices = that have insufficient resources to run DNS-SD/mDNS
[1] = (Some running code [7]). The work in [2][3] depicts an
autoconfiguration scheme for the global (or local) DNS names = of IoT
devices. It uses an specific DNS Name Format
(unique_id.object_identifier.OID.domain_name).

- Resource Directory (RD): A web entity that = stores information about
web resources and implements the = REST interfaces for registration and
lookup of resources. = A mapping between CoRE Link Format attributes and
DNS-Based = Service Discovery aspects (mapping ins to <Instance>,
Mapping rt to <ServiceType> and Domain mapping) is = descripted in
version 9 of RD draft [4].

- Optimization of DNS-SD: A proposal for an optimization of = DNS-SD
query using TXT records is descripted in [5].

- DNS Message Compression [6], implemented in = uBonjour Contiki.

Thus, new work (or = updates) is needed to set the requirements for
label = interoperation in this type of environments. I understand that
this is out of scope of dns-interop draft. So, what about to = add in
the dns-interop draft some text like:

"Related to constrained environments, work is = ongoing such as
autoconfiguration[2], optimization of = DNS-SD [5] and DNS message
compression [6] that would help = to get an efficient selection of
labels for DNS and other = resolution systems."

Hope that it helps.

Cheers,

Ines.


[1] https://www.ietf.org/mail-archive/web/dnssd/current/msg00589.ht= ml
[2] https://tools.ietf.org/html/draft-jeong-its-iot-dns-autoconf-01=
[3] Lee, Sejun, Jaehoon Paul Jeong, and Jung-Soo = Park. "DNSNA: DNS
name autoconfiguration for Internet of = Things devices." Advanced
Communication Technology = (ICACT), 2016 18th International Conference
on. IEEE, = 2016.
[4] https://tools.ietf.org/html/draft-ietf-core-resource-directory-= 09
[5]
https://tools.ietf.org/html/draft-aggarwal-dnssd-optimize-query= -00
[6] Klauck, Ronny, and Michael Kirsche. "Enhanced = DNS message
compression-Optimizing mDNS/DNS-SD for the use = in 6LoWPANs." Pervasive
Computing and Communications = Workshops (PERCOM Workshops), 2013 IEEE
International = Conference on. IEEE, 2013.
[7] = https://github.com/Agile-IoT/awesome-open-iot#mdns--bonjour


= --Apple-Mail=_A8FB0ECA-1BD9-4521-9700-E6CFD83556CA-- From nobody Wed Mar 15 09:32: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 36B3A131710; Wed, 15 Mar 2017 09:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, 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=googlemail.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 42t7DUzo6sB8; Wed, 15 Mar 2017 09:32:10 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 EDE221316A1; Wed, 15 Mar 2017 09:32:08 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id r136so11539630vke.1; Wed, 15 Mar 2017 09:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EMntoE2nKmGHrWGxrIudCapKucB3AOF2JY9i1VNKD+w=; b=uumxWlB+bWcLcreVO4JWCYjuWAmAc9J5wVnvIxpKeBr5M0kaAust2TUoEVlWL7UzIt Y9pyxf46BZqOVro59BOuGD4Xw6uG73wzbRNN0EC6GI1TYDJEkWIRS1z7mthP8l2NCON+ /tDjtFl9KGx53OubOv0uMICQH3y1QUkKoF9SmtUZKvObwD+giWc3/R8nMmRyiLSGS7k6 eFsRr0jItmlBkpnu3A6ZXm1ESt2P2EN6Ll83H3yExzb+99t3SeDAm9QnAie/76ziBOZ5 x9wIx2ORwMzIOyMn56rPK95tioRg4Wv5yjgc0TUpWKFXbQ19adimBTP0zgYMV+442RkH i+Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EMntoE2nKmGHrWGxrIudCapKucB3AOF2JY9i1VNKD+w=; b=bfubUaan8K/IN6E//Xj3hTVJSb7mzn1lkNsBb5KAxSxQV/OcMxP5DsJTj6LMj9qnAV tCm2mzyrtQS12u6pHCpKy7epfm9ICeXj0iy4afJLZLtbu3R7fOxMJCRe3gF9eWb0AWsa Zo8n9AZGENdkAoqu6PWj2M7xmB/enccFHbnw4HUdPfFEcxg7TC2wTEsyQqKj0KHZJSkK RcQJ6OugtB8lf3jbxDdxmtZJ7xS2qmrswtq/+4iR8s5w2XB5auzTAn085xyaJKxq9Sg8 ng62ExrZn5/tBUFZQ+hhkkGxWNVycvoV7VmTBb0AuTbmbgleeGn7KMQdjoy6oDFNUjhw 1+6g== X-Gm-Message-State: AFeK/H3i+3RSgrUJnFMT/eVbqhFWJLXAIxMXpRH8Ba26Gx3nr6zUEQ5hX7JBmCotJFcrctJcKjRww3lWfIt6PA== X-Received: by 10.31.72.67 with SMTP id v64mr1395895vka.37.1489595527979; Wed, 15 Mar 2017 09:32:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.85.130 with HTTP; Wed, 15 Mar 2017 09:32:07 -0700 (PDT) In-Reply-To: References: <148951856846.2289.9860804626640095928@ietfa.amsl.com> From: Ines Robles Date: Wed, 15 Mar 2017 13:32:07 -0300 Message-ID: To: Tim Chown Cc: Ines Robles , Ralph Droms , dnssd@ietf.org, ietf , "iot-dir@ietf.org" , draft-ietf-dnssd-mdns-dns-interop.all@ietf.org, peter van der Stok Content-Type: multipart/alternative; boundary=001a114db19e4dea24054ac77c0b Archived-At: Subject: Re: [dnssd] [IoT-DIR] Review of draft-ietf-dnssd-mdns-dns-interop-04 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 Mar 2017 16:32:14 -0000 --001a114db19e4dea24054ac77c0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tim, We (Peter van der Stok and me ) are willing to present it. How much time would we have? We might need 10 min, but we can adapt it to less time though, since the agenda is already full. Thank you, Peter and Ines. 2017-03-15 7:32 GMT-03:00 Tim Chown : > Hi Ines, > > Many thanks for this review. > > As you=E2=80=99ve implictly noted, the focus of draft-ietf-dnssd-mdns-dns= -interop-04 > is interoperability of the labels used, primarily between unicast and > multicast DNS. > > You raise some very good points about the efficiency of mDNS/DNS-SD, > particularly in constrained environments. This isn=E2=80=99t something we= =E2=80=99ve > covered in any detail as yet in the dnssd WG, aside from > draft-aggarwal-dnssd-optimize-query-00 being presented a few IETFs ago, > but DNS-SD in mesh networks is in our charter ( > https://datatracker.ietf.org/wg/dnssd/charter/). To date we=E2=80=99ve fo= cused on > enterprise and home networks as managed and unmanaged multi-link IP > environments. > > It would be useful to explore potential issues with DNS-SD in constrained > environments further. Is there someone who might be at Chicago and able t= o > raise this issue in our meeting, briefly? We could make some time for th= is > topic. That might then help seed further work. > > Tim (dnssd co-chair) > > On 14 Mar 2017, at 19:09, Ines Robles > wrote: > > Reviewer: Ines Robles > Review result: Ready > > Hi, > > I have read the draft. The document provides a description of the > requirements for a profile for label interoperation. > > In IoT, networks and nodes, in general, have constrained resources. > Related to the topic of the draft in review, several aspects should be > considered from IoT point of view, such as: > > - Type of devices that have insufficient resources to run DNS-SD/mDNS > [1] (Some running code [7]). The work in [2][3] depicts an > autoconfiguration scheme for the global (or local) DNS names of IoT > devices. It uses an specific DNS Name Format > (unique_id.object_identifier.OID.domain_name). > > - Resource Directory (RD): A web entity that stores information about > web resources and implements the REST interfaces for registration and > lookup of resources. A mapping between CoRE Link Format attributes and > DNS-Based Service Discovery aspects (mapping ins to , > Mapping rt to and Domain mapping) is descripted in > version 9 of RD draft [4]. > > - Optimization of DNS-SD: A proposal for an optimization of DNS-SD > query using TXT records is descripted in [5]. > > - DNS Message Compression [6], implemented in uBonjour Contiki. > > Thus, new work (or updates) is needed to set the requirements for > label interoperation in this type of environments. I understand that > this is out of scope of dns-interop draft. So, what about to add in > the dns-interop draft some text like: > > "Related to constrained environments, work is ongoing such as > autoconfiguration[2], optimization of DNS-SD [5] and DNS message > compression [6] that would help to get an efficient selection of > labels for DNS and other resolution systems." > > Hope that it helps. > > Cheers, > > Ines. > > > [1] https://www.ietf.org/mail-archive/web/dnssd/current/msg00589.html > [2] https://tools.ietf.org/html/draft-jeong-its-iot-dns-autoconf-01 > [3] Lee, Sejun, Jaehoon Paul Jeong, and Jung-Soo Park. "DNSNA: DNS > name autoconfiguration for Internet of Things devices." Advanced > Communication Technology (ICACT), 2016 18th International Conference > on. IEEE, 2016. > [4] https://tools.ietf.org/html/draft-ietf-core-resource-directory-09 > [5] > https://tools.ietf.org/html/draft-aggarwal-dnssd-optimize-query-00 > [6] Klauck, Ronny, and Michael Kirsche. "Enhanced DNS message > compression-Optimizing mDNS/DNS-SD for the use in 6LoWPANs." Pervasive > Computing and Communications Workshops (PERCOM Workshops), 2013 IEEE > International Conference on. IEEE, 2013. > [7] https://github.com/Agile-IoT/awesome-open-iot#mdns--bonjour > > > > _______________________________________________ > IoT-DIR mailing list > IoT-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/iot-dir > > --001a114db19e4dea24054ac77c0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,

We (Peter van der Stok and= me ) are willing to present it.

How much time= would we have? We might need 10 min, but we can adapt it to less time thou= gh, since the agenda is already full.

Thank you,

Peter and Ines.

2017-03-15 7:32 GMT-03:00 Tim Chown <t= jc@ecs.soton.ac.uk>:
Hi Ines,

Many thanks for t= his review.

As you=E2=80=99ve implictly noted, the= focus of=C2=A0draft-ietf-dnssd-mdns-dns-interop-04 is interoperabilit= y of the labels used, primarily between unicast and multicast DNS.

You raise some very good points about the efficiency of mD= NS/DNS-SD, particularly in constrained environments. This isn=E2=80=99t som= ething we=E2=80=99ve covered in any detail as yet in the dnssd WG, aside fr= om draft-aggarwal-dnssd-optimize-query-00 being presented a few IETFs = ago, but DNS-SD in mesh networks is in our charter (https://datatracker.i= etf.org/wg/dnssd/charter/). To date we=E2=80=99ve focused on enter= prise and home networks as managed and unmanaged multi-link IP environments= .=C2=A0

It would be useful to explore potential is= sues with DNS-SD in constrained environments further. Is there someone who = might be at Chicago and able to raise this issue in our meeting, briefly?= =C2=A0 We could make some time for this topic. That might then help seed fu= rther work.

Tim (dnssd co-chair)

=
On 14 Mar 2017, at 19:09, Ines Robles &= lt;mari= a.ines.robles@ericsson.com> wrote:

Reviewer: Ines Robles
R= eview result: Ready

Hi,

I have read the draft. The document p= rovides a description of the
requirements for a profile for label intero= peration.

In IoT, networks and nodes, in general, have constrained r= esources.
Related to the topic of the draft in review, several aspects s= hould be
considered from IoT point of view, such as:

- Type of de= vices that have insufficient resources to run DNS-SD/mDNS
[1] (Some runn= ing code [7]). The work in [2][3] depicts an
autoconfiguration scheme fo= r the global (or local) DNS names of IoT
devices. It uses an specific DN= S Name Format
(unique_id.object_identifier.OID.domain_name).
- Resource Directory (RD): A web entity that stores information about
w= eb resources and implements the REST interfaces for registration and
loo= kup of resources. A mapping between CoRE Link Format attributes and
DNS-= Based Service Discovery aspects (mapping ins to <Instance>,
Mappin= g rt to <ServiceType> and Domain mapping) is descripted in
version= 9 of RD draft [4].

- Optimization of DNS-SD: A proposal for an opt= imization of DNS-SD
query using TXT records is descripted in [5].
- DNS Message Compression [6], implemented in uBonjour Contiki.

Thu= s, new work (or updates) is needed to set the requirements for
label int= eroperation in this type of environments. I understand that
this is out = of scope of dns-interop draft. So, what about to add in
the dns-interop = draft some text like:

"Related to constrained environments, wor= k is ongoing such as
autoconfiguration[2], optimization of DNS-SD [5] an= d DNS message
compression [6] that would help to get an efficient select= ion of
labels for DNS and other resolution systems."

Hope th= at it helps.

Cheers,

Ines.


[1] https://www.ietf.org/mail-archive/web/dnssd/current/msg00589.ht= ml
[2] https://tools.ietf.org/html/draft-jeo= ng-its-iot-dns-autoconf-01
[3] Lee, Sejun, Jaehoon Paul Jeong, = and Jung-Soo Park. "DNSNA: DNS
name autoconfiguration for Internet = of Things devices." Advanced
Communication Technology (ICACT), 2016= 18th International Conference
on. IEEE, 2016.
[4] https://tools.ietf.org/html/draft-ietf-core-resource-directory= -09
[5]
https://tools.ietf.org/html/dr= aft-aggarwal-dnssd-optimize-query-00
[6] Klauck, Ronny, and Mic= hael Kirsche. "Enhanced DNS message
compression-Optimizing mDNS/DNS= -SD for the use in 6LoWPANs." Pervasive
Computing and Communication= s Workshops (PERCOM Workshops), 2013 IEEE
International Conference on. I= EEE, 2013.
[7] https://github.com/Agile-IoT/awesome-= open-iot#mdns--bonjour


=

_______________________________________________<= br> IoT-DIR mailing list
IoT-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/iot-dir<= br>

--001a114db19e4dea24054ac77c0b-- From nobody Sun Mar 19 13:25:09 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 C8EE71293EC for ; Sun, 19 Mar 2017 13:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001, 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 skeEIRNA6E2F for ; Sun, 19 Mar 2017 13:25:05 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 8AAD01273E2 for ; Sun, 19 Mar 2017 13:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1489955105; 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=8x6/cW5AnMzF8uV0Fdmpdxpt84Xu33nTbOAMd+ftvxE=; b=GjvHnyGqkYOn8MRdWFEnxDYK+q2X0fHbeB5HGtoKifNw0/n6gwtdgQ1pkpYJdlYK phqJe44pUS9ko2wQx2ln4z4d/ERbEHuQluu0xgVvoKw8b7tjS0YnQDtSnMSl/W61 akFLKF+x16TK+e7/4cvg+56ei+63Gq8qbI2ffqFs49Yaq3QcdmZJdBtnYvdkQa0b Q46Q66Bla8zzfwZxT5KLrUNYEDYiuhaH5I/mvWKg20w0mnB2QQY51cUd/K7TVgYQ 91rfTxvBATHR3SJj12z1njgB1CmL44uLAiEbT4j5blCFJ4Nk/q2x6zhPVY1ap/NC bK4iOQ1D4gMMpR7wkilxjg==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 7F.56.30096.E19EEC85; Sun, 19 Mar 2017 13:25:05 -0700 (PDT) X-AuditID: 11973e11-0d9ff70000007590-e6-58cee91ee747 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay2.apple.com (Apple SCV relay) with SMTP id 91.52.06512.E19EEC85; Sun, 19 Mar 2017 13:25:02 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.50.205] (unknown [17.153.50.205]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ON200DFJWPKZD60@koseret.apple.com>; Sun, 19 Mar 2017 13:25:02 -0700 (PDT) Sender: cheshire@apple.com From: Stuart Cheshire In-reply-to: Date: Sun, 19 Mar 2017 13:26:04 -0700 Cc: "dnssd@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <2C65F0EC-180C-49FD-9871-15B58C49AE68@apple.com> References: To: Tim Chown , Ralph Droms X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUi2FDorKv48lyEwcxLwhbvl85itGi81sdq 0ffzMZsDs8fOWXfZPZYs+cnksfL3FbYA5igum5TUnMyy1CJ9uwSujHW3H7IWfJSv+HdjM2sD Y5tUFyMnh4SAicTtR1fYuxi5OIQE9jJKHF49gxkm8e7ecSaIxCpGiUl3jjGBJHgFBCV+TL7H 0sXIwcEsoC4xZUouRE0rk8SMbbdYQGqEBaQkXq38zAxhG0k8uT+JHcRmE9CSePH5ChuIzSlg JzHl+z02kDksAqoSu45XgYSZgcyrx/pYIGxtiSfvLrBCrLWRWHN+K1irkICtxMzvj8BaRQQ8 Jea+NoY4WVbiyclFLCDnSAhMYJOYc+Ee4wRG4VlIrp6FcPUsJBsWMDKvYhTKTczM0c3MM9JL LCjISdVLzs/dxAgK9el2gjsYj6+yOsQowMGoxMPbcOFchBBrYllxZe4hRmkOFiVx3ulTzkYI CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYHTj/r5l5szbbUwJGv7X3ik+F5xyeNnMDnGtPTMu rcyt3VD8P5h7xl077t0PDxdXn79vnLwh4YCGPbdO0L7Spikz9q7eeKVm3YXItnc1+wUbhOv2 WAdNmbNDZYP9q/npM+2v/9+XGlXycqIAR4b98+7m+Rmqc5+zz2s/nByx3N7hzp63Fy/Ve7Ir sRRnJBpqMRcVJwIAvXmh0lYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUiON1OXVfu5bkIg7Nv1CzeL53FaNF4rY/V ou/nYzYHZo+ds+6yeyxZ8pPJY+XvK2wBzFFcNimpOZllqUX6dglcGetuP2Qt+Chf8e/GZtYG xjapLkZODgkBE4l3944zdTFycQgJrGKUmHTnGBNIgldAUOLH5HssXYwcHMwC6hJTpuRC1LQy SczYdosFpEZYQEri1crPzBC2kcST+5PYQWw2AS2JF5+vsIHYnAJ2ElO+32MDmcMioCqx63gV SJgZyLx6rI8FwtaWePLuAivEWhuJNee3grUKCdhKzPz+CKxVRMBTYu5rY4iTZSWenFzEMoFR YBaSQ2chHDoLydAFjMyrGAWKUnMSK430EgsKclL1kvNzNzGCQrOh0HkH47FlVocYBTgYlXh4 b1w6FyHEmlhWXJl7iFGCg1lJhHfDQ6AQb0piZVVqUX58UWlOavEhRmkOFiVx3v4jQCmB9MSS 1OzU1ILUIpgsEwenVANjTfbf66tTndafzVr3K/3SthSuxPceF3TTeZ67bP3QX3yTYaPejn8e Rbc+LT3wMz6Qd2HHhGLTbWXhGdPYvTnm9GZena5b8XPChvMTa7fXbNTiOj9jjW7835VfeO0Z ZFeZrLEpE1TjFHxnsFDznNWTRQn1LtJPPuz9qBHcIbPlifCmxwpL7Kd1K7EUZyQaajEXFScC AJ9Ed4lJAgAA Archived-At: Subject: Re: [dnssd] Provisional agenda for IETF98 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: Sun, 19 Mar 2017 20:25:08 -0000 On 14 Mar 2017, at 09:20, Tim Chown wrote: > Hi, >=20 > The provisional agenda for IETF98 is included below. Please let Ralph = or I know if you have suggestions for changes or additions. Thanks Tim. This looks good. Here is the status as I see it: 1. draft-ietf-dnssd-hybrid (Discovery Proxy) =E2=80=94 ready to progress = to the IESG. 2. draft-ietf-dnssd-push =E2=80=94 ready for WGLC. 3. draft-ietf-dnsop-session-signal =E2=80=94 ready for DNSOP WGLC. Other documents I did not get done by the draft deadline, but really = hope to have ready to submit when submissions re-open on Monday 27th. It = would not be reasonable to expect people to discuss the content in our = Tuesday meeting, but it would be good if I could have a few minutes to = draw people=E2=80=99s attention to them. 4. draft-cheshire-dnssd-roadmap =E2=80=94 there are many components that = make up service discovery, at various levels, and few people really = understand how they all fit together. This short overview document is = intended to remedy that. 5. Discovery Broker =E2=80=94 this is a kind of meta Discovery Proxy. = =46rom the outside it looks like a basic Discovery Proxy. Except, it = doesn=E2=80=99t get its answers by querying using Multicast; it gets its = answers by querying other Discovery Proxies. It has two purposes. One is = client efficiency. Instead of a client opening three Push connections to = three Discovery Proxies on three different links, the client can open a = single Push connection to a Discovery Broker, which has its own = connections to the relevant Discovery Proxies, and aggregates the = results for the client. The second purpose is infrastructure efficiency. = Instead of a thousand clients all opening separate Push connections to a = poor little overloaded router on the link, the thousand clients can open = Push connections to a big-iron Discovery Broker in the data centre, = which has a single connection to the actual Discovery Proxy embedded in = the router on the link. That way, the router on the link only has to = serve a single client =E2=80=94 the Discovery Broker. 6. Sleep Proxy =E2=80=94 Apple has shipped this for years; I need to = document it. It=E2=80=99s basically DNS Update, plus garbage collection, = plus Wake-on-LAN magic packet. Simple, but should be documented. 7. Advertising Proxy =E2=80=94 this allows a device, with appropriate = security, to advertise services via multicast service discovery, on a = physical link to which the device is not directly attached. It has = applicability for mesh networks like 6LoWPAN, where the trusted devices = are conceptually part of the network, but can=E2=80=99t themselves use = multicast. There have been efforts to support multicast on mesh = networks, but this may be an overly heavyweight solution if there=E2=80=99= s a better way to advertise services without requiring the mesh to = support multicast in its full generality. It=E2=80=99s basically Sleep = Proxy without the Wake-on-LAN magic packet. 8. Zone Stitching =E2=80=94 when clients can interrogate multiple links = (e.g., via a Discovery Broker) it would be convenient if we did not have = names duplicated on the different underlying links. I confess that I = still don=E2=80=99t have a single blindingly-obvious answer to this, so = I welcome discussion and suggestions. I suspect the solution might build = on the Discovery Proxy. When two links are configured to not allow = duplicated names, the two Discovery Proxies in question would establish = a bidirectional TCP connection. When one Discovery Proxy sees a device = ask (using Multicast DNS) =E2=80=9CIs this name in use?=E2=80=9D the = Discovery Proxy would ask its peer (over the TCP connection) =E2=80=9CIs = this name already in use on your link?=E2=80=9D and if the answer is = =E2=80=9CYes=E2=80=9D, then the Discovery Proxy tells the local device = (using Multicast DNS) =E2=80=9CName already in use; pick another.=E2=80=9D= Stuart Cheshire From nobody Mon Mar 20 01:08:03 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 7B6C41296C8 for ; Mon, 20 Mar 2017 01:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMsHyEM6Syl7 for ; Mon, 20 Mar 2017 01:07:59 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.229]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5D31296CE for ; Mon, 20 Mar 2017 01:07:59 -0700 (PDT) Received: from poro.lan (80.220.131.63) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 58A591F800B027BC; Mon, 20 Mar 2017 10:07:52 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Markus Stenberg In-Reply-To: <2C65F0EC-180C-49FD-9871-15B58C49AE68@apple.com> Date: Mon, 20 Mar 2017 10:07:50 +0200 Cc: Tim Chown , Ralph Droms , "dnssd@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <11497C4D-07FF-498B-B53E-2A97DA808446@iki.fi> References: <2C65F0EC-180C-49FD-9871-15B58C49AE68@apple.com> To: Stuart Cheshire X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [dnssd] Provisional agenda for IETF98 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, 20 Mar 2017 08:08:02 -0000 On 19 Mar 2017, at 22.26, Stuart Cheshire wrote: > 8. Zone Stitching =E2=80=94 when clients can interrogate multiple = links (e.g., via a Discovery Broker) it would be convenient if we did = not have names duplicated on the different underlying links. I confess = that I still don=E2=80=99t have a single blindingly-obvious answer to = this, so I welcome discussion and suggestions. I suspect the solution = might build on the Discovery Proxy. When two links are configured to not = allow duplicated names, the two Discovery Proxies in question would = establish a bidirectional TCP connection. When one Discovery Proxy sees = a device ask (using Multicast DNS) =E2=80=9CIs this name in use?=E2=80=9D = the Discovery Proxy would ask its peer (over the TCP connection) =E2=80=9C= Is this name already in use on your link?=E2=80=9D and if the answer is = =E2=80=9CYes=E2=80=9D, then the Discovery Proxy tells the local device = (using Multicast DNS) =E2=80=9CName already in use; pick another.=E2=80=9D= I have thought quite a bit about this over the years (less recently, as = I am mostly working on non-IETF stuff). I am not very fond of discovery proxies talking with each other; you = wind up with O(N^2) connections given N links.=20 Instead, I would probably do this as function of discovery broker; = either a) it provides rewritten information to its clients (somewhat fishy, as = if mdns info contains computer-42, and there is another computer-42, you = would wind up with e.g. computer-42-2 for one of them) b) discovery broker <> discovery proxy action is actually bidirectional, = and DB can tell DP to force client to rename. Either design is relatively simple given devices that do not move.=20 However, in presence of moving devices, I am somewhat uncertain on what = is the correct way; as device moves, it gets new IP address, so how to = correlate that X.link1.example.com is actually X.link2.example.com? I = can think of few obvious heuristics but given recent work in IPv6 = address pseudorandomization per link, they seem error prone and = therefore not advisable. Therefore I am currently leaning towards design c) DB just shows (DNS-SD) services, even if they are duplicate (omitting = extra ones?), and they point to host names on various links that may not = be unique. In other words, just omit conflict resolution across links. or even d) DB just shows (DNS-SD services) for each link; based on cursory = reading of RFC 6763, nothing prevents PTR _http.tcp.example.com =3D> = site on X._http._tcp.link1.example.com I am not quite sure if d) is valid, but at any rate, I am really leery = of options a and b currently due to how they interact (or actually do = not interact _well_) with moving hosts. Cheers, -Markus= From nobody Mon Mar 20 05:18:18 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 9D607131442 for ; Mon, 20 Mar 2017 05:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Z-Po3iG506sZ for ; Mon, 20 Mar 2017 05:18:13 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 CC8F9130A97 for ; Mon, 20 Mar 2017 05:18:12 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id 1so107878224qkl.3 for ; Mon, 20 Mar 2017 05:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Kl+QgIpspgTtlKFZnN2FBTL6Iz0AuFR3whbaPDTvY7g=; b=rc1QRqc3RBQj/12B+1oszHzHHkFoG079FOYHut4tv2EkMtcYuq2AZnoO4zPA7YfQEH 1wI3V5KMoomLeV91uWwjDuHcpu4n4eeMxxRlrF6Ry7taCBWtZqu+lyZvjCaClZvZkkyj KUZxF10k0Wd1UsZvWK2jLZzkvQjboa/Zc/41eaSgGKrOsJ4f2Zuo3iplG4nUVqP0yhl5 L+cV8bmfznk3VtkA7PmkyZiVR28MYr06GDscSxOUhtLLQrtEVtwzYf0k/sF2f74SAo1M Pu01zSAgu4HB6ZODJX/dHhgxnCHWQ2gwbqdoKL2VIvZnjj2alf/SOwgkzUybZnWbMjmJ /kHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Kl+QgIpspgTtlKFZnN2FBTL6Iz0AuFR3whbaPDTvY7g=; b=ObwFdgeW/XyDUgSg6wlzTywtae8HCkFk4AwU0iIVyqhySZF9F15cz1LBOlRIHP80Qn nE76YqIzmZjXt6yCZKfbdmjyl60DUQ54qDla//o1kHNSTyYPqasYYXbGXT1Nl63TS4am AmonCp8UPBANS6ezuijkcuE69MGM2RdhwKUbIrvhzFQOS2xh2NmsHQIimIdXEc0pkmTn fYtkudR8bmFWy8u8eWRiWQgcEzX9AgZUM9Z8ebXAG7aQ/3kGQjwTVCzNBFJwHGXfeLmR 3OfpiX5l2+kBo3J2+T6dnBGj/kvzBpfvLTAj6NYODTMqDm4a/b/ifQwZy859n3swVoBu tK+Q== X-Gm-Message-State: AFeK/H39CYJVCWpl2iWlLhnZzYcq8fcB9uwBSeRfA0Kev4ZETkYsad1/Hg6tLrklSJKvSA== X-Received: by 10.233.222.6 with SMTP id s6mr26886416qkf.231.1490012291904; Mon, 20 Mar 2017 05:18:11 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id h16sm10711008qta.34.2017.03.20.05.18.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 05:18:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: <11497C4D-07FF-498B-B53E-2A97DA808446@iki.fi> Date: Mon, 20 Mar 2017 08:18:09 -0400 Cc: Stuart Cheshire , Tim Chown , "dnssd@ietf.org" , Ralph Droms Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C65F0EC-180C-49FD-9871-15B58C49AE68@apple.com> <11497C4D-07FF-498B-B53E-2A97DA808446@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [dnssd] Provisional agenda for IETF98 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, 20 Mar 2017 12:18:17 -0000 It might be useful to collect some operational data on this. My = experience is that "duplicate" devices are always the same device = appearing either sequentially or simultaneously on two different links. = Defending the name therefore has the effect of causing the device to = constantly rename itself, so that it never has a stable name. This = really sucks from a usability perspective. Having the service simply = mark duplicate names, rather than defending them, seems more likely to = work. This is what we suggest in the simple homenet naming = architecture draft. > On Mar 20, 2017, at 4:07 AM, Markus Stenberg = wrote: >=20 > On 19 Mar 2017, at 22.26, Stuart Cheshire wrote: >> 8. Zone Stitching =E2=80=94 when clients can interrogate multiple = links (e.g., via a Discovery Broker) it would be convenient if we did = not have names duplicated on the different underlying links. I confess = that I still don=E2=80=99t have a single blindingly-obvious answer to = this, so I welcome discussion and suggestions. I suspect the solution = might build on the Discovery Proxy. When two links are configured to not = allow duplicated names, the two Discovery Proxies in question would = establish a bidirectional TCP connection. When one Discovery Proxy sees = a device ask (using Multicast DNS) =E2=80=9CIs this name in use?=E2=80=9D = the Discovery Proxy would ask its peer (over the TCP connection) =E2=80=9C= Is this name already in use on your link?=E2=80=9D and if the answer is = =E2=80=9CYes=E2=80=9D, then the Discovery Proxy tells the local device = (using Multicast DNS) =E2=80=9CName already in use; pick another.=E2=80=9D= >=20 > I have thought quite a bit about this over the years (less recently, = as I am mostly working on non-IETF stuff). >=20 > I am not very fond of discovery proxies talking with each other; you = wind up with O(N^2) connections given N links.=20 >=20 > Instead, I would probably do this as function of discovery broker; = either >=20 > a) it provides rewritten information to its clients (somewhat fishy, = as if mdns info contains computer-42, and there is another computer-42, = you would wind up with e.g. computer-42-2 for one of them) >=20 > b) discovery broker <> discovery proxy action is actually = bidirectional, and DB can tell DP to force client to rename. >=20 > Either design is relatively simple given devices that do not move.=20 >=20 > However, in presence of moving devices, I am somewhat uncertain on = what is the correct way; as device moves, it gets new IP address, so how = to correlate that X.link1.example.com is actually X.link2.example.com? I = can think of few obvious heuristics but given recent work in IPv6 = address pseudorandomization per link, they seem error prone and = therefore not advisable. Therefore I am currently leaning towards design >=20 > c) DB just shows (DNS-SD) services, even if they are duplicate = (omitting extra ones?), and they point to host names on various links = that may not be unique. In other words, just omit conflict resolution = across links. >=20 > or even >=20 > d) DB just shows (DNS-SD services) for each link; based on cursory = reading of RFC 6763, nothing prevents PTR _http.tcp.example.com =3D> = site on X._http._tcp.link1.example.com >=20 > I am not quite sure if d) is valid, but at any rate, I am really leery = of options a and b currently due to how they interact (or actually do = not interact _well_) with moving hosts. >=20 > Cheers, >=20 > -Markus > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Mon Mar 20 10:15:52 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 EA57F13154A for ; Mon, 20 Mar 2017 10:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=jisc.ac.uk 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 tuec9aREOnAY for ; Mon, 20 Mar 2017 10:15:46 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A546131526 for ; Mon, 20 Mar 2017 10:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1490030065; bh=b7fuCgBXN1z6fSlsWTdVsI1fUnl8wnQET24awWXvAx0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b+3zBb2wEcMZjubo3EILivWvAJCjzS2THTf9Ar5b7zhlJnfpkcdDEWsPxbBetqx2L7ppjHJZJwJ62HbR286jU8sfQuMienUdJI5gOCKe3bEc+FztXDLQNNcpIMfjvvIkVK5GVFgOrIl2t/e5DtU+iuan8HslHgvwmPzAZLHx3eU= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0241.outbound.protection.outlook.com [213.199.154.241]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-100-Pa8MplFrPF2M--skyCPWPQ-1; Mon, 20 Mar 2017 17:14:20 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 17:14:17 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0991.011; Mon, 20 Mar 2017 17:14:17 +0000 From: Tim Chown To: Stuart Cheshire CC: Ralph Droms , "dnssd@ietf.org" Thread-Topic: [dnssd] Provisional agenda for IETF98 Thread-Index: AQHSnN7wIhCBpo8+Vku0ambTqCyVFKGcpFIAgAFcvgA= Date: Mon, 20 Mar 2017 17:14:17 +0000 Message-ID: <35A86B92-54B8-4DB5-9A7F-DA240109E97F@jisc.ac.uk> References: <2C65F0EC-180C-49FD-9871-15B58C49AE68@apple.com> In-Reply-To: <2C65F0EC-180C-49FD-9871-15B58C49AE68@apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:dd81:d5c7:2bf4:9c2a] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:udwqcG8uPonAn81Y7QcAGKRrmmdVotYK43qMnzfkxG84yLJ7QSTOhHxq67KDYH/6GOXjATp5NP0DgBCZuaVifGs1COazkvzB60ly7EuVYi5qhuU4FgbMzD1SVIxYfrOm1OwEsNtvjpCS9ZKUL6QGXidakhFv5+RWEEXVL7Y6wkw/3xiXU8mSNqCEbUsnKQ+HtFVVLYzeAP8+32iR32kVCnl/aEcUSrKkHByki+GkJ8xQkvZiBNZ4SiJ15mOvEoh/NI+EFQmwRa8z0JyQtVWW8emszS7X9l007tHV2tcofAPh7tEKQaSZ/ZbYkH7gJIGDAZM7NLaTVCEp+Z0SvlUPWA==; 20:1Avb0z24/4dVtG08lXGQdOxIxp7mxA8Izjhi9CTwz0pH74HuV9fpL9JLwuC4m3gaj2gA7eVFKRMifNpeM2Fd/j2UX33TCdj3U4uwJ8tvxlG0h6qC7TjIlNBZGR89zJHCkWsNylMHx27gfpvDPq5lN6R/XmwBqFDFLBo7Kw5h5V0= x-ms-office365-filtering-correlation-id: 24f58f49-292a-4707-3765-08d46fb48aae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(192374486261705)(176510541525296)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(54906002)(53936002)(8666007)(6512007)(36756003)(6506006)(99286003)(6436002)(33656002)(38730400002)(110136004)(50226002)(8936002)(4326008)(81166006)(229853002)(8676002)(2900100001)(6246003)(86362001)(6486002)(39060400002)(189998001)(83716003)(76176999)(57306001)(6116002)(102836003)(50986999)(7736002)(74482002)(5660300001)(3660700001)(53546008)(5890100001)(305945005)(3280700002)(2906002)(82746002)(42882006)(6916009)(5250100002)(2950100002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <48DAB75E3052A543A6EE34F05557E810@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 17:14:17.6190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: Pa8MplFrPF2M--skyCPWPQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [dnssd] Provisional agenda for IETF98 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, 20 Mar 2017 17:15:50 -0000 SGkgU3R1YXJ0LA0KDQo+IE9uIDE5IE1hciAyMDE3LCBhdCAyMDoyNiwgU3R1YXJ0IENoZXNoaXJl IDxjaGVzaGlyZUBhcHBsZS5jb20+IHdyb3RlOg0KPiANCj4gT24gMTQgTWFyIDIwMTcsIGF0IDA5 OjIwLCBUaW0gQ2hvd24gPFRpbS5DaG93bkBqaXNjLmFjLnVrPiB3cm90ZToNCj4gDQo+PiBIaSwN Cj4+IA0KPj4gVGhlIHByb3Zpc2lvbmFsIGFnZW5kYSBmb3IgSUVURjk4IGlzIGluY2x1ZGVkIGJl bG93LiBQbGVhc2UgbGV0IFJhbHBoIG9yIEkga25vdyBpZiB5b3UgaGF2ZSBzdWdnZXN0aW9ucyBm b3IgY2hhbmdlcyBvciBhZGRpdGlvbnMuDQo+IA0KPiBUaGFua3MgVGltLiBUaGlzIGxvb2tzIGdv b2QuDQo+IA0KPiBIZXJlIGlzIHRoZSBzdGF0dXMgYXMgSSBzZWUgaXQ6DQo+IA0KPiAxLiBkcmFm dC1pZXRmLWRuc3NkLWh5YnJpZCAoRGlzY292ZXJ5IFByb3h5KSDigJQgcmVhZHkgdG8gcHJvZ3Jl c3MgdG8gdGhlIElFU0cuDQo+IA0KPiAyLiBkcmFmdC1pZXRmLWRuc3NkLXB1c2gg4oCUIHJlYWR5 IGZvciBXR0xDLg0KDQpSYWxwaCBhbmQgSSBhZ3JlZSwgYW5kIHdpbGwgYmUgYWN0aW5nIG9uIHRo aXMgdmVyeSBzb29uLiBPbmUgb2YgdXMgd2lsbCBuZWVkIHRvIGRvIHRoZSBzaGVwaGVyZCB3cml0 ZXVwLiBJIHJlY2FsbCB0aGVyZSBpcyB0aGUgZGlzY292ZXJ5IHByb3h5IElQUiBkaXNjbG9zdXJl IHdlIG5lZWQgdG8gaW5jbHVkZS4NCg0KPiAzLiBkcmFmdC1pZXRmLWRuc29wLXNlc3Npb24tc2ln bmFsIOKAlCByZWFkeSBmb3IgRE5TT1AgV0dMQy4NCj4gDQo+IE90aGVyIGRvY3VtZW50cyBJIGRp ZCBub3QgZ2V0IGRvbmUgYnkgdGhlIGRyYWZ0IGRlYWRsaW5lLCBidXQgcmVhbGx5IGhvcGUgdG8g aGF2ZSByZWFkeSB0byBzdWJtaXQgd2hlbiBzdWJtaXNzaW9ucyByZS1vcGVuIG9uIE1vbmRheSAy N3RoLiBJdCB3b3VsZCBub3QgYmUgcmVhc29uYWJsZSB0byBleHBlY3QgcGVvcGxlIHRvIGRpc2N1 c3MgdGhlIGNvbnRlbnQgaW4gb3VyIFR1ZXNkYXkgbWVldGluZywgYnV0IGl0IHdvdWxkIGJlIGdv b2QgaWYgSSBjb3VsZCBoYXZlIGEgZmV3IG1pbnV0ZXMgdG8gZHJhdyBwZW9wbGXigJlzIGF0dGVu dGlvbiB0byB0aGVtLg0KDQpZb3UgaGF2ZSAyMCBtaW51dGVzIGF0IHByZXNlbnQuIFdlIG1heSBi ZSBhYmxlIHRvIHJhaXNlIHRoYXQgYSBsaXR0bGUuDQoNCj4gNC4gZHJhZnQtY2hlc2hpcmUtZG5z c2Qtcm9hZG1hcCDigJQgdGhlcmUgYXJlIG1hbnkgY29tcG9uZW50cyB0aGF0IG1ha2UgdXAgc2Vy dmljZSBkaXNjb3ZlcnksIGF0IHZhcmlvdXMgbGV2ZWxzLCBhbmQgZmV3IHBlb3BsZSByZWFsbHkg dW5kZXJzdGFuZCBob3cgdGhleSBhbGwgZml0IHRvZ2V0aGVyLiBUaGlzIHNob3J0IG92ZXJ2aWV3 IGRvY3VtZW50IGlzIGludGVuZGVkIHRvIHJlbWVkeSB0aGF0Lg0KPiANCj4gNS4gRGlzY292ZXJ5 IEJyb2tlciDigJQgdGhpcyBpcyBhIGtpbmQgb2YgbWV0YSBEaXNjb3ZlcnkgUHJveHkuIEZyb20g dGhlIG91dHNpZGUgaXQgbG9va3MgbGlrZSBhIGJhc2ljIERpc2NvdmVyeSBQcm94eS4gRXhjZXB0 LCBpdCBkb2VzbuKAmXQgZ2V0IGl0cyBhbnN3ZXJzIGJ5IHF1ZXJ5aW5nIHVzaW5nIE11bHRpY2Fz dDsgaXQgZ2V0cyBpdHMgYW5zd2VycyBieSBxdWVyeWluZyBvdGhlciBEaXNjb3ZlcnkgUHJveGll cy4gSXQgaGFzIHR3byBwdXJwb3Nlcy4gT25lIGlzIGNsaWVudCBlZmZpY2llbmN5LiBJbnN0ZWFk IG9mIGEgY2xpZW50IG9wZW5pbmcgdGhyZWUgUHVzaCBjb25uZWN0aW9ucyB0byB0aHJlZSBEaXNj b3ZlcnkgUHJveGllcyBvbiB0aHJlZSBkaWZmZXJlbnQgbGlua3MsIHRoZSBjbGllbnQgY2FuIG9w ZW4gYSBzaW5nbGUgUHVzaCBjb25uZWN0aW9uIHRvIGEgRGlzY292ZXJ5IEJyb2tlciwgd2hpY2gg aGFzIGl0cyBvd24gY29ubmVjdGlvbnMgdG8gdGhlIHJlbGV2YW50IERpc2NvdmVyeSBQcm94aWVz LCBhbmQgYWdncmVnYXRlcyB0aGUgcmVzdWx0cyBmb3IgdGhlIGNsaWVudC4gVGhlIHNlY29uZCBw dXJwb3NlIGlzIGluZnJhc3RydWN0dXJlIGVmZmljaWVuY3kuIEluc3RlYWQgb2YgYSB0aG91c2Fu ZCBjbGllbnRzIGFsbCBvcGVuaW5nIHNlcGFyYXRlIFB1c2ggY29ubmVjdGlvbnMgdG8gYSBwb29y IGxpdHRsZSBvdmVybG9hZGVkIHJvdXRlciBvbiB0aGUgbGluaywgdGhlIHRob3VzYW5kIGNsaWVu dHMgY2FuIG9wZW4gUHVzaCBjb25uZWN0aW9ucyB0byBhIGJpZy1pcm9uIERpc2NvdmVyeSBCcm9r ZXIgaW4gdGhlIGRhdGEgY2VudHJlLCB3aGljaCBoYXMgYSBzaW5nbGUgY29ubmVjdGlvbiB0byB0 aGUgYWN0dWFsIERpc2NvdmVyeSBQcm94eSBlbWJlZGRlZCBpbiB0aGUgcm91dGVyIG9uIHRoZSBs aW5rLiBUaGF0IHdheSwgdGhlIHJvdXRlciBvbiB0aGUgbGluayBvbmx5IGhhcyB0byBzZXJ2ZSBh IHNpbmdsZSBjbGllbnQg4oCUIHRoZSBEaXNjb3ZlcnkgQnJva2VyLg0KDQpPSywgdGhpcyBpcyBp bnRlcmVzdGluZy4gSXQgdG91Y2hlcyBvbiBib3RoIHRoZSBlZmZpY2llbmN5IGlzc3VlcyB0aGF0 IHdlcmUgcmFpc2VkIHByZXZpb3VzbHkgaW4gdGhlIFdHLCBhbmQgYWxzbyB0aGUgd29yayB0aGF0 IFJhbHBoIGFuZCBUb20gYXJlIGRvaW5nIG9uIGVudGVycHJpc2UgYmVzdCBkZXBsb3ltZW50IHBy YWN0aWNlcy4gDQoNCj4gNi4gU2xlZXAgUHJveHkg4oCUIEFwcGxlIGhhcyBzaGlwcGVkIHRoaXMg Zm9yIHllYXJzOyBJIG5lZWQgdG8gZG9jdW1lbnQgaXQuIEl04oCZcyBiYXNpY2FsbHkgRE5TIFVw ZGF0ZSwgcGx1cyBnYXJiYWdlIGNvbGxlY3Rpb24sIHBsdXMgV2FrZS1vbi1MQU4gbWFnaWMgcGFj a2V0LiBTaW1wbGUsIGJ1dCBzaG91bGQgYmUgZG9jdW1lbnRlZC4NCj4gDQo+IDcuIEFkdmVydGlz aW5nIFByb3h5IOKAlCB0aGlzIGFsbG93cyBhIGRldmljZSwgd2l0aCBhcHByb3ByaWF0ZSBzZWN1 cml0eSwgdG8gYWR2ZXJ0aXNlIHNlcnZpY2VzIHZpYSBtdWx0aWNhc3Qgc2VydmljZSBkaXNjb3Zl cnksIG9uIGEgcGh5c2ljYWwgbGluayB0byB3aGljaCB0aGUgZGV2aWNlIGlzIG5vdCBkaXJlY3Rs eSBhdHRhY2hlZC4gSXQgaGFzIGFwcGxpY2FiaWxpdHkgZm9yIG1lc2ggbmV0d29ya3MgbGlrZSA2 TG9XUEFOLCB3aGVyZSB0aGUgdHJ1c3RlZCBkZXZpY2VzIGFyZSBjb25jZXB0dWFsbHkgcGFydCBv ZiB0aGUgbmV0d29yaywgYnV0IGNhbuKAmXQgdGhlbXNlbHZlcyB1c2UgbXVsdGljYXN0LiBUaGVy ZSBoYXZlIGJlZW4gZWZmb3J0cyB0byBzdXBwb3J0IG11bHRpY2FzdCBvbiBtZXNoIG5ldHdvcmtz LCBidXQgdGhpcyBtYXkgYmUgYW4gb3Zlcmx5IGhlYXZ5d2VpZ2h0IHNvbHV0aW9uIGlmIHRoZXJl 4oCZcyBhIGJldHRlciB3YXkgdG8gYWR2ZXJ0aXNlIHNlcnZpY2VzIHdpdGhvdXQgcmVxdWlyaW5n IHRoZSBtZXNoIHRvIHN1cHBvcnQgbXVsdGljYXN0IGluIGl0cyBmdWxsIGdlbmVyYWxpdHkuIEl0 4oCZcyBiYXNpY2FsbHkgU2xlZXAgUHJveHkgd2l0aG91dCB0aGUgV2FrZS1vbi1MQU4gbWFnaWMg cGFja2V0Lg0KDQpUaGlzIGlzIHdoYXQgUmFscGggYW5kIEkgcmVzZXJ2ZWQgdGhlIDIwIG1pbnMg Zm9yLiAgQnV0IGlmIHdlIGNhbiBnZXQgV0cgZmVlZGJhY2sgb24gZWFjaCB0b3BpYyB5b3XigJl2 ZSByYWlzZWQsIHRoYXQgd291bGQgb2YgY291cnNlIGJlIGdyZWF0Lg0KPiANCj4gOC4gWm9uZSBT dGl0Y2hpbmcg4oCUIHdoZW4gY2xpZW50cyBjYW4gaW50ZXJyb2dhdGUgbXVsdGlwbGUgbGlua3Mg KGUuZy4sIHZpYSBhIERpc2NvdmVyeSBCcm9rZXIpIGl0IHdvdWxkIGJlIGNvbnZlbmllbnQgaWYg d2UgZGlkIG5vdCBoYXZlIG5hbWVzIGR1cGxpY2F0ZWQgb24gdGhlIGRpZmZlcmVudCB1bmRlcmx5 aW5nIGxpbmtzLiBJIGNvbmZlc3MgdGhhdCBJIHN0aWxsIGRvbuKAmXQgaGF2ZSBhIHNpbmdsZSBi bGluZGluZ2x5LW9idmlvdXMgYW5zd2VyIHRvIHRoaXMsIHNvIEkgd2VsY29tZSBkaXNjdXNzaW9u IGFuZCBzdWdnZXN0aW9ucy4gSSBzdXNwZWN0IHRoZSBzb2x1dGlvbiBtaWdodCBidWlsZCBvbiB0 aGUgRGlzY292ZXJ5IFByb3h5LiBXaGVuIHR3byBsaW5rcyBhcmUgY29uZmlndXJlZCB0byBub3Qg YWxsb3cgZHVwbGljYXRlZCBuYW1lcywgdGhlIHR3byBEaXNjb3ZlcnkgUHJveGllcyBpbiBxdWVz dGlvbiB3b3VsZCBlc3RhYmxpc2ggYSBiaWRpcmVjdGlvbmFsIFRDUCBjb25uZWN0aW9uLiBXaGVu IG9uZSBEaXNjb3ZlcnkgUHJveHkgc2VlcyBhIGRldmljZSBhc2sgKHVzaW5nIE11bHRpY2FzdCBE TlMpIOKAnElzIHRoaXMgbmFtZSBpbiB1c2U/4oCdIHRoZSBEaXNjb3ZlcnkgUHJveHkgd291bGQg YXNrIGl0cyBwZWVyIChvdmVyIHRoZSBUQ1AgY29ubmVjdGlvbikg4oCcSXMgdGhpcyBuYW1lIGFs cmVhZHkgaW4gdXNlIG9uIHlvdXIgbGluaz/igJ0gYW5kIGlmIHRoZSBhbnN3ZXIgaXMg4oCcWWVz 4oCdLCB0aGVuIHRoZSBEaXNjb3ZlcnkgUHJveHkgdGVsbHMgdGhlIGxvY2FsIGRldmljZSAodXNp bmcgTXVsdGljYXN0IEROUykg4oCcTmFtZSBhbHJlYWR5IGluIHVzZTsgcGljayBhbm90aGVyLuKA nQ0KDQpUaGlzIG92ZXJsYXBzIHdpdGggcHJldmlvdXMgZGlzY3Vzc2lvbnMgb2YgY291cnNlLCBh bmQgd2hhdCBUZWQgaGFzIHNwb2tlbiBvbiBwcmV2aW91c2x5LiAgV2UgZG9u4oCZdCByZWFsbHkg aGF2ZSBhIGdvb2QgYW5zd2VyIGZvciB0aGlzIHlldC4gDQoNClRpbQ0KDQo= From nobody Tue Mar 21 04:24:18 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 DBC5E1296E1 for ; Tue, 21 Mar 2017 04:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 UjeEiVYui5ck for ; Tue, 21 Mar 2017 04:24:15 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D42C128CDC for ; Tue, 21 Mar 2017 04:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1490095453; bh=udaUqjvC4EjUXPbESED/+oz8a5NCrzL4bOm7lksgK5Y=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=OH6oy4M81MlmpBlY9AybuHoXsKyG/gXs4sFYVzoCP8herOrhjuiLb/RVfOVC19IILwBrn1qaGWYa01OigIjMC3fQ3pr4w/FYNUeitHY86Ra1MDka0fDeViz1FZ+avncyPc/QMFeE6IMUA9Pa+v7IWjyUjxerjt+CF7Pn0SiJp7E= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0248.outbound.protection.outlook.com [213.199.154.248]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-107-N4Z-61uuMpqkyYSTRn0Y9g-1; Tue, 21 Mar 2017 11:24:06 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Tue, 21 Mar 2017 11:24:05 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0991.013; Tue, 21 Mar 2017 11:24:05 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: WGLC on draft-ietf-dnssd-push-10 Thread-Index: AQHSojWmA8/nJyU5yUu9r4xhlnhscA== Date: Tue, 21 Mar 2017 11:24:04 +0000 Message-ID: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [94.117.237.162] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:pga+aArvsSIHWP+6/rNfgPRSCvFDIEH05WsrSIRFvtBBPQa0Xxj6B79v5sAThoNErGsdoioaYTknXEKWSsPh17oDXof/DO7MApKBZqwLZhp7iuF4IEQNLbCESiJNahttPqLjJG86GCVJQvkIa6mwTJjSMkm7HmbEMY4hZwqtrL/x9Bf0k4CLVKGb0MTEsygTAKUcAmROlvh1OgS55FvAzC8hZSxg0Tl301JIdDnrlh1/nDZifmf1G+bZK2P25U5VYmFuxzZJ2jNPgFLkut8qurn34pBdROAFOdxtjhJG34JptJsgKqvLofvoxAwaeKtQupdDU/1ThgsWsH3Eiayy8w==; 20:MEdE7sx9gy018CjyEm6dECPrZmfLwFkH02ksKSDWgNvmWR5HvqprLip4ksDHH/xFdCeN64BJ7MyU5u6hz8AhuRGZQvQI4lUGrkt/awB/7ktasJq+1cP+TeYW5w9C97kHBnuRA81a7leG+3OVNMb+z/XAhIEU7vzXvzCWOo4Mb9w= x-ms-office365-filtering-correlation-id: c8870935-5a0d-4619-d539-08d4704cc885 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(54896002)(6512007)(6306002)(2906002)(3280700002)(236005)(3660700001)(7736002)(5640700003)(6436002)(83716003)(1730700003)(81166006)(6116002)(8676002)(3846002)(36756003)(102836003)(606005)(110136004)(7906003)(99286003)(57306001)(2900100001)(189998001)(42882006)(82746002)(38730400002)(6506006)(6916009)(8936002)(6486002)(2351001)(86362001)(2501003)(66066001)(74482002)(50226002)(50986999)(33656002)(5660300001)(5250100002)(53936002)(230783001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 11:24:04.9601 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: N4Z-61uuMpqkyYSTRn0Y9g-1 Content-Type: multipart/alternative; boundary="_000_43A42C9DFC484AF19E9B299D5B0179E1jiscacuk_" Archived-At: Subject: [dnssd] WGLC on draft-ietf-dnssd-push-10 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, 21 Mar 2017 11:24:18 -0000 --_000_43A42C9DFC484AF19E9B299D5B0179E1jiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Dear dnssd WG participants, We are initiating a WG Last Call today on draft-ietf-dnssd-push-10, which y= ou can find at https://tools.ietf.org/html/draft-ietf-dnssd-push-10 The call runs for two weeks, and will thus close on Tuesday 4th April. Please send any comments, which includes indications of support for progres= sion of the document as is, to the dnssd@ietf.org li= st. Such statements of support are important; this draft will not be advan= ced for publication unless there is sufficient response and support from th= e WG. There will be a brief opportunity to also make comments in the dnssd WG mee= ting in Chicago next week, but the chairs would appreciate a record of comm= ents to the list. We are expecting the associated DNS session signalling draft to also go thr= ough WGLC in the dnsop WG in the next couple of weeks, with the aim of both= documents being published together. The DNS-SD Discovery Proxy (formerly the DNS-SD Hybrid Proxy), which Stuart= has updated to reflect the new nomenclature, will be sent to the IESG once= the shepherd write-up is completed. Best wishes, Ralph and Tim dnssd WG co-chairs --_000_43A42C9DFC484AF19E9B299D5B0179E1jiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: <564630919173A747B1234D073BF93DD3@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Dear dnssd WG participants,

We are initiating a WG Last Call today on draft-ietf-dnssd-= push-10, which you can find at https://tools.ietf.org/html/draft-ietf= -dnssd-push-10

The call runs for two weeks, and will thus close on Tuesday= 4th April.

Please send any comments, which includes indications of sup= port for progression of the document as is, to the dnssd@ietf.org list.  Such statemen= ts of support are important; this draft will not be advanced for publication unless there is sufficient response and support from = the WG.  

There will be a brief opportunity to also make comments in = the dnssd WG meeting in Chicago next week, but the chairs would appreciate = a record of comments to the list.

We are expecting the associated DNS session signalling draf= t to also go through WGLC in the dnsop WG in the next couple of weeks, with= the aim of both documents being published together.

The DNS-SD Discovery Proxy (formerly the DNS-SD Hybrid Prox= y), which Stuart has updated to reflect the new nomenclature, will be sent = to the IESG once the shepherd write-up is completed.

Best wishes,

Ralph and Tim
dnssd WG co-chairs


--_000_43A42C9DFC484AF19E9B299D5B0179E1jiscacuk_-- From nobody Tue Mar 28 10:33:51 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 5B1F8129671 for ; Tue, 28 Mar 2017 10:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 2lrvqGNUl-6M for ; Tue, 28 Mar 2017 10:33:47 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B58126DDF for ; Tue, 28 Mar 2017 10:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1490722424; bh=FhvS8CmUxaHIu8unrnbf+lVreRZqILRt72/NxJdRCw8=; h=From:To:Subject:Date:Message-ID:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=P0fVdrgjMV1hbV65vlrJ92WfDn00WH5ybABBaQadwHsFDyC6dt4CP5Zkz3izCaEuUNZczpBMVyp32TgSQG2x+68hNf4WhbrxS41wEOF/5s3By/JbPHE9NAbPNMCU1Z+nqYwEkeVsuuJzSArYebau7X6Xzlygl5q9noIJX3qX7Eg= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0239.outbound.protection.outlook.com [213.199.154.239]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-3-_GvsJKfpNoG3_Dr-qIT4_Q-1; Tue, 28 Mar 2017 18:33:41 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 17:33:40 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.1005.010; Tue, 28 Mar 2017 17:33:40 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: dnssd WG session today Thread-Index: AQHSp+lwiLbPjBIIpEOZleEIclnfCQ== Date: Tue, 28 Mar 2017 17:33:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.149.62] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:IAHQv3VNxgu1gzPhrxgFiTMiMWG4e/nQ1usklO5DN1HMC/U6skfzI9kSYsqRwv00fADpARmgmtqGUSYJpVn+WizHCitEaf2sI0dheGbGmafhKlF2Yj0tyTkOkULmRjqCm0ranqFovlPTf5q3hUxlbmCsOcNHhx34XGWMR/dBsj1KMVL3NjbEW7c6ht3b3KfW3hhRqTUIaMMiFysYl+HyOWcDadIKnKS2pnc23sAY7RFrZCsDnWonBMA9I/EEh0C+u3F5TjDllHfQjd0TNN7u6U6TxXb4T29cu4HKXEOJlektbDfpLOmerTQxkHc4mHB1LJEi5CKmSjsWfpthTU5UHg==; 20:tpEZG1j2dWytRAdavYTYu3gyNgurQdRDSl2q9gka6M532++8qNZcqPojQRMK4GqX0k1JA1m8EFvwRg4TURLD+YtxqYwh5ab6/AaP0gkGE6BEHoJMr9kOmtQbDFIbDSEYExQ3siidUzTkAYDEDUs3m6HRJynJHw0C475ihJmG2II= x-ms-office365-filtering-correlation-id: c4c34375-dfc1-4d69-57c1-08d476009339 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM3PR07MB1140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39450400003)(39410400002)(39840400002)(279900001)(36756003)(2900100001)(3280700002)(3660700001)(25786009)(33656002)(7736002)(189998001)(2351001)(74482002)(2501003)(38730400002)(966004)(110136004)(3846002)(102836003)(6116002)(305945005)(5250100002)(66066001)(42882006)(53936002)(6512007)(19625305001)(99286003)(6306002)(6436002)(5640700003)(6916009)(50986999)(5660300001)(1730700003)(81166006)(2906002)(50226002)(8676002)(6506006)(86362001)(8936002)(6486002)(3480700004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <2047AAC613C069478C251A9FBC5807CA@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 17:33:40.5836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: _GvsJKfpNoG3_Dr-qIT4_Q-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: [dnssd] dnssd WG session today 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, 28 Mar 2017 17:33:50 -0000 SGksDQoNClRoZSBkbnNzZCBXRyBzZXNzaW9uIGlzIDQuNDBwbSB0byA2LjQwcG0gbG9jYWwgdGlt ZSB0b2RheS4NCg0KVGltIFdpY2luc2tpIGhhcyBraW5kbHkgYWdyZWVkIHRvIHRha2UgbWludXRl cy4NCg0KSeKAmXZlIHByZWxvYWRlZCB0aGUgRXRoZXJwYWQgd2l0aCB0aGUgYWdlbmRhIC0gaHR0 cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9ub3Rlcy1pZXRmLTk4LWRuc3NkDQoN CldlIHdpbGwgbmVlZCBhIEphYmJlciBzY3JpYmUgLSB2b2x1bnRlZXJzIHdlbGNvbWU7IHJlbWVt YmVyIHlvdSBjYW4ganVzdCB1c2UgTWVldEVjaG8gdG8gam9pbiB0aGUgamFiYmVyIGNoYXQgLSBz ZWUgaHR0cHM6Ly96dXJpY2hiLmNvbmYubWVldGVjaG8uY29tL3EtbWVldGVjaG8vbG9naW4uanNw P2lldGY9ZG5zc2QgDQoNClRoZSBhZ2VuZGEgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9tZWV0aW5nLzk4L2FnZW5kYS9kbnNzZC8NCg0KU2xpZGUgZGVja3MgYXJlIGF2YWlsYWJs ZSBmcm9tIHRoZSBNZWV0aW5nIE1hdGVyaWFscyBsaW5rIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy85OC9hZ2VuZGEuaHRtbA0KDQpUaW0gDQoNCg0KDQo= From nobody Tue Mar 28 11:01:41 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 AAA8D1297A5 for ; Tue, 28 Mar 2017 11:01:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149072409969.1303.1872529801501274350.idtracker@ietfa.amsl.com> Date: Tue, 28 Mar 2017 11:01:39 -0700 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, 28 Mar 2017 18:01:40 -0000 Changed milestone "Adopt wide-area service discovery solution draft as WG document ", set description to "Adopt wide-area service discovery solution draft as WG document". Changed milestone "Adopt privacy extensions for DNS-SD draft as a WG document", set state to active from review, accepting new milestone. Changed milestone "Adopt device pairing mechanism draft as a WG document", set state to active from review, accepting new milestone. Changed milestone " Submit wide-area service discovery solution draft to the IESG as Standards Track RFC", set description to "Submit wide-area service discovery solution draft to the IESG as Standards Track RFC". Changed milestone "Submit DNS Push draft to the IESG as Standards Track RFC", set state to active from review, accepting new milestone. Changed milestone "Adopt DNS-SD Advertising Proxy draft as a WG document", set state to active from review, accepting new milestone. Changed milestone "Submit Privacy Extensions for DNS-SD draft to the IESG as Standards Track RFC", set state to active from review, accepting new milestone. Changed milestone "Submit Device Pairing Using Short Authentication Strings draft to the IESG as Standards Track RFC", set state to active from review, accepting new milestone. Changed milestone "Submit DNS-SD Advertising Proxy draft to the IESG as Standards Track RFC", set state to active from review, accepting new milestone. Changed milestone "Submit DNS-SD Deployment for campus/enterprise networks draft to the IESG as a BCP document", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/dnssd/about/ From nobody Thu Mar 30 14:10: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 C46611294B8; Thu, 30 Mar 2017 14:10:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk CC: dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-mdns-dns-interop@ietf.org, suzworldwide@gmail.com, Suzanne Woolf , terry.manderson@icann.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149090820270.9007.2835487042847566330.idtracker@ietfa.amsl.com> Date: Thu, 30 Mar 2017 14:10:02 -0700 Archived-At: Subject: [dnssd] Last Call: (On Interoperation of Labels Among Conventional DNS and Other Resolution Systems) to Informational RFC 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 Mar 2017 21:10:16 -0000 The IESG has received a request from the Extensions for Scalable DNS Service Discovery WG (dnssd) to consider the following document: - 'On Interoperation of Labels Among Conventional DNS and Other Resolution Systems' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-04-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnssd-mdns-dns-interop/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnssd-mdns-dns-interop/ballot/ No IPR declarations have been submitted directly on this I-D.