From nobody Mon Nov 3 14:43:58 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C0E1A8782 for ; Mon, 3 Nov 2014 14:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywpLuNHgpoVG for ; Mon, 3 Nov 2014 14:43:50 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFB21A878C for ; Mon, 3 Nov 2014 14:43:50 -0800 (PST) Received: from h226.viagenie.ca (h226.viagenie.ca [206.123.31.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C5F8C40DB3 for ; Mon, 3 Nov 2014 17:43:48 -0500 (EST) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_BEAC0888-8882-40E8-9D5E-E32A550C52C7" Date: Mon, 3 Nov 2014 17:43:43 -0500 References: To: "" Message-Id: <1CBF70C5-B241-4D1B-A5C8-8B92DEC57BEF@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Oq3mR0iopS645JHMq5L7xHuth0w Subject: [weirds] Fwd: [weirds-interop] weirds interop session logistics details X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 22:43:54 -0000 --Apple-Mail=_BEAC0888-8882-40E8-9D5E-E32A550C52C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI, we have been doing the interop sessions since many IETFs without too = much =C2=AB advertisement =C2=BB in the weirds mailing list. If new = people have RDAP implementations and want to join and test, please come. = This interop session will most likely be the last one colocated with = IETF meetings. Marc. > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >=20 > De: Marc Blanchet > Date: 3 novembre 2014 17:41:28 UTC=E2=88=925 > =C3=80: weirds-interop@viagenie.ca > Objet: [weirds-interop] weirds interop session logistics details >=20 > Hello, > the weirds interop session will happen on sunday nov. 9th in the IETF = hotel (Hilton) from 8h00-10h00 am in Rainbow 3 room in the Rainbow = Tower. >=20 > Regards, Marc. > _______________________________________________ > weirds-interop mailing list > weirds-interop@viagenie.ca > https://www.viagenie.ca/mailman/listinfo/weirds-interop --Apple-Mail=_BEAC0888-8882-40E8-9D5E-E32A550C52C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI,
 we have been doing the interop = sessions since many IETFs without too much =C2=AB advertisement = =C2=BB in the weirds mailing list. If new people have RDAP = implementations and want to join and test, please come.  This = interop session will most likely be the last one colocated with IETF = meetings.

Marc.

D=C3=A9but du message = r=C3=A9exp=C3=A9di=C3=A9 :

De: = Marc Blanchet <marc.blanchet@viagenie.ca>
Date: = 3 novembre 2014 17:41:28 = UTC=E2=88=925
=C3=80: = weirds-interop@viagenie.ca
Objet: = [weirds-interop] = weirds interop session logistics details

Hello,
the weirds interop session will happen on sunday nov. 9th in = the IETF hotel (Hilton) from 8h00-10h00 am in  Rainbow 3 room in = the Rainbow Tower.

Regards, Marc.
_______________________________________________
weirds-interop mailing list
weirds-interop@viagenie.ca
https://www.viagenie.ca/mailman/listinfo/weirds-interop

= --Apple-Mail=_BEAC0888-8882-40E8-9D5E-E32A550C52C7-- From nobody Mon Nov 3 20:55:14 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062E71A88A1 for ; Mon, 3 Nov 2014 20:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.414 X-Spam-Level: * X-Spam-Status: No, score=1.414 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=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 TyWX1qvQb7e6 for ; Mon, 3 Nov 2014 20:55:11 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21DB1A88A0 for ; Mon, 3 Nov 2014 20:55:11 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id sA44t9J7022048; Tue, 4 Nov 2014 13:55:09 +0900 X-AuditID: ac120820-b7f318e000000deb-cd-54585c2da9a9 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 1B.C2.03563.D2C58545; Tue, 4 Nov 2014 13:55:09 +0900 (JST) Date: Tue, 04 Nov 2014 13:54:31 +0900 (JST) Message-Id: <20141104.135431.135524778.kambe@jprs.co.jp> To: marc.blanchet@viagenie.ca From: Naoki Kambe In-Reply-To: <1CBF70C5-B241-4D1B-A5C8-8B92DEC57BEF@viagenie.ca> References: <1CBF70C5-B241-4D1B-A5C8-8B92DEC57BEF@viagenie.ca> Organization: Japan Registry Services Co., Ltd. X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsWyRoiFT1c3JiLEYP5DdouuFXuYLeZ3HWdx YPJYsuQnk8e6D+YBTFFcNimpOZllqUX6dglcGc+vz2EtmMBc0buyl7GBcTdTFyMnh4SAicTD jVfYIWwxiQv31rOB2EICJxklHiwWBrFZBLQl1kzrAYpzcPAKWEg8mekAEhYRkJU4f2M2WDmz gLDEjhcvwWxhgTCJ+fO+sYLYbAIqEsvubWYCaeUUsJfoeVQHMb1YYuq3o2AT+QX0JaY2pUAc YCfR9PcdC8QiQYm/O4QhhmtJ9Mx4zA5hy0tsfzuHeQKjwCyEqllIqmYhqVrAyLyKUSY/LU23 ODUvpTg33cBQr6QyXy+roKhYLxlEb2IEhyWHwg7GGacMDjEKcDAq8fByyUWECLEmlhVX5h5i lORgUhLl5QkDCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhnfU7PESINyWxsiq1KB8mJc3BoiTO y2zcGywkkJ5YkpqdmlqQWgSTleHgUJLgvRsFNFSwKDU9tSItM6cEIc3EwQkynAdo+BeQGt7i gsTc4sx0iPwpRlWOlqa3vUxCLHn5ealS4rxa0UBFAiBFGaV5cHNeMYoDvSPMywCS5QGmHrgJ r4CGMwENd+wKARlekoiQkmpg9NJMuzxB8LPpYlM1qTcpV9U0Jea+k5sdNyX1ocWpbSdiUt6U tDewPjpv2LYy6bNjBM8Vt22ndrwuusCi/eRcw+7PQSu8nW8YN59f4FMaKpbwZLrrr1mKt9d/ fnWx9jtz1KkqM4c80fNszOIZl1cbmYVe3BHJeirm9F7rlh3HD3dqZ/tmzjm1RYmlOCPRUIu5 qDgRAF3RlBj6AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/OIQBiN-DazimoIKHRIsI1nHdwiQ Cc: weirds@ietf.org Subject: Re: [weirds] Fwd: [weirds-interop] weirds interop session logistics details X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 04:55:13 -0000 Hello, I have a question. From: Marc Blanchet Date: Mon, 3 Nov 2014 17:43:43 -0500 > This interop session will most likely be the last one colocated with IETF meetings. What about sharing feedbacks after this session? We had shared them at the weirds WG meeting until the previous IETF. I'm sure that we won't have it this time. Regards, Naoki Kambe From nobody Tue Nov 4 03:55:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06C71A1AEE for ; Tue, 4 Nov 2014 03:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6CcVdcGpYZz for ; Tue, 4 Nov 2014 03:55:13 -0800 (PST) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2311A007F for ; Tue, 4 Nov 2014 03:55:11 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKVFi+nrpyF6GPhaBLIzWj3u6tzgrqN8dt@postini.com; Tue, 04 Nov 2014 03:55:12 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id sA4Bt9KP004694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Nov 2014 06:55:10 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 4 Nov 2014 06:54:51 -0500 From: "Hollenbeck, Scott" To: Marc Blanchet , "" Thread-Topic: [weirds] Fwd: [weirds-interop] weirds interop session logistics details Thread-Index: AQHP97eppdm7GsgDHEKCJyYic+QuL5xQXG5g Date: Tue, 4 Nov 2014 11:55:09 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4950FCC4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <1CBF70C5-B241-4D1B-A5C8-8B92DEC57BEF@viagenie.ca> In-Reply-To: <1CBF70C5-B241-4D1B-A5C8-8B92DEC57BEF@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F4950FCC4BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/7aaHjQ30dzka9NRiQVXpyxkilLY Subject: Re: [weirds] Fwd: [weirds-interop] weirds interop session logistics details X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 11:55:16 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F4950FCC4BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RldJVyBJIGNhbiBzZWUgYSBuZWVkIGZvciBhZGRpdGlvbmFsIHNlc3Npb25zIG9uY2UgdGhlIElD QU5OLWNvbnRyYWN0ZWQgZG9tYWluIG5hbWUgcmVnaXN0cmllcyBzdGFydCBkb2luZyBpbXBsZW1l bnRhdGlvbiB3b3JrLiBJ4oCZbSB3aWxsaW5nIHRvIGhlbHAgZmFjaWxpdGF0ZSBhcyB0aGF0IG5l ZWQgYXJpc2VzLg0KDQpTY290dA0KDQpGcm9tOiB3ZWlyZHMgW21haWx0bzp3ZWlyZHMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmMgQmxhbmNoZXQNClNlbnQ6IE1vbmRheSwgTm92 ZW1iZXIgMDMsIDIwMTQgNTo0NCBQTQ0KVG86IDx3ZWlyZHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBb d2VpcmRzXSBGd2Q6IFt3ZWlyZHMtaW50ZXJvcF0gd2VpcmRzIGludGVyb3Agc2Vzc2lvbiBsb2dp c3RpY3MgZGV0YWlscw0KDQpGWUksDQogd2UgaGF2ZSBiZWVuIGRvaW5nIHRoZSBpbnRlcm9wIHNl c3Npb25zIHNpbmNlIG1hbnkgSUVURnMgd2l0aG91dCB0b28gbXVjaCDCqyBhZHZlcnRpc2VtZW50 IMK7IGluIHRoZSB3ZWlyZHMgbWFpbGluZyBsaXN0LiBJZiBuZXcgcGVvcGxlIGhhdmUgUkRBUCBp bXBsZW1lbnRhdGlvbnMgYW5kIHdhbnQgdG8gam9pbiBhbmQgdGVzdCwgcGxlYXNlIGNvbWUuICBU aGlzIGludGVyb3Agc2Vzc2lvbiB3aWxsIG1vc3QgbGlrZWx5IGJlIHRoZSBsYXN0IG9uZSBjb2xv Y2F0ZWQgd2l0aCBJRVRGIG1lZXRpbmdzLg0KDQpNYXJjLg0KDQoNCkTDqWJ1dCBkdSBtZXNzYWdl IHLDqWV4cMOpZGnDqSA6DQoNCkRlOiBNYXJjIEJsYW5jaGV0IDxtYXJjLmJsYW5jaGV0QHZpYWdl bmllLmNhPG1haWx0bzptYXJjLmJsYW5jaGV0QHZpYWdlbmllLmNhPj4NCkRhdGU6IDMgbm92ZW1i cmUgMjAxNCAxNzo0MToyOCBVVEPiiJI1DQrDgDogd2VpcmRzLWludGVyb3BAdmlhZ2VuaWUuY2E8 bWFpbHRvOndlaXJkcy1pbnRlcm9wQHZpYWdlbmllLmNhPg0KT2JqZXQ6IFt3ZWlyZHMtaW50ZXJv cF0gd2VpcmRzIGludGVyb3Agc2Vzc2lvbiBsb2dpc3RpY3MgZGV0YWlscw0KDQpIZWxsbywNCnRo ZSB3ZWlyZHMgaW50ZXJvcCBzZXNzaW9uIHdpbGwgaGFwcGVuIG9uIHN1bmRheSBub3YuIDl0aCBp biB0aGUgSUVURiBob3RlbCAoSGlsdG9uKSBmcm9tIDhoMDAtMTBoMDAgYW0gaW4gIFJhaW5ib3cg MyByb29tIGluIHRoZSBSYWluYm93IFRvd2VyLg0KDQpSZWdhcmRzLCBNYXJjLg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCndlaXJkcy1pbnRlcm9wIG1h aWxpbmcgbGlzdA0Kd2VpcmRzLWludGVyb3BAdmlhZ2VuaWUuY2E8bWFpbHRvOndlaXJkcy1pbnRl cm9wQHZpYWdlbmllLmNhPg0KaHR0cHM6Ly93d3cudmlhZ2VuaWUuY2EvbWFpbG1hbi9saXN0aW5m by93ZWlyZHMtaW50ZXJvcA0KDQo= --_000_831693C2CDA2E849A7D7A712B24E257F4950FCC4BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9y bWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZXSVcgSSBjYW4gc2Vl IGEgbmVlZCBmb3IgYWRkaXRpb25hbCBzZXNzaW9ucyBvbmNlIHRoZSBJQ0FOTi1jb250cmFjdGVk IGRvbWFpbiBuYW1lIHJlZ2lzdHJpZXMgc3RhcnQgZG9pbmcgaW1wbGVtZW50YXRpb24gd29yay4g SeKAmW0gd2lsbGluZyB0byBoZWxwIGZhY2lsaXRhdGUgYXMgdGhhdCBuZWVkIGFyaXNlcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2Nv dHQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gd2VpcmRzIFttYWlsdG86d2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcmMgQmxhbmNoZXQ8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBOb3ZlbWJlciAwMywgMjAxNCA1OjQ0IFBNPGJyPg0KPGI+VG86PC9iPiAmbHQ7d2VpcmRzQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbd2VpcmRzXSBGd2Q6IFt3ZWlyZHMtaW50 ZXJvcF0gd2VpcmRzIGludGVyb3Agc2Vzc2lvbiBsb2dpc3RpY3MgZGV0YWlsczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZZSSw8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDt3ZSBoYXZlIGJlZW4gZG9pbmcgdGhl IGludGVyb3Agc2Vzc2lvbnMgc2luY2UgbWFueSBJRVRGcyB3aXRob3V0IHRvbyBtdWNoIMKrJm5i c3A7YWR2ZXJ0aXNlbWVudCZuYnNwO8K7IGluIHRoZSB3ZWlyZHMgbWFpbGluZyBsaXN0LiBJZiBu ZXcgcGVvcGxlIGhhdmUgUkRBUCBpbXBsZW1lbnRhdGlvbnMgYW5kIHdhbnQgdG8gam9pbiBhbmQg dGVzdCwgcGxlYXNlIGNvbWUuICZuYnNwO1RoaXMgaW50ZXJvcCBzZXNzaW9uIHdpbGwgbW9zdCBs aWtlbHkNCiBiZSB0aGUgbGFzdCBvbmUgY29sb2NhdGVkIHdpdGggSUVURiBtZWV0aW5ncy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFyYy48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ew6lidXQgZHUgbWVz c2FnZSByw6lleHDDqWRpw6kgOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkRlOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NYXJjIEJs YW5jaGV0ICZsdDs8YSBocmVmPSJtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYSI+bWFy Yy5ibGFuY2hldEB2aWFnZW5pZS5jYTwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EYXRlOiA8 L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4zIG5vdmVtYnJlIDIwMTQgMTc6NDE6MjggVVRD4oiS NTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+w4A6IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhy ZWY9Im1haWx0bzp3ZWlyZHMtaW50ZXJvcEB2aWFnZW5pZS5jYSI+d2VpcmRzLWludGVyb3BAdmlh Z2VuaWUuY2E8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PYmpldDogW3dlaXJkcy1pbnRlcm9wXSB3 ZWlyZHMgaW50ZXJvcCBzZXNzaW9uIGxvZ2lzdGljcyBkZXRhaWxzPC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8sPGJyPg0KdGhlIHdlaXJkcyBp bnRlcm9wIHNlc3Npb24gd2lsbCBoYXBwZW4gb24gc3VuZGF5IG5vdi4gOXRoIGluIHRoZSBJRVRG IGhvdGVsIChIaWx0b24pIGZyb20gOGgwMC0xMGgwMCBhbSBpbiAmbmJzcDtSYWluYm93IDMgcm9v bSBpbiB0aGUgUmFpbmJvdyBUb3dlci48YnI+DQo8YnI+DQpSZWdhcmRzLCBNYXJjLjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kd2VpcmRz LWludGVyb3AgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOndlaXJkcy1pbnRlcm9w QHZpYWdlbmllLmNhIj53ZWlyZHMtaW50ZXJvcEB2aWFnZW5pZS5jYTwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy52aWFnZW5pZS5jYS9tYWlsbWFuL2xpc3RpbmZvL3dlaXJkcy1pbnRlcm9w Ij5odHRwczovL3d3dy52aWFnZW5pZS5jYS9tYWlsbWFuL2xpc3RpbmZvL3dlaXJkcy1pbnRlcm9w PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_831693C2CDA2E849A7D7A712B24E257F4950FCC4BRN1WNEXMBX01vc_-- From nobody Tue Nov 4 15:38:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215331A1A4F for ; Tue, 4 Nov 2014 15:38:39 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbtrqjhDYLw8 for ; Tue, 4 Nov 2014 15:38:35 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62B61A1A47 for ; Tue, 4 Nov 2014 15:38:35 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2121420798 for ; Tue, 4 Nov 2014 18:38:35 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 04 Nov 2014 18:38:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=mesmtp; bh=fTkHM+hAKEMeYe/R rme2H0xhxcE=; b=wdBoRzXdBLdm9gMyL7ff/q90udVojpQunZ6D9+PDo8eh352J seS17Fq3mkAvb1ZNLLYp/5nzUscMjGosmdtOnHPI9mZ8bqZdkWeCOzvizWInOBNS FHlJQgMIp9bhItox51ExeGWE4dVW53yijmbQghga7UnUMFqQvMC9MqI5NsU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:message-id:references:to; s= smtpout; bh=fTkHM+hAKEMeYe/Rrme2H0xhxcE=; b=lJVNI4DQmQSt6k5IssJL I/NoxTuyVisBDTbAD4ZHYUpOvSPzxiVzE3UdDYZDKdginGKeFKArgmUZoIpYBIG/ nKt4fklWTpRCVO3QpXZxQZlurnAOUkC3aPI+k5msBTRHKqQVE7cvVEv3/IgucV7r j2RayfJymxuXCh4U2OEIReI= X-Sasl-enc: WACPCkX3ae8eV53pB2/t0S/2mUzGzCtGEVgqMf1k3uFC 1415144314 Received: from [10.35.132.83] (unknown [128.107.239.235]) by mail.messagingengine.com (Postfix) with ESMTPA id 3AAA568006D; Tue, 4 Nov 2014 18:38:34 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_EEB0BCEE-7430-46BC-AAB7-DA8C609D434E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F495084BA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Tue, 4 Nov 2014 15:38:32 -0800 Message-Id: <513528CD-A267-4583-B997-2AF99E7ECA57@cooperw.in> References: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495084BA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/DSgMznmaifQ6U_CTzR56lm1fHWw Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , IESG , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 23:38:39 -0000 --Apple-Mail=_EEB0BCEE-7430-46BC-AAB7-DA8C609D434E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all, On Oct 29, 2014, at 8:03 AM, Hollenbeck, Scott = wrote: >> -----Original Message----- >> From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Alissa >> Cooper >> Sent: Tuesday, October 28, 2014 7:16 PM >> To: The IESG >> Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- >> chairs@tools.ietf.org; weirds@ietf.org >> Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap- >> sec-10: (with DISCUSS and COMMENT) >>=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-weirds-rdap-sec-10: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to http://www.ietf.org/iesg/statement/discuss- >> criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> =3D General comment =3D >> I'm not exactly sure which document this remark is directed at, but = I'm >> putting it in a DISCUSS here and we can figure that out later. >>=20 >> I feel like the RDAP document suite is missing an overall explanation >> of >> the privacy threat model associated with registration data, the = policy >> choices that are left up to registry providers, and the mechanisms >> included in RDAP to help protect registrant and client/user privacy >> and >> facilitate those policy choices. There are mentions of some of this >> here >> and there, but even those are not necessarily consistent with each >> other >> (see my DISCUSS on draft-ietf-weirds-using-http). So I think it would >> be >> beneficial to capture this in one place and articulate it explicitly, >> rather than implicitly across the documents. Some of the salient = points >> for starters: >>=20 >> * WHOIS data has historically included personal information about >> registrants, has been made public, and has not had the benefit of >> authentication or access control mechanisms to gate access to it. In >> part >> as a result of this, proxy and privacy services have arisen to shield >> the >> identities of registrants. >>=20 >> * The standardization of RDAP does not change or impact the data that >> registries may require to be collected from registrants. However, = RDAP >> data structures allow servers to indicate when data returned to = clients >> has been made private, redacted, obscured, or shielded by a proxy. >>=20 >> * RDAP uses the jCard standard format for entity representation, but >> many >> of the jCard fields are irrelevant for registry operation purposes = and >> their use should be minimized. >>=20 >> * RDAP includes mechanisms that can be used to authenticate clients, >> allowing servers to support tiered access based on local policy. This >> means that all registration data need no longer be public, and = personal >> data or data that may be considered more sensitive can have its = access >> restricted to specifically privileged clients. >>=20 >> * [Something about confidentiality of requests and responses ... see = my >> other DISCUSS point below.] >>=20 >> * etc. >=20 > I could see adding a good bit of what you wrote above to a new section = titled "Privacy Threats Associated with Registration Data" that appears = as a new section in the Introduction or perhaps between the existing = sections 2 and 3. Would one of those options work? During the IESG call last week I said that I would take point on = suggesting text to accommodate both my and Kathleen=92s suggestions for = this new privacy threats section. Picking up from the points above and = from the thread about Kathleen=92s json-response DISCUSS, my strawman = suggestion for a new section in rdap-sec is below. I tried to frame this = as an explanation of the available choices to registries that want to = mitigate the identified privacy threats, picking up on Pete and Ed=92s = concerns that we do not want to be specifying registry policy in the = weirds documents. I=92m still thinking about my other DISCUSS point re TLS =85 will follow = up on that later. --- Privacy Threats Associated with Registration Data Registration data has historically included personal data about = registrants. WHOIS services have historically made this information = available to the public, creating a privacy risk by revealing the = personal details of registrants. WHOIS services have not had the = benefit of authentication or access control mechanisms to gate access to = registration data. In part as a result of this, proxy and privacy = services have arisen to shield the identities of registrants. The standardization of RDAP does not change or impact the data that = registries may require to be collected from registrants, but it provides = support for a number of mechanisms that may be used to mitigate privacy = threats to registrants should registries choose to use them.=20 RDAP includes mechanisms that can be used to authenticate clients, = allowing servers to support tiered access based on local policy. This = means that all registration data need no longer be public, and personal = data or data that may be considered more sensitive can have its access = restricted to specifically privileged clients. RDAP data structures allow servers to indicate via status values when = data returned to clients has been made private, redacted, obscured, or = registered by a proxy. Private means that the data is not designated for = public consumption. Redacted means that some registration data fields = are not being made available. Obscured means that data has been altered = for the purposes of not readily revealing the actual registration = information. One option that registries have available to them to reduce = privacy risks to registrants is to adopt policies that make use of these = status values to restrict the registrant data shared with any or all = clients according to the sensitivity of the data, the privileges of the = clients, or some other heuristics.=20 RDAP uses the jCard standard format for entity representation. = Registries may find that many of the jCard fields are irrelevant for = registry operation purposes or that they have no reason to collect = information from registrants that would correspond to certain fields. = Registries wishing to reduce privacy risks for registrants may restrict = which information they collect and/or which fields they populate in = responses. In addition to privacy risks to registrants, there are also potential = privacy risks for those who query registration data. For example, the = fact that a law enforcement officer performs a particular query may = reveal information about the officer=92s activities that she would have = preferred to keep private. To provide privacy protection for those = querying registrant data as well as registrants, RDAP supports the use = of HTTP over TLS.=20= --Apple-Mail=_EEB0BCEE-7430-46BC-AAB7-DA8C609D434E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi all,

On Oct 29, 2014, at = 8:03 AM, Hollenbeck, Scott <shollenbeck@verisign.com> = wrote:

-----Original Message-----
From: weirds [mailto:weirds-bounces@ietf.org= ] On Behalf Of Alissa
Cooper
Sent: Tuesday, October 28, 2014 7:16 = PM
To: The IESG
Cc: draft-ietf-weird= s-rdap-sec@tools.ietf.org; weirds-
chairs@tools.ietf.org; weirds@ietf.org
Subject: [weirds] = Alissa Cooper's Discuss on draft-ietf-weirds-rdap-
sec-10: (with = DISCUSS and COMMENT)

Alissa Cooper has entered the following = ballot position for
draft-ietf-weirds-rdap-sec-10: = Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC lines. (Feel = free to cut this
introductory paragraph, however.)


Please = refer to http://www.ietf.org/i= esg/statement/discuss-
criteria.html
for more information = about IESG DISCUSS and COMMENT positions.


The document, along = with other ballot positions, can be found here:
http:= //datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/



= ----------------------------------------------------------------------
= DISCUSS:
--------------------------------------------------------------= --------

=3D General comment =3D
I'm not exactly sure which = document this remark is directed at, but I'm
putting it in a DISCUSS = here and we can figure that out later.

I feel like the RDAP = document suite is missing an overall explanation
of
the privacy = threat model associated with registration data, the policy
choices = that are left up to registry providers, and the mechanisms
included = in RDAP to help protect registrant  and client/user = privacy
and
facilitate those policy choices. There are mentions of = some of this
here
and there, but even those are not necessarily = consistent with each
other
(see my DISCUSS on = draft-ietf-weirds-using-http). So I think it would
be
beneficial = to capture this in one place and articulate it explicitly,
rather = than implicitly across the documents. Some of the salient points
for = starters:

* WHOIS data has historically included personal = information about
registrants, has been made public, and has not had = the benefit of
authentication or access control mechanisms to gate = access to it. In
part
as a result of this, proxy and privacy = services have arisen to shield
the
identities of = registrants.

* The standardization of RDAP does not change or = impact the data that
registries may require to be collected from = registrants. However, RDAP
data structures allow servers to indicate = when data returned to clients
has been made private, redacted, = obscured, or shielded by a proxy.

* RDAP uses the jCard standard = format for entity representation, but
many
of the jCard fields are = irrelevant for registry operation purposes and
their use should be = minimized.

* RDAP includes mechanisms that can be used to = authenticate clients,
allowing servers to support tiered access based = on local policy. This
means that all registration data need no longer = be public, and personal
data or data that may be considered more = sensitive can have its access
restricted to specifically privileged = clients.

* [Something about confidentiality of requests and = responses ... see my
other DISCUSS point below.]

* = etc.

I could see adding a good bit of what you wrote = above to a new section titled "Privacy Threats Associated with = Registration Data" that appears as a new section in the Introduction or = perhaps between the existing sections 2 and 3. Would one of those = options work?

During the IESG call last = week I said that I would take point on suggesting text to accommodate = both my and Kathleen=92s suggestions for this new privacy threats = section. Picking up from the points above and from the thread about = Kathleen=92s json-response DISCUSS, my strawman suggestion for a new = section in rdap-sec is below. I tried to frame this as an explanation of = the available choices to registries that want to mitigate the identified = privacy threats, picking up on Pete and Ed=92s concerns that we do not = want to be specifying registry policy in the weirds = documents.

I=92m still thinking about my other = DISCUSS point re TLS =85 will follow up on that = later.

---

Privacy = Threats Associated with Registration = Data

Registration data has historically = included personal data about registrants. WHOIS services have = historically made this information available to the public, creating a = privacy risk by revealing the personal details of registrants. =  WHOIS services have not had the benefit of authentication or = access control mechanisms to gate access to registration data. In part = as a result of this, proxy and privacy services have arisen to shield = the identities of registrants.

The = standardization of RDAP does not change or impact the data that = registries may require to be collected from registrants, but it provides = support for a number of mechanisms that may be used to mitigate privacy = threats to registrants should registries choose to use = them. 

RDAP includes mechanisms that can = be used to authenticate clients, allowing servers to support tiered = access based on local policy. This means that all registration data need = no longer be public, and personal data or data that may be considered = more sensitive can have its access restricted to specifically privileged = clients.

RDAP data structures allow servers to = indicate via status values when data returned to clients has been made = private, redacted, obscured, or registered by a proxy. Private means = that the data is not designated for public consumption. Redacted means = that some registration data fields are not being made available. = Obscured means that data has been altered for the purposes of not = readily revealing the actual registration information. One option that = registries have available to them to reduce privacy risks to registrants = is to adopt policies that make use of these status values to restrict = the registrant data shared with any or all clients according to the = sensitivity of the data, the privileges of the clients, or some other = heuristics. 

RDAP uses the jCard standard = format for entity representation. Registries may find that many of the = jCard fields are irrelevant for registry operation purposes or that they = have no reason to collect information from registrants that would = correspond to certain fields. Registries wishing to reduce privacy risks = for registrants may restrict which information they collect and/or which = fields they populate in responses.

In addition = to privacy risks to registrants, there are also potential privacy risks = for those who query registration data. For example, the fact that a law = enforcement officer performs a particular query may reveal information = about the officer=92s activities that she would have preferred to keep = private. To provide privacy protection for those querying registrant = data as well as registrants, RDAP supports the use of HTTP over = TLS. 
= --Apple-Mail=_EEB0BCEE-7430-46BC-AAB7-DA8C609D434E-- From nobody Tue Nov 4 17:15:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3672F1A1A8C; Tue, 4 Nov 2014 16:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYfp2sN_MaZH; Tue, 4 Nov 2014 16:34:18 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A93D1A1AB2; Tue, 4 Nov 2014 16:34:17 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id z12so3702229lbi.36 for ; Tue, 04 Nov 2014 16:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=caqfwfktWKM/XT+QWgRL3fYBq4KpXiD5lUXw9EuVoNM=; b=dpfl5CsDVE2+7e/MpLQd2DZnXPF9UwpkLgCUdN9id6zZgMFy7YGXAqOzjVTP+egZiN mcEBaAitEwAGy6G0nBvQvruGmFmwyLpFwJbvJWpI2G/7IpVY9Je0oas8YRi/oUHS9QqJ dLxeu2SKnm7SPtj8c9GyH1ZHpXBhG+2rTsl8iICwJ6ncoVky+FUj3ZfTrFC0OtemFsZy XOMsSeU4K5fhICn6WdCQ9jSo5QF1x+guJ7PrIsentwF+mfQCAdEN6yFqR1rSidYZ2U3D m9JzEhmsbo1z0h+cpIcApMplWWiTd3y+COO7ypjLirRUrSSbhvPlpxhPVjyHNMXzxupR ZrSQ== MIME-Version: 1.0 X-Received: by 10.152.29.41 with SMTP id g9mr64294929lah.83.1415147656358; Tue, 04 Nov 2014 16:34:16 -0800 (PST) Received: by 10.112.95.17 with HTTP; Tue, 4 Nov 2014 16:34:16 -0800 (PST) In-Reply-To: <513528CD-A267-4583-B997-2AF99E7ECA57@cooperw.in> References: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495084BA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <513528CD-A267-4583-B997-2AF99E7ECA57@cooperw.in> Date: Tue, 4 Nov 2014 19:34:16 -0500 Message-ID: From: Kathleen Moriarty To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NCOfEOsLDUBsHebW2RABj_J9AN0 X-Mailman-Approved-At: Tue, 04 Nov 2014 17:15:20 -0800 Cc: "weirds@ietf.org" , "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , IESG Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 00:34:23 -0000 On Tue, Nov 4, 2014 at 6:38 PM, Alissa Cooper wrote: > Hi all, > > On Oct 29, 2014, at 8:03 AM, Hollenbeck, Scott > wrote: > > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Alissa > Cooper > Sent: Tuesday, October 28, 2014 7:16 PM > To: The IESG > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > chairs@tools.ietf.org; weirds@ietf.org > Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap- > sec-10: (with DISCUSS and COMMENT) > > Alissa Cooper has entered the following ballot position for > draft-ietf-weirds-rdap-sec-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > =3D General comment =3D > I'm not exactly sure which document this remark is directed at, but I'm > putting it in a DISCUSS here and we can figure that out later. > > I feel like the RDAP document suite is missing an overall explanation > of > the privacy threat model associated with registration data, the policy > choices that are left up to registry providers, and the mechanisms > included in RDAP to help protect registrant and client/user privacy > and > facilitate those policy choices. There are mentions of some of this > here > and there, but even those are not necessarily consistent with each > other > (see my DISCUSS on draft-ietf-weirds-using-http). So I think it would > be > beneficial to capture this in one place and articulate it explicitly, > rather than implicitly across the documents. Some of the salient points > for starters: > > * WHOIS data has historically included personal information about > registrants, has been made public, and has not had the benefit of > authentication or access control mechanisms to gate access to it. In > part > as a result of this, proxy and privacy services have arisen to shield > the > identities of registrants. > > * The standardization of RDAP does not change or impact the data that > registries may require to be collected from registrants. However, RDAP > data structures allow servers to indicate when data returned to clients > has been made private, redacted, obscured, or shielded by a proxy. > > * RDAP uses the jCard standard format for entity representation, but > many > of the jCard fields are irrelevant for registry operation purposes and > their use should be minimized. > > * RDAP includes mechanisms that can be used to authenticate clients, > allowing servers to support tiered access based on local policy. This > means that all registration data need no longer be public, and personal > data or data that may be considered more sensitive can have its access > restricted to specifically privileged clients. > > * [Something about confidentiality of requests and responses ... see my > other DISCUSS point below.] > > * etc. > > > I could see adding a good bit of what you wrote above to a new section > titled "Privacy Threats Associated with Registration Data" that appears a= s a > new section in the Introduction or perhaps between the existing sections = 2 > and 3. Would one of those options work? > > > During the IESG call last week I said that I would take point on suggesti= ng > text to accommodate both my and Kathleen=E2=80=99s suggestions for this n= ew privacy > threats section. Picking up from the points above and from the thread abo= ut > Kathleen=E2=80=99s json-response DISCUSS, my strawman suggestion for a ne= w section > in rdap-sec is below. I tried to frame this as an explanation of the > available choices to registries that want to mitigate the identified priv= acy > threats, picking up on Pete and Ed=E2=80=99s concerns that we do not want= to be > specifying registry policy in the weirds documents. > > I=E2=80=99m still thinking about my other DISCUSS point re TLS =E2=80=A6 = will follow up on > that later. > > --- > > Privacy Threats Associated with Registration Data > > Registration data has historically included personal data about registran= ts. > WHOIS services have historically made this information available to the > public, creating a privacy risk by revealing the personal details of > registrants. WHOIS services have not had the benefit of authentication o= r > access control mechanisms to gate access to registration data. In part as= a > result of this, proxy and privacy services have arisen to shield the > identities of registrants. > > The standardization of RDAP does not change or impact the data that > registries may require to be collected from registrants, but it provides > support for a number of mechanisms that may be used to mitigate privacy > threats to registrants should registries choose to use them. > > RDAP includes mechanisms that can be used to authenticate clients, allowi= ng > servers to support tiered access based on local policy. This means that a= ll > registration data need no longer be public, and personal data or data tha= t > may be considered more sensitive can have its access restricted to > specifically privileged clients. > > RDAP data structures allow servers to indicate via status values when dat= a > returned to clients has been made private, redacted, obscured, or registe= red > by a proxy. Private means that the data is not designated for public > consumption. Redacted means that some registration data fields are not be= ing > made available. Obscured means that data has been altered for the purpose= s > of not readily revealing the actual registration information. One option > that registries have available to them to reduce privacy risks to > registrants is to adopt policies that make use of these status values to > restrict the registrant data shared with any or all clients according to = the > sensitivity of the data, the privileges of the clients, or some other > heuristics. > > RDAP uses the jCard standard format for entity representation. Registries > may find that many of the jCard fields are irrelevant for registry operat= ion > purposes or that they have no reason to collect information from registra= nts > that would correspond to certain fields. Registries wishing to reduce > privacy risks for registrants may restrict which information they collect > and/or which fields they populate in responses. > > In addition to privacy risks to registrants, there are also potential > privacy risks for those who query registration data. For example, the fac= t > that a law enforcement officer performs a particular query may reveal > information about the officer=E2=80=99s activities that she would have pr= eferred to > keep private. To provide privacy protection for those querying registrant > data as well as registrants, RDAP supports the use of HTTP over TLS. Thanks, Alissa. Your suggested text looks very good. --=20 Best regards, Kathleen From nobody Tue Nov 4 19:09:44 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC501A1B69 for ; Tue, 4 Nov 2014 19:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 28oF9di36oFi for ; Tue, 4 Nov 2014 19:09:41 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911581A1BCC for ; Tue, 4 Nov 2014 19:09:39 -0800 (PST) Received: (qmail 76563 invoked from network); 5 Nov 2014 03:09:37 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Nov 2014 03:09:37 -0000 Date: 5 Nov 2014 03:09:15 -0000 Message-ID: <20141105030915.75596.qmail@ary.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <513528CD-A267-4583-B997-2AF99E7ECA57@cooperw.in> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2rcIUnldK8XDzDX_AX69SMhIeYs Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 03:09:43 -0000 >Privacy Threats Associated with Registration Data Everything you say is true, but it's equally true about any protocol that might let you query a database that contains PII. It would, for example, be applicable to online phone book web sites. For the ICANN contracted registries and registrars, the policies about who can see what via WHOIS are defined by their contracts with ICANN, sometimes modified by national law where it is more restrictive. All of the ccTLDs that offer WHOIS have their own policies, again informed by the relevant national law. For numbering information, the RIRs again set their own policies through their internal processes, although it's less of an issue since it is rare for RIRs to delegate to individuals rather than organizations. Since this is an IETF document that describes mechanisms, and the likely implementers mentioned above already have (better or worse) WHOIS privacy policies in place which nobody I know expects to be different when they move from WHOIS to RDAP, could you clarify who is the intended audience for this privacy discussion? R's, John From nobody Wed Nov 5 07:21:18 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4019B1A892C for ; Wed, 5 Nov 2014 07:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmFvjGwmo87n for ; Wed, 5 Nov 2014 07:21:15 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20271A892A for ; Wed, 5 Nov 2014 07:21:14 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 5 Nov 2014 07:21:13 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Wed, 5 Nov 2014 07:21:13 -0800 From: Edward Lewis To: "weirds@ietf.org" Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) Thread-Index: AQHP8wUss2MGfYWr0kiOYBgWOmcbk5xHolMAgAoOoQCAADrggIAAeKsA Date: Wed, 5 Nov 2014 15:21:13 +0000 Message-ID: References: <513528CD-A267-4583-B997-2AF99E7ECA57@cooperw.in> <20141105030915.75596.qmail@ary.lan> In-Reply-To: <20141105030915.75596.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3498027668_4242860" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/xUeiMqgIuHgCH7BUtP4dcklGd_w Cc: Kathleen Moriarty , John Levine Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:21:17 -0000 --B_3498027668_4242860 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable First I=E2=80=99ll say I am fine with the suggested text. Second I=E2=80=99ll respond a bit to John=E2=80=99s comment below: -----Original Message----- From: John Levine Date: Tuesday, November 4, 2014 at 22:09 To: "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) >>Privacy Threats Associated with Registration Data > >Everything you say is true, but it's equally true about any protocol >that might let you query a database that contains PII. It would, for >example, be applicable to online phone book web sites. > >For the ICANN contracted registries and registrars, the policies about >who can see what via WHOIS are defined by their contracts with ICANN, >sometimes modified by national law where it is more restrictive. Nit picking, the =E2=80=9CICANN" policies aren=E2=80=99t *defined* in the contracts, polices in ICANN are a result of a policy development process - analogous to many other organizations. =E2=80=9CWhoIs=E2=80=9D is a significant topic of discuss= ion amongst participants in the policy development processes. >All >of the ccTLDs that offer WHOIS have their own policies, again informed >by the relevant national law. For numbering information, the RIRs >again set their own policies through their internal processes, >although it's less of an issue since it is rare for RIRs to delegate >to individuals rather than organizations. I=E2=80=99d disagree with that to some extent. There=E2=80=99s a strong structural analogy between an RIR allocating space to an LIR who then assigns a small range to a customer to a (domain name *) TLD accepting a registration of a name from a registrar on behalf of a registrant. E.g., some TLDs permit registrant contact information to be obscured via a third party; some RIR=E2=80=99s permit obscuring the holder of a less than a =E2=80=9Cslash-X=E2=80=9D (/29 in IPv4?) of space. I=E2=80=99ve worked both sides of the fence, there=E2=80=99s not much difference betwee= n them. Really, registries are registries. How they decide to approve a request may differ - addresses are based on demonstrated need while some names are first-come-first-served and some have other criteria, the process of registration (object -> entity) is the same. >Since this is an IETF document that describes mechanisms, and the >likely implementers mentioned above already have (better or worse) >WHOIS privacy policies in place which nobody I know expects to be >different when they move from WHOIS to RDAP, could you clarify who is >the intended audience for this privacy discussion? IMHO, anyone who will implement RDAP without reading all of the documents in the IETF library. ;) Implementers !=3D Operators, just as protocol engineers !=3D implementers (IETF is pretty good at bridging that gap). Sometimes implementers need to know what knobs and dials are needed in code so that operators can run the protocol. --B_3498027668_4242860 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSIsV/CVylDv1x6txg8 K2dSg7rPPjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx MDUxNTIxMDhaMA0GCSqGSIb3DQEBAQUABIIBAIPLDfjetgh/AzIeeRIJ0j6iDNNd8+nk4JL0 w3de7V1NHl/TCRLxfodTeozqR1BdXscbU0kN5rPxgWW5PbMYvfDwa5zJ4CwPb/YC+v2IwQYF 99dYw0PKw1je4JJkkf/MEM974SYN7BwWx8bkpkPlNx9mK+aSjkVM7z03bB1TTD5JhCZcmq7G HkBLDsyiMBo+asqsY/+qWeqwpFBv+gv6HIi2pXSQA1PMkw4eDWY+NCDpx6qUI83Zz7EQbxXy Pks+5v+mUjBe9yrTLUDOS5s4FQ1Vyl/z0y8m4jOmf6QMfT7fc07iTsRpRJIPAGyZPlO8Nu7q PZfXMsGBlmrcAOntWhk= --B_3498027668_4242860-- From nobody Wed Nov 5 07:56:57 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F681A88EB for ; Wed, 5 Nov 2014 07:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI-Dbh8n_dqy for ; Wed, 5 Nov 2014 07:56:53 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247491A8997 for ; Wed, 5 Nov 2014 07:56:32 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKVFpIn/UhjoO0Ii5VlhoKZpZxw+p5tm1J@postini.com; Wed, 05 Nov 2014 07:56:53 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id sA5FuEO8027947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Nov 2014 10:56:14 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 5 Nov 2014 10:56:14 -0500 From: "Hollenbeck, Scott" To: Edward Lewis , "weirds@ietf.org" Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) Thread-Index: AQHP8wUfEIZLGkYoKkacqpPaBIZ0W5xHIoBggApcKgCAADrggIAAzIKA//+wHTA= Date: Wed, 5 Nov 2014 15:56:13 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49512285@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <513528CD-A267-4583-B997-2AF99E7ECA57@cooperw.in> <20141105030915.75596.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2sJZHYGzPe0eL28QPXusURt5gPE Cc: Kathleen Moriarty , John Levine Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:56:56 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB3ZWlyZHMgW21haWx0bzp3ZWly ZHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVkd2FyZCBMZXdpcw0KPiBTZW50OiBX ZWRuZXNkYXksIE5vdmVtYmVyIDA1LCAyMDE0IDEwOjIxIEFNDQo+IFRvOiB3ZWlyZHNAaWV0Zi5v cmcNCj4gQ2M6IEthdGhsZWVuIE1vcmlhcnR5OyBKb2huIExldmluZQ0KPiBTdWJqZWN0OiBSZTog W3dlaXJkc10gQWxpc3NhIENvb3BlcidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi13ZWlyZHMtDQo+ IHJkYXAtc2VjLTEwOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gRmlyc3QgSeKA mWxsIHNheSBJIGFtIGZpbmUgd2l0aCB0aGUgc3VnZ2VzdGVkIHRleHQuDQo+IA0KPiBTZWNvbmQg SeKAmWxsIHJlc3BvbmQgYSBiaXQgdG8gSm9obuKAmXMgY29tbWVudCBiZWxvdzoNCj4gDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvaG4gTGV2aW5lIDxqb2hubEB0YXVn aC5jb20+DQo+IERhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDQsIDIwMTQgYXQgMjI6MDkNCj4gVG86 ICJ3ZWlyZHNAaWV0Zi5vcmciIDx3ZWlyZHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbd2Vp cmRzXSBBbGlzc2EgQ29vcGVyJ3MgRGlzY3VzcyBvbg0KPiBkcmFmdC1pZXRmLXdlaXJkcy1yZGFw LXNlYy0xMDogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+ID4+UHJpdmFjeSBUaHJl YXRzIEFzc29jaWF0ZWQgd2l0aCBSZWdpc3RyYXRpb24gRGF0YQ0KPiA+DQo+ID5FdmVyeXRoaW5n IHlvdSBzYXkgaXMgdHJ1ZSwgYnV0IGl0J3MgZXF1YWxseSB0cnVlIGFib3V0IGFueSBwcm90b2Nv bA0KPiA+dGhhdCBtaWdodCBsZXQgeW91IHF1ZXJ5IGEgZGF0YWJhc2UgdGhhdCBjb250YWlucyBQ SUkuICBJdCB3b3VsZCwgZm9yDQo+ID5leGFtcGxlLCBiZSBhcHBsaWNhYmxlIHRvIG9ubGluZSBw aG9uZSBib29rIHdlYiBzaXRlcy4NCj4gPg0KPiA+Rm9yIHRoZSBJQ0FOTiBjb250cmFjdGVkIHJl Z2lzdHJpZXMgYW5kIHJlZ2lzdHJhcnMsIHRoZSBwb2xpY2llcyBhYm91dA0KPiA+d2hvIGNhbiBz ZWUgd2hhdCB2aWEgV0hPSVMgYXJlIGRlZmluZWQgYnkgdGhlaXIgY29udHJhY3RzIHdpdGggSUNB Tk4sDQo+ID5zb21ldGltZXMgbW9kaWZpZWQgYnkgbmF0aW9uYWwgbGF3IHdoZXJlIGl0IGlzIG1v cmUgcmVzdHJpY3RpdmUuDQo+IA0KPiBOaXQgcGlja2luZywgdGhlIOKAnElDQU5OIiBwb2xpY2ll cyBhcmVu4oCZdCAqZGVmaW5lZCogaW4gdGhlIGNvbnRyYWN0cywNCj4gcG9saWNlcyBpbiBJQ0FO TiBhcmUgYSByZXN1bHQgb2YgYSBwb2xpY3kgZGV2ZWxvcG1lbnQgcHJvY2VzcyAtDQo+IGFuYWxv Z291cw0KPiB0byBtYW55IG90aGVyIG9yZ2FuaXphdGlvbnMuICDigJxXaG9Jc+KAnSBpcyBhIHNp Z25pZmljYW50IHRvcGljIG9mDQo+IGRpc2N1c3Npb24NCj4gYW1vbmdzdCBwYXJ0aWNpcGFudHMg aW4gdGhlIHBvbGljeSBkZXZlbG9wbWVudCBwcm9jZXNzZXMuDQo+IA0KPiA+QWxsDQo+ID5vZiB0 aGUgY2NUTERzIHRoYXQgb2ZmZXIgV0hPSVMgaGF2ZSB0aGVpciBvd24gcG9saWNpZXMsIGFnYWlu IGluZm9ybWVkDQo+ID5ieSB0aGUgcmVsZXZhbnQgbmF0aW9uYWwgbGF3LiAgRm9yIG51bWJlcmlu ZyBpbmZvcm1hdGlvbiwgdGhlIFJJUnMNCj4gPmFnYWluIHNldCB0aGVpciBvd24gcG9saWNpZXMg dGhyb3VnaCB0aGVpciBpbnRlcm5hbCBwcm9jZXNzZXMsDQo+ID5hbHRob3VnaCBpdCdzIGxlc3Mg b2YgYW4gaXNzdWUgc2luY2UgaXQgaXMgcmFyZSBmb3IgUklScyB0byBkZWxlZ2F0ZQ0KPiA+dG8g aW5kaXZpZHVhbHMgcmF0aGVyIHRoYW4gb3JnYW5pemF0aW9ucy4NCj4gDQo+IEnigJlkIGRpc2Fn cmVlIHdpdGggdGhhdCB0byBzb21lIGV4dGVudC4gIFRoZXJl4oCZcyBhIHN0cm9uZyBzdHJ1Y3R1 cmFsDQo+IGFuYWxvZ3kgYmV0d2VlbiBhbiBSSVIgYWxsb2NhdGluZyBzcGFjZSB0byBhbiBMSVIg d2hvIHRoZW4gYXNzaWducyBhDQo+IHNtYWxsDQo+IHJhbmdlIHRvIGEgY3VzdG9tZXIgdG8gYSAo ZG9tYWluIG5hbWUgKikgVExEIGFjY2VwdGluZyBhIHJlZ2lzdHJhdGlvbg0KPiBvZiBhDQo+IG5h bWUgZnJvbSBhIHJlZ2lzdHJhciBvbiBiZWhhbGYgb2YgYSByZWdpc3RyYW50LiAgRS5nLiwgc29t ZSBUTERzDQo+IHBlcm1pdA0KPiByZWdpc3RyYW50IGNvbnRhY3QgaW5mb3JtYXRpb24gdG8gYmUg b2JzY3VyZWQgdmlhIGEgdGhpcmQgcGFydHk7IHNvbWUNCj4gUklS4oCZcyBwZXJtaXQgb2JzY3Vy aW5nIHRoZSBob2xkZXIgb2YgYSBsZXNzIHRoYW4gYSDigJxzbGFzaC1Y4oCdICgvMjkgaW4NCj4g SVB2ND8pIG9mIHNwYWNlLg0KPiANCj4gSeKAmXZlIHdvcmtlZCBib3RoIHNpZGVzIG9mIHRoZSBm ZW5jZSwgdGhlcmXigJlzIG5vdCBtdWNoIGRpZmZlcmVuY2UNCj4gYmV0d2Vlbg0KPiB0aGVtLiAg UmVhbGx5LCByZWdpc3RyaWVzIGFyZSByZWdpc3RyaWVzLiAgSG93IHRoZXkgZGVjaWRlIHRvIGFw cHJvdmUgYQ0KPiByZXF1ZXN0IG1heSBkaWZmZXIgLSBhZGRyZXNzZXMgYXJlIGJhc2VkIG9uIGRl bW9uc3RyYXRlZCBuZWVkIHdoaWxlDQo+IHNvbWUNCj4gbmFtZXMgYXJlIGZpcnN0LWNvbWUtZmly c3Qtc2VydmVkIGFuZCBzb21lIGhhdmUgb3RoZXIgY3JpdGVyaWEsIHRoZQ0KPiBwcm9jZXNzIG9m IHJlZ2lzdHJhdGlvbiAob2JqZWN0IC0+IGVudGl0eSkgaXMgdGhlIHNhbWUuDQo+IA0KPiA+U2lu Y2UgdGhpcyBpcyBhbiBJRVRGIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIG1lY2hhbmlzbXMsIGFu ZCB0aGUNCj4gPmxpa2VseSBpbXBsZW1lbnRlcnMgbWVudGlvbmVkIGFib3ZlIGFscmVhZHkgaGF2 ZSAoYmV0dGVyIG9yIHdvcnNlKQ0KPiA+V0hPSVMgcHJpdmFjeSBwb2xpY2llcyBpbiBwbGFjZSB3 aGljaCBub2JvZHkgSSBrbm93IGV4cGVjdHMgdG8gYmUNCj4gPmRpZmZlcmVudCB3aGVuIHRoZXkg bW92ZSBmcm9tIFdIT0lTIHRvIFJEQVAsIGNvdWxkIHlvdSBjbGFyaWZ5IHdobyBpcw0KPiA+dGhl IGludGVuZGVkIGF1ZGllbmNlIGZvciB0aGlzIHByaXZhY3kgZGlzY3Vzc2lvbj8NCj4gDQo+IElN SE8sIGFueW9uZSB3aG8gd2lsbCBpbXBsZW1lbnQgUkRBUCB3aXRob3V0IHJlYWRpbmcgYWxsIG9m IHRoZQ0KPiBkb2N1bWVudHMNCj4gaW4gdGhlIElFVEYgbGlicmFyeS4gOykNCj4gDQo+IEltcGxl bWVudGVycyAhPSBPcGVyYXRvcnMsIGp1c3QgYXMgcHJvdG9jb2wgZW5naW5lZXJzICE9IGltcGxl bWVudGVycw0KPiAoSUVURiBpcyBwcmV0dHkgZ29vZCBhdCBicmlkZ2luZyB0aGF0IGdhcCkuDQo+ IA0KPiBTb21ldGltZXMgaW1wbGVtZW50ZXJzIG5lZWQgdG8ga25vdyB3aGF0IGtub2JzIGFuZCBk aWFscyBhcmUgbmVlZGVkIGluDQo+IGNvZGUgc28gdGhhdCBvcGVyYXRvcnMgY2FuIHJ1biB0aGUg cHJvdG9jb2wuDQoNCkksIHRvbywgZG9uJ3QgaGF2ZSBhbnkgaXNzdWVzIHdpdGggdGhlIHByb3Bv c2VkIHRleHQuIEkgbWF5IGNoYW5nZSBteSBtaW5kIGlmL3doZW4gSSBhY3R1YWxseSBhZGQgaXQg dG8gdGhlIGRvY3VtZW50IGFuZCByZWFkIGl0IG1vcmUgY2xvc2VseSwgYnV0IGluIHRoZSBtZWFu dGltZSBJIHRoaW5rIGl0J3MgZmluZS4NCg0KVGhpcyBsYXN0IHBvaW50IG1hZGUgYnkgRWQgaXMg c2lnbmlmaWNhbnQuIEd1aWRhbmNlIHRoYXQgaGVscHMgcG9saWN5IG1ha2VycyBiZXR0ZXIgdW5k ZXJzdGFuZCB0aGUgbmV3IGtub2JzIGFuZCBkaWFscyB3ZSdyZSBtYWtpbmcgYXZhaWxhYmxlIHRv IHRoZW0gd2lsbCBiZSBoZWxwZnVsLiBDbGVhcmx5IGlkZW50aWZ5aW5nIHRoZXNlIHRvcGljcyB3 aWxsIGhlbHAgaW5mb3JtIHBvbGljeS1tYWtpbmcgZGlzY3Vzc2lvbnMgdGhhdCB3aWxsIG5lZWQg dG8gc3RhcnQgc29vbiBnaXZlbiB0aGF0IHNvbWUgb3BlcmF0b3JzIGhhdmUgY29udHJhY3R1YWwg dGVybXMgdGhhdCBhZGRyZXNzIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50IG9mIFJEQVAu IEhlcmUncyB0aGUgdGV4dCBmcm9tIHRoZSBiYXNlIHJlZ2lzdHJ5IGFncmVlbWVudCAoaHR0cDov L25ld2d0bGRzLmljYW5uLm9yZy9lbi9hcHBsaWNhbnRzL2FnYi9hZ3JlZW1lbnQtYXBwcm92ZWQt MjBub3YxMy1lbi5wZGYpOg0KDQoiUmVnaXN0cnkgT3BlcmF0b3Igc2hhbGwgaW1wbGVtZW50IGEg bmV3IHN0YW5kYXJkIHN1cHBvcnRpbmcgYWNjZXNzIHRvIGRvbWFpbiBuYW1lIHJlZ2lzdHJhdGlv biBkYXRhIChTQUMgMDUxKSBubyBsYXRlciB0aGFuIG9uZSBodW5kcmVkIHRoaXJ0eS1maXZlICgx MzUpIGRheXMgYWZ0ZXIgaXQgaXMgcmVxdWVzdGVkIGJ5IElDQU5OIGlmOiAxKSB0aGUgSUVURiBw cm9kdWNlcyBhIHN0YW5kYXJkIChpLmUuLCBpdCBpcyBwdWJsaXNoZWQsIGF0IGxlYXN0LCBhcyBh IFByb3Bvc2VkIFN0YW5kYXJkIFJGQyBhcyBzcGVjaWZpZWQgaW4gUkZDIDIwMjYpOyBhbmQgMikg aXRzIGltcGxlbWVudGF0aW9uIGlzIGNvbW1lcmNpYWxseSByZWFzb25hYmxlIGluIHRoZSBjb250 ZXh0IG9mIHRoZSBvdmVyYWxsIG9wZXJhdGlvbiBvZiB0aGUgcmVnaXN0cnkuIg0KDQpTY290dA0K From nobody Wed Nov 5 10:37:51 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE141ACF78 for ; Wed, 5 Nov 2014 07:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obMwHS8kTji0 for ; Wed, 5 Nov 2014 07:47:10 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7CC1ACEB0 for ; Wed, 5 Nov 2014 07:47:10 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id ge10so935374lab.16 for ; Wed, 05 Nov 2014 07:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LSOuA24IWWvkNagkG7dyzb4DxDhufcm9YcALabVAYwk=; b=QXSEqh+kAdF9QglJ4seBOGhUwhtXtHxK0ogUi99p3I330exhnd1TDWgukOH0zALbBl JxphaaQTOYrwz5j+SWv1rJX4i3WtORLaLD+O0f+or11XBEPHFKV6JOsKhKYPf+ZWg6MC nsJRQ0lu0KlkW4y5ZkILnGBdzpfYBz/cPCjquKGngOm34f+aLYBHNoM+as9jVWmXUGdB YrKbeRTOWMjnv1RQvNsj/l94dOB9Y7HFPk71FOjEA2+KUoVKOylmKpPhnVgIgXYaPEoy DzD0n+6rEaRcMxmbX4ORQoilnJLKiQwc1ohBruf7oDiSxUekeel5dMcOZEZTM5x6vEHz ul5A== MIME-Version: 1.0 X-Received: by 10.152.1.74 with SMTP id 10mr40323867lak.61.1415202428308; Wed, 05 Nov 2014 07:47:08 -0800 (PST) Received: by 10.112.95.17 with HTTP; Wed, 5 Nov 2014 07:47:08 -0800 (PST) In-Reply-To: References: <513528CD-A267-4583-B997-2AF99E7ECA57@cooperw.in> <20141105030915.75596.qmail@ary.lan> Date: Wed, 5 Nov 2014 10:47:08 -0500 Message-ID: From: Kathleen Moriarty To: Edward Lewis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/_vmuPn6kMzcZq1B0caTOQBUdi_Q X-Mailman-Approved-At: Wed, 05 Nov 2014 10:37:31 -0800 Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:47:12 -0000 On Wed, Nov 5, 2014 at 10:21 AM, Edward Lewis wrot= e: > First I=E2=80=99ll say I am fine with the suggested text. > > Second I=E2=80=99ll respond a bit to John=E2=80=99s comment below: > > -----Original Message----- > From: John Levine > Date: Tuesday, November 4, 2014 at 22:09 > To: "weirds@ietf.org" > Subject: Re: [weirds] Alissa Cooper's Discuss on > draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) > >>>Privacy Threats Associated with Registration Data >> >>Everything you say is true, but it's equally true about any protocol >>that might let you query a database that contains PII. It would, for >>example, be applicable to online phone book web sites. >> >>For the ICANN contracted registries and registrars, the policies about >>who can see what via WHOIS are defined by their contracts with ICANN, >>sometimes modified by national law where it is more restrictive. > > Nit picking, the =E2=80=9CICANN" policies aren=E2=80=99t *defined* in the= contracts, > polices in ICANN are a result of a policy development process - analogous > to many other organizations. =E2=80=9CWhoIs=E2=80=9D is a significant to= pic of discussion > amongst participants in the policy development processes. > >>All >>of the ccTLDs that offer WHOIS have their own policies, again informed >>by the relevant national law. For numbering information, the RIRs >>again set their own policies through their internal processes, >>although it's less of an issue since it is rare for RIRs to delegate >>to individuals rather than organizations. > > I=E2=80=99d disagree with that to some extent. There=E2=80=99s a strong = structural > analogy between an RIR allocating space to an LIR who then assigns a smal= l > range to a customer to a (domain name *) TLD accepting a registration of = a > name from a registrar on behalf of a registrant. E.g., some TLDs permit > registrant contact information to be obscured via a third party; some > RIR=E2=80=99s permit obscuring the holder of a less than a =E2=80=9Cslash= -X=E2=80=9D (/29 in > IPv4?) of space. > > I=E2=80=99ve worked both sides of the fence, there=E2=80=99s not much dif= ference between > them. Really, registries are registries. How they decide to approve a > request may differ - addresses are based on demonstrated need while some > names are first-come-first-served and some have other criteria, the > process of registration (object -> entity) is the same. > >>Since this is an IETF document that describes mechanisms, and the >>likely implementers mentioned above already have (better or worse) >>WHOIS privacy policies in place which nobody I know expects to be >>different when they move from WHOIS to RDAP, could you clarify who is >>the intended audience for this privacy discussion? > > IMHO, anyone who will implement RDAP without reading all of the documents > in the IETF library. ;) > > Implementers !=3D Operators, just as protocol engineers !=3D implementers > (IETF is pretty good at bridging that gap). > > Sometimes implementers need to know what knobs and dials are needed in > code so that operators can run the protocol. Exactly. As we discussed on the telechat, we (ADs interested in this discussion) are all fine with pointing out that knobs are available with RDAP and can be used or not used according to implementers policies. We'd all be a bit more comfortable if there was at least some educational discussion pointing out what is available and have no interest in setting what gets implemented in any kind of policy. Thanks. --=20 Best regards, Kathleen From nobody Wed Nov 5 12:03:06 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083441A6FEA; Wed, 5 Nov 2014 12:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbxtDknKbQnQ; Wed, 5 Nov 2014 12:02:56 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D781A700B; Wed, 5 Nov 2014 12:02:07 -0800 (PST) Received: by mail-oi0-f43.google.com with SMTP id e131so1545885oig.30 for ; Wed, 05 Nov 2014 12:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7B/k8XfbEPp/GbXAHa+54VieH0IN9ulZ1rQFBPLtwlg=; b=LSDm56H2qD5xzr/UHEZUD98eHhjrGzlO8+6fNZrNpf3xgsmAxuwd7vFOzNIWXQMLiQ DDVIqx9qJP6oDuSP4KPQW2j8F9ghhAuYrQnoRn0xNIxYfM6E/YsXE7tFImp8ty7rgAEh xU/i0P5o9uyP/Mo9MQiAdF+XMXeZzWW3pEK/nbmAbPSUOwAqKtYv8UsykOa3+uN29E7U FdaXmN8+zozcJqO9JfZ+XmJIE7AqbZdjnA9TKii2e6ccnscLZ1cCvnBfm7FmaIuRSZsx B5Z2hgMMa/5BDT9lkWuatosaLid0UaruesOms9LMwWOdHH1iw76UnIoaxZbqA9nF3nWo pT8w== X-Received: by 10.202.212.207 with SMTP id l198mr31467868oig.12.1415217727009; Wed, 05 Nov 2014 12:02:07 -0800 (PST) Received: from ?IPv6:2605:6000:9004:ce00:4f8:c4d1:237d:9db3? ([2605:6000:9004:ce00:4f8:c4d1:237d:9db3]) by mx.google.com with ESMTPSA id sm7sm1888143obc.1.2014.11.05.12.02.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 12:02:05 -0800 (PST) Message-ID: <545A823A.9000002@gmail.com> Date: Wed, 05 Nov 2014 14:02:02 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20141029064244.10900.50891.idtracker@ietfa.amsl.com> In-Reply-To: <20141029064244.10900.50891.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/0dbX5kgE6hXVhY-ysV9LeY43eVc Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-json-response@tools.ietf.org Subject: Re: [weirds] Barry Leiba's No Objection on draft-ietf-weirds-json-response-11: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 20:02:59 -0000 On 10/29/2014 01:42 AM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-weirds-json-response-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In section 9 it might be worth saying a few more words about how > responses can be truncated. Until I saw the example, I was thinking that > the JSON itself might be incomplete. The example made me realise that > you're talking about limiting what is returned, not actually truncating > what used to be a complete response. I'm OK with referring to it as > "truncated", but I'd like to see just a little explanation of the > situations you're talking about, so it's clear you don't just mean > snipping it in the middle. This is Barry's comment, but I find "truncated" to be just as confusing as he did. Would "abbreviated" be a better choice of words? Spencer From nobody Tue Nov 18 04:18:54 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E33B1A0369; Tue, 18 Nov 2014 04:18:51 -0800 (PST) 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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA9LEWsWjWMu; Tue, 18 Nov 2014 04:18:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 548221A0371; Tue, 18 Nov 2014 04:18:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141118121848.7354.19920.idtracker@ietfa.amsl.com> Date: Tue, 18 Nov 2014 04:18:48 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/uo6pqyQwiIEK92l3gSzYyuwekLA Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-11.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 12:18:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Security Services for the Registration Data Access Protocol Authors : Scott Hollenbeck Ning Kong Filename : draft-ietf-weirds-rdap-sec-11.txt Pages : 13 Date : 2014-11-18 Abstract: The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services including authentication, authorization, availability, data confidentiality, and data integrity for RDAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-sec-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 18 04:18:56 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D457A1A0372 for ; Tue, 18 Nov 2014 04:18:52 -0800 (PST) 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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVPryIrvT3dl; Tue, 18 Nov 2014 04:18:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D33A01A0379; Tue, 18 Nov 2014 04:18:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com, Kathleen.Moriarty.ietf@gmail.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141118121849.7354.60984.idtracker@ietfa.amsl.com> Date: Tue, 18 Nov 2014 04:18:49 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/w90x5_ZcWCamTFppmcUHllmfCSI Subject: [weirds] New Version Notification - draft-ietf-weirds-rdap-sec-11.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 12:18:53 -0000 A new version (-11) has been submitted for draft-ietf-weirds-rdap-sec: http://www.ietf.org/internet-drafts/draft-ietf-weirds-rdap-sec-11.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-sec-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Nov 19 11:59:38 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F661AD4E8; Wed, 19 Nov 2014 11:59:32 -0800 (PST) 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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgH-aioQp72W; Wed, 19 Nov 2014 11:59:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 805001AD4E1; Wed, 19 Nov 2014 11:58:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141119195853.20008.66676.idtracker@ietfa.amsl.com> Date: Wed, 19 Nov 2014 11:58:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/uN_9vRTXzd2VA1RaYh4xEVUIs54 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-12.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:59:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : JSON Responses for the Registration Data Access Protocol (RDAP) Authors : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-json-response-12.txt Pages : 91 Date : 2014-11-19 Abstract: This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-json-response-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-json-response-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 19 11:59:40 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755111AD4FF for ; Wed, 19 Nov 2014 11:59:35 -0800 (PST) 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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex_PnvK6aHrs; Wed, 19 Nov 2014 11:59:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B861AD4E6; Wed, 19 Nov 2014 11:58:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com, Kathleen.Moriarty.ietf@gmail.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141119195853.20008.40012.idtracker@ietfa.amsl.com> Date: Wed, 19 Nov 2014 11:58:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/10pIrZtF78xEzVLC8IwzZRC-Jzw Subject: [weirds] New Version Notification - draft-ietf-weirds-json-response-12.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:59:35 -0000 A new version (-12) has been submitted for draft-ietf-weirds-json-response: http://www.ietf.org/internet-drafts/draft-ietf-weirds-json-response-12.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-json-response-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Nov 19 17:38:27 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8A11A6FCC; Wed, 19 Nov 2014 17:38:18 -0800 (PST) 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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpVnsLTx7Llp; Wed, 19 Nov 2014 17:38:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E5C1A8AF0; Wed, 19 Nov 2014 17:38:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141120013813.14211.25211.idtracker@ietfa.amsl.com> Date: Wed, 19 Nov 2014 17:38:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/SrvotdDtKZVIbD_EuiPK76rOFKs Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-15.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 01:38:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : HTTP usage in the Registration Data Access Protocol (RDAP) Authors : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-15.txt Pages : 20 Date : 2014-11-19 Abstract: This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-using-http-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-using-http-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 19 17:38:33 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CAE1A8ADD for ; Wed, 19 Nov 2014 17:38:23 -0800 (PST) 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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvG0EZzsBq5u; Wed, 19 Nov 2014 17:38:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B830E1A8AFA; Wed, 19 Nov 2014 17:38:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-using-http@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141120013813.14211.46885.idtracker@ietfa.amsl.com> Date: Wed, 19 Nov 2014 17:38:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/-pDSJrx1VpVhkBFicPNrvWlPK5Q Subject: [weirds] New Version Notification - draft-ietf-weirds-using-http-15.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 01:38:24 -0000 A new version (-15) has been submitted for draft-ietf-weirds-using-http: http://www.ietf.org/internet-drafts/draft-ietf-weirds-using-http-15.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-using-http-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Nov 25 11:47:21 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23551A87A9; Tue, 25 Nov 2014 11:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDFXkhxuLHvU; Tue, 25 Nov 2014 11:45:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E42BA1A87B3; Tue, 25 Nov 2014 11:45:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125194534.30404.29634.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 11:45:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/vmtgnjsHXnhykPrnLZkndpwJsnw Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-json-response@tools.ietf.org Subject: [weirds] Kathleen Moriarty's No Objection on draft-ietf-weirds-json-response-12: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:45:42 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-weirds-json-response-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for adding suggested text to expand the privacy considerations section, this is very helpful. Thanks for addressing the SecDir review and including information on a possible cache poisoning attack. http://www.ietf.org/mail-archive/web/secdir/current/msg05183.html Some nits were included as well that might be helpful. From nobody Tue Nov 25 12:07:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E53F1A8852; Tue, 25 Nov 2014 12:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p6XLxyHiqYh; Tue, 25 Nov 2014 12:05:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 227861A87E7; Tue, 25 Nov 2014 12:05:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125200521.27832.73902.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 12:05:21 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ZGfpHEJBSTfSDZRlbhdp0fSYKTA Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Kathleen Moriarty's No Objection on draft-ietf-weirds-rdap-sec-11: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 20:05:25 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-weirds-rdap-sec-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this and the other Weirds drafts and adding in my requested text on privacy options to the response draft (Alissa's in this draft) as well as addressing my other discuss points (TLS BCP, etc.). The new sections are helpful to explain privacy and access control options (3.1) that have been added in this new protocol. Section 3.1 As an FYI (not asking for anything to be done here except to participate in HTTPAuth last calls) - HTTP Digest and Basic just went through a revision and are just about done. There are a few minor updates and the security considerations in the updated documents spell out the remaining issues. Although these are the solutions for HTTP Auth, most people don't rely on it and use other methods, so we don't have implementations of better options. There are a few other options in the HTTPAuth WG about to go to IETF last call or are WG drafts. If you are going to rely on HTTPAuth methods, maybe there should be a push for the improved options from the WEIRDS WG - at least pitching in to review during last calls. https://datatracker.ietf.org/wg/httpauth/documents/