From nobody Sun Apr 2 14:34:10 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 D0D9C120724 for ; Sun, 2 Apr 2017 14:34:08 -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, 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, 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 vXbqN6ivWo7C for ; Sun, 2 Apr 2017 14:34:06 -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 7B48F12944F for ; Sun, 2 Apr 2017 14:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491168836; bh=nWCn9ZzFbmhfGP69VsnVmG9WTf2ahAOZCa7/jS1MBjE=; h=From:To:Subject:Date:Message-ID:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aLEK1QpksvrTjal0FVKKYbav/XkygK0fH/9yinupn+8g4oT63p9I1LQ8EY6q7B21idXPzPznBZ+hWjRh3qHGt9HTNm7/3CzR2HdImHJjT1kkeAf799PfgegZhdTcbo/2sp29EGuKPqjam0DjX08gtrGTzeb1kNPoBELWa9l1Zzs= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0207.outbound.protection.outlook.com [213.199.154.207]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-12-oDdshj_-N3CBPfKVNy9DnQ-1; Sun, 02 Apr 2017 22:33:54 +0100 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.1019.8; Sun, 2 Apr 2017 21:33:52 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Sun, 2 Apr 2017 21:33:52 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: IETF98 WG meeting minutes and actions Thread-Index: AQHSq/jSqyFZgaM0r0yOxQTwdc3O8g== Date: Sun, 2 Apr 2017 21:33:52 +0000 Message-ID: <2C1FE4AA-BDA4-4AB4-9FF1-79E48802AAB5@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: [2001:a88:d510:1101:2c40:904f:2602:55e7] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:0B4T3C4gPWkBs/UyN4mzEBQSluvNYUVpCuAvmJOhUCskvY7Qmtu/WmhlNis3LKxrFsb/+J+k5sXUYnnKN9jcUCZwgPJzX8/3LS1+oAhxJC8LGQd/3hkRyKte43aPs7xlFodaLVSagxyLTaIAMt8OAeogTj9uhNZM8a20qOJYFmExQm0vQo+6gvkYRxZdFoOM2N120iZrCihSwiWAl31duWVvtcH5isUW5COakYXYWaqSWbLe5l7Xm0n99QM2aOiK4cP/EbBWktDt45EzFPF24pP8wAwYlP6LlEtgbq1skmuBgrMdgOhAuXQxZiGAq+guN2cSSZoLSR10La2qoZsX9g==; 20:6fg1I/3oEErCt5wHAqJP7a5Tppvmkq9IgDqS24pr3G8Xq+1OfeDHN/AaOZgWSN2Nu6DFkhv8rpj4oFgp+T7Cowc3akJefDI6rMzNoVKGxHyE1tgaoZhLp4c1jDb1xAO8E5IK8WE0YP4LXWQbgpB53KHatbloZKDDlwE09zGbVqA= x-ms-office365-filtering-correlation-id: f062e1d5-ca4a-4232-5033-08d47a0ff556 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1137; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123562025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(279900001)(66654002)(5640700003)(38730400002)(53936002)(110136004)(3660700001)(8676002)(6116002)(102836003)(5660300001)(99286003)(2501003)(7736002)(305945005)(6506006)(19625305001)(6306002)(42882006)(8936002)(6916009)(74482002)(966004)(2351001)(86362001)(6512007)(6436002)(189998001)(33656002)(81166006)(25786009)(50226002)(36756003)(3280700002)(2906002)(2900100001)(6486002)(1730700003)(50986999); 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: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2017 21:33:52.3380 (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: oDdshj_-N3CBPfKVNy9DnQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: [dnssd] IETF98 WG meeting minutes and actions 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, 02 Apr 2017 21:34:09 -0000 SGksDQoNCk1hbnkgdGhhbmtzIHRvIFRpbSBXaWNpbnNraSBmb3IgdGFraW5nIG91ciBXRyBtaW51 dGVzOyB0aGUgZHJhZnQgY29weSBpcyBhdmFpbGFibGUgb24gdGhlIGdyb3VwIGV0aGVycGFkLg0K UGxlYXNlIHNlZSBodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9wL25vdGVzLWll dGYtOTgtZG5zc2Q/dXNlTW9ub3NwYWNlRm9udD10cnVlLCBhbmQgY29tbWVudCBvciBhbWVuZCBh Y2NvcmRpbmdseS4NCldl4oCZbGwgc3VibWl0IHRoZSBmaW5hbCB2ZXJzaW9uIG9uIEZyaWRheSA3 dGguDQoNCkEgc3VtbWFyeSBvZiBhY3Rpb25zIGlzIGFsc28gbGlzdGVkIGJlbG93Lg0KDQpGaW5h bGx5LCBhIHJlbWluZGVyIHRoYXQgdGhlIFdHTEMgb24gRE5TIFB1c2ggaXMgcnVubmluZzsgcGxl YXNlIGNvbW1lbnQsIGV2ZW4gaWYganVzdCB0byBzYXkgeW91IHRoaW5rIHRoZSB3b3JrIGlzIHJl YWR5IHRvIHByb2dyZXNzIHRvIHRoZSBJRVNHLg0KDQpCZXN0IHdpc2hlcywNClRpbSAmIFJhbHBo DQoNCg0KRE5TIFB1c2ggTm90aWZpY2F0aW9ucw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtZG5zc2QtcHVzaC0xMA0KU3R1YXJ0IENoZXNoaXJlIHByZXNlbnRpbmcNCkFD VElPTjogYXV0aG9ycyB3aWxsIGNvbGxlY3QgaW5wdXQgZnJvbSBXRyBsYXN0IGNhbGwgb24NCmRy YWZ0LWlldGYtZG5zc2QtcHVzaC0xMDsgd2lsbCBzZWUgaWYgYW55dGhpbmcgbmVlZHMgdG8gYmUg Y2hhbmdlZA0KZnJvbSB1cGNvbWluZyBXRyBsYXN0IGNhbGwgaW4gZG5zb3Agb24gZHJhZnQtaWV0 Zi1kbnNvcC1zZXNzaW9uLXNpZ25hbC0wMw0Kd2hlbiBwdWJsaXNoZWQgc2hvcnRseS4NCg0KRE5T IFNlc3Npb24gU2lnbmFsbGluZw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZG5zb3Atc2Vzc2lvbi1zaWduYWwtMDINClN0dWFydCBDaGVzaGlyZSBwcmVzZW50aW5nDQpB Q1RJT046IHRoaXMgZHJhZnQgaXMgYSBkbnNvcCBXRyB3b3JrIGl0ZW07IG5vIGRuc3NkIFdHIGFj dGlvbg0KDQpETlMtU0QgRGlzY292ZXJ5IFByb3h5DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1kbnNzZC1oeWJyaWQtMDYNClN0dWFydCBDaGVzaGlyZSBwcmVzZW50aW5n DQpBQ1RJT046IGRyYWZ0LWlldGYtZG5zc2QtaHlicmlkLTA2IGlzIHJlYWR5IGZvciBJRVNHIHJl dmlldzsgZmluZCBhDQpzaGVwaGVyZCAoZWxzZSBjaGFpcnMgd2lsbCBkbyBpdCkNCg0KRE5TLVNE IEFkdmVydGlzaW5nIFByb3h5IC0gZGlzY3Vzc2lvbg0KKHBsdXMgU2xlZXAgUHJveHksIERpc2Nv dmVyeSBCcm9rZXIsIFpvbmUgU3RpdGNoaW5nLCBhbmQgRE5TLVNEIHJvYWRtYXApDQpTdHVhcnQg Q2hlc2hpcmUgcHJlc2VudGluZw0KQUNUSU9OOiBOb3RpbmcgaHVtIGluIGZhdm91ciwgV0cgZW5j b3VyYWdlcyBmdXJ0aGVyIHdvcmsgb24gRGlzY292ZXJ5IEJyb2tlciANCkFDVElPTjogTm8gb2Jq ZWN0aW9uIHRvIFNsZWVwIFByb3h5IHdvcmssIHNvIHByb2NlZWRpbmcgd2l0aCB3cml0aW5nDQog ICAgICAgdGhpcyBkb2N1bWVudGF0aW9uIGlzIGVuY291cmFnZWQ7IHJlc3VsdGluZyBkb2N1bWVu dCB0byBiZQ0KCXByZXNlbnRlZCBhdCBJbnRBcmVhIFdHIG1lZXRpbmcgZm9yIGV4dGVybmFsIHJl dmlld3Mgb2YNCgljb21wb25lbnRzIHN1Y2ggYXMgQVJQIGFuZCBORCBwcm94eQ0KQUNUSU9OOiBO b3RpbmcgaHVtLCBwcm9ncmVzc2luZyBBZHZlcnRpc2luZyBQcm94eSBpcyBlbmNvdXJhZ2VkDQpB Q1RJT046IFpvbmUgc3RpdGNoaW5nIGlzIHN0aWxsIGNvbmNlcHR1YWw7IG5vIGV4cGxpY2l0IGFj dGlvbiBmcm9tDQogICAgICAgdGhpcyBwcmVzZW50YXRpb24gDQpBQ1RJT046IFJvYWRtYXAgaXMg c3RpbGwgY29uY2VwdHVhbDsgbm8gZXhwbGljaXQgYWN0aW9uIGZyb20gdGhpcw0KICAgICAgIHBy ZXNlbnRhdGlvbiANCg0KUHJpdmFjeSBFeHRlbnNpb25zIGZvciBETlMtU0QNCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRuc3NkLXByaXZhY3ktMDENCkNocmlzdGlhbiBI dWl0ZW1hIChDSCkgcHJlc2VudGluZw0KQUNUSU9OOiBkcmFmdC1pZXRmLWRuc3NkLXByaXZhY3kt MDEgaXMgcmVhZHkgZm9yIFdHIGxhc3QgY2FsbA0KDQpEZXZpY2UgUGFpcmluZyBVc2luZyBTaG9y dCBBdXRoZW50aWNhdGlvbiBTdHJpbmdzDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1kbnNzZC1wYWlyaW5nLTAxDQpDaHJpc3RpYW4gSHVpdGVtYSAoQ0gpIHByZXNlbnRp bmcNCkFDVElPTjogV0cgcHJlZmVyZW5jZSBpcyBub3QgdG8gc3BsaXQgdGhlIGRvY3VtZW50OyBT dHVhcnQgQ2hlc2hpcmUsDQogICAgICAgVGVkIExlbW9uLCBUaW0gV2ljaW5za2kgdG8gcmV2aWV3 OyByZWFkeSBmb3IgV0cgbGFzdCBjYWxsDQogICAgICAgYWZ0ZXIgbmV4dCByZXZpc2lvbiANCg0K RE5TLVNEIERlcGxveW1lbnQgZm9yIGNhbXB1cy9lbnRlcnByaXNlIG5ldHdvcmtzIC0gQkNQIGRv Y3VtZW50IGRpc2N1c3Npb24NCmh0dHBzOi8vZ2l0aHViLmNvbS9wdXNhdGVyaS9kcmFmdC1wdXNh dGVyaS1oeWJyaWRwcm94eS1pbXBsL2Jsb2IvbWFzdGVyL2RyYWZ0LXB1c2F0ZXJpLWRuc3NkLWh5 cC1pbXBsLnR4dA0KR2VuZXJhbCBkaXNjdXNzaW9uIGxlZCBieSBjaGFpcnMNCkFDVElPTjogV0cg ZW5jb3VyYWdlcyBjb250aW51ZWQgd29yayBvbiB0aGlzIGRvY3VtZW50OyB2b2x1bnRlZXJzDQp3 ZWxjb21lIChSYW4gQXRraW5zb24gb2ZmZXJlZCBzb21lIGhlbHApOyBsaWtlbHkgdG8gYmUgSW5m b3JtYXRpb25hbA0KcmF0aGVyIHRoYW4gQkNQLCBhdCBsZWFzdCBmb3Igbm93Lg0KDQpTaW1wbGUg SG9tZW5ldCBOYW1pbmcgYW5kIFNlcnZpY2UgRGlzY292ZXJ5IEFyY2hpdGVjdHVyZQ0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRsZG0tc2ltcGxlLWhvbWVuZXQtbmFtaW5nLTAw DQpUZWQgTGVtb24gcHJlc2VudGluZw0KQUNUSU9OOiBleHBsb3JhdG9yeSBhdCB0aGlzIHN0YWdl OyBubyBhY3Rpb25zIGZvciBkbnNzZCBXRzsgVGVkIG5lZWRzDQp0byB0aGluayBhYm91dCBwcm9i bGVtIHRvIGJlIHNvbHZlZCwgd2hpY2ggZXhpc3RpbmcgZG5zc2QgY29tcG9uZW50cw0KY2FuIGJl IHJldXNlZCwgYW5kIHdoYXQgdGhlIGdhcHMgYXJlLg0KDQpTdGF0ZWZ1bCBNdWx0aS1MaW5rIERO UyBTZXJ2aWNlIERpc2NvdmVyeQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxl bW9uLXN0YXRlZnVsLWRuc3NkLTAwDQpUZWQgTGVtb24gcHJlc2VudGluZw0KQUNUSU9OOiBleHBs b3JhdG9yeSBhdCB0aGlzIHN0YWdlOyBubyBhY3Rpb25zIGZvciBkbnNzZCBXRw0KDQpETlMtU0Qg aW4gSW9UIChhbmQgY29uc3RyYWluZWQgbmV0d29yayBlbnZpcm9ubWVudHMpDQpQZXRlciB2YW4g ZGVyIFN0b2NrIChwcmVzZW50aW5nKS9JbmVzIFJvYmxlcw0KVXNlIG9mIFJEIGluIENvUkUgbm90 ZWQuDQpBQ1RJT046IGRuc3NkIGFuZCBDb1JFIFdHIHJlcHJlc2VudGF0aXZlcyBlbmNvdXJhZ2Vk IHRvIG1lZXQgYW5kDQpkaXNjdXNzIHdheSBmb3J3YXJkLCBlLmcuIFN0dWFydCwgQ2Fyc3Rlbiwg S2VycnksIFBldGVyLiANCg0K From nobody Thu Apr 6 01:59:40 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 AA8011201FA for ; Thu, 6 Apr 2017 01:59:38 -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, 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 Sgkiyy-bAdvf for ; Thu, 6 Apr 2017 01:59:36 -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 D769112783A for ; Thu, 6 Apr 2017 01:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491469174; bh=e/WF7BskdzW4vHlW4GPxMhOwI0yoOPxU7W1X8MdGVkM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fcJnVuvxkb2cpBjqbq5uDCunbl1EPBqimyst4nPBbWvquGnBmfykgCGn7jPpIqPFv4YMqHVrxLaZcZ0ugopv5k6LbFxIJ0edEk/G7V9Dra0jaezIYgvaC2DRNJBlibuTGU/t7lzE7XRjNtQpIhqPDbzUhjttkaPmohui5m/LwKE= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0119.outbound.protection.outlook.com [213.199.154.119]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-101-oy95BCY4MgyJQbVSptHESg-1; Thu, 06 Apr 2017 09:59:30 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 6 Apr 2017 08:59:29 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.021; Thu, 6 Apr 2017 08:59:29 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) Thread-Index: AQHSrrQZkjs+5/KWK0Kpr5nnI3HxzA== Date: Thu, 6 Apr 2017 08:59:29 +0000 Message-ID: References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> In-Reply-To: <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: [2001:a88:d510:1101:a824:23c0:227c:5eb4] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:ahQf/Gnty+Bq1E4Ia9Fwf+4chmoA9Nx4u2iC0w6gA1Tate8QB1J/LI3Fw593BPjIGiBHT6LmQmcO+CqUq+zEk9QUdk7AYdnQdkg9YsoC+V2/dzhPkAP3ExFxYc1WylmLXdZMJLrarEb/DdkHjq5WeNmA0j7srdhKXZ+SuN6iBDGjLTJdkSQNwb5ZnEzP/vKu5QLx4wTG+HjAWcZFrUmRWjQvaADUICqrLAk1my/8CtXsF+ThHt7CyJvO0Wl5Eut3sbEOsNq8h53yRao2sn1W6oYfSV3eyzSlNqvNlYIcGMA7F2lN2X4ZAj12H7YVxtidf1mGi6GuHAAPKui124iPoQ==; 20:MIKm74viIvoGnBnTn0Su5bCL21fQMgGxfAU79Jy8pDk6eymaBcgGj99CyTgPIrcef7CPHu/A6hbSj+E2kI3Okpvw7Zv1YJmHhvMIRyD0US0jrKhF7qsOWCbnNabtXtAjXoR7LTYHgLcSsi/hu9X9aKtxPXCqNY8MPppArYel1Z0= x-ms-office365-filtering-correlation-id: b98babdb-775f-4940-5609-08d47ccb3c4e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1138; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39850400002)(39450400003)(39410400002)(39840400002)(66654002)(24454002)(102836003)(2906002)(3660700001)(6116002)(3280700002)(5660300001)(2900100001)(53936002)(8936002)(81166006)(1730700003)(50226002)(6246003)(5250100002)(305945005)(2501003)(7736002)(189998001)(38730400002)(6486002)(99286003)(6506006)(86362001)(8676002)(230783001)(6306002)(82746002)(53546009)(6512007)(25786009)(57306001)(83716003)(5640700003)(2351001)(76176999)(50986999)(229853002)(74482002)(42882006)(6916009)(2950100002)(33656002)(36756003); 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: <6BE1C8D1A95C944BA011CCEFD2B55D3E@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 08:59:29.6983 (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: oy95BCY4MgyJQbVSptHESg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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: Thu, 06 Apr 2017 08:59:39 -0000 SGksDQoNCldlIGhhdmUgaGFkIG5vIGNvbW1lbnRzIG9uIHRoaXMgV0dMQy4NCg0KSW4gb3JkZXIg dG8gcHJvZ3Jlc3MgdGhlIGRyYWZ0IHRvIG91ciBBRC9JRVNHIHdlIG5lZWQgc29tZSBwb3NpdGl2 ZSBleHByZXNzaW9ucyBvZiBzdXBwb3J0OyBwbGVhc2UgZG8gdHJ5IHRvIGZpbmQgc29tZSB0aW1l IHRvIHJlYWQgYW5kIGNvbW1lbnQgb24gdGhlIGRvY3VtZW50Lg0KDQpXZeKAmWxsIGV4dGVuZCB0 aGUgV0dMQyB1bnRpbCBuZXh0IEZyaWRheSwgMTR0aCBBcHJpbCwgZ2l2ZW4gd2UgYXJlIGFsc28g d2FpdGluZyBvbiBhIFdHTEMgZm9yIHRoZSBETlMgc2Vzc2lvbiBzaWduYWxsaW5nIGRyYWZ0IHVz ZWQgYnkgRE5TIFB1c2guDQoNCk1hbnkgdGhhbmtzLA0KVGltICYgUmFscGgNCg0KPiBPbiAyMSBN YXIgMjAxNywgYXQgMTE6MjQsIFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs+IHdyb3Rl Og0KPiANCj4gRGVhciBkbnNzZCBXRyBwYXJ0aWNpcGFudHMsDQo+IA0KPiBXZSBhcmUgaW5pdGlh dGluZyBhIFdHIExhc3QgQ2FsbCB0b2RheSBvbiBkcmFmdC1pZXRmLWRuc3NkLXB1c2gtMTAsIHdo aWNoIHlvdSBjYW4gZmluZCBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1kbnNzZC1wdXNoLTEwDQo+IA0KPiBUaGUgY2FsbCBydW5zIGZvciB0d28gd2Vla3MsIGFuZCB3 aWxsIHRodXMgY2xvc2Ugb24gVHVlc2RheSA0dGggQXByaWwuDQo+IA0KPiBQbGVhc2Ugc2VuZCBh bnkgY29tbWVudHMsIHdoaWNoIGluY2x1ZGVzIGluZGljYXRpb25zIG9mIHN1cHBvcnQgZm9yIHBy b2dyZXNzaW9uIG9mIHRoZSBkb2N1bWVudCBhcyBpcywgdG8gdGhlIGRuc3NkQGlldGYub3JnIGxp c3QuICBTdWNoIHN0YXRlbWVudHMgb2Ygc3VwcG9ydCBhcmUgaW1wb3J0YW50OyB0aGlzIGRyYWZ0 IHdpbGwgbm90IGJlIGFkdmFuY2VkIGZvciBwdWJsaWNhdGlvbiB1bmxlc3MgdGhlcmUgaXMgc3Vm ZmljaWVudCByZXNwb25zZSBhbmQgc3VwcG9ydCBmcm9tIHRoZSBXRy4gIA0KPiANCj4gVGhlcmUg d2lsbCBiZSBhIGJyaWVmIG9wcG9ydHVuaXR5IHRvIGFsc28gbWFrZSBjb21tZW50cyBpbiB0aGUg ZG5zc2QgV0cgbWVldGluZyBpbiBDaGljYWdvIG5leHQgd2VlaywgYnV0IHRoZSBjaGFpcnMgd291 bGQgYXBwcmVjaWF0ZSBhIHJlY29yZCBvZiBjb21tZW50cyB0byB0aGUgbGlzdC4NCj4gDQo+IFdl IGFyZSBleHBlY3RpbmcgdGhlIGFzc29jaWF0ZWQgRE5TIHNlc3Npb24gc2lnbmFsbGluZyBkcmFm dCB0byBhbHNvIGdvIHRocm91Z2ggV0dMQyBpbiB0aGUgZG5zb3AgV0cgaW4gdGhlIG5leHQgY291 cGxlIG9mIHdlZWtzLCB3aXRoIHRoZSBhaW0gb2YgYm90aCBkb2N1bWVudHMgYmVpbmcgcHVibGlz aGVkIHRvZ2V0aGVyLg0KPiANCj4gVGhlIEROUy1TRCBEaXNjb3ZlcnkgUHJveHkgKGZvcm1lcmx5 IHRoZSBETlMtU0QgSHlicmlkIFByb3h5KSwgd2hpY2ggU3R1YXJ0IGhhcyB1cGRhdGVkIHRvIHJl ZmxlY3QgdGhlIG5ldyBub21lbmNsYXR1cmUsIHdpbGwgYmUgc2VudCB0byB0aGUgSUVTRyBvbmNl IHRoZSBzaGVwaGVyZCB3cml0ZS11cCBpcyBjb21wbGV0ZWQuDQo+IA0KPiBCZXN0IHdpc2hlcywN Cj4gDQo+IFJhbHBoIGFuZCBUaW0NCj4gZG5zc2QgV0cgY28tY2hhaXJzDQo+IA0KPiANCg0K From nobody Fri Apr 7 13:47:59 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 E2CE8127873; Fri, 7 Apr 2017 13:47:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks 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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149159806986.11195.9301095647004982341@ietfa.amsl.com> Date: Fri, 07 Apr 2017 13:47:49 -0700 Archived-At: Subject: [dnssd] Genart last call 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: Fri, 07 Apr 2017 20:47:50 -0000 Reviewer: Robert Sparks Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dnssd-mdns-dns-interop-04 Reviewer: Robert Sparks Review Date: 2017-04-07 IETF LC End Date: 2017-04-13 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as an Informational RFC From nobody Tue Apr 11 08:15:59 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 6356812EAB0; Tue, 11 Apr 2017 08:15:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner 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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149192374936.15734.41201323624268863@ietfa.amsl.com> Date: Tue, 11 Apr 2017 08:15:49 -0700 Archived-At: Subject: [dnssd] Secdir last call 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, 11 Apr 2017 15:15:49 -0000 Reviewer: Sean Turner Review result: Ready The draft is short and well written. The security considerations is also brief, but I agree with its basic point "This memo presents some requirements for future development, but does not specify anything." The persistent "visual confusability" consideration wrt internationalized domain names is duly noted as a consideration. In my opinion, the security considerations as written is appropriate and sufficient; other DNSSD WG protocol-focused drafts have more extensive security considerations and it is better to grind the security axe against those documents rather than here. From nobody Wed Apr 12 22:53:22 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 80620127201 for ; Wed, 12 Apr 2017 22:53:12 -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=unavailable 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 KpUQeYAoaWtZ for ; Wed, 12 Apr 2017 22:53:11 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 D3759127449 for ; Wed, 12 Apr 2017 22:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1492062788; 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=ynhZtJ+zD8DkXmpIZacyrL01VH5Ia97z0k1h8lV6j7k=; b=E935uCSKFKRNgv3BV6HaVBNS6uLgTb5B74rr94a5hLFetenyh53hm7d5EJkZFrJo 5ykoAAL+u/dYnuBSKmHwlmBbAe5hDT5bwAgE2WfsKA4uS+FMFtCKyyZie3NDdr// J5SO7BFxzKcLLW4LYLbSCsqmP5DmBRAiJr2vsijq4yixjVu0adbtq+7YYSSImWt3 dBGPVQduf5zOq4bofTBaovwdTOHuGIpdQz/vKAl6z21DHDmZAc5fAwygB65/0L7n 09nJ7DB2pqg5EOQplioOtqCctGsR8YIvp+C9SmwcF/dv1VMg+6CCfvIZ58dH8sX4 G7+Qna5MXH4OnV7vM0Zv9Q==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id CC.2C.13165.3421FE85; Wed, 12 Apr 2017 22:53:08 -0700 (PDT) X-AuditID: 11ab0215-dc5879a00000336d-9f-58ef12435967 Received: from kencur (kencur.apple.com [17.151.62.38]) by relay7.apple.com (Apple SCV relay) with SMTP id 34.87.26825.3421FE85; Wed, 12 Apr 2017 22:53:07 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [10.0.1.35] (50-197-138-101-static.hfc.comcastbusiness.net [50.197.138.101]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOC00MTF30HRX60@kencur.apple.com>; Wed, 12 Apr 2017 22:53:07 -0700 (PDT) Sender: cheshire@apple.com From: Stuart Cheshire In-reply-to: <149090820270.9007.2835487042847566330.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 22:53:07 -0700 Cc: IETF-Announce , draft-ietf-dnssd-mdns-dns-interop@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, Suzanne Woolf , terry.manderson@icann.org Content-transfer-encoding: quoted-printable Message-id: <099780BE-C3BC-4EF7-8C0F-93522195E6AE@apple.com> References: <149090820270.9007.2835487042847566330.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FCYqusi9D7CoOOOicWVd33MFu+XzmK0 +Pb7HZvFvTPT2SyebZzPYtE0ZRqrRevRm6wO7B47Z91l9zh84T6Lx5IlP5kCmKO4bFJSczLL Uov07RK4MpZ9+cxasNCy4uaNe+wNjEv1uhg5OSQETCRuT7/F0sXIxSEksJ9R4sLVWUwwictv jrBCJFYwSrx+v4INJMErICjxY/I9oA4ODmYBdYkpU3Khapgkutd2g9UIC0hJvFr5mRkkISyw lVFi8fnFLCAJNgEtiRefr4AVcQr4Skzp2QW2jUVAVWLroYlg25gFjjFKPH12F6yIWUBb4sm7 C6wg23gFbCQ2vaoECQsJ+EhMn32BCSQsAnTQwceWEEfLSjw5uQjsGwmBHWwSj+beZ53AKDwL yd2zEO6ehWTBAkbmVYzCuYmZObqZeUaGeokFBTmpesn5uZsYQZGxmkl0B+P8V4aHGAU4GJV4 eDsE30cIsSaWFVfmHmKU5mBREuedPvVdhJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG6owp 1i7RFXqb7Or7pixhP3e67vV0NaVlQj8+TP8n8VE1KLosImiOw1Efhq85DoJNjltyNPhbF7sr zWNh+5PaYH3OZx6jpn2jl5/pmndcD1wkt6d9+Sz9ZgrHy4VyX7ImL86eknzl65SrYk3q92bu fqFS76Cc7K+1Q+5/7N51/qkCxY0KKTuUWIozEg21mIuKEwHhXzGvbQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUiON1OTddZ6H2Ewf13OhZX3vUxW7xfOovR 4tvvd2wW985MZ7N4tnE+i0XTlGmsFq1Hb7I6sHvsnHWX3ePwhfssHkuW/GQKYI7isklJzcks Sy3St0vgylj25TNrwULLips37rE3MC7V62Lk5JAQMJG4/OYIaxcjF4eQwApGidfvV7CBJHgF BCV+TL7H0sXIwcEsoC4xZUouVA2TRPfabrAaYQEpiVcrPzODJIQFtjJKLD6/mAUkwSagJfHi 8xWwIk4BX4kpPbuYQGwWAVWJrYcmgm1jFjjGKPH02V2wImYBbYkn7y6wgmzjFbCR2PSqEiQs JOAjMX32BSaQsAjQQQcfW0IcLSvx5OQilgmMArOQnDoL4dRZSGYuYGRexShQlJqTWGmul1hQ kJOql5yfu4kRFMYNhak7GBuXWx1iFOBgVOLhPSH7LkKINbGsuDL3EKMEB7OSCO/sn0Ah3pTE yqrUovz4otKc1OJDjNIcLErivJdF3kQICaQnlqRmp6YWpBbBZJk4OKUaGO2nuCo0fErgl9vA r7mnScfs3pyJFz/uTdptv+zSgaRZO8+ZTdE7dfjwJu0jm899K1y87vabXjGp0GPczUckt/3d 7KMdeE0mcPukF10RDmslU527lZakK8T6ml4QUF+8Z1H9vGR3q51ST48yTn6exZ0au+SuKYep /axeuW0J8ifv3S6sOBx+20+JpTgj0VCLuag4EQB1gAN3XwIAAA== Archived-At: Subject: Re: [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 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 05:53:12 -0000 On 30 Mar 2017, at 14:10, The IESG wrote: > 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 Overall I think this document is very good. Re-reading draft-04 today, I have a few minor comments. Page 3: > Users and developers of applications are, of course, frequently > unconcerned with (not to say oblivious to) the name-resolution > system(s) in service at any given moment Does =E2=80=9Cnot to say=E2=80=9D mean =E2=80=9Cnot oblivious=E2=80=9D = or =E2=80=9Coblivious=E2=80=9D? It would be clearer to say: > Users ... are, of course, frequently unconcerned with (but not = oblivious to) ... or > Users ... are, of course, frequently unconcerned with (or even = oblivious to) ... Page 3: > As a result, the same domain name might be tried using different name = resolution technologies. Any given name may only be looked up using the single name resolution = technology appropriate for that name. It might be clearer to say: > As a result, names entered into the same domain name slot might be = resolved using different name resolution technologies. Page 3: > the global DNS is eventually likely to be implicated The global DNS is already used for service discovery. Every time someone = prints at an IETF meeting using AirPrint to the Terminal Room printer, = the global DNS is being used. This is now, not the future. How about just removing the word =E2=80=9Ceventually=E2=80=9D? Page 5: > In any case, if a given portion is implicated, the > profile will need to apply to all labels in that portion. This is overly strict. It=E2=80=99s not necessarily all-or-nothing. The = portion of the Service Instance Name may require mixed = handling. Consider the Service Instance Name: Public Printer._ipp._tcp.3rd Floor.caf=C3=A9.com. The portion, =E2=80=9CPublic Printer=E2=80=9D, is UTF-8. The portion, =E2=80=9C_ipp._tcp=E2=80=9D, is plain ASCII, and = uncomplicated. The portion is mixed. =E2=80=9C3rd Floor=E2=80=9D has a space, and has to be UTF-8. But =E2=80=9Ccaf=C3=A9.com=E2=80=9D is actually registered as = =E2=80=9Cxn--caf-dma.com=E2=80=9D and has to be converted as such. Fortunately the iterative algorithm described in RFC 6763, and = implemented and shipping in Apple products and the Open Source = mDNSResponder code, handles this. So, while this may appear to be a = problem, it is in fact a solved problem. Page 6: > some recommendations from [RFC6763] will not really be possible to = implement Can you elaborate on what recommendations are not possible to implement? > many labels in the part of a Service Instance Name are > unlikely to be found in the UTF-8 form in the public DNS tree Saying =E2=80=9Cunlikely=E2=80=9D is too strong. An administrator who = wants spaces or similar exotic Unicode characters in a service discovery = domain name will have to use UTF-8 for that name, even if host names in = the same zone use Punycode. And this is not hard to do. You simply edit = the zone file using a UTF-8-capable text editor, and type in the desired = UTF-8 text. Name servers such as =E2=80=98named=E2=80=99 will happily = serve that zone. The name server itself doesn=E2=80=99t need to be = UTF-8-capable in any way. It just acts on the bytes in the zone file, = without attempting to interpret how humans will perceive those bytes. Page 6: > mDNS normally uses UTF-8. should say: > mDNS exclusively uses UTF-8. Page 7: > As a practical matter, this > likely means special-purpose name resolution software for DNS-SD. This reads as if it=E2=80=99s talking about some hypothetical future. = This special-purpose name resolution software is already used for = service discovery, and has been since Mac OS X 10.2 in 2002. This = special-purpose name resolution software, and its APIs, is on Apple = products, Microsoft Windows, Linux, and Android. So, again, this text is = describing a non-problem. It=E2=80=99s like text warning against using = JPEG as an image format in 2017, because JPEG images require = =E2=80=9Cspecial-purpose JPEG image decoding software=E2=80=9D, at a = time when all major platforms have had JPEG image decoding software for = many years. Page 8: > DNS-SD implementations ought somehow to identify the portion = of > the Service Instance Name and treat it subject to IDNA2008 in case the > domain is to be queried from the global DNS. In the event that the > portion of the Service Instance Name fails to resolve, it is > acceptable to substitute labels with plain UTF-8, starting at the > lowest label in the DNS tree and working toward the root. This > approach differs from the rule for resolution published in [RFC6763], > because it privileges IDNA2008-compatible labels over UTF-8 labels. If we want to recommend this change in behavior, I think this document = is the wrong place to do it. RFC 6763 is a published Standards-Track specification. For good or bad, = it went though thorough lengthy review, and is a result of the IETF = consensus process. I think it=E2=80=99s confusing to have an = Informational RFC that appears to update a Standards-Track RFC. Should = an implementer follow RFC 6763 because it=E2=80=99s a Standards-Track = specification and this document is merely Informational, and doesn=E2=80=99= t say, =E2=80=9CUpdates: RFC 6763=E2=80=9D? Or should an implementer = follow this document because it=E2=80=99s newer and therefore is assumed = to supersede any text found in older Standards-Track RFCs? RFC 6763 specifies an iterative algorithm that is implemented, and in = use, and appears to work. Overturning that specification should require = careful scrutiny and Standards-Track action. In 2017, does the IETF want = to be encouraging movement towards UTF-8 as the universal encoding for = everything, or encouraging continued diversification into =E2=80=9Cevery = protocol invents its own different incompatible encoding for = international text=E2=80=9D? Page 8: > The first of these is rejected because it represents a potentially > significant increase in DNS lookup traffic for no value. I request removing the value judgement =E2=80=9Cfor no value=E2=80=9D. The value of using UTF-8 is that it is both more compact and more = expressive than Punycode. How about: > An issue with the first of these is that it represents a potentially > significant increase in DNS lookup traffic. Page 8: > it is unlikely that the UTF-8 version of the zone will be delegated = from anywhere This is circular logic. An administrator using a UTF-8 zone *will* make = sure that UTF-8 zone is accessible, or there=E2=80=99s no point having = it. This could be done by delegation, but need not be. Subdomains = don=E2=80=99t have to be delegated -- subdomains can exist in a single = zone. Not all subdomain boundaries need to be zone cuts, and many are = not. Stuart Cheshire From nobody Thu Apr 13 15:26:48 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDBE12EB40 for ; Thu, 13 Apr 2017 15:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqXFvXmjlxzB for ; Thu, 13 Apr 2017 15:26:43 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 100AF129A96 for ; Thu, 13 Apr 2017 15:26:43 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id v3so56298429qtd.3 for ; Thu, 13 Apr 2017 15:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=oBxU7zZdoMaLQPeO6emX/Bek440xkP1OAtpizA7lG7g=; b=L5WSEsk0/1p17lCaO5JpzzW5wiGj+75Jfa4c2PMw1NkDigdKHVhiTODnK2lT8nttXY ZN08TBGwkiS/+VH4/DDa5dxcYo5EtFulmwUaPk9c6vl/IDJCCI4xr1Cg9ysv+4940wzz 26H14M7dCGwHiD3uEVI8vJk0iI/hM/uqkE0sYwSJxsq5MGRQacvgrAClIjWwCdqtWkg4 fALAeVXBAxzrR7dq1Qy9hvogGj5nzSAnUlK6cfaH0eDasw6CUAkjednzL2DHVK5VrWjG BS7Xl+0MdETKeGcXChpjxVgrDHm2dT0CZNpHfBaW1JcPPOxyV3QMEyDCyt4RPAdjE4X/ UNoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=oBxU7zZdoMaLQPeO6emX/Bek440xkP1OAtpizA7lG7g=; b=ew7J73vWl2Av8FVBK9N+GyGxnQGJ0uzoanzGXhUa37kQIcEOUeOnyD4tb0KpFr0RBk 10wIL0GcYurppolZnVbwu8t74lz9lUwTXtJ2WLKuBrk/tYc0ijHxa6Q2F3VuYKVOgQeR 6vmqe9XeWt4TgZaJSiKd8JB+Al8ISt2BAzOBnh1QXuSK3lb5gBvexJlEMsxFyWQZmZ5y QpXNxK7NNTunckCXCj9rMZvCtia8DyvTtQ+AqDBJPptMDYHJPolzJpmGoUgJActPNKjs 0l3KSlM2ogtRTot30anvYSU1GCAJLphB9iPf3gOvLj2+Df94bmN5lrFzcYrY6GOD8Kby 0XOw== X-Gm-Message-State: AN3rC/6FD139qkVXxAL+Yr41x2yLBOf9URCbbQ6ELi5OSTuGk1mNTaOM ZQ3bRzJ0J9/QEQoy5cg= X-Received: by 10.200.57.73 with SMTP id t9mr4608798qtb.182.1492122402043; Thu, 13 Apr 2017 15:26:42 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:4c01:b47:1703:8517? ([2601:18f:801:600:4c01:b47:1703:8517]) by smtp.gmail.com with ESMTPSA id o91sm46742qte.42.2017.04.13.15.26.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 15:26:41 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 18:26:38 -0400 References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> To: "dnssd@ietf.org" In-Reply-To: Message-Id: <9A671E6C-369C-48F8-A310-2BF40BA9F856@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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: Thu, 13 Apr 2017 22:26:45 -0000 I think draft-ietf-dnssd-push-10 is ready to be forwarded to the IESG, = after the following comment is addressed: I found the second item in the list in section 6.1 confusing: 6.1. Discovery The first step in DNS Push Notification subscription is to discover an appropriate DNS server that supports DNS Push Notifications for the desired zone. The client MUST also determine which TCP port on the server is listening for connections, which need not be (and often is not) the typical TCP port 53 used for conventional DNS, or TCP port 853 used for DNS over TLS [RFC7858]. 1. The client begins the discovery by sending a DNS query to its local resolver, with record type SOA [RFC1035], for the domain name to which it wishes to subscribe. 2. If the SOA record exists, it MUST be returned in the Answer Section of the response. If not, the local resolver SHOULD include the SOA record for the zone of the requested name in the Authority Section. The second sentence seems self-contradictory: "If the SOA record doesn't = exist, include the SOA record in the Authority Section." Minor editorial nit: In the "NOTE:" at the end of section 6.2.1, s/were/where/ - Ralph > On Apr 6, 2017, at 4:59 AM, Tim Chown wrote: >=20 > Hi, >=20 > We have had no comments on this WGLC. >=20 > In order to progress the draft to our AD/IESG we need some positive = expressions of support; please do try to find some time to read and = comment on the document. >=20 > We=E2=80=99ll extend the WGLC until next Friday, 14th April, given we = are also waiting on a WGLC for the DNS session signalling draft used by = DNS Push. >=20 > Many thanks, > Tim & Ralph >=20 >> On 21 Mar 2017, at 11:24, Tim Chown wrote: >>=20 >> Dear dnssd WG participants, >>=20 >> 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 >>=20 >> The call runs for two weeks, and will thus close on Tuesday 4th = April. >>=20 >> Please send any comments, which includes indications of support for = progression of the document as is, to the dnssd@ietf.org list. Such = statements of support are important; this draft will not be advanced for = publication unless there is sufficient response and support from the WG. = =20 >>=20 >> 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. >>=20 >> We are expecting the associated DNS session signalling draft to also = go through WGLC in the dnsop WG in the next couple of weeks, with the = aim of both documents being published together. >>=20 >> 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. >>=20 >> Best wishes, >>=20 >> Ralph and Tim >> dnssd WG co-chairs >>=20 >>=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Thu Apr 13 18:05:22 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 20E7B1270A7 for ; Thu, 13 Apr 2017 18:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tC1fQ5s_aF6n for ; Thu, 13 Apr 2017 18:05:19 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B081127876 for ; Thu, 13 Apr 2017 18:05:18 -0700 (PDT) Received: from [172.30.6.40] (rrcs-67-53-196-2.west.biz.rr.com [67.53.196.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id C1EB326C4D; Thu, 13 Apr 2017 20:57:02 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tom Pusateri In-Reply-To: <9A671E6C-369C-48F8-A310-2BF40BA9F856@gmail.com> Date: Thu, 13 Apr 2017 15:05:15 -1000 Cc: "dnssd@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <16076F38-42A1-4F9D-991A-C362BB549B14@bangj.com> References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> <9A671E6C-369C-48F8-A310-2BF40BA9F856@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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: Fri, 14 Apr 2017 01:05:21 -0000 > On Apr 13, 2017, at 12:26 PM, Ralph Droms = wrote: >=20 > I think draft-ietf-dnssd-push-10 is ready to be forwarded to the = IESG, after the following comment is addressed: >=20 > I found the second item in the list in section 6.1 confusing: >=20 > 6.1. Discovery >=20 > The first step in DNS Push Notification subscription is to discover > an appropriate DNS server that supports DNS Push Notifications for > the desired zone. The client MUST also determine which TCP port on > the server is listening for connections, which need not be (and = often > is not) the typical TCP port 53 used for conventional DNS, or TCP > port 853 used for DNS over TLS [RFC7858]. >=20 > 1. The client begins the discovery by sending a DNS query to its > local resolver, with record type SOA [RFC1035], for the domain > name to which it wishes to subscribe. >=20 > 2. If the SOA record exists, it MUST be returned in the Answer > Section of the response. If not, the local resolver SHOULD > include the SOA record for the zone of the requested name in the > Authority Section. >=20 > The second sentence seems self-contradictory: "If the SOA record = doesn't exist, include the SOA record in the Authority Section.=E2=80=9D >=20 It=E2=80=99s not contradictory but could be worded better. =46rom the LLQ draft: The client begins by sending a standard DNS query for the name of the LLQ, with type SOA. The server MUST answer with that SOA record in the Answer section, if the record exists. The server SHOULD include an SOA record for that name's zone in the Authority section, if the LLQ name (type SOA) does not exist. For example, a query for _ftp._tcp.apple.com. may return an SOA record named apple.com. in the Authority section if there is no SOA record named _ftp._tcp.apple.com. If, in this case, the server does not include the SOA record in the Authority section, the client strips the leading label from the name and tries again, repeating until an answer is received. We can make this more clear. > Minor editorial nit: >=20 > In the "NOTE:" at the end of section 6.2.1, s/were/where/ Fixed. Thanks, Tom >=20 > - Ralph >=20 >> On Apr 6, 2017, at 4:59 AM, Tim Chown wrote: >>=20 >> Hi, >>=20 >> We have had no comments on this WGLC. >>=20 >> In order to progress the draft to our AD/IESG we need some positive = expressions of support; please do try to find some time to read and = comment on the document. >>=20 >> We=E2=80=99ll extend the WGLC until next Friday, 14th April, given we = are also waiting on a WGLC for the DNS session signalling draft used by = DNS Push. >>=20 >> Many thanks, >> Tim & Ralph >>=20 >>> On 21 Mar 2017, at 11:24, Tim Chown wrote: >>>=20 >>> Dear dnssd WG participants, >>>=20 >>> 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 >>>=20 >>> The call runs for two weeks, and will thus close on Tuesday 4th = April. >>>=20 >>> Please send any comments, which includes indications of support for = progression of the document as is, to the dnssd@ietf.org list. Such = statements of support are important; this draft will not be advanced for = publication unless there is sufficient response and support from the WG. = =20 >>>=20 >>> 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. >>>=20 >>> We are expecting the associated DNS session signalling draft to also = go through WGLC in the dnsop WG in the next couple of weeks, with the = aim of both documents being published together. >>>=20 >>> 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. >>>=20 >>> Best wishes, >>>=20 >>> Ralph and Tim >>> dnssd WG co-chairs >>>=20 >>>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Fri Apr 14 04:56:35 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 299E812EB7F for ; Fri, 14 Apr 2017 04:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7fBVq8KzzA6 for ; Fri, 14 Apr 2017 04:56:30 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 989EF12EB9D for ; Fri, 14 Apr 2017 04:56:28 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id f133so66768608qke.2 for ; Fri, 14 Apr 2017 04:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Zhg4moD/Sz+tihniwTxQCeKAA/3dpnVWp8V4xJ2F94Q=; b=gI5EMFGOEpNlzDzyINqhjT0uqEZNGlL5FmDYHiJkGXBt4yNfKzsZqlMOeknRDeA/fl Fq6YHF+mYHlfl4+ddwQSDvi5xBTg3VVLsUqIJ0/WndG8rhhhTVvHx0gfnuVIsN5dv+yY FYt/tGbA2fIeSSJMOBY6hu+55MtVEUdaRpEYifYXx5sd2ci3X0lZWhIITpeJ9wK3pl6f YN3q2JNr6daIWO7fm4+LMZjFt6D2tTrKKraca58Sh6e+EEsxapzxZpxIqa+DG+lfi2a9 7PnI3S85Nm9ipOrY2rR3MOSxx9ZVGNVxjc6RnRM02TzUvAtUQMpazTyct7yWcrZFSNdB JB5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Zhg4moD/Sz+tihniwTxQCeKAA/3dpnVWp8V4xJ2F94Q=; b=r+B6ojxxisecOeaKFVCU2r+TXrug+D1VN+1wMqLhC3hJ1INHJQRGR8w3+bGeGw54tT UEEECcuLU4w3pTyRZslBXRNWQcjnUDRcgimVKoRfp8Q8/PTaEpe9k2SdnGkRuxXWf9Ip wuWYkf6UtiW037ap0+aZ3r+k0yt/2Q/EWI/rhkRnPfE0rW3kJHtkEB1vKYN18SiLYbw7 viXPTY4+3ofXmQcha4u4M5m6Mrcs+xIclWM0fr/4tRI+J0n9YHLMfF8VkZY7//P3TeJC Lxtz1xVtQG9T7JUXZpMATieDV2TH7bTD+O3EXXypVx7DUeeJVBcFQSBJ6U4294dIz+hu DJ4A== X-Gm-Message-State: AN3rC/6YKcyu1AHsZLIX2mC8vwTPOW36A+UeufdlU5xtB+1fRrAXcscB w2ZC6MmK6ONIgKMh0CE= X-Received: by 10.55.108.68 with SMTP id h65mr7350692qkc.302.1492170987795; Fri, 14 Apr 2017 04:56:27 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:c4a8:6e8:c7e7:abee? ([2601:18f:801:600:c4a8:6e8:c7e7:abee]) by smtp.gmail.com with ESMTPSA id 94sm1101216qte.37.2017.04.14.04.56.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 04:56:27 -0700 (PDT) From: Ralph Droms Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_14B63A0A-44DF-4127-BBDA-0E9AD02713B7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Apr 2017 07:56:25 -0400 In-Reply-To: <16076F38-42A1-4F9D-991A-C362BB549B14@bangj.com> Cc: "dnssd@ietf.org" To: Tom Pusateri References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> <9A671E6C-369C-48F8-A310-2BF40BA9F856@gmail.com> <16076F38-42A1-4F9D-991A-C362BB549B14@bangj.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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: Fri, 14 Apr 2017 11:56:33 -0000 --Apple-Mail=_14B63A0A-44DF-4127-BBDA-0E9AD02713B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 13, 2017, at 9:05 PM, Tom Pusateri wrote: >=20 >>=20 >> On Apr 13, 2017, at 12:26 PM, Ralph Droms = wrote: >>=20 >> I think draft-ietf-dnssd-push-10 is ready to be forwarded to the = IESG, after the following comment is addressed: >>=20 >> I found the second item in the list in section 6.1 confusing: >>=20 >> 6.1. Discovery >>=20 >> The first step in DNS Push Notification subscription is to discover >> an appropriate DNS server that supports DNS Push Notifications for >> the desired zone. The client MUST also determine which TCP port on >> the server is listening for connections, which need not be (and = often >> is not) the typical TCP port 53 used for conventional DNS, or TCP >> port 853 used for DNS over TLS [RFC7858]. >>=20 >> 1. The client begins the discovery by sending a DNS query to its >> local resolver, with record type SOA [RFC1035], for the domain >> name to which it wishes to subscribe. >>=20 >> 2. If the SOA record exists, it MUST be returned in the Answer >> Section of the response. If not, the local resolver SHOULD >> include the SOA record for the zone of the requested name in the >> Authority Section. >>=20 >> The second sentence seems self-contradictory: "If the SOA record = doesn't exist, include the SOA record in the Authority Section.=E2=80=9D >>=20 >=20 > It=E2=80=99s not contradictory but could be worded better. >=20 > =46rom the LLQ draft: >=20 > The client begins by sending a standard DNS query for the name of = the > LLQ, with type SOA. The server MUST answer with that SOA record in > the Answer section, if the record exists. The server SHOULD include > an SOA record for that name's zone in the Authority section, if the > LLQ name (type SOA) does not exist. For example, a query for > _ftp._tcp.apple.com . may return an SOA = record named apple.com . in the > Authority section if there is no SOA record named > _ftp._tcp.apple.com . If, in this case, the = server does not include > the SOA record in the Authority section, the client strips the > leading label from the name and tries again, repeating until an > answer is received. >=20 > We can make this more clear. Got it. One change that would clarify the example from the LLQ draft = (at least clarify for me) would be to use an initial request for which = the zone is not simply the original FQDN with the service specifiers = stripped off. E.g.: for the query _ftp._tcp.bldg1.apple.com, the SOA = record in the Authority section would be apple.com. This SOA record = would result in a different query in the next step, rather than simply = re-issuing the same request. - Ralph >=20 >> Minor editorial nit: >>=20 >> In the "NOTE:" at the end of section 6.2.1, s/were/where/ >=20 > Fixed. >=20 > Thanks, > Tom >=20 >=20 >>=20 >> - Ralph >>=20 >>> On Apr 6, 2017, at 4:59 AM, Tim Chown wrote: >>>=20 >>> Hi, >>>=20 >>> We have had no comments on this WGLC. >>>=20 >>> In order to progress the draft to our AD/IESG we need some positive = expressions of support; please do try to find some time to read and = comment on the document. >>>=20 >>> We=E2=80=99ll extend the WGLC until next Friday, 14th April, given = we are also waiting on a WGLC for the DNS session signalling draft used = by DNS Push. >>>=20 >>> Many thanks, >>> Tim & Ralph >>>=20 >>>> On 21 Mar 2017, at 11:24, Tim Chown wrote: >>>>=20 >>>> Dear dnssd WG participants, >>>>=20 >>>> 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 >>>>=20 >>>> The call runs for two weeks, and will thus close on Tuesday 4th = April. >>>>=20 >>>> Please send any comments, which includes indications of support for = progression of the document as is, to the dnssd@ietf.org list. Such = statements of support are important; this draft will not be advanced for = publication unless there is sufficient response and support from the WG. = =20 >>>>=20 >>>> 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. >>>>=20 >>>> We are expecting the associated DNS session signalling draft to = also go through WGLC in the dnsop WG in the next couple of weeks, with = the aim of both documents being published together. >>>>=20 >>>> 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. >>>>=20 >>>> Best wishes, >>>>=20 >>>> Ralph and Tim >>>> dnssd WG co-chairs >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd = --Apple-Mail=_14B63A0A-44DF-4127-BBDA-0E9AD02713B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 13, 2017, at 9:05 PM, Tom Pusateri <pusateri@bangj.com> = wrote:


On Apr 13, 2017, at 12:26 PM, Ralph = Droms <rdroms.ietf@gmail.com> wrote:

I think draft-ietf-dnssd-push-10  is ready to be = forwarded to the IESG, after the following comment is addressed:

I found the second item in the list in section = 6.1 confusing:

6.1.  Discovery

 The first step in DNS Push Notification = subscription is to discover
 an appropriate DNS = server that supports DNS Push Notifications for
 the = desired zone.  The client MUST also determine which TCP port on
 the server is listening for connections, which need not = be (and often
 is not) the typical TCP port 53 used = for conventional DNS, or TCP
 port 853 used for DNS = over TLS [RFC7858].

 1.  The = client begins the discovery by sending a DNS query to its
     local resolver, with record = type SOA [RFC1035], for the domain
     name to which it wishes to = subscribe.

 2.  If the SOA record = exists, it MUST be returned in the Answer
     Section of the response. =  If not, the local resolver SHOULD
     include the SOA record for the = zone of the requested name in the
     Authority Section.

The second sentence seems self-contradictory: = "If the SOA record doesn't exist, include the SOA record in the = Authority Section.=E2=80=9D


It=E2=80=99s not contradictory but could be = worded better.

=46rom the LLQ = draft:

  The = client begins by sending a standard DNS query for the name of = the
  LLQ, with type SOA. The = server MUST answer with that SOA record in
  the = Answer section, if the record exists. The server SHOULD = include
  an SOA record for that name's = zone in the Authority section, if the
  LLQ = name (type SOA) does not exist. For example, a query for
  _ftp._tcp.apple.com. may return an SOA = record named apple.com. in the
  Authority section if there is no SOA = record named
  _ftp._tcp.apple.com. If, in this case, = the server does not include
  the SOA = record in the Authority section, the client strips the
  leading label from the name and = tries again, repeating until an
  answer = is received.

We can make this = more clear.

Got it.  One change that would clarify the example = from the LLQ draft (at least clarify for me) would be to use an initial = request for which the zone is not simply the original FQDN with the = service specifiers stripped off.  E.g.: for the query _ftp._tcp.bldg1.apple.com, = the SOA record in the Authority section would be apple.com.  This SOA = record would result in a different query in the next step, rather than = simply re-issuing the same request.

- = Ralph


Minor editorial nit:

In the = "NOTE:" at the end of section 6.2.1, s/were/where/

Fixed.

Thanks,
Tom



- Ralph

On Apr 6, = 2017, at 4:59 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

Hi,

We have had no comments on = this WGLC.

In order to progress the draft = to our AD/IESG we need some positive expressions of support; please do = try to find some time to read and comment on the document.

We=E2=80=99ll extend the WGLC until next = Friday, 14th April, given we are also waiting on a WGLC for the DNS = session signalling draft used by DNS Push.

Many thanks,
Tim & Ralph

On 21 Mar 2017, at = 11:24, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

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 support for progression of the = document as is, to the dnssd@ietf.org list.  Such statements 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 draft = 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 = 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



_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_14B63A0A-44DF-4127-BBDA-0E9AD02713B7-- From nobody Fri Apr 14 10:05: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 CB83D129516 for ; Fri, 14 Apr 2017 10:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 oBmWSZrqO85x for ; Fri, 14 Apr 2017 10:05:23 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0773C12946C for ; Fri, 14 Apr 2017 10:05:23 -0700 (PDT) Received: from [62.232.251.194] (port=22112 helo=[192.168.12.23]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cz4et-0001mY-FI for dnssd@ietf.org; Fri, 14 Apr 2017 18:05:21 +0100 From: Sara Dickinson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Apr 2017 18:05:14 +0100 References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> To: "dnssd@ietf.org" In-Reply-To: Message-Id: <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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: Fri, 14 Apr 2017 17:05:25 -0000 HI All,=20 This draft looks in very good shape to me. I have a couple of minor = comments: - I think there could be a reference to RFC7858 at the end of the second = paragraph in Section 4. - Section 6.4.1 discusses clients having 2 messages in flight with the = same MESSAGE ID (SUBSCRIBE and UNSUBSCRIBE). This is a valid use case in = this context but it does conflict with the statement in RFC7766 =E2=80=9CW= hen sending multiple queries over a TCP connection, clients MUST NOT = reuse the DNS Message ID of an in-flight query on that connection in = order to avoid Message ID collisions. =E2=80=9C. I think it would be = helpful to point out this exception and in fact I think that means this = draft technically updates RFC7766? - Section 7 - I think it would help if there was a reference to = draft-ietf-dprive-dtls-and-tls-profiles - the discussion of server = authentication here overlaps with that draft. Also a reference to = section 9 of draft-ietf-dprive-dtls-and-tls-profiles could be used = instead of sections 7.3 and 7.4 as that document already makes = recommendations about following RFC7525, TLS Session resumption and = similar.=20 Sara.=20 > On 6 Apr 2017, at 09:59, Tim Chown wrote: >=20 > Hi, >=20 > We have had no comments on this WGLC. >=20 > In order to progress the draft to our AD/IESG we need some positive = expressions of support; please do try to find some time to read and = comment on the document. >=20 > We=E2=80=99ll extend the WGLC until next Friday, 14th April, given we = are also waiting on a WGLC for the DNS session signalling draft used by = DNS Push. >=20 > Many thanks, > Tim & Ralph >=20 >> On 21 Mar 2017, at 11:24, Tim Chown wrote: >>=20 >> Dear dnssd WG participants, >>=20 >> 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 >>=20 >> The call runs for two weeks, and will thus close on Tuesday 4th = April. >>=20 >> Please send any comments, which includes indications of support for = progression of the document as is, to the dnssd@ietf.org list. Such = statements of support are important; this draft will not be advanced for = publication unless there is sufficient response and support from the WG. = =20 >>=20 >> 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. >>=20 >> We are expecting the associated DNS session signalling draft to also = go through WGLC in the dnsop WG in the next couple of weeks, with the = aim of both documents being published together. >>=20 >> 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. >>=20 >> Best wishes, >>=20 >> Ralph and Tim >> dnssd WG co-chairs >>=20 >>=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Fri Apr 14 12:04:16 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 B3F1112953D for ; Fri, 14 Apr 2017 12:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YiYodD-4L-s for ; Fri, 14 Apr 2017 12:04:12 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 A6853126DDF for ; Fri, 14 Apr 2017 12:04:12 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id f133so73036892qke.2 for ; Fri, 14 Apr 2017 12:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U091zL23mrPNA5MfcywGu6jeKYC/BR6yfTm1yrjGdsQ=; b=KA9WJI8iqb5NlhzoOJVKZVTndxNqirfjwd6poIAYIpWKyz8WEF4E1oARe3QMaZNbKg 1e1Al5pDRGg7aGDAzX4Hp+VzwGvUUBvAtcXrsFnzGEE0gTCJWUP+RQnXczQdlehw83CN 7ZbIfLHstBVI+VkEjH6en3V/qnnhPIIW/DEzH1fvLrMIQRy0DFUQPtwKy5R+DcCcecap c3PvjeIecOxQfuufux/eSaOdxirjOK0/T5vkRMklgNi/JlOVhgOoFAhRq4sE7m4FYrzP 3Y3xs4IF8hDqymt+Q5mXsEb055nDeXoD7rL+kyhTAsV7V8T9UtJmTSiUjMVwQjNmc8Kl EqKw== 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=U091zL23mrPNA5MfcywGu6jeKYC/BR6yfTm1yrjGdsQ=; b=X0J/gNH8wLMfpJeFx0c2SveqrKjta1FvpIxev3noAt2QkAlsMOfx+sAVV5hrDkuaQU gjgvCN1HRFeD5S6BhxNpCADNssmB2LfOvt2qAQWrijP0i5fCCdOum7KxRCH6JCrfEKci z9aTx9BQ/+IZRNK4IUAn9CmN2SgjTRQfxidbnhMEtKFIHGM/RW/MCXhrcIg70JZWBDWn gfH2WolvilKOM5ekMOSc4F4vuRUeZ8XnbwdMd8AGUOynQHjqHSZcXKSrlYqt748wfmfm 3ObwS5MxK1r3QKn+/tmPVrcLsC850Lbx3WUys9rM6FWHDQRe5PGbkibYSEd7oKRcVrP9 imag== X-Gm-Message-State: AN3rC/4UNJc0IKMKfHOZ+XixH+KqYUqHmV5DagMS4NVYSjzxNnaaGSqH ahetTsNvIzji5/P3/kg= X-Received: by 10.55.41.206 with SMTP id p75mr9034720qkp.240.1492196651797; Fri, 14 Apr 2017 12:04:11 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:c83f:b1ca:ba4c:6d04? ([2601:18f:801:600:c83f:b1ca:ba4c:6d04]) by smtp.gmail.com with ESMTPSA id m130sm1732811qke.66.2017.04.14.12.04.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 12:04:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ralph Droms In-Reply-To: <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> Date: Fri, 14 Apr 2017 15:04:08 -0400 Cc: "dnssd@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0726BAF6-F647-4C7E-AC35-06C26534027C@gmail.com> References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> To: Sara Dickinson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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: Fri, 14 Apr 2017 19:04:15 -0000 Thanks for your review, Sara. Everyone - we have still received only minimal response to the WG last = call, and we really need more support for consensus to progress the = draft to the IESG. Please review the document and respond to the = mailing list - even a simple "I've read the draft and it's ready to go = to the IESG" is helpful. - Ralph > On Apr 14, 2017, at 1:05 PM, Sara Dickinson wrote: >=20 > HI All,=20 >=20 > This draft looks in very good shape to me. I have a couple of minor = comments: >=20 > - I think there could be a reference to RFC7858 at the end of the = second paragraph in Section 4. >=20 > - Section 6.4.1 discusses clients having 2 messages in flight with the = same MESSAGE ID (SUBSCRIBE and UNSUBSCRIBE). This is a valid use case in = this context but it does conflict with the statement in RFC7766 =E2=80=9CW= hen sending multiple queries over a TCP connection, clients MUST NOT = reuse the DNS Message ID of an in-flight query on that connection in = order to avoid Message ID collisions. =E2=80=9C. I think it would be = helpful to point out this exception and in fact I think that means this = draft technically updates RFC7766? >=20 > - Section 7 - I think it would help if there was a reference to = draft-ietf-dprive-dtls-and-tls-profiles - the discussion of server = authentication here overlaps with that draft. Also a reference to = section 9 of draft-ietf-dprive-dtls-and-tls-profiles could be used = instead of sections 7.3 and 7.4 as that document already makes = recommendations about following RFC7525, TLS Session resumption and = similar.=20 >=20 > Sara.=20 >=20 >=20 >> On 6 Apr 2017, at 09:59, Tim Chown wrote: >>=20 >> Hi, >>=20 >> We have had no comments on this WGLC. >>=20 >> In order to progress the draft to our AD/IESG we need some positive = expressions of support; please do try to find some time to read and = comment on the document. >>=20 >> We=E2=80=99ll extend the WGLC until next Friday, 14th April, given we = are also waiting on a WGLC for the DNS session signalling draft used by = DNS Push. >>=20 >> Many thanks, >> Tim & Ralph >>=20 >>> On 21 Mar 2017, at 11:24, Tim Chown wrote: >>>=20 >>> Dear dnssd WG participants, >>>=20 >>> 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 >>>=20 >>> The call runs for two weeks, and will thus close on Tuesday 4th = April. >>>=20 >>> Please send any comments, which includes indications of support for = progression of the document as is, to the dnssd@ietf.org list. Such = statements of support are important; this draft will not be advanced for = publication unless there is sufficient response and support from the WG. = =20 >>>=20 >>> 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. >>>=20 >>> We are expecting the associated DNS session signalling draft to also = go through WGLC in the dnsop WG in the next couple of weeks, with the = aim of both documents being published together. >>>=20 >>> 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. >>>=20 >>> Best wishes, >>>=20 >>> Ralph and Tim >>> dnssd WG co-chairs >>>=20 >>>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Fri Apr 14 13:40: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 CDFF7129562 for ; Fri, 14 Apr 2017 13:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 wWD1RRyxLK9n for ; Fri, 14 Apr 2017 13:40:34 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 2DA9712957A for ; Fri, 14 Apr 2017 13:40:34 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id g60so4980459qtd.3 for ; Fri, 14 Apr 2017 13:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fCIcAOaemXR7JmF1nZpNo1mS95KBenNJFK3aOZfxc0s=; b=zJe2hKCVD9dCSIlNf3kGhtiWpBWv5Mm51l5O4U3CzDrCEwEDs/zaSFsmRJNTPktWXg 6MQuSByKNwhX7jzuwVg3TS6xlf6TcLQhJI7IFAJk4zOwrPGVbnOBd1zQ8wf9pIqPzWvf vRCovqHOAZpg+lLo+uiMpYgT9y0YoDFNdWiu3ZqRq4ySXaAXjfcdPuH/g75f+mUPQT2p yCP6MhrcWtcOH7DC4F6XT7jMdQSkzlKRvfdpMwoe3onO1j/RJ3suegr/9tgi5Bk4dFe5 VzrD4J5PW1Wff/uun6RThNlAbTCgcFsypV+8KLvMrB6EmRAEiS4w+h83MOEPjNgSoCq7 hfdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fCIcAOaemXR7JmF1nZpNo1mS95KBenNJFK3aOZfxc0s=; b=ipH8r6w7Se60k7/p3Q5Z+tBJTbQR4xLHJBCAdP9yMEfNEpyqfNeC8XUDUeaPD6dsYw lKt8/vLe9apGuTIh+bYOsJCg7pdSD67M61BgKFri+PCwh7G0Owms113WBQ2Wh/9dY91N P5n1b+XY/AVmzEmrIXFfMlN9j8kXINjmvT5NbdD+CBoKneBwD7BZyMi99QxzWmiOG0TI SvNZa3EP+GEolrFvfdelwBgfPRvQXtFD0a6hjLS/mzpzqBURcLtNUB2NTgcr0sMeWzoE Nun2YXcmL0nGy0GdJfv8DSixfbnYTFRSJ6K9A26BeUgXn/c/JkTEkjyt53ORrUeNw/pM OyGA== X-Gm-Message-State: AN3rC/71ILHnzMwLZt+14xrUaRCrl1fwK8Wf9ErsISA6Mwl3xxi3rqFy 2IvzPJrUs662fg== X-Received: by 10.200.36.131 with SMTP id s3mr9862238qts.289.1492202433417; Fri, 14 Apr 2017 13:40:33 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n65sm1905334qka.27.2017.04.14.13.40.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 13:40:32 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A1893AC7-405C-4DE7-A86F-E5740F3677AD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Apr 2017 16:40:30 -0400 In-Reply-To: <0726BAF6-F647-4C7E-AC35-06C26534027C@gmail.com> Cc: "dnssd@ietf.org" To: Ralph Droms References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> <0726BAF6-F647-4C7E-AC35-06C26534027C@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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: Fri, 14 Apr 2017 20:40:36 -0000 --Apple-Mail=_A1893AC7-405C-4DE7-A86F-E5740F3677AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 14, 2017, at 3:04 PM, Ralph Droms wrote: > Everyone - we have still received only minimal response to the WG last = call, and we really need more support for consensus to progress the = draft to the IESG. I don't get that. The working group agreed to adopt the work, the work = was done, it's been reviewed, I've never understood why at this point in = the process we need a show of hands to say "yes, publish it." = Nevertheless, FWIW, yes, publish it. --Apple-Mail=_A1893AC7-405C-4DE7-A86F-E5740F3677AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 14, 2017, at 3:04 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
Everyone - we have still received only = minimal response to the WG last call, and we really need more support = for consensus to progress the draft to the = IESG.

I = don't get that.   The working group agreed to adopt the work, the = work was done, it's been reviewed, I've never understood why at this = point in the process we need a show of hands to say "yes, publish it." =   Nevertheless, FWIW, yes, publish it.

= --Apple-Mail=_A1893AC7-405C-4DE7-A86F-E5740F3677AD-- From nobody Fri Apr 14 20:14:31 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 7CABF1272E1 for ; Fri, 14 Apr 2017 20:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GoXItsqD8qbK for ; Fri, 14 Apr 2017 20:14:28 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD04F1288B8 for ; Fri, 14 Apr 2017 20:14:27 -0700 (PDT) Received: from unk-426d04f9.adelphiacom.net (unknown [107.14.56.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id EB75326E39; Fri, 14 Apr 2017 23:06:07 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tom Pusateri In-Reply-To: <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> Date: Fri, 14 Apr 2017 17:14:23 -1000 Cc: "dnssd@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> To: Sara Dickinson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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: Sat, 15 Apr 2017 03:14:30 -0000 Thanks for the review Sara. The last paragraph of section 6.4.1 needs to be removed. It was left = over from previous versions where the message id was 0. We now expect = SUBSCRIBE and UNSUBSCRIBE requests (even overlapping ones) to have = unique message IDs and will fully conform with RFC 7766. I=E2=80=99ll add the appropriate references to the profiles draft. Tom > On Apr 14, 2017, at 7:05 AM, Sara Dickinson wrote: >=20 > HI All,=20 >=20 > This draft looks in very good shape to me. I have a couple of minor = comments: >=20 > - I think there could be a reference to RFC7858 at the end of the = second paragraph in Section 4. >=20 > - Section 6.4.1 discusses clients having 2 messages in flight with the = same MESSAGE ID (SUBSCRIBE and UNSUBSCRIBE). This is a valid use case in = this context but it does conflict with the statement in RFC7766 =E2=80=9CW= hen sending multiple queries over a TCP connection, clients MUST NOT = reuse the DNS Message ID of an in-flight query on that connection in = order to avoid Message ID collisions. =E2=80=9C. I think it would be = helpful to point out this exception and in fact I think that means this = draft technically updates RFC7766? >=20 > - Section 7 - I think it would help if there was a reference to = draft-ietf-dprive-dtls-and-tls-profiles - the discussion of server = authentication here overlaps with that draft. Also a reference to = section 9 of draft-ietf-dprive-dtls-and-tls-profiles could be used = instead of sections 7.3 and 7.4 as that document already makes = recommendations about following RFC7525, TLS Session resumption and = similar.=20 >=20 > Sara.=20 >=20 >=20 >> On 6 Apr 2017, at 09:59, Tim Chown wrote: >>=20 >> Hi, >>=20 >> We have had no comments on this WGLC. >>=20 >> In order to progress the draft to our AD/IESG we need some positive = expressions of support; please do try to find some time to read and = comment on the document. >>=20 >> We=E2=80=99ll extend the WGLC until next Friday, 14th April, given we = are also waiting on a WGLC for the DNS session signalling draft used by = DNS Push. >>=20 >> Many thanks, >> Tim & Ralph >>=20 >>> On 21 Mar 2017, at 11:24, Tim Chown wrote: >>>=20 >>> Dear dnssd WG participants, >>>=20 >>> 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 >>>=20 >>> The call runs for two weeks, and will thus close on Tuesday 4th = April. >>>=20 >>> Please send any comments, which includes indications of support for = progression of the document as is, to the dnssd@ietf.org list. Such = statements of support are important; this draft will not be advanced for = publication unless there is sufficient response and support from the WG. = =20 >>>=20 >>> 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. >>>=20 >>> We are expecting the associated DNS session signalling draft to also = go through WGLC in the dnsop WG in the next couple of weeks, with the = aim of both documents being published together. >>>=20 >>> 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. >>>=20 >>> Best wishes, >>>=20 >>> Ralph and Tim >>> dnssd WG co-chairs >>>=20 >>>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Sun Apr 16 07:53: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 EF905128B93 for ; Sun, 16 Apr 2017 07:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=OPaLbAsL; dkim=pass (1024-bit key) header.d=yitter.info header.b=G3lYNO3Y 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 kyZpDQa23dg4 for ; Sun, 16 Apr 2017 07:53:48 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DD1126C25 for ; Sun, 16 Apr 2017 07:53:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 381DABD996 for ; Sun, 16 Apr 2017 14:53:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492354397; bh=va5zhTL1WajQdOv+tqnSN3ytQA+K+lsbVR61PpME71M=; h=Date:From:To:Subject:References:In-Reply-To:From; b=OPaLbAsL2cz39FknxPQ3ITzgql/S6SObHjAHJbwcgVn93XRIQGqKVqs3TEkDS/aH1 EO+j6gEOEvmqM8mRXPCTFse4LD72oiLAuAEWqokpQ4wTI5fHrYWwgjyc/1i94Q3WdI dHex/YkOs/KG9sLTVYYWfWpa5Aj0pEkExj4HjoWs= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd7CqBFkpTM0 for ; Sun, 16 Apr 2017 14:53:15 +0000 (UTC) Date: Sun, 16 Apr 2017 14:52:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492354395; bh=va5zhTL1WajQdOv+tqnSN3ytQA+K+lsbVR61PpME71M=; h=Date:From:To:Subject:References:In-Reply-To:From; b=G3lYNO3YbJLUB3LEt5KtlaBkt1P0vX3aUus4sG6ojdCZ9kIceyhf7usOEqpFy9Z5A HjBOc3pwxSTvXCL55hR+vfJXJ0vR9ivbqyfVAk0W6x9MeCI/sAvB2Wr6CArY0E2qE2 qOnJyz7d7erbEikKfXvVfodC/kcuT8DgJxwHqGtU= From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20170416145239.GB21074@mx4.yitter.info> References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> <0726BAF6-F647-4C7E-AC35-06C26534027C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0726BAF6-F647-4C7E-AC35-06C26534027C@gmail.com> Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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, 16 Apr 2017 14:53:50 -0000 Hi, This review is late. It has been an interesting couple of weeks learning how the new corporate masters do things. Many apologies for being late. If this is too late to be useful, I apologise for that too. I hadn't looked carefully at this document in some time. It's in good shape. There are a few nits below that could use addressing, but none are AFACIT fatal. In general, I like this document and I've been looking forward to its publication; it should be published. The review text below is a little telegraphic in style because I was running out of battery. In section 3 there's a reference to RFC 1996. I wonder whether RFC 7719 might be better, since it appears to be about the terms. What should a server do if it gets a query over the open TCP connection with the RD bit set? What about for a zone outside the server's bailiwick? REFUSED? (In general, there are a bunch of requirements that create error conditions, where it isn't clear what the right answer is. These are perhaps answered in the tables of RCODEs later, but if so a forward reference would be better.) SRV records are discussed here but mystifying until you get to 6.1. Maybe a forward reference? Classes are included but implementations are permitted not to support them. What do you do if you get a query for a class you don't support? This seems strange. (It is possible to leave classes other than IN undefined, though it seems sticky. I tried to get DNSOP to deprecate classes, but I got pushback.) "DNS Push Notification clients MUST NOT recklessly create an excessive" I don't know what MUST NOT means there; I think it's guidance, not protocol spec. (In general, throughout the draft there are uses of 2119 language that don't really create protocol rules, so that might be revisited). In section 6, DNS Push Notification clients and servers MUST support DNS Session Signaling, but the server MUST NOT issue any DNS Session Signaling operations until after the client has first initiated a DNS Session Signaling operation of its own. Why MUST NOT? Session signalling only says SHOULD NOT. I can imagine a server in a network that is closely managed having the ability to be certain of what all the clients can do (or, what's the same, not caring because such clients shoukdn't be there). I think what item 2 of 6.1 is saying is that you need a NOERROR/NODATA response with an SOA in the authority section (it's intially a little confusing, because it seems like you have to put the SOA of the non-existent zone in the authority, but that doesn't make any sense so that couldn't be it :). Maybe a reference to RFC 2308 would be helpful? In step 3, does that mean "no SOA in the response message at all, in any section"? There sometimes appears to be an ambiguity in what people mean by "returned" for a DNS query -- it often means the Answer section, and in that interpretation step 3 would cause an extra unneeded query, which I'm sure isn't the goal. In step 5, I'm a little leery of the MUST NOT exist. Since there's no way to constrain what people might put in their zones if they don't implement this specification, that's not really a rule one can make. Maybe, "For implemneters of this specification, an authoritative answer for that SRV record, and only such an answer, will determine whether the zone supports DNS Push Notifications"? The point is that you can't control whether a non-implemnter will put such an SRV in a zone, but you can say what an implementation of this spec will do. Each time a client makes a new DNS Push Notification subscription connection, it SHOULD repeat the discovery process in order to determine the preferred DNS server for subscriptions at that time. and the following paragraph is a little surprising, because couldn't you subscribe to the SRV record itself and thereby get notified when a zone's rules change? Anyway, if you're going to query for the same SOA again within the TTL window, you're likely to tickle RRL. Why can't you use the cached SOA and SRV record for the length of the TTL? In 6.2, what should happen if a server does issue a Subscribe request? Ignore it? In 6.2.1, do all errors result in TCP RST or just the duplicate queries? (Apparently not given 6.2.2.) Why is this required? Why not just ignore the request? The CNAME handling is a little strange. CNAME is defined as canonical name, so formally it means that the owner name just _is_ the target. I think what is meant here, however, is that a CNAME in the query is interpreted as matching the CNAME record itself, and on the server side the CNAME expansion is not performed. Right? (This comes up again later.) The discussion of ALL vs ANY here is a little surprising to me. It seems to me that the semantics in this case are the same, because you can only get these notifications from a server that is authoritative, no? ANY in that case does effectively mean ALL, but that's an accident. I'm leery of this document making the QTYPE=255 semantics even more convoluted than they already are. In 6.2.2 I'm a little worried about the use of SERVFAIL here. It appears to be somewhat at odds with the regular meaning of this response code. In 6.4, if a client gets an UNSUBSCRIBE request from a server, what should it do? Again, I don't think any of these are fatal, but if they could be cleaned up it might make the document more useful. Best regards, A From nobody Mon Apr 17 06:04:45 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 1ECAC12EC93 for ; Mon, 17 Apr 2017 06:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GanGajOlQY8D for ; Mon, 17 Apr 2017 06:04:42 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F04128D40 for ; Mon, 17 Apr 2017 06:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6410; q=dns/txt; s=iport; t=1492434281; x=1493643881; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rwexeGCk74ly7kg5YKXv26zB3unvgEpj7H/x6IzI2FY=; b=d57ihXA1l9E/OUVbJTcu2OxwYi+Z9UXYqd2jZCOwc10OW8RVcbZTXYDg pvvDdjDr7mfaA39QMwhw1Ugsj6/0lZHYU+HL8+Tn8Kt76QYdkMLOrVsJR H4i+oLhUVPNA/V2Vxoza3105+nnqoDKkp12xbFQVN3GLFcf9IkkSiB0wW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgDWvPRY/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KFZFcb5Rwgg8hC4V4AhqDZT8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECAQEBIREaIAsQAgEIGAICCAEdAgICJQoBFRACBAENBR0EiW4IDqpUg?= =?us-ascii?q?iaLCQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFR4FdK4I5NIRBFgczgkwugjE?= =?us-ascii?q?FljKGaQGHA4MriDaBf4Uwg12GOpQJAR84gQVjFUQRAYZTdYgRAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.37,215,1488844800"; d="scan'208";a="413503155" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2017 13:04:40 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3HD4ePS029588 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Apr 2017 13:04:40 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Apr 2017 08:04:39 -0500 Received: from xch-aln-019.cisco.com ([173.36.7.29]) by XCH-ALN-019.cisco.com ([173.36.7.29]) with mapi id 15.00.1210.000; Mon, 17 Apr 2017 08:04:39 -0500 From: "Jan Komissar (jkomissa)" To: Tom Pusateri , Sara Dickinson CC: "dnssd@ietf.org" Thread-Topic: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) Thread-Index: AQHSrrQt5BVSQhAYcUm1aHehOchuNqHFePoAgACqMoCAA4aGgA== Date: Mon, 17 Apr 2017 13:04:39 +0000 Message-ID: <342F7B95-40B6-4A29-8ED9-C183917394D4@cisco.com> References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.67.117] Content-Type: text/plain; charset="utf-8" Content-ID: <4F30F041208C7644885FE0A25211CCE4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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, 17 Apr 2017 13:04:44 -0000 SGkgVG9tLA0KDQpEb2VzIHRoaXMgbWVhbiB0aGF0IGEgY2xpZW50IG1heSBub3QgdW5zdWJzY3Jp YmUgYSBzdWJzY3JpcHRpb24gdW50aWwgaXQgaGFzIHJlY2VpdmVkIHRoZSByZXNwb25zZSB0byB0 aGUgc3Vic2NyaXB0aW9uIHJlcXVlc3Q/IFlvdSBtYXkgd2FudCB0byBjbGFyaWZ5IHRoYXQgaW4g c2VjdGlvbiA2LjQuMSBwYXJhZ3JhcGggNCwgd2hpY2ggZXhwbGljaXRseSBhbGxvd3MgYW4gdW5z dWJzY3JpYmUgYmVmb3JlIHRoZSBzdWJzY3JpYmUgaXMgYWNrbm93bGVkZ2VkLCBlZmZlY3RpdmVs eSBhbGxvd2luZyB0d28gbWVzc2FnZXMgaW4gZmxpZ2h0IHdpdGggdGhlIHNhbWUgaWQgYXQgdGhl IHNhbWUgdGltZS4gKE9yIGhhcyB0aGVyZSBiZWVuIGEgcHJvdG9jb2wgY2hhbmdlIHRoYXQgSSBt aXNzZWQ/KQ0KDQpSZWdhcmRzLA0KDQpKYW4uDQoNCk9uIDQvMTQvMTcsIDExOjE0IFBNLCAiZG5z c2Qgb24gYmVoYWxmIG9mIFRvbSBQdXNhdGVyaSIgPGRuc3NkLWJvdW5jZXNAaWV0Zi5vcmcgb24g YmVoYWxmIG9mIHB1c2F0ZXJpQGJhbmdqLmNvbT4gd3JvdGU6DQoNCiAgICBUaGFua3MgZm9yIHRo ZSByZXZpZXcgU2FyYS4NCiAgICANCiAgICBUaGUgbGFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA2 LjQuMSBuZWVkcyB0byBiZSByZW1vdmVkLiBJdCB3YXMgbGVmdCBvdmVyIGZyb20gcHJldmlvdXMg dmVyc2lvbnMgd2hlcmUgdGhlIG1lc3NhZ2UgaWQgd2FzIDAuIFdlIG5vdyBleHBlY3QgU1VCU0NS SUJFIGFuZCBVTlNVQlNDUklCRSByZXF1ZXN0cyAoZXZlbiBvdmVybGFwcGluZyBvbmVzKSB0byBo YXZlIHVuaXF1ZSBtZXNzYWdlIElEcyBhbmQgd2lsbCBmdWxseSBjb25mb3JtIHdpdGggUkZDIDc3 NjYuDQogICAgDQogICAgSeKAmWxsIGFkZCB0aGUgYXBwcm9wcmlhdGUgcmVmZXJlbmNlcyB0byB0 aGUgcHJvZmlsZXMgZHJhZnQuDQogICAgDQogICAgVG9tDQogICAgDQogICAgPiBPbiBBcHIgMTQs IDIwMTcsIGF0IDc6MDUgQU0sIFNhcmEgRGlja2luc29uIDxzYXJhQHNpbm9kdW4uY29tPiB3cm90 ZToNCiAgICA+IA0KICAgID4gSEkgQWxsLCANCiAgICA+IA0KICAgID4gVGhpcyBkcmFmdCBsb29r cyBpbiB2ZXJ5IGdvb2Qgc2hhcGUgdG8gbWUuIEkgaGF2ZSBhIGNvdXBsZSBvZiBtaW5vciBjb21t ZW50czoNCiAgICA+IA0KICAgID4gLSBJIHRoaW5rIHRoZXJlIGNvdWxkIGJlIGEgcmVmZXJlbmNl IHRvIFJGQzc4NTggYXQgdGhlIGVuZCBvZiB0aGUgc2Vjb25kIHBhcmFncmFwaCBpbiBTZWN0aW9u IDQuDQogICAgPiANCiAgICA+IC0gU2VjdGlvbiA2LjQuMSBkaXNjdXNzZXMgY2xpZW50cyBoYXZp bmcgMiBtZXNzYWdlcyBpbiBmbGlnaHQgd2l0aCB0aGUgc2FtZSBNRVNTQUdFIElEIChTVUJTQ1JJ QkUgYW5kIFVOU1VCU0NSSUJFKS4gVGhpcyBpcyBhIHZhbGlkIHVzZSBjYXNlIGluIHRoaXMgY29u dGV4dCBidXQgaXQgZG9lcyBjb25mbGljdCB3aXRoIHRoZSBzdGF0ZW1lbnQgaW4gUkZDNzc2NiDi gJxXaGVuIHNlbmRpbmcgbXVsdGlwbGUgcXVlcmllcyBvdmVyIGEgVENQIGNvbm5lY3Rpb24sIGNs aWVudHMgTVVTVCBOT1QgcmV1c2UgdGhlIEROUyBNZXNzYWdlIElEIG9mIGFuIGluLWZsaWdodCBx dWVyeSBvbiB0aGF0IGNvbm5lY3Rpb24gaW4gb3JkZXIgdG8gYXZvaWQgTWVzc2FnZSBJRCBjb2xs aXNpb25zLiDigJwuIEkgdGhpbmsgaXQgd291bGQgYmUgaGVscGZ1bCB0byBwb2ludCBvdXQgdGhp cyBleGNlcHRpb24gYW5kIGluIGZhY3QgSSB0aGluayB0aGF0IG1lYW5zIHRoaXMgZHJhZnQgdGVj aG5pY2FsbHkgdXBkYXRlcyBSRkM3NzY2Pw0KICAgID4gDQogICAgPiAtIFNlY3Rpb24gNyAtIEkg dGhpbmsgaXQgd291bGQgaGVscCBpZiB0aGVyZSB3YXMgYSByZWZlcmVuY2UgdG8gZHJhZnQtaWV0 Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzIC0gdGhlIGRpc2N1c3Npb24gb2Ygc2VydmVy IGF1dGhlbnRpY2F0aW9uIGhlcmUgb3ZlcmxhcHMgd2l0aCB0aGF0IGRyYWZ0LiBBbHNvIGEgcmVm ZXJlbmNlIHRvICBzZWN0aW9uIDkgb2YgZHJhZnQtaWV0Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXBy b2ZpbGVzIGNvdWxkIGJlIHVzZWQgaW5zdGVhZCBvZiBzZWN0aW9ucyA3LjMgYW5kIDcuNCBhcyB0 aGF0IGRvY3VtZW50IGFscmVhZHkgbWFrZXMgcmVjb21tZW5kYXRpb25zIGFib3V0IGZvbGxvd2lu ZyBSRkM3NTI1LCBUTFMgU2Vzc2lvbiByZXN1bXB0aW9uIGFuZCBzaW1pbGFyLiANCiAgICA+IA0K ICAgID4gU2FyYS4gDQogICAgPiANCiAgICA+IA0KICAgID4+IE9uIDYgQXByIDIwMTcsIGF0IDA5 OjU5LCBUaW0gQ2hvd24gPFRpbS5DaG93bkBqaXNjLmFjLnVrPiB3cm90ZToNCiAgICA+PiANCiAg ICA+PiBIaSwNCiAgICA+PiANCiAgICA+PiBXZSBoYXZlIGhhZCBubyBjb21tZW50cyBvbiB0aGlz IFdHTEMuDQogICAgPj4gDQogICAgPj4gSW4gb3JkZXIgdG8gcHJvZ3Jlc3MgdGhlIGRyYWZ0IHRv IG91ciBBRC9JRVNHIHdlIG5lZWQgc29tZSBwb3NpdGl2ZSBleHByZXNzaW9ucyBvZiBzdXBwb3J0 OyBwbGVhc2UgZG8gdHJ5IHRvIGZpbmQgc29tZSB0aW1lIHRvIHJlYWQgYW5kIGNvbW1lbnQgb24g dGhlIGRvY3VtZW50Lg0KICAgID4+IA0KICAgID4+IFdl4oCZbGwgZXh0ZW5kIHRoZSBXR0xDIHVu dGlsIG5leHQgRnJpZGF5LCAxNHRoIEFwcmlsLCBnaXZlbiB3ZSBhcmUgYWxzbyB3YWl0aW5nIG9u IGEgV0dMQyBmb3IgdGhlIEROUyBzZXNzaW9uIHNpZ25hbGxpbmcgZHJhZnQgdXNlZCBieSBETlMg UHVzaC4NCiAgICA+PiANCiAgICA+PiBNYW55IHRoYW5rcywNCiAgICA+PiBUaW0gJiBSYWxwaA0K ICAgID4+IA0KICAgID4+PiBPbiAyMSBNYXIgMjAxNywgYXQgMTE6MjQsIFRpbSBDaG93biA8VGlt LkNob3duQGppc2MuYWMudWs+IHdyb3RlOg0KICAgID4+PiANCiAgICA+Pj4gRGVhciBkbnNzZCBX RyBwYXJ0aWNpcGFudHMsDQogICAgPj4+IA0KICAgID4+PiBXZSBhcmUgaW5pdGlhdGluZyBhIFdH IExhc3QgQ2FsbCB0b2RheSBvbiBkcmFmdC1pZXRmLWRuc3NkLXB1c2gtMTAsIHdoaWNoIHlvdSBj YW4gZmluZCBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1w dXNoLTEwDQogICAgPj4+IA0KICAgID4+PiBUaGUgY2FsbCBydW5zIGZvciB0d28gd2Vla3MsIGFu ZCB3aWxsIHRodXMgY2xvc2Ugb24gVHVlc2RheSA0dGggQXByaWwuDQogICAgPj4+IA0KICAgID4+ PiBQbGVhc2Ugc2VuZCBhbnkgY29tbWVudHMsIHdoaWNoIGluY2x1ZGVzIGluZGljYXRpb25zIG9m IHN1cHBvcnQgZm9yIHByb2dyZXNzaW9uIG9mIHRoZSBkb2N1bWVudCBhcyBpcywgdG8gdGhlIGRu c3NkQGlldGYub3JnIGxpc3QuICBTdWNoIHN0YXRlbWVudHMgb2Ygc3VwcG9ydCBhcmUgaW1wb3J0 YW50OyB0aGlzIGRyYWZ0IHdpbGwgbm90IGJlIGFkdmFuY2VkIGZvciBwdWJsaWNhdGlvbiB1bmxl c3MgdGhlcmUgaXMgc3VmZmljaWVudCByZXNwb25zZSBhbmQgc3VwcG9ydCBmcm9tIHRoZSBXRy4g IA0KICAgID4+PiANCiAgICA+Pj4gVGhlcmUgd2lsbCBiZSBhIGJyaWVmIG9wcG9ydHVuaXR5IHRv IGFsc28gbWFrZSBjb21tZW50cyBpbiB0aGUgZG5zc2QgV0cgbWVldGluZyBpbiBDaGljYWdvIG5l eHQgd2VlaywgYnV0IHRoZSBjaGFpcnMgd291bGQgYXBwcmVjaWF0ZSBhIHJlY29yZCBvZiBjb21t ZW50cyB0byB0aGUgbGlzdC4NCiAgICA+Pj4gDQogICAgPj4+IFdlIGFyZSBleHBlY3RpbmcgdGhl IGFzc29jaWF0ZWQgRE5TIHNlc3Npb24gc2lnbmFsbGluZyBkcmFmdCB0byBhbHNvIGdvIHRocm91 Z2ggV0dMQyBpbiB0aGUgZG5zb3AgV0cgaW4gdGhlIG5leHQgY291cGxlIG9mIHdlZWtzLCB3aXRo IHRoZSBhaW0gb2YgYm90aCBkb2N1bWVudHMgYmVpbmcgcHVibGlzaGVkIHRvZ2V0aGVyLg0KICAg ID4+PiANCiAgICA+Pj4gVGhlIEROUy1TRCBEaXNjb3ZlcnkgUHJveHkgKGZvcm1lcmx5IHRoZSBE TlMtU0QgSHlicmlkIFByb3h5KSwgd2hpY2ggU3R1YXJ0IGhhcyB1cGRhdGVkIHRvIHJlZmxlY3Qg dGhlIG5ldyBub21lbmNsYXR1cmUsIHdpbGwgYmUgc2VudCB0byB0aGUgSUVTRyBvbmNlIHRoZSBz aGVwaGVyZCB3cml0ZS11cCBpcyBjb21wbGV0ZWQuDQogICAgPj4+IA0KICAgID4+PiBCZXN0IHdp c2hlcywNCiAgICA+Pj4gDQogICAgPj4+IFJhbHBoIGFuZCBUaW0NCiAgICA+Pj4gZG5zc2QgV0cg Y28tY2hhaXJzDQogICAgPj4+IA0KICAgID4+PiANCiAgICA+PiANCiAgICA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+IGRuc3NkIG1haWxp bmcgbGlzdA0KICAgID4+IGRuc3NkQGlldGYub3JnDQogICAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kbnNzZA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gZG5zc2QgbWFpbGluZyBsaXN0 DQogICAgPiBkbnNzZEBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kbnNzZA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgZG5zc2QgbWFpbGluZyBsaXN0DQogICAgZG5zc2RAaWV0 Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ruc3NkDQog ICAgDQoNCg== From nobody Mon Apr 17 11:12:53 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 EEA3B131751 for ; Mon, 17 Apr 2017 11:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0V6-VyDGfoIw for ; Mon, 17 Apr 2017 11:12:48 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FFA129434 for ; Mon, 17 Apr 2017 11:12:48 -0700 (PDT) Received: from [172.30.6.40] (rrcs-67-53-196-2.west.biz.rr.com [67.53.196.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 78D63262AB; Mon, 17 Apr 2017 14:04:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tom Pusateri In-Reply-To: <342F7B95-40B6-4A29-8ED9-C183917394D4@cisco.com> Date: Mon, 17 Apr 2017 08:12:41 -1000 Cc: Sara Dickinson , "dnssd@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <33194F09-8498-4422-8256-83B36C8E3482@bangj.com> References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> <342F7B95-40B6-4A29-8ED9-C183917394D4@cisco.com> To: "Jan Komissar (jkomissa)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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, 17 Apr 2017 18:12:51 -0000 Sorry, Stuart changed this on me. The UNSUBSCRIBE used to contain the = record name and type like the subscribe. I was still thinking that it = did. I think this is the better approach and will discuss with Stuart. = Then you can have unique IDs. Thanks, Tom > On Apr 17, 2017, at 3:04 AM, Jan Komissar (jkomissa) = wrote: >=20 > Hi Tom, >=20 > Does this mean that a client may not unsubscribe a subscription until = it has received the response to the subscription request? You may want = to clarify that in section 6.4.1 paragraph 4, which explicitly allows an = unsubscribe before the subscribe is acknowledged, effectively allowing = two messages in flight with the same id at the same time. (Or has there = been a protocol change that I missed?) >=20 > Regards, >=20 > Jan. >=20 > On 4/14/17, 11:14 PM, "dnssd on behalf of Tom Pusateri" = wrote: >=20 > Thanks for the review Sara. >=20 > The last paragraph of section 6.4.1 needs to be removed. It was = left over from previous versions where the message id was 0. We now = expect SUBSCRIBE and UNSUBSCRIBE requests (even overlapping ones) to = have unique message IDs and will fully conform with RFC 7766. >=20 > I=E2=80=99ll add the appropriate references to the profiles draft. >=20 > Tom >=20 >> On Apr 14, 2017, at 7:05 AM, Sara Dickinson wrote: >>=20 >> HI All,=20 >>=20 >> This draft looks in very good shape to me. I have a couple of minor = comments: >>=20 >> - I think there could be a reference to RFC7858 at the end of the = second paragraph in Section 4. >>=20 >> - Section 6.4.1 discusses clients having 2 messages in flight with = the same MESSAGE ID (SUBSCRIBE and UNSUBSCRIBE). This is a valid use = case in this context but it does conflict with the statement in RFC7766 = =E2=80=9CWhen sending multiple queries over a TCP connection, clients = MUST NOT reuse the DNS Message ID of an in-flight query on that = connection in order to avoid Message ID collisions. =E2=80=9C. I think = it would be helpful to point out this exception and in fact I think that = means this draft technically updates RFC7766? >>=20 >> - Section 7 - I think it would help if there was a reference to = draft-ietf-dprive-dtls-and-tls-profiles - the discussion of server = authentication here overlaps with that draft. Also a reference to = section 9 of draft-ietf-dprive-dtls-and-tls-profiles could be used = instead of sections 7.3 and 7.4 as that document already makes = recommendations about following RFC7525, TLS Session resumption and = similar.=20 >>=20 >> Sara.=20 >>=20 >>=20 >>> On 6 Apr 2017, at 09:59, Tim Chown wrote: >>>=20 >>> Hi, >>>=20 >>> We have had no comments on this WGLC. >>>=20 >>> In order to progress the draft to our AD/IESG we need some positive = expressions of support; please do try to find some time to read and = comment on the document. >>>=20 >>> We=E2=80=99ll extend the WGLC until next Friday, 14th April, given = we are also waiting on a WGLC for the DNS session signalling draft used = by DNS Push. >>>=20 >>> Many thanks, >>> Tim & Ralph >>>=20 >>>> On 21 Mar 2017, at 11:24, Tim Chown wrote: >>>>=20 >>>> Dear dnssd WG participants, >>>>=20 >>>> 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 >>>>=20 >>>> The call runs for two weeks, and will thus close on Tuesday 4th = April. >>>>=20 >>>> Please send any comments, which includes indications of support for = progression of the document as is, to the dnssd@ietf.org list. Such = statements of support are important; this draft will not be advanced for = publication unless there is sufficient response and support from the WG. = =20 >>>>=20 >>>> 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. >>>>=20 >>>> We are expecting the associated DNS session signalling draft to = also go through WGLC in the dnsop WG in the next couple of weeks, with = the aim of both documents being published together. >>>>=20 >>>> 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. >>>>=20 >>>> Best wishes, >>>>=20 >>>> Ralph and Tim >>>> dnssd WG co-chairs >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd >=20 >=20 From nobody Mon Apr 17 11:24:15 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 D91AA1293E1 for ; Mon, 17 Apr 2017 11:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 LSj2ZsYuCcmY for ; Mon, 17 Apr 2017 11:24:11 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AD813175F for ; Mon, 17 Apr 2017 11:24:11 -0700 (PDT) Received: from [172.30.6.40] (rrcs-67-53-196-2.west.biz.rr.com [67.53.196.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 88758262AE; Mon, 17 Apr 2017 14:15:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tom Pusateri In-Reply-To: <33194F09-8498-4422-8256-83B36C8E3482@bangj.com> Date: Mon, 17 Apr 2017 08:24:05 -1000 Cc: "dnssd@ietf.org" , Sara Dickinson Content-Transfer-Encoding: quoted-printable Message-Id: <9E85D19A-77B8-4D17-98D7-EF564A534B24@bangj.com> References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> <342F7B95-40B6-4A29-8ED9-C183917394D4@cisco.com> <33194F09-8498-4422-8256-83B36C8E3482@bangj.com> To: "Jan Komissar (jkomissa)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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, 17 Apr 2017 18:24:14 -0000 Alternatively, the UNSUBSCRIBE TLV could contain the SUBSCRIBE ID as = SSOP-DATA and still have it=E2=80=99s own unique message ID. Tom > On Apr 17, 2017, at 8:12 AM, Tom Pusateri wrote: >=20 > Sorry, Stuart changed this on me. The UNSUBSCRIBE used to contain the = record name and type like the subscribe. I was still thinking that it = did. I think this is the better approach and will discuss with Stuart. = Then you can have unique IDs. >=20 > Thanks, > Tom >=20 >=20 >> On Apr 17, 2017, at 3:04 AM, Jan Komissar (jkomissa) = wrote: >>=20 >> Hi Tom, >>=20 >> Does this mean that a client may not unsubscribe a subscription until = it has received the response to the subscription request? You may want = to clarify that in section 6.4.1 paragraph 4, which explicitly allows an = unsubscribe before the subscribe is acknowledged, effectively allowing = two messages in flight with the same id at the same time. (Or has there = been a protocol change that I missed?) >>=20 >> Regards, >>=20 >> Jan. >>=20 >> On 4/14/17, 11:14 PM, "dnssd on behalf of Tom Pusateri" = wrote: >>=20 >> Thanks for the review Sara. >>=20 >> The last paragraph of section 6.4.1 needs to be removed. It was = left over from previous versions where the message id was 0. We now = expect SUBSCRIBE and UNSUBSCRIBE requests (even overlapping ones) to = have unique message IDs and will fully conform with RFC 7766. >>=20 >> I=E2=80=99ll add the appropriate references to the profiles draft. >>=20 >> Tom >>=20 >>> On Apr 14, 2017, at 7:05 AM, Sara Dickinson = wrote: >>>=20 >>> HI All,=20 >>>=20 >>> This draft looks in very good shape to me. I have a couple of minor = comments: >>>=20 >>> - I think there could be a reference to RFC7858 at the end of the = second paragraph in Section 4. >>>=20 >>> - Section 6.4.1 discusses clients having 2 messages in flight with = the same MESSAGE ID (SUBSCRIBE and UNSUBSCRIBE). This is a valid use = case in this context but it does conflict with the statement in RFC7766 = =E2=80=9CWhen sending multiple queries over a TCP connection, clients = MUST NOT reuse the DNS Message ID of an in-flight query on that = connection in order to avoid Message ID collisions. =E2=80=9C. I think = it would be helpful to point out this exception and in fact I think that = means this draft technically updates RFC7766? >>>=20 >>> - Section 7 - I think it would help if there was a reference to = draft-ietf-dprive-dtls-and-tls-profiles - the discussion of server = authentication here overlaps with that draft. Also a reference to = section 9 of draft-ietf-dprive-dtls-and-tls-profiles could be used = instead of sections 7.3 and 7.4 as that document already makes = recommendations about following RFC7525, TLS Session resumption and = similar.=20 >>>=20 >>> Sara.=20 >>>=20 >>>=20 >>>> On 6 Apr 2017, at 09:59, Tim Chown wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> We have had no comments on this WGLC. >>>>=20 >>>> In order to progress the draft to our AD/IESG we need some positive = expressions of support; please do try to find some time to read and = comment on the document. >>>>=20 >>>> We=E2=80=99ll extend the WGLC until next Friday, 14th April, given = we are also waiting on a WGLC for the DNS session signalling draft used = by DNS Push. >>>>=20 >>>> Many thanks, >>>> Tim & Ralph >>>>=20 >>>>> On 21 Mar 2017, at 11:24, Tim Chown wrote: >>>>>=20 >>>>> Dear dnssd WG participants, >>>>>=20 >>>>> 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 >>>>>=20 >>>>> The call runs for two weeks, and will thus close on Tuesday 4th = April. >>>>>=20 >>>>> Please send any comments, which includes indications of support = for progression of the document as is, to the dnssd@ietf.org list. Such = statements of support are important; this draft will not be advanced for = publication unless there is sufficient response and support from the WG. = =20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> We are expecting the associated DNS session signalling draft to = also go through WGLC in the dnsop WG in the next couple of weeks, with = the aim of both documents being published together. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Best wishes, >>>>>=20 >>>>> Ralph and Tim >>>>> dnssd WG co-chairs >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >>=20 >>=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Mon Apr 17 13:26:14 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 609D0128C82 for ; Mon, 17 Apr 2017 13:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 qwhHAGwOnrE1 for ; Mon, 17 Apr 2017 13:26:10 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B771200FC for ; Mon, 17 Apr 2017 13:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8064; q=dns/txt; s=iport; t=1492460770; x=1493670370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GeXB/+Hd/bPRNP2k+U4DZTxb9G14k69nJ9IBG151ok4=; b=FD6IyQPjY95O90AqS1GP4EBrOvR8ayUkGXEK8Nk1qS4q2TEzKduJ/Krc sWVCzivGp7Z3mjwS63eq5VHmGxh3yReTQZrWwqI+VX5nXrEGyhf71T5DV /GFeLJ2sNvdVYVM6E4Od89y1VMwRrzlkdNG6D6cSHG+gP8v9mc+h9PFpW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgBFJPVY/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KFZFeb5Rwgg8hC4V4AhqDaT8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECAQEBIREaIAsQAgEIGAICCAEdAgICJQoBFRACBA4FHQSJbggOqyKCJ?= =?us-ascii?q?osbAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VHgV0rgWNWNIRBHTOCTC6CMQW?= =?us-ascii?q?Pd4Y7hmkBhwODK4g2gX+FMINdhjqUCQEfOIEFYxVEEQGEVByBY3WIDoENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,216,1488844800"; d="scan'208";a="408670472" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2017 20:26:09 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3HKQ9bx018840 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Apr 2017 20:26:09 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Apr 2017 15:26:08 -0500 Received: from xch-aln-019.cisco.com ([173.36.7.29]) by XCH-ALN-019.cisco.com ([173.36.7.29]) with mapi id 15.00.1210.000; Mon, 17 Apr 2017 15:26:08 -0500 From: "Jan Komissar (jkomissa)" To: Tom Pusateri CC: "dnssd@ietf.org" , Sara Dickinson Thread-Topic: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) Thread-Index: AQHSrrQt5BVSQhAYcUm1aHehOchuNqHFePoAgACqMoCAA4aGgIAAmR+AgAADL4D//98MAA== Date: Mon, 17 Apr 2017 20:26:08 +0000 Message-ID: <73294CB0-F691-494B-85AC-50AEA5F49123@cisco.com> References: <43A42C9D-FC48-4AF1-9E9B-299D5B0179E1@jisc.ac.uk> <87789F25-8664-404F-B4A8-E962A1722F62@sinodun.com> <342F7B95-40B6-4A29-8ED9-C183917394D4@cisco.com> <33194F09-8498-4422-8256-83B36C8E3482@bangj.com> <9E85D19A-77B8-4D17-98D7-EF564A534B24@bangj.com> In-Reply-To: <9E85D19A-77B8-4D17-98D7-EF564A534B24@bangj.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.73] Content-Type: text/plain; charset="utf-8" Content-ID: <3C9C7E89CB866343B137543FF803DACA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April) 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, 17 Apr 2017 20:26:13 -0000 SGkgVG9tLA0KDQpUaGF0IHNvdW5kcyBiZXR0ZXIuDQoNCkFuZCB5ZXMgZm9yIFdHIGFkb3B0aW9u Lg0KDQpSZWdhcmRzLA0KDQpKYW4uDQoNCk9uIDQvMTcvMTcsIDI6MjQgUE0sICJUb20gUHVzYXRl cmkiIDxwdXNhdGVyaUBiYW5nai5jb20+IHdyb3RlOg0KDQogICAgQWx0ZXJuYXRpdmVseSwgdGhl IFVOU1VCU0NSSUJFIFRMViBjb3VsZCBjb250YWluIHRoZSBTVUJTQ1JJQkUgSUQgYXMgU1NPUC1E QVRBIGFuZCBzdGlsbCBoYXZlIGl04oCZcyBvd24gdW5pcXVlIG1lc3NhZ2UgSUQuDQogICAgDQog ICAgVG9tDQogICAgDQogICAgPiBPbiBBcHIgMTcsIDIwMTcsIGF0IDg6MTIgQU0sIFRvbSBQdXNh dGVyaSA8cHVzYXRlcmlAYmFuZ2ouY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gU29ycnksIFN0 dWFydCBjaGFuZ2VkIHRoaXMgb24gbWUuIFRoZSBVTlNVQlNDUklCRSB1c2VkIHRvIGNvbnRhaW4g dGhlIHJlY29yZCBuYW1lIGFuZCB0eXBlIGxpa2UgdGhlIHN1YnNjcmliZS4gSSB3YXMgc3RpbGwg dGhpbmtpbmcgdGhhdCBpdCBkaWQuIEkgdGhpbmsgdGhpcyBpcyB0aGUgYmV0dGVyIGFwcHJvYWNo IGFuZCB3aWxsIGRpc2N1c3Mgd2l0aCBTdHVhcnQuIFRoZW4geW91IGNhbiBoYXZlIHVuaXF1ZSBJ RHMuDQogICAgPiANCiAgICA+IFRoYW5rcywNCiAgICA+IFRvbQ0KICAgID4gDQogICAgPiANCiAg ICA+PiBPbiBBcHIgMTcsIDIwMTcsIGF0IDM6MDQgQU0sIEphbiBLb21pc3NhciAoamtvbWlzc2Ep IDxqa29taXNzYUBjaXNjby5jb20+IHdyb3RlOg0KICAgID4+IA0KICAgID4+IEhpIFRvbSwNCiAg ICA+PiANCiAgICA+PiBEb2VzIHRoaXMgbWVhbiB0aGF0IGEgY2xpZW50IG1heSBub3QgdW5zdWJz Y3JpYmUgYSBzdWJzY3JpcHRpb24gdW50aWwgaXQgaGFzIHJlY2VpdmVkIHRoZSByZXNwb25zZSB0 byB0aGUgc3Vic2NyaXB0aW9uIHJlcXVlc3Q/IFlvdSBtYXkgd2FudCB0byBjbGFyaWZ5IHRoYXQg aW4gc2VjdGlvbiA2LjQuMSBwYXJhZ3JhcGggNCwgd2hpY2ggZXhwbGljaXRseSBhbGxvd3MgYW4g dW5zdWJzY3JpYmUgYmVmb3JlIHRoZSBzdWJzY3JpYmUgaXMgYWNrbm93bGVkZ2VkLCBlZmZlY3Rp dmVseSBhbGxvd2luZyB0d28gbWVzc2FnZXMgaW4gZmxpZ2h0IHdpdGggdGhlIHNhbWUgaWQgYXQg dGhlIHNhbWUgdGltZS4gKE9yIGhhcyB0aGVyZSBiZWVuIGEgcHJvdG9jb2wgY2hhbmdlIHRoYXQg SSBtaXNzZWQ/KQ0KICAgID4+IA0KICAgID4+IFJlZ2FyZHMsDQogICAgPj4gDQogICAgPj4gSmFu Lg0KICAgID4+IA0KICAgID4+IE9uIDQvMTQvMTcsIDExOjE0IFBNLCAiZG5zc2Qgb24gYmVoYWxm IG9mIFRvbSBQdXNhdGVyaSIgPGRuc3NkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHB1 c2F0ZXJpQGJhbmdqLmNvbT4gd3JvdGU6DQogICAgPj4gDQogICAgPj4gICBUaGFua3MgZm9yIHRo ZSByZXZpZXcgU2FyYS4NCiAgICA+PiANCiAgICA+PiAgIFRoZSBsYXN0IHBhcmFncmFwaCBvZiBz ZWN0aW9uIDYuNC4xIG5lZWRzIHRvIGJlIHJlbW92ZWQuIEl0IHdhcyBsZWZ0IG92ZXIgZnJvbSBw cmV2aW91cyB2ZXJzaW9ucyB3aGVyZSB0aGUgbWVzc2FnZSBpZCB3YXMgMC4gV2Ugbm93IGV4cGVj dCBTVUJTQ1JJQkUgYW5kIFVOU1VCU0NSSUJFIHJlcXVlc3RzIChldmVuIG92ZXJsYXBwaW5nIG9u ZXMpIHRvIGhhdmUgdW5pcXVlIG1lc3NhZ2UgSURzIGFuZCB3aWxsIGZ1bGx5IGNvbmZvcm0gd2l0 aCBSRkMgNzc2Ni4NCiAgICA+PiANCiAgICA+PiAgIEnigJlsbCBhZGQgdGhlIGFwcHJvcHJpYXRl IHJlZmVyZW5jZXMgdG8gdGhlIHByb2ZpbGVzIGRyYWZ0Lg0KICAgID4+IA0KICAgID4+ICAgVG9t DQogICAgPj4gDQogICAgPj4+IE9uIEFwciAxNCwgMjAxNywgYXQgNzowNSBBTSwgU2FyYSBEaWNr aW5zb24gPHNhcmFAc2lub2R1bi5jb20+IHdyb3RlOg0KICAgID4+PiANCiAgICA+Pj4gSEkgQWxs LCANCiAgICA+Pj4gDQogICAgPj4+IFRoaXMgZHJhZnQgbG9va3MgaW4gdmVyeSBnb29kIHNoYXBl IHRvIG1lLiBJIGhhdmUgYSBjb3VwbGUgb2YgbWlub3IgY29tbWVudHM6DQogICAgPj4+IA0KICAg ID4+PiAtIEkgdGhpbmsgdGhlcmUgY291bGQgYmUgYSByZWZlcmVuY2UgdG8gUkZDNzg1OCBhdCB0 aGUgZW5kIG9mIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIFNlY3Rpb24gNC4NCiAgICA+Pj4gDQog ICAgPj4+IC0gU2VjdGlvbiA2LjQuMSBkaXNjdXNzZXMgY2xpZW50cyBoYXZpbmcgMiBtZXNzYWdl cyBpbiBmbGlnaHQgd2l0aCB0aGUgc2FtZSBNRVNTQUdFIElEIChTVUJTQ1JJQkUgYW5kIFVOU1VC U0NSSUJFKS4gVGhpcyBpcyBhIHZhbGlkIHVzZSBjYXNlIGluIHRoaXMgY29udGV4dCBidXQgaXQg ZG9lcyBjb25mbGljdCB3aXRoIHRoZSBzdGF0ZW1lbnQgaW4gUkZDNzc2NiDigJxXaGVuIHNlbmRp bmcgbXVsdGlwbGUgcXVlcmllcyBvdmVyIGEgVENQIGNvbm5lY3Rpb24sIGNsaWVudHMgTVVTVCBO T1QgcmV1c2UgdGhlIEROUyBNZXNzYWdlIElEIG9mIGFuIGluLWZsaWdodCBxdWVyeSBvbiB0aGF0 IGNvbm5lY3Rpb24gaW4gb3JkZXIgdG8gYXZvaWQgTWVzc2FnZSBJRCBjb2xsaXNpb25zLiDigJwu IEkgdGhpbmsgaXQgd291bGQgYmUgaGVscGZ1bCB0byBwb2ludCBvdXQgdGhpcyBleGNlcHRpb24g YW5kIGluIGZhY3QgSSB0aGluayB0aGF0IG1lYW5zIHRoaXMgZHJhZnQgdGVjaG5pY2FsbHkgdXBk YXRlcyBSRkM3NzY2Pw0KICAgID4+PiANCiAgICA+Pj4gLSBTZWN0aW9uIDcgLSBJIHRoaW5rIGl0 IHdvdWxkIGhlbHAgaWYgdGhlcmUgd2FzIGEgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtZHByaXZl LWR0bHMtYW5kLXRscy1wcm9maWxlcyAtIHRoZSBkaXNjdXNzaW9uIG9mIHNlcnZlciBhdXRoZW50 aWNhdGlvbiBoZXJlIG92ZXJsYXBzIHdpdGggdGhhdCBkcmFmdC4gQWxzbyBhIHJlZmVyZW5jZSB0 byAgc2VjdGlvbiA5IG9mIGRyYWZ0LWlldGYtZHByaXZlLWR0bHMtYW5kLXRscy1wcm9maWxlcyBj b3VsZCBiZSB1c2VkIGluc3RlYWQgb2Ygc2VjdGlvbnMgNy4zIGFuZCA3LjQgYXMgdGhhdCBkb2N1 bWVudCBhbHJlYWR5IG1ha2VzIHJlY29tbWVuZGF0aW9ucyBhYm91dCBmb2xsb3dpbmcgUkZDNzUy NSwgVExTIFNlc3Npb24gcmVzdW1wdGlvbiBhbmQgc2ltaWxhci4gDQogICAgPj4+IA0KICAgID4+ PiBTYXJhLiANCiAgICA+Pj4gDQogICAgPj4+IA0KICAgID4+Pj4gT24gNiBBcHIgMjAxNywgYXQg MDk6NTksIFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs+IHdyb3RlOg0KICAgID4+Pj4g DQogICAgPj4+PiBIaSwNCiAgICA+Pj4+IA0KICAgID4+Pj4gV2UgaGF2ZSBoYWQgbm8gY29tbWVu dHMgb24gdGhpcyBXR0xDLg0KICAgID4+Pj4gDQogICAgPj4+PiBJbiBvcmRlciB0byBwcm9ncmVz cyB0aGUgZHJhZnQgdG8gb3VyIEFEL0lFU0cgd2UgbmVlZCBzb21lIHBvc2l0aXZlIGV4cHJlc3Np b25zIG9mIHN1cHBvcnQ7IHBsZWFzZSBkbyB0cnkgdG8gZmluZCBzb21lIHRpbWUgdG8gcmVhZCBh bmQgY29tbWVudCBvbiB0aGUgZG9jdW1lbnQuDQogICAgPj4+PiANCiAgICA+Pj4+IFdl4oCZbGwg ZXh0ZW5kIHRoZSBXR0xDIHVudGlsIG5leHQgRnJpZGF5LCAxNHRoIEFwcmlsLCBnaXZlbiB3ZSBh cmUgYWxzbyB3YWl0aW5nIG9uIGEgV0dMQyBmb3IgdGhlIEROUyBzZXNzaW9uIHNpZ25hbGxpbmcg ZHJhZnQgdXNlZCBieSBETlMgUHVzaC4NCiAgICA+Pj4+IA0KICAgID4+Pj4gTWFueSB0aGFua3Ms DQogICAgPj4+PiBUaW0gJiBSYWxwaA0KICAgID4+Pj4gDQogICAgPj4+Pj4gT24gMjEgTWFyIDIw MTcsIGF0IDExOjI0LCBUaW0gQ2hvd24gPFRpbS5DaG93bkBqaXNjLmFjLnVrPiB3cm90ZToNCiAg ICA+Pj4+PiANCiAgICA+Pj4+PiBEZWFyIGRuc3NkIFdHIHBhcnRpY2lwYW50cywNCiAgICA+Pj4+ PiANCiAgICA+Pj4+PiBXZSBhcmUgaW5pdGlhdGluZyBhIFdHIExhc3QgQ2FsbCB0b2RheSBvbiBk cmFmdC1pZXRmLWRuc3NkLXB1c2gtMTAsIHdoaWNoIHlvdSBjYW4gZmluZCBhdCBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1wdXNoLTEwDQogICAgPj4+Pj4gDQog ICAgPj4+Pj4gVGhlIGNhbGwgcnVucyBmb3IgdHdvIHdlZWtzLCBhbmQgd2lsbCB0aHVzIGNsb3Nl IG9uIFR1ZXNkYXkgNHRoIEFwcmlsLg0KICAgID4+Pj4+IA0KICAgID4+Pj4+IFBsZWFzZSBzZW5k IGFueSBjb21tZW50cywgd2hpY2ggaW5jbHVkZXMgaW5kaWNhdGlvbnMgb2Ygc3VwcG9ydCBmb3Ig cHJvZ3Jlc3Npb24gb2YgdGhlIGRvY3VtZW50IGFzIGlzLCB0byB0aGUgZG5zc2RAaWV0Zi5vcmcg bGlzdC4gIFN1Y2ggc3RhdGVtZW50cyBvZiBzdXBwb3J0IGFyZSBpbXBvcnRhbnQ7IHRoaXMgZHJh ZnQgd2lsbCBub3QgYmUgYWR2YW5jZWQgZm9yIHB1YmxpY2F0aW9uIHVubGVzcyB0aGVyZSBpcyBz dWZmaWNpZW50IHJlc3BvbnNlIGFuZCBzdXBwb3J0IGZyb20gdGhlIFdHLiAgDQogICAgPj4+Pj4g DQogICAgPj4+Pj4gVGhlcmUgd2lsbCBiZSBhIGJyaWVmIG9wcG9ydHVuaXR5IHRvIGFsc28gbWFr ZSBjb21tZW50cyBpbiB0aGUgZG5zc2QgV0cgbWVldGluZyBpbiBDaGljYWdvIG5leHQgd2Vlaywg YnV0IHRoZSBjaGFpcnMgd291bGQgYXBwcmVjaWF0ZSBhIHJlY29yZCBvZiBjb21tZW50cyB0byB0 aGUgbGlzdC4NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBXZSBhcmUgZXhwZWN0aW5nIHRoZSBhc3Nv Y2lhdGVkIEROUyBzZXNzaW9uIHNpZ25hbGxpbmcgZHJhZnQgdG8gYWxzbyBnbyB0aHJvdWdoIFdH TEMgaW4gdGhlIGRuc29wIFdHIGluIHRoZSBuZXh0IGNvdXBsZSBvZiB3ZWVrcywgd2l0aCB0aGUg YWltIG9mIGJvdGggZG9jdW1lbnRzIGJlaW5nIHB1Ymxpc2hlZCB0b2dldGhlci4NCiAgICA+Pj4+ PiANCiAgICA+Pj4+PiBUaGUgRE5TLVNEIERpc2NvdmVyeSBQcm94eSAoZm9ybWVybHkgdGhlIERO Uy1TRCBIeWJyaWQgUHJveHkpLCB3aGljaCBTdHVhcnQgaGFzIHVwZGF0ZWQgdG8gcmVmbGVjdCB0 aGUgbmV3IG5vbWVuY2xhdHVyZSwgd2lsbCBiZSBzZW50IHRvIHRoZSBJRVNHIG9uY2UgdGhlIHNo ZXBoZXJkIHdyaXRlLXVwIGlzIGNvbXBsZXRlZC4NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBCZXN0 IHdpc2hlcywNCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBSYWxwaCBhbmQgVGltDQogICAgPj4+Pj4g ZG5zc2QgV0cgY28tY2hhaXJzDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gDQogICAgPj4+PiANCiAg ICA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgPj4+PiBkbnNzZCBtYWlsaW5nIGxpc3QNCiAgICA+Pj4+IGRuc3NkQGlldGYub3JnDQogICAg Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ruc3NkDQogICAgPj4+ IA0KICAgID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KICAgID4+PiBkbnNzZCBtYWlsaW5nIGxpc3QNCiAgICA+Pj4gZG5zc2RAaWV0Zi5vcmcNCiAg ICA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNzZA0KICAgID4+ IA0KICAgID4+ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICA+PiAgIGRuc3NkIG1haWxpbmcgbGlzdA0KICAgID4+ICAgZG5zc2RAaWV0Zi5vcmcN CiAgICA+PiAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zc2QNCiAg ICA+PiANCiAgICA+PiANCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICA+IGRuc3NkIG1haWxpbmcgbGlzdA0KICAgID4gZG5z c2RAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG5zc2QNCiAgICANCiAgICANCg0K