From nobody Mon Nov 2 19:05:04 2015 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 AB5C01ACED4; Mon, 2 Nov 2015 19:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 G0q9rMhVpLAW; Mon, 2 Nov 2015 19:04:59 -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 E4FEE1ACEC1; Mon, 2 Nov 2015 19:04:57 -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.1044.25; Mon, 2 Nov 2015 19:04:55 -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.1044.021; Mon, 2 Nov 2015 19:04:55 -0800 From: Francisco Arias To: "gtld-tech@icann.org" Thread-Topic: [weirds] gTLD RDAP profile meeting during IETF94 Thread-Index: AQHREpS/sT0xryvMTU6sj9cXMEOUw56Kr9EA Date: Tue, 3 Nov 2015 03:04:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/mixed; boundary="_004_D25E506C77D3Dfranciscoariasicannorg_" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] gTLD RDAP profile meeting during IETF94 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, 03 Nov 2015 03:05:02 -0000 --_004_D25E506C77D3Dfranciscoariasicannorg_ Content-Type: multipart/alternative; boundary="_000_D25E506C77D3Dfranciscoariasicannorg_" --_000_D25E506C77D3Dfranciscoariasicannorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIHRob3NlIG9mIHlvdSBpbnRlcmVzdGVkIGluIGpvaW5pbmcgcmVtb3RlbHksIHBsZWFzZSBh Y2Nlc3MgdGhlIEFkb2JlIENvbm5lY3Qgcm9vbSBiZWxvdy4gSWYgeW91IHdvdWxkIGxpa2UgdG8g am9pbiBieSBwaG9uZSwgdGhlcmUgYXJlIHBob25lIGFjY2VzcyBudW1iZXJzIGluIHRoZSBBZG9i ZSBDb25uZWN0IHJvb20gYW5kIGluIHRoZSBhdHRhY2hlZC4NCg0KaHR0cHM6Ly9pY2Fubi5hZG9i ZWNvbm5lY3QuY29tL3RlY2gtc2VydmljZXMvDQoNCk1lZXRpbmcgaXMgdGhpcyBXZWRuZXNkYXks IDQgTm92ZW1iZXIgZnJvbSAwOTowMCB0byAxMTozMCAoWW9rb2hhbWEgdGltZSksIHdoaWNoIGlz IDAwOjAwIC0gMDI6MzAgVVRDLg0KDQpSZWdhcmRzLA0KDQotLQ0KRnJhbmNpc2NvLg0KDQoNCk9u IDEwLzI5LzE1LCAyOjU3IFBNLCAiRnJhbmNpc2NvIEFyaWFzIiA8ZnJhbmNpc2NvLmFyaWFzQGlj YW5uLm9yZzxtYWlsdG86ZnJhbmNpc2NvLmFyaWFzQGljYW5uLm9yZz4+IHdyb3RlOg0KDQpEZWFy IGNvbGxlYWd1ZXMsDQoNCldlIGhhdmUgcm9vbSA0MTkgaW4gdGhlIElFVEYgdmVudWUgZnJvbSA5 OjAwIC0gMTI6MDAgb24gV2VkbmVzZGF5LCA0LU5vdiAobG9jYWwgdGltZSkuIEFueW9uZSBpbnRl cmVzdGVkIGluIGRpc2N1c3NpbmcgdGhlIGRyYWZ0IGdUTEQgUkRBUCBwcm9maWxlIGlzIHdlbGNv bWUuIEZlZWwgZnJlZSB0byBjaXJjdWxhdGUgdGhpcy4NCg0KUmVnYXJkcywNCg0KLS0NCkZyYW5j aXNjby4NCg0KDQpPbiAxMC8xNC8xNSwgNToxOCBQTSwgIndlaXJkcyBvbiBiZWhhbGYgb2YgR3Vz dGF2byBMb3phbm8iIDx3ZWlyZHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86d2VpcmRzLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBndXN0YXZvLmxvemFub0BpY2Fubi5vcmc8bWFpbHRv Omd1c3Rhdm8ubG96YW5vQGljYW5uLm9yZz4+IHdyb3RlOg0KDQpIZWxsbywNCg0KW0Fwb2xvZ2ll cyBpZiB5b3UgcmVjZWl2ZSBtdWx0aXBsZSBjb3BpZXMgb2YgdGhpcyBlbWFpbF0NCg0KQXJlIHlv dSBpbnRlcmVzdGVkIGluIG1lZXRpbmcgZHVyaW5nIElFVEY5NCBpbiBvcmRlciB0byBkaXNjdXNz IHRoZSBnVExEIFJEQVAgcHJvZmlsZSAoc2VlIGh0dHA6Ly9tbS5pY2Fubi5vcmcvcGlwZXJtYWls L2d0bGQtdGVjaC8yMDE1LVNlcHRlbWJlci8wMDA1MDcuaHRtbCk/DQoNCklmIHRoZXJlIGlzIGVu b3VnaCBpbnRlcmVzdCwgSSBjb3VsZCByZXF1ZXN0IGEgcm9vbS4NCg0KUmVtb3RlIHBhcnRpY2lw YXRpb24gd291bGQgYmUgcHJvdmlkZWQgaWYgdGhlcmUgaXMgaW50ZXJlc3QuDQoNClJlZ2FyZHMs DQpHdXN0YXZvDQo= --_000_D25E506C77D3Dfranciscoariasicannorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+Rm9y IHRob3NlIG9mIHlvdSBpbnRlcmVzdGVkIGluIGpvaW5pbmcgcmVtb3RlbHksIHBsZWFzZSBhY2Nl c3MgdGhlIEFkb2JlIENvbm5lY3Qgcm9vbSBiZWxvdy4gSWYgeW91IHdvdWxkIGxpa2UgdG8gam9p biBieSBwaG9uZSwgdGhlcmUgYXJlIHBob25lIGFjY2VzcyBudW1iZXJzIGluIHRoZSBBZG9iZSBD b25uZWN0IHJvb20gYW5kIGluIHRoZSBhdHRhY2hlZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vaWNhbm4uYWRvYmVjb25uZWN0LmNvbS90ZWNoLXNlcnZp Y2VzIj5odHRwczovL2ljYW5uLmFkb2JlY29ubmVjdC5jb20vdGVjaC1zZXJ2aWNlczwvYT4vPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5NZWV0aW5nIGlzIHRoaXMgV2VkbmVzZGF5LCA0 IE5vdmVtYmVyIGZyb20gMDk6MDAgdG8gMTE6MzAgKFlva29oYW1hIHRpbWUpLCB3aGljaCBpcyAw MDowMCAtIDAyOjMwIFVUQy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMs PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pi0tJm5ic3A7PC9k aXY+DQo8ZGl2PkZyYW5jaXNjby48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxkaXY+DQo8ZGl2Pk9uIDEwLzI5LzE1LCAyOjU3IFBNLCAmcXVvdDtGcmFuY2lz Y28gQXJpYXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuY2lzY28uYXJpYXNAaWNhbm4u b3JnIj5mcmFuY2lzY28uYXJpYXNAaWNhbm4ub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBB RERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5l LWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXpl OiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+ RGVhciBjb2xsZWFndWVzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2UgaGF2ZSBy b29tIDQxOSBpbiB0aGUgSUVURiB2ZW51ZSBmcm9tIDk6MDAgLSAxMjowMCBvbiBXZWRuZXNkYXks IDQtTm92IChsb2NhbCB0aW1lKS4gQW55b25lIGludGVyZXN0ZWQgaW4gZGlzY3Vzc2luZyB0aGUg ZHJhZnQgZ1RMRCBSREFQIHByb2ZpbGUgaXMgd2VsY29tZS4gRmVlbCBmcmVlIHRvIGNpcmN1bGF0 ZSB0aGlzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxk aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+LS0mbmJzcDs8L2Rpdj4NCjxkaXY+ RnJhbmNpc2NvLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdj4NCjxkaXY+T24gMTAvMTQvMTUsIDU6MTggUE0sICZxdW90O3dlaXJkcyBvbiBiZWhhbGYg b2YgR3VzdGF2byBMb3phbm8mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZWlyZHMtYm91bmNl c0BpZXRmLm9yZyI+d2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEg aHJlZj0ibWFpbHRvOmd1c3Rhdm8ubG96YW5vQGljYW5uLm9yZyI+Z3VzdGF2by5sb3phbm9AaWNh bm4ub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9 IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAg MCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+SGVsbG8sPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5bQXBvbG9naWVzIGlmIHlvdSByZWNlaXZlIG11bHRpcGxlIGNvcGllcyBv ZiB0aGlzIGVtYWlsXTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXJlIHlvdSBpbnRl cmVzdGVkIGluIG1lZXRpbmcgZHVyaW5nIElFVEY5NCBpbiBvcmRlciB0byBkaXNjdXNzIHRoZSBn VExEIFJEQVAgcHJvZmlsZSAoc2VlDQo8YSBocmVmPSJodHRwOi8vbW0uaWNhbm4ub3JnL3BpcGVy bWFpbC9ndGxkLXRlY2gvMjAxNS1TZXB0ZW1iZXIvMDAwNTA3Lmh0bWwiPmh0dHA6Ly9tbS5pY2Fu bi5vcmcvcGlwZXJtYWlsL2d0bGQtdGVjaC8yMDE1LVNlcHRlbWJlci8wMDA1MDcuaHRtbDwvYT4p PyZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYgdGhlcmUgaXMgZW5vdWdo IGludGVyZXN0LCBJIGNvdWxkIHJlcXVlc3QgYSByb29tLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5SZW1vdGUgcGFydGljaXBhdGlvbiB3b3VsZCBiZSBwcm92aWRlZCBp ZiB0aGVyZSBpcyBpbnRlcmVzdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2Fy ZHMsPC9kaXY+DQo8ZGl2Pkd1c3Rhdm88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_D25E506C77D3Dfranciscoariasicannorg_-- --_004_D25E506C77D3Dfranciscoariasicannorg_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 03 Nov 2015 03:04:54 GMT"; modification-date="Tue, 03 Nov 2015 03:04:54 GMT" Content-ID: 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.1044.25 via Mailbox Transport; Mon, 2 Nov 2015 18:55:43 -0800 Received: from PFE112-CA-2.pexch112.icann.org (64.78.40.18) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 2 Nov 2015 18:55:41 -0800 Received: from ppa5.dc.icann.org (192.0.46.78) by PFE112-CA-2.pexch112.icann.org (64.78.40.12) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Mon, 2 Nov 2015 18:55:41 -0800 Received: from pechora3.lax.icann.org (pechora3.icann.org [192.0.33.73]) by ppa5.dc.icann.org (8.15.0.59/8.15.0.59) with ESMTPS id tA32tceA018234 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 3 Nov 2015 02:55:39 GMT Received: from mx131182.pbs.unifiedemail.net (mx131182.pbs.unifiedemail.net [209.143.131.182]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id tA32tHSP009983 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 3 Nov 2015 02:55:38 GMT Received: from TEJSMTP01.premconf.com ([206.216.32.1]) by mx.pbs11.unifiedemail.net with MailEnable ESMTP; Mon, 2 Nov 2015 21:55:02 -0500 Received: from ([10.3.3.248]) by TEJSMTP01.premconf.com with Microsoft SMTPSVC(8.5.9600.16384); Mon, 2 Nov 2015 20:55:01 -0600 From: To: Subject: RDAP Date: Mon, 2 Nov 2015 20:55:01 -0600 Content-Type: multipart/mixed; boundary="mix 1209387asdfkje" Message-ID: X-OriginalArrivalTime: 03 Nov 2015 02:55:01.0850 (UTC) FILETIME=[08B823A0:01D115E3] X-ME-Bayesian: 0.000000 Errors-To: Bounces-To: X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Tue, 03 Nov 2015 02:55:38 +0000 (UTC) X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 include:_netblocks.mimecast.com ip4:209.143.131.182 ip4:209.143.131.187 ip4:199.227.211.46 ip4:199.227.211.35 ip4:206.216.32.116 ip4:206.216.32.1 include:aspmx.pardot.com include:sendgrid.net ~all X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-11-03_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=72 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1511030051 Return-Path: DoNotReply@PGi.com X-MS-Exchange-Organization-Network-Message-Id: 31a1d2ad-b97c-4949-5298-08d2e3fa430c X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 X-MS-Exchange-Organization-AuthSource: PFE112-CA-2.pexch112.icann.org X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 --mix 1209387asdfkje Content-Type: text/html; charset="us-ascii"
You're invited.
You've been invited to a GlobalMeet® audio meeting.
Have the meeting call you.
Click the Connect Me link below. No need to dial-in.
Connect Me
Not at your computer?
You can join by dialing one of the access numbers below.
Mobile: tel://1-719-867-1571,*,,2839402851#
Phone Only Controls : https://go.conferencinghub.com/1mrhi
Primary Access Number: 1-719-867-1571
Guest Passcode: 283 940 2851
Additional Access:
USA: 1-719-867-1571
Canada, Calgary: +1 403 407 5797
Canada, Montreal: +1 514 669 5924
Canada, Toronto: +1 647 426 9185
Canada, Vancouver: +1 604 222 1848
Argentina (toll free): 0800 800 1243
Argentina, Buenos Aires: +54 (0) 11 5172 6015
Australia (toll free): 1 800 205 565
Australia, Brisbane: +61 (0) 7 3015 0534
Australia, Melbourne: +61 (0) 3 8687 0563
Australia, Sydney: +61 (0) 2 8017 6211
Austria (toll free): 0800 8866 3423
Austria, Vienna: +43 (0) 1 25302 1796
Bahrain (toll free): 800 81106
Bahrain, Manama: +973 1619 8749
Belarus (toll free): 8 820 0011 0346
Belgium (toll free): 0800 39622
Belgium, Brussels: +32 (0) 2 400 6945
Brazil (toll free): 0800 887 0238
Brazil, Rio de Janeiro: +55 21 4560 0068
Brazil, Sao Paulo: +55 11 4935 7165
Bulgaria (toll free): 00800 111 4960
Bulgaria, Sofia: +359 (0) 2 491 6053
Canada (toll free): 1 855 950 3721
Chile (toll free): 171 800 835 936
Chile, Santiago: +56 (0) 2 2666 0707
China (national): +400 613 8236
China, Beijing: +86 10 5667 0004
China, Shanghai: +86 21 2039 7082
Colombia (toll free): 01 800 755 0099
Colombia, Bogota: +57 1 508 8123
Croatia (toll free): 0800 7377
Cyprus (toll free): 800 97438
Czech Republic (toll free): 800 701 540
Czech Republic, Prague: +420 225 986 568
Denmark (toll free): 80 70 35 95
Denmark, Copenhagen: +45 32 72 78 21
Egypt (toll free): 0800 000 0542
Estonia (toll free): 800 011 1579
Estonia, Tallinn: +372 622 6571
Fiji (toll free): 00800 3326
Finland (toll free): 0800 772 244
Finland, Helsinki: +358 (0) 9 2310 1536
France (national): 0811 655 115
France (toll free): 0800 947 300
France, Paris: +33 (0) 1 70 37 16 77
Germany (national): 01801 001 359
Germany (toll free): 0800 588 9165
Germany, Frankfurt: +49 (0) 69 2222 13416
Germany, Munich: +49 (0) 89 2030 31231
Greece (toll free): 00800 128 821
Greece, Athens: +30 211 181 3832
Hong Kong: +852 3018 9115
Hong Kong (toll free): 800 901 667
Hungary (toll free): 068 002 0147
Hungary, Budapest: +36 1408 8967
Iceland (toll free): 800 9014
India (toll free): 000 800 1008 382
India (toll free): 1800 266 0379
India, Bangalore: +91 (0) 80 6127 6707
India, Chennai: +91 (0)44 6688 6065
India, Delhi: +91 (0) 11 6641 1385
India, Mumbai: +91 (0)22 6187 5035
Indonesia (toll free): 007 803 321 8929
Ireland (national): 1890 907 641
Ireland (toll free): 1800 937 668
Ireland, Dublin: +353 (0) 1 526 9439
Israel (toll free): 1809 258 053
Israel, Tel Aviv: +972 (0)3 721 7956
Italy (toll free): 800 148 216
Italy, Milan: +39 02 3600 8015
Italy, Rome: +39 06 8750 0689
Japan (mobile): 0120 358 311
Japan (toll free): 0120 840 900
Japan, Osaka: +81 (0) 6 4560 2412
Japan, Tokyo: +81 (0) 3 4588 9619
Kazakhstan (toll free): 8800 333 7563
Latvia (toll free): 8000 4416
Latvia, Riga: +371 6601 3643
Lithuania (toll free): 8800 31439
Lithuania, Vilnius: +370 5205 5488
Luxembourg: +352 2088 1799
Luxembourg (toll free): 800 24840
Malaysia (toll free): 1 800 816 154
Malaysia,Kuala Lumpur: +60 (0) 3 7724 8012
Mexico (toll free): 01 800 801 7889
Mexico, Guadalajara: +52 33 4162 3993
Mexico, Mexico City: +52 55 8421 0849
Mexico, Monterrey: +52 81 4162 3845
Morocco (toll free): 0800 091 303
Morocco, Casablanca: +212 (0) 520 48 0029
Netherlands (toll free): 0800 023 1432
Netherlands, Amsterdam: +31 (0) 20 715 3987
New Zealand (toll free): 0800 452 944
New Zealand, Auckland: +64 (0) 9 929 1831
New Zealand, Christchurch: +64 (0) 3 974 2595
New Zealand, Wellington: +64 (0) 4 909 4675
Nigeria, Lagos: +234 1 277 5110
Norway (toll free): 800 56092
Norway, Oslo: +47 21 00 48 39
Oman (toll free): 800 77256
Panama (toll free): 00800 223 1414
Panama, Panama City: +507 8 339 749
Peru (toll free): 0800 78119
Peru, Lima: +51 (0) 1 700 9583
Philippines (toll free): 1 800 111 014 01
Philippines, Manila: +63 (0)2 395 3431
Poland (toll free): 00 800 121 4353
Poland, Warsaw: +48 22 295 3586
Portugal (toll free): 800 788 162
Portugal, Lisbon: 2142 45173
Qatar (toll free): 00 800 100 496
Romania (toll free): 0800 885 824
Romania, Bucharest: +40 (0) 21 529 1309
Russia (toll free): 8 800 500 9280
Russia, Moscow: +7 495 646 1854
Saudi Arabia (toll free): 800 844 9962
Saudi Arabia (toll free): 800 850 0223
Singapore: +65 6823 2279
Singapore (toll free): 800 616 3202
Slovakia (toll free): 0800 606 282
Slovakia, Bratislava: +421 (0)2 3321 5506
Slovenia (toll free): 0800 81211
Slovenia, Ljubljana: +386 1 888 8198
South Africa (toll free): 0800 999 435
South Africa, Johannesburg: +27 (0)11 589 8336
South Korea (toll free): 00798 6136 2235
South Korea, Seoul: +82 (0) 2 6007 0083
Spain (toll free): 900 828 071
Spain, Barcelona: +34 93 800 1974
Spain, Madrid: +34 91 114 7296
Sweden (toll free): 0200 125 598
Sweden, Stockholm: +46 (0) 8 5065 3965
Switzerland (toll free): 0800 841 683
Switzerland, Geneva: +41 (0) 22 595 4838
Switzerland, Zurich: +41 (0) 44 580 7227
Taiwan (toll free): 0800 666 627
Taiwan, Taipei: +886 (0) 2 2650 7331
Thailand (toll free): 001 800 6136 1475
Turkey (toll free): 00 800 4488 28083
Turkey, Istanbul: +90 212 375 5033
UAE (toll free): 8000 3570 2659
UK (03): +44 (0)330 336 6006
UK (national): 0844 581 8066
UK (national): 0845 351 2798
UK (toll free): 0800 358 6403
Ukraine (toll free): 0800 500 869
Uruguay (toll free): 0004 019 0254
USA /Canada (toll free): 1-877-860-3058
Venezuela (toll free): 0 800 100 8414
Vietnam (toll free): 1201 1443
--mix 1209387asdfkje Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR VERSION:2.0 METHOD:REQUEST PRODID:-//Premiere Global Services//Conference Reservation CES 1.0//EN BEGIN:VEVENT ORGANIZER;CN="Francisco Arias Correa":MAILTO:PortalServer@pgi.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="francisco.arias@icann.org":MAILTO:francisco.arias@icann.org DTSTART:20151104T000000Z DTEND:20151104T023000Z UID:{65D5CD1A-A5EE-4E50-AA78-F35B8CC2A514} CLASS:PUBLIC DTSTAMP:20151103T105400Z SUMMARY:RDAP TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:0 LOCATION:See Audio Access below for meeting access information. DESCRIPTION:AUDIO MEETING DETAILS:\n Conference Title: External\n Moderator Name: Francisco Arias Correa\nDate: Tuesday\, November 03\, 2015\nTime: 4:00 PM Pacific Time X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:Reminder TRIGGER;RELATED=START:-PT30M END:VALARM END:VEVENT END:VCALENDAR --mix 1209387asdfkje Content-Type: application/octet-stream; charset="UTF-8"; name="Reminder.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Reminder.ics" QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KTUVUSE9EOlJFUVVFU1QNClBST0RJRDotLy9Q cmVtaWVyZSBHbG9iYWwgU2VydmljZXMvL0NvbmZlcmVuY2UgUmVzZXJ2YXRpb24gQ0VTIDEuMC8v RU4NCkJFR0lOOlZFVkVOVA0KT1JHQU5JWkVSO0NOPSJGcmFuY2lzY28gQXJpYXMgQ29ycmVhIjpN QUlMVE86UG9ydGFsU2VydmVyQHBnaS5jb20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5U O1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049ImZyYW5jaXNjby5hcmlhc0BpY2Fu bi5vcmciOk1BSUxUTzpmcmFuY2lzY28uYXJpYXNAaWNhbm4ub3JnDQpEVFNUQVJUOjIwMTUxMTA0 VDAwMDAwMFoNCkRURU5EOjIwMTUxMTA0VDAyMzAwMFoNClVJRDp7NjVENUNEMUEtQTVFRS00RTUw LUFBNzgtRjM1QjhDQzJBNTE0fQ0KQ0xBU1M6UFVCTElDDQpEVFNUQU1QOjIwMTUxMTAzVDEwNTQw MFoNClNVTU1BUlk6UkRBUA0KVFJBTlNQOk9QQVFVRQ0KU1RBVFVTOkNPTkZJUk1FRA0KU0VRVUVO Q0U6MA0KTE9DQVRJT046U2VlIEF1ZGlvIEFjY2VzcyBiZWxvdyBmb3IgbWVldGluZyBhY2Nlc3Mg aW5mb3JtYXRpb24uDQpERVNDUklQVElPTjpBVURJTyBNRUVUSU5HIERFVEFJTFM6XG4gICBDb25m ZXJlbmNlIFRpdGxlOiAgICBFeHRlcm5hbFxuICAgTW9kZXJhdG9yIE5hbWU6ICAgICAgRnJhbmNp c2NvIEFyaWFzIENvcnJlYVxuRGF0ZTogVHVlc2RheVwsIE5vdmVtYmVyIDAzXCwgMjAxNVxuVGlt ZTogNDowMCBQTSBQYWNpZmljIFRpbWUNClgtTUlDUk9TT0ZULUNETy1CVVNZU1RBVFVTOlRFTlRB VElWRQ0KWC1NSUNST1NPRlQtQ0RPLUlNUE9SVEFOQ0U6MQ0KWC1NSUNST1NPRlQtQ0RPLUlOVEVO REVEU1RBVFVTOkJVU1kNCkJFR0lOOlZBTEFSTQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9O OlJlbWluZGVyDQpUUklHR0VSO1JFTEFURUQ9U1RBUlQ6LVBUMzBNDQpFTkQ6VkFMQVJNDQpFTkQ6 VkVWRU5UDQpFTkQ6VkNBTEVOREFS --mix 1209387asdfkje-- --_004_D25E506C77D3Dfranciscoariasicannorg_-- From nobody Fri Nov 6 12:55:16 2015 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 D63B81A003A for ; Fri, 6 Nov 2015 12:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4I_6x1BYrQvf for ; Fri, 6 Nov 2015 12:55:13 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC30A1A01F7 for ; Fri, 6 Nov 2015 12:55:13 -0800 (PST) Received: by vkbk63 with SMTP id k63so11270847vkb.0 for ; Fri, 06 Nov 2015 12:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=4g0TLLBXCU403aKo3t1itNPVMWHI4Qb1nvp1c/jZ2NQ=; b=dY5ftspg6Wg2RxwahGTSJ+1mj73H2Xgd1JFAE5UAzEEGtEx8uRzn0Pfz+GT3HHm/KC jydBo0ko51pRbg/0fJhGvG2vyp7j7gIZ+yqIApIr2ZESXcv0RiSgy80IgVie8goP2os+ /l3gm1NyrDolGCyW/pZy0++OwCeacxhYx8rATtXnzd6wJ8hPl/GNlMSVq6A4069mT/sC ts7zuSkGxVcn7iu7pp+2lOEDPNLCYQHOr9CTtxJRYF/FIPrISQiH+ytBFY5Hrh6xTu94 YN69L5HTEpdnnxIWZVCkw1FsnZajzwMEkPc5W0WNgOmxnBJn8bYOYvXhH8ovzjLdZbWj Rb/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=4g0TLLBXCU403aKo3t1itNPVMWHI4Qb1nvp1c/jZ2NQ=; b=JshjKE/UYKByoeJo42drYzmbQeGauDYMZtSZDBKubG2+W5fIyYXjfcgQOmZuqVdkyC LIFBMB8K+ZMuS+DuhicDEVrGDlHqaDruqcOh1DcUTeAP4YB78riPo3eN7fTKJPHsn20X o3u2UOvgX+AziPiFVWCRB5kIDq+n+37Yxigaspqpf85S1LUQM2hbAcz5ULjxAtSsQ8ih Gehm9hQ6x/HHKYOB8h1zpIuWefWs9r4PXFfaH32f9iUSQ8QqBwGcy/qGqIAvD21mT5mk puJWRCZvt4VVMOt5tARHSqVxYS/r+qlQUEf68/1UXRT+964ANcjC2NQ+FemxrCNTwwmf 0kcQ== X-Gm-Message-State: ALoCoQmTi4I59S8aldkqdQupKC/4Est4WfV06XmfPlLFgCsNNRvuuBAOMBwxKMRAimQ5THZHnKTB X-Received: by 10.31.138.72 with SMTP id m69mr15770045vkd.66.1446843312736; Fri, 06 Nov 2015 12:55:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.230.68 with HTTP; Fri, 6 Nov 2015 12:54:53 -0800 (PST) From: Brian Mountford Date: Fri, 6 Nov 2015 15:54:53 -0500 Message-ID: To: weirds@ietf.org Content-Type: multipart/alternative; boundary=001a11456322b3bfd10523e575da Archived-At: Cc: Justine Tunney Subject: [weirds] Entity name searches 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: Fri, 06 Nov 2015 20:55:15 -0000 --001a11456322b3bfd10523e575da Content-Type: text/plain; charset=UTF-8 RFC 7483 describes entity name searches. As I understand it, the searches are to use the same rules as for domains and nameservers: a prefix, followed by at most one wildcard, followed by some number of domain labels. I have been assuming that there will be no domain labels for entity names, so it would just be a prefix search. My coworker has pointed out to me that this isn't necessarily so useful. You could search for contacts by first name, but not by last, and so on. Is that in fact what you have in mind with these sorts of searches? And only names? There is no provision for searching entities by address, etc.? Also, what is to be done with non-ASCII characters? Should the names be folded to ASCII values, so that a search for "Bohm" will match an O with an umlaut? Or is that not correct behavior? Is this to be a case-insensitive search? What about whitespace? We didn't see clear directives in the RFC, but maybe we missed them. Thanks. Brian --001a11456322b3bfd10523e575da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC 7483 describes entity name searches. As I understand i= t, the searches are to use the same rules as for domains and nameservers: a= prefix, followed by at most one wildcard, followed by some number of domai= n labels. I have been assuming that there will be no domain labels for enti= ty names, so it would just be a prefix search.

My cowork= er has pointed out to me that this isn't necessarily so useful. You cou= ld search for contacts by first name, but not by last, and so on. Is that i= n fact what you have in mind with these sorts of searches?

And only names? There is no provision for searching entities by ad= dress, etc.?

Also, what is to be done with non-ASC= II characters? Should the names be folded to ASCII values, so that a search= for "Bohm" will match an O with an umlaut? Or is that not correc= t behavior? Is this to be a case-insensitive search? What about whitespace?= We didn't see clear directives in the RFC, but maybe we missed them.

Thanks.

Brian
--001a11456322b3bfd10523e575da-- From nobody Fri Nov 6 13:47:39 2015 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 73A691A6F0B for ; Fri, 6 Nov 2015 13:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 010zOMLo8rTi for ; Fri, 6 Nov 2015 13:47:37 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749611A6F03 for ; Fri, 6 Nov 2015 13:47:37 -0800 (PST) Received: by wmll128 with SMTP id l128so44268914wml.0 for ; Fri, 06 Nov 2015 13:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CSyMNmHLNp8aRR8plMWuPp1ZRR8YiMdapYjnYXmvMH4=; b=XK1jYo06RXI5alChJPbAp0u+aHj7u9hY0iTcYTTBcGrHqYXuV7/cHfakYMd11XFi9s R8q2OmhlgbZGjS2hk8TtN1qgyenLOdlvcjMS8wlCCgGImYduHTXp2sKnkjp+vYkQgO5/ 5B6w9THw41qVzRY95+e8S6WwViI582UHq8vHtucMNhtOMDrkFgMoIWNa9wq9J1pwnIxy l4ajnow6fnISl3Gt7rLlhMmLN4j8ZnVYXdR5GMhIf2KVuGL/RKQGia1eG+cV6EJAssQP 5mqMnBRx2+/tV8MmuklN3mQjzsuiOmg4RCUG42Q7Vcd54y6UtkNv3gGF8poNN7ssPDC3 NAYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CSyMNmHLNp8aRR8plMWuPp1ZRR8YiMdapYjnYXmvMH4=; b=U/0OqHDhwUbr+b4rId8naS9efJ3JTozHZta6wZdVty2mJDo3gDYXdZkG2y9B2mULci F4o8wheqo3F9juTUEj/CQE+w0qGWntluUNasgUjv9SiQLwSnUc81TAP1S3vMabP1Wg7G u42LX8eImdOW2bjQJwsXhs2byC24AoX0NQourV1r1x2JRdgLMQLG8tPmWZ1xh2Pv0AnA tZlNAzfaCX6XqFIKPVefEBqQYeuQ8z8wuuS7bLuzi8l3MfAs6aaEDeWQG5Kkgt6VG48S h//QcNYrHoIbsTSw+92lvMBIzS4QCmuLnF0vkZzm/1CNdLVXIAL4k8EzDnAYo5ZPaU3W Sjgg== X-Gm-Message-State: ALoCoQnetQlUvOGjQeulWyYcuhk5KyMSdT1L2/vwlxA+5PUyNUBNZflhXhwztVR2HPUxa8MCQeux MIME-Version: 1.0 X-Received: by 10.28.143.144 with SMTP id r138mr13296246wmd.100.1446846456102; Fri, 06 Nov 2015 13:47:36 -0800 (PST) Received: by 10.194.91.134 with HTTP; Fri, 6 Nov 2015 13:47:36 -0800 (PST) X-Originating-IP: [101.110.53.38] In-Reply-To: References: Date: Sat, 7 Nov 2015 06:47:36 +0900 Message-ID: From: Andrew Newton To: Brian Mountford Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Justine Tunney , "weirds@ietf.org" Subject: Re: [weirds] Entity name searches 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: Fri, 06 Nov 2015 21:47:38 -0000 Welcome to the world of internationalization, where the concept of a last name vs a first name is not universal, and US ASCII is not representative all the characters used. Since you know the data in your database best, you should taylor the interpretation of the query input to that which works best with your registry. On Sat, Nov 7, 2015 at 5:54 AM, Brian Mountford wrote: > > And only names? There is no provision for searching entities by address, > etc.? > I don't think that ever came up. It would require an RDAP extension. I do question how useful such a thing would be. Why does anybody care that a particular registry has contacts living on Mumford Lane in East Westover? Are they searching all the registries for that information? Do they need a telephone book instead? -andy From nobody Mon Nov 9 09:13:15 2015 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 6907B1B7FD1 for ; Mon, 9 Nov 2015 09:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 c5DBjkaHKTmb for ; Mon, 9 Nov 2015 09:13:13 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05A91B7FD0 for ; Mon, 9 Nov 2015 09:13:12 -0800 (PST) Received: by ykdr82 with SMTP id r82so625609ykd.3 for ; Mon, 09 Nov 2015 09:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yVxAvfXW5TKqrhvkQmIniBORNi61t5lHqt+K8SR+ZYM=; b=RNx8zPCB0jGzPzrTE++JkQRlAqmv3jIfpUX9+LEmrMC4RjKQpAF/oju6Q4X8R+A0ez 67KZZ3A2SVKeTtKeOIfngFJV+ifLRnaoECqgxA6OfevOOSzOqP12GICuQqQs2DX8x2mB JNBBbZYY3hM4M4+EoRtGlpocweJRB12uJfLA/41mxNf7FP6krr1CAD3vBZR2dKgfAYR+ NDa18SEELYLcGU2gdwmKDcln1BJA1rG64qslRjtgEvAb+RkAYax/Gme9PFFDVpysYB2O JwsrYK0ZQ6urX3UcY8Nx7UlbpUKM881mYqaHVxp9y7fZiiJHz9RSSMRJHhXi0JeuSe3Y SCzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yVxAvfXW5TKqrhvkQmIniBORNi61t5lHqt+K8SR+ZYM=; b=GOw0+yTElF0IXONpk9Wq/LZxHyQQGSQC5OWFUphM3y6dXzyeKIj8VWT4GJGYVD2UGv dVRNoupZvEUFddRwbigf+2gUdCqkPGVoDRhIvrM9ngadRBNQPzSDBTlEcvc6IbhaftcA RUFKHvr3sSHhVkVR5LsENeUdlhHqH1hyL8eMCa18a/kKoIzED0i8eGvl0nh1PrcYCemH 1SyVANoiHxUobM6y9ctraZQaVprLM7OFi27e4XAywDK5m49uugF2ig+Syc4KMz/ZYpoT 0/XDEIF3PspSo8cR3MxLJ5pjkfLWgyl1Vq7e3ox50IPiUzmGqvLptdtEuaHqfMy77iqx r1QA== X-Gm-Message-State: ALoCoQkvhuKLs1gEBKPn8f8Q3AheU3czp/XTVK7j3e1nPWPMkP7cf8gsUj4TXkUw/QbDvsOBo1a4 X-Received: by 10.13.233.199 with SMTP id s190mr28636764ywe.316.1447089191520; Mon, 09 Nov 2015 09:13:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.230.68 with HTTP; Mon, 9 Nov 2015 09:12:52 -0800 (PST) In-Reply-To: References: From: Brian Mountford Date: Mon, 9 Nov 2015 12:12:52 -0500 Message-ID: To: Andrew Newton Content-Type: multipart/alternative; boundary=001a114ef12238736105241eb5e0 Archived-At: Cc: Justine Tunney , "weirds@ietf.org" Subject: Re: [weirds] Entity name searches 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, 09 Nov 2015 17:13:14 -0000 --001a114ef12238736105241eb5e0 Content-Type: text/plain; charset=UTF-8 Well, for instance, one might want to search the organization. When I do a WHOIS query for google.com, the contacts have an organization of Google Inc. I might want to search for all contacts with that organization. I can try to tailor the interpretation, but since the search string syntax does not allow for arbitrary suffix searching, it's not clear what tailoring is possible. Are you saying that I could take an entity name search string of "McB*" and interpret that as a search for names any of whose words begin with McB, so that it would find Joe McBride as well as McBurns Simpson? That seems to be playing pretty loose with the partial search string rules, since the RFC takes pains to define that syntax so precisely. Brian On Fri, Nov 6, 2015 at 4:47 PM, Andrew Newton wrote: > Welcome to the world of internationalization, where the concept of a > last name vs a first name is not universal, and US ASCII is not > representative all the characters used. > > Since you know the data in your database best, you should taylor the > interpretation of the query input to that which works best with your > registry. > > On Sat, Nov 7, 2015 at 5:54 AM, Brian Mountford > wrote: > > > > And only names? There is no provision for searching entities by address, > > etc.? > > > > I don't think that ever came up. It would require an RDAP extension. I > do question how useful such a thing would be. Why does anybody care > that a particular registry has contacts living on Mumford Lane in East > Westover? Are they searching all the registries for that information? > Do they need a telephone book instead? > > -andy > --001a114ef12238736105241eb5e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 6, 2015 at 4:47 PM, Andrew Newton <andy@hxr.us><= /span> wrote:
Welcome to the world of int= ernationalization, where the concept of a
last name vs a first name is not universal, and US ASCII is not
representative all the characters used.

Since you know the data in your database best, you should taylor the
interpretation of the query input to that which works best with your
registry.

On Sat, Nov 7, 2015 at 5:54 AM, Brian Mountford <mountford@google.com> wrote:
>
> And only names? There is no provision for searching entities by addres= s,
> etc.?
>

I don't think that ever came up. It would require an RDAP extens= ion. I
do question how useful such a thing would be. Why does anybody care
that a particular registry has contacts living on Mumford Lane in East
Westover? Are they searching all the registries for that information?
Do they need a telephone book instead?

-andy

--001a114ef12238736105241eb5e0-- From nobody Mon Nov 9 09:45:06 2015 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 04D2E1A8969 for ; Mon, 9 Nov 2015 09:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 Uv2MxZ_dAR7Q for ; Mon, 9 Nov 2015 09:45:02 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D64E1A8967 for ; Mon, 9 Nov 2015 09:45:02 -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.1044.25; Mon, 9 Nov 2015 09:45:00 -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.1044.021; Mon, 9 Nov 2015 09:45:00 -0800 From: Dave Piscitello To: Brian Mountford Thread-Topic: [weirds] Entity name searches Thread-Index: AQHRGNV/4iTet5vJAke73jAZnpXocZ6QDfAAgARqPACAAAj1gA== Date: Mon, 9 Nov 2015 17:44:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.236] Content-Type: multipart/signed; boundary="Apple-Mail=_83341103-0C14-45EB-BEA9-BA232B7AC8EA"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Justine Tunney , "weirds@ietf.org" Subject: Re: [weirds] Entity name searches 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, 09 Nov 2015 17:45:05 -0000 --Apple-Mail=_83341103-0C14-45EB-BEA9-BA232B7AC8EA Content-Type: multipart/alternative; boundary="Apple-Mail=_33F98B15-A6FD-46FC-9CFA-58155B650D9B" --Apple-Mail=_33F98B15-A6FD-46FC-9CFA-58155B650D9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 More generally, if you are looking at 100,000 registration records that = have been associated with spam, you=E2=80=99d want the ability to search = or pivot on any data/string that establish relationships among the = domain strings (e.g., botnet DGA) but as importantly, _any_ element of = the registration record that subsets share: POC, creation date, name = server=E2=80=A6 > On Nov 9, 2015, at 12:12 PM, Brian Mountford = wrote: >=20 > Well, for instance, one might want to search the organization. When I = do a WHOIS query for google.com , the contacts have = an organization of Google Inc. I might want to search for all contacts = with that organization. >=20 > I can try to tailor the interpretation, but since the search string = syntax does not allow for arbitrary suffix searching, it's not clear = what tailoring is possible. Are you saying that I could take an entity = name search string of "McB*" and interpret that as a search for names = any of whose words begin with McB, so that it would find Joe McBride as = well as McBurns Simpson? That seems to be playing pretty loose with the = partial search string rules, since the RFC takes pains to define that = syntax so precisely. >=20 > Brian >=20 > On Fri, Nov 6, 2015 at 4:47 PM, Andrew Newton > wrote: > Welcome to the world of internationalization, where the concept of a > last name vs a first name is not universal, and US ASCII is not > representative all the characters used. >=20 > Since you know the data in your database best, you should taylor the > interpretation of the query input to that which works best with your > registry. >=20 > On Sat, Nov 7, 2015 at 5:54 AM, Brian Mountford > wrote: > > > > And only names? There is no provision for searching entities by = address, > > etc.? > > >=20 > I don't think that ever came up. It would require an RDAP extension. I > do question how useful such a thing would be. Why does anybody care > that a particular registry has contacts living on Mumford Lane in East > Westover? Are they searching all the registries for that information? > Do they need a telephone book instead? >=20 > -andy >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_33F98B15-A6FD-46FC-9CFA-58155B650D9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 More generally, if you are looking at 100,000 registration = records that have been associated with spam, you=E2=80=99d want the = ability to search or pivot on any data/string that establish = relationships among the domain strings (e.g., botnet DGA) but as = importantly, _any_ element of the registration record that subsets = share: POC, creation date, name server=E2=80=A6

On = Nov 9, 2015, at 12:12 PM, Brian Mountford <mountford@google.com> wrote:

Well, for instance, one might = want to search the organization. When I do a WHOIS query for google.com, the contacts have = an organization of Google Inc. I might want to search for all contacts = with that organization.

I can try to tailor the interpretation, but since the search = string syntax does not allow for arbitrary suffix searching, it's not = clear what tailoring is possible. Are you saying that I could take an = entity name search string of "McB*" and interpret that as a search for = names any of whose words begin with McB, so that it would find Joe = McBride as well as McBurns Simpson? That seems to be playing pretty = loose with the partial search string rules, since the RFC takes pains to = define that syntax so precisely.

Brian

On Fri, = Nov 6, 2015 at 4:47 PM, Andrew Newton <andy@hxr.us> wrote:
Welcome to the world of internationalization, = where the concept of a
last name vs a first name is not universal, and US ASCII is not
representative all the characters used.

Since you know the data in your database best, you should taylor the
interpretation of the query input to that which works best with your
registry.

On Sat, Nov 7, 2015 at 5:54 AM, Brian Mountford <mountford@google.com> wrote:
>
> And only names? There is no provision for searching entities by = address,
> etc.?
>

I don't think that ever came up. It would require an RDAP = extension. I
do question how useful such a thing would be. Why does anybody care
that a particular registry has contacts living on Mumford Lane in = East
Westover? Are they searching all the registries for that information?
Do they need a telephone book instead?

-andy

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

= --Apple-Mail=_33F98B15-A6FD-46FC-9CFA-58155B650D9B-- --Apple-Mail=_83341103-0C14-45EB-BEA9-BA232B7AC8EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWQNuXAAoJEGwWiPOSXEFN9BQH+gJecr+B0mX/cpxSvEuLC62T 0DGtOt6KiNEIu9BZ1zFclskvmDLQ5r2lIbMzuPsXgWAiBf7vBF7LODo/jN2B+Afk M8V44fBDUH3HU136VEypCCC/DXldqwZRljw9TQ+WkRgbeNb8i/kcsCXO55v/gj3f mxhpSzKTBg1mdp6tzeJEA/xy1pCHTDpowLj91lNkgW+vGyQBL2PF9fP9iDqPfIeI NCT5Giq+fh2M24Q+AYYN1IHtnlICweOrlCUVIcq4wttNuco85xffvay4kM8bJxom UMqtJx+e34DEDsK4vL1gRErXjMv0DSBoHYSSyD5BsZdkV/Tfd7wEyqZOGOxcozs= =Q0hp -----END PGP SIGNATURE----- --Apple-Mail=_83341103-0C14-45EB-BEA9-BA232B7AC8EA-- From nobody Mon Nov 9 12:32:36 2015 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 930A01B839F for ; Mon, 9 Nov 2015 12:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 Gokk90VhIJDU for ; Mon, 9 Nov 2015 12:32:34 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B721B839C for ; Mon, 9 Nov 2015 12:32:33 -0800 (PST) Received: by wmww144 with SMTP id w144so92031953wmw.1 for ; Mon, 09 Nov 2015 12:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qjk6gqUaC4pg76L3m6PoBC9MMsCLQdA6AEdVzX1pZJE=; b=yleDdrUxqM/baI3SpwYPqu6pbSgWNER6G90Ycl2byenX+3uSm/WhO7jQGV2NP2k30V qrrhGwfYj89O3Z5LzMYLFcrF3c3Mf3OysjChPa9oTW8BmYnR799nFFqB2MnJYeyGb1Xk e47U3JkFM1s7T5vx4PF8O1x4t9O/Oi4x3Q5gEjcp7/II8jjD1qnnN3CY/+JYBlT+K89A jK2ZsgwQr7d8JC8RNeuR/upafbwvk6lpgJtjPmwOlj3Gap93swtpDSA7ghmUHXrtRhq8 suZJrZRBCc9NQedJb1ESNPSHTFkFW0LQG2mnyiPxBKkY4KLaqLFMQCTlwT5P3cCxBS97 zumA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Qjk6gqUaC4pg76L3m6PoBC9MMsCLQdA6AEdVzX1pZJE=; b=baYo6JvyyCCkvvZ4tWONXHRM83+tM1ZP5rMvKbkirR9ZvybrnmTFpEfXKFRFAQ+snP TL9GdhgwdwotmKlcVoYXQznMm5PTRd6zFmhujQ8l95Jss6Ap893Sqyt9pT4maCR3hI11 r5ZD/i6ukEy196SavOJT+KusUKKONlzcVrREUnynKc62ZTX2UrhwKWa/nyByYot0lKxe +iRpIsRKrUc399Bj/jJv0WabK29GqOX2I5oVqoVeK2sCQdq8hPea93WDFNj9VLbgTz/C a56vyldHsRKLKHavNuegLvaRbdLNe/8pcEmP+hA7YaKgto4ac1709bQsAZ8LANlLe0oN a+ew== X-Gm-Message-State: ALoCoQkV7F+ZxLErJKfjGd+9+TTIlBWZoE8LT4SxDpw/yjnMRPRriGeJoQXt5UAgfECiuO7IDSqC MIME-Version: 1.0 X-Received: by 10.28.174.139 with SMTP id x133mr29828349wme.100.1447101152403; Mon, 09 Nov 2015 12:32:32 -0800 (PST) Received: by 10.194.91.134 with HTTP; Mon, 9 Nov 2015 12:32:32 -0800 (PST) X-Originating-IP: [2001:500:4:15:f24d:a2ff:fe31:a268] In-Reply-To: References: Date: Mon, 9 Nov 2015 15:32:32 -0500 Message-ID: From: Andrew Newton To: Dave Piscitello Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Mountford , Justine Tunney , "weirds@ietf.org" Subject: Re: [weirds] Entity name searches 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, 09 Nov 2015 20:32:35 -0000 Ok. I understand the use case. It still requires an extension to RDAP. That type of search never came up during the standardization process. At ARIN we do offer more targeted RESTful searches, but it has been my experience they are used almost exclusively for data mining. And I suspect that if left wide open, that's how it would be used in RDAP for DNRs. So to get a "system" to work, there would need to be an authorization system... and since we are talking multiple DNRs, that would be federated authorization. And because there are multiple DNRs, these queries would have to be run in parallel against each one (using the bootstrap to find them). And then you have the problem that some domain registries are thin. Those are a lot of problems to solve, and I'm not sure who has the will to do it. -andy On Mon, Nov 9, 2015 at 12:44 PM, Dave Piscitello wrote: > More generally, if you are looking at 100,000 registration records that h= ave > been associated with spam, you=E2=80=99d want the ability to search or pi= vot on any > data/string that establish relationships among the domain strings (e.g., > botnet DGA) but as importantly, _any_ element of the registration record > that subsets share: POC, creation date, name server=E2=80=A6 > > On Nov 9, 2015, at 12:12 PM, Brian Mountford wrote= : > > Well, for instance, one might want to search the organization. When I do = a > WHOIS query for google.com, the contacts have an organization of Google I= nc. > I might want to search for all contacts with that organization. > > I can try to tailor the interpretation, but since the search string synta= x > does not allow for arbitrary suffix searching, it's not clear what tailor= ing > is possible. Are you saying that I could take an entity name search strin= g > of "McB*" and interpret that as a search for names any of whose words beg= in > with McB, so that it would find Joe McBride as well as McBurns Simpson? T= hat > seems to be playing pretty loose with the partial search string rules, si= nce > the RFC takes pains to define that syntax so precisely. > > Brian > > On Fri, Nov 6, 2015 at 4:47 PM, Andrew Newton wrote: >> >> Welcome to the world of internationalization, where the concept of a >> last name vs a first name is not universal, and US ASCII is not >> representative all the characters used. >> >> Since you know the data in your database best, you should taylor the >> interpretation of the query input to that which works best with your >> registry. >> >> On Sat, Nov 7, 2015 at 5:54 AM, Brian Mountford >> wrote: >> > >> > And only names? There is no provision for searching entities by addres= s, >> > etc.? >> > >> >> I don't think that ever came up. It would require an RDAP extension. I >> do question how useful such a thing would be. Why does anybody care >> that a particular registry has contacts living on Mumford Lane in East >> Westover? Are they searching all the registries for that information? >> Do they need a telephone book instead? >> >> -andy > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > From nobody Mon Nov 9 12:45:45 2015 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 0FCE11B83FE for ; Mon, 9 Nov 2015 12:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 7bsOnfNSgKe5 for ; Mon, 9 Nov 2015 12:45:35 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48561B83E4 for ; Mon, 9 Nov 2015 12:45:34 -0800 (PST) Received: by wmnn186 with SMTP id n186so125676582wmn.1 for ; Mon, 09 Nov 2015 12:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VILa/uFmGAnubCNO+5K3FiMoO3auZghMvJmADVr7FhI=; b=qCbd4ldvhP1pOR23WORJDZjgkpxyVSakPD6RW1qac/42C1qf4tg/RaJsr0P7eNY/zG g9h95jjT6eOm5ycPbkwKEEb1hKesvfGAdHn1UafaLfp/2e31aX7PWoJyiDyOcHp0YdGo RZUVUpztYSLed9QP+Rh8NoPhk8jLo62edsz1cyVknMrtM9KR3oMf0lvkHuYxNtxxvv0m ZUkFNyMIQ8Sdjn384+87ZbzjYpyjPwG99c+ey8Qoe/7ntXWsnsn8yDuJjwOIgM3rsWaH oXQhDbRu60pu0EJm11yd0iqAFDw5VVQNdRvlEZFS6ARJskZ4vEztK0CPANNgSAG6kDlZ Fj8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VILa/uFmGAnubCNO+5K3FiMoO3auZghMvJmADVr7FhI=; b=RCgxiBjVqw3Ih0dWnd2VTssVk3p9D/JxwEEqJXsvjnzTlJktl3CwnG0NOFKekh1YS0 yceEgw0KFR6Q07lLjNr6SdaG24B86kGlM++VGnFQY1+kkyIcPeO5Shey49T+i9Kw6obh Hws7w7MbvkUWjs54dVl8ZEzcskv9/sTb257+PpvXsuldrueqLU26jFUm5TqeweiNy2wV JWcUNOBUDdenr69NhN9v2BlxvEiZbTL75jUVBkBsnMX+JSix6fT4cYmrJ+lod5uk9pkQ rVPdyjnbKHZAnsov2ASyXy02LiFvNt2i/FDUHyo7AQovVwQCV7zxaSRoIL0lWBAJjF/i LGAA== X-Gm-Message-State: ALoCoQkTecm/LufHirTOyuUS3RbwSQPEBI6JD+UId6vz0tb5e2GP9zL9/snc11f+jLbmLxWZXy+v MIME-Version: 1.0 X-Received: by 10.194.87.39 with SMTP id u7mr8735865wjz.11.1447101933413; Mon, 09 Nov 2015 12:45:33 -0800 (PST) Received: by 10.194.91.134 with HTTP; Mon, 9 Nov 2015 12:45:33 -0800 (PST) X-Originating-IP: [2001:500:4:15:f24d:a2ff:fe31:a268] In-Reply-To: References: Date: Mon, 9 Nov 2015 15:45:33 -0500 Message-ID: From: Andrew Newton To: Brian Mountford Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Justine Tunney , "weirds@ietf.org" Subject: Re: [weirds] Entity name searches 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, 09 Nov 2015 20:45:36 -0000 It depends. Are you trying to do something useful or trying to meet a conformance checkbox? If it is the former, I'm unsure who would complain with your broadened search results. If the issue is that the semantics in the specification should be better, its best to have a concrete proposal to put in an Internet Draft. If you are trying to conform to something like an ICANN agreement, I'd do as the RFC says because ICANN has signalled they intend to submit Internet Drafts describing the search capabilities they specifically need. Anything you guess at today is likely just to be extra work. -andy On Mon, Nov 9, 2015 at 12:12 PM, Brian Mountford wrote: > Well, for instance, one might want to search the organization. When I do a > WHOIS query for google.com, the contacts have an organization of Google Inc. > I might want to search for all contacts with that organization. > > I can try to tailor the interpretation, but since the search string syntax > does not allow for arbitrary suffix searching, it's not clear what tailoring > is possible. Are you saying that I could take an entity name search string > of "McB*" and interpret that as a search for names any of whose words begin > with McB, so that it would find Joe McBride as well as McBurns Simpson? That > seems to be playing pretty loose with the partial search string rules, since > the RFC takes pains to define that syntax so precisely. > > Brian > > On Fri, Nov 6, 2015 at 4:47 PM, Andrew Newton wrote: >> >> Welcome to the world of internationalization, where the concept of a >> last name vs a first name is not universal, and US ASCII is not >> representative all the characters used. >> >> Since you know the data in your database best, you should taylor the >> interpretation of the query input to that which works best with your >> registry. >> >> On Sat, Nov 7, 2015 at 5:54 AM, Brian Mountford >> wrote: >> > >> > And only names? There is no provision for searching entities by address, >> > etc.? >> > >> >> I don't think that ever came up. It would require an RDAP extension. I >> do question how useful such a thing would be. Why does anybody care >> that a particular registry has contacts living on Mumford Lane in East >> Westover? Are they searching all the registries for that information? >> Do they need a telephone book instead? >> >> -andy > > From nobody Mon Nov 9 12:45:49 2015 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 564F41B8404 for ; Mon, 9 Nov 2015 12:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 hSuZr5oIc2Ey for ; Mon, 9 Nov 2015 12:45:41 -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 68CD51B83FE for ; Mon, 9 Nov 2015 12:45:40 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 9 Nov 2015 12:45:38 -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.1044.021; Mon, 9 Nov 2015 12:45:38 -0800 From: Dave Piscitello To: Andrew Newton Thread-Topic: [weirds] Entity name searches Thread-Index: AQHRGNV/4iTet5vJAke73jAZnpXocZ6QDfAAgARqPACAAAj1gIAALtUAgAADnoA= Date: Mon, 9 Nov 2015 20:45:37 +0000 Message-ID: <29946A12-95CF-451E-8B7E-48A7EA51D62F@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.236] Content-Type: multipart/signed; boundary="Apple-Mail=_FCB7ED55-2FEA-42BD-B418-A7C1A500C7D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Brian Mountford , Justine Tunney , "weirds@ietf.org" Subject: Re: [weirds] Entity name searches 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, 09 Nov 2015 20:45:46 -0000 --Apple-Mail=_FCB7ED55-2FEA-42BD-B418-A7C1A500C7D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Can we clear up one question before we venture into extensions? Q: What is the purpose of such an extension versus the ability that is = naturally available if one is able to collect structured data into a = local data store? For my example, so long as I=E2=80=99m able to gather the 100,000 = structured records, I and others will happily take structured data, = incorporate these into SQL or other databases, and search to our = hearts=E2=80=99 content. What has inhibited the kinds of _domain name_ = investigations my example illustrates in the past was the combination of = non-standard, unstructured data, rate limiting, and other completely = non-RDAP related matters. Perhaps I=E2=80=99m missing something, but the extension(s) required to = do what I suggested on a query level would require federated = {authentication,authorization,auditing=E2=80=A6 } that would be quite = remarkable objective for the numbers world and a monumental undertaking = for the domain world, no? > On Nov 9, 2015, at 3:32 PM, Andrew Newton wrote: >=20 > Ok. I understand the use case. It still requires an extension to RDAP. > That type of search never came up during the standardization process. >=20 > At ARIN we do offer more targeted RESTful searches, but it has been my > experience they are used almost exclusively for data mining. And I > suspect that if left wide open, that's how it would be used in RDAP > for DNRs. So to get a "system" to work, there would need to be an > authorization system... and since we are talking multiple DNRs, that > would be federated authorization. And because there are multiple DNRs, > these queries would have to be run in parallel against each one (using > the bootstrap to find them). And then you have the problem that some > domain registries are thin. Those are a lot of problems to solve, and > I'm not sure who has the will to do it. >=20 > -andy >=20 > On Mon, Nov 9, 2015 at 12:44 PM, Dave Piscitello > wrote: >> More generally, if you are looking at 100,000 registration records = that have >> been associated with spam, you=E2=80=99d want the ability to search = or pivot on any >> data/string that establish relationships among the domain strings = (e.g., >> botnet DGA) but as importantly, _any_ element of the registration = record >> that subsets share: POC, creation date, name server=E2=80=A6 >>=20 >> On Nov 9, 2015, at 12:12 PM, Brian Mountford = wrote: >>=20 >> Well, for instance, one might want to search the organization. When I = do a >> WHOIS query for google.com, the contacts have an organization of = Google Inc. >> I might want to search for all contacts with that organization. >>=20 >> I can try to tailor the interpretation, but since the search string = syntax >> does not allow for arbitrary suffix searching, it's not clear what = tailoring >> is possible. Are you saying that I could take an entity name search = string >> of "McB*" and interpret that as a search for names any of whose words = begin >> with McB, so that it would find Joe McBride as well as McBurns = Simpson? That >> seems to be playing pretty loose with the partial search string = rules, since >> the RFC takes pains to define that syntax so precisely. >>=20 >> Brian >>=20 >> On Fri, Nov 6, 2015 at 4:47 PM, Andrew Newton wrote: >>>=20 >>> Welcome to the world of internationalization, where the concept of a >>> last name vs a first name is not universal, and US ASCII is not >>> representative all the characters used. >>>=20 >>> Since you know the data in your database best, you should taylor the >>> interpretation of the query input to that which works best with your >>> registry. >>>=20 >>> On Sat, Nov 7, 2015 at 5:54 AM, Brian Mountford = >>> wrote: >>>>=20 >>>> And only names? There is no provision for searching entities by = address, >>>> etc.? >>>>=20 >>>=20 >>> I don't think that ever came up. It would require an RDAP extension. = I >>> do question how useful such a thing would be. Why does anybody care >>> that a particular registry has contacts living on Mumford Lane in = East >>> Westover? Are they searching all the registries for that = information? >>> Do they need a telephone book instead? >>>=20 >>> -andy >>=20 >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >>=20 >>=20 --Apple-Mail=_FCB7ED55-2FEA-42BD-B418-A7C1A500C7D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWQQXwAAoJEGwWiPOSXEFNlKUH/iL57HzpzwD2VAeHyJYBXGd8 faNL9NiRVgQMzMK1tCzPerwza73UH/s4R2oTAiZ0esFqDt8Bt/QxgMYRPT/mVRyU XBAmpg25ADL58eSA6KDACyOkGry8XvhgBkHnc17IlVvF9uS4W/NzZaxZERcOiUMp vSitXD4nDdxiX0gAq82vIsZ8kFRPwUXj3x05B1y4sHC55+u+dgqhyeief9aMAQ5c 9L35LTByq2orh5ngtHiPIHqY1h5mZb/+InIVFq/E9PI3KgFbFUuBDzf5manjW0t8 4H5C6hnsTzWMRzk5+T5XbTV3tJsfFkl8L5XNu0lo5K47L3Nd2s49np07cB0SDf4= =9UfM -----END PGP SIGNATURE----- --Apple-Mail=_FCB7ED55-2FEA-42BD-B418-A7C1A500C7D6-- From nobody Mon Nov 9 14:17:25 2015 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 AEC5A1B843B for ; Mon, 9 Nov 2015 14:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 Ga2cfcaNn1el for ; Mon, 9 Nov 2015 14:17:22 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EBB1B85F0 for ; Mon, 9 Nov 2015 14:17:21 -0800 (PST) Received: by wmec201 with SMTP id c201so104533235wme.0 for ; Mon, 09 Nov 2015 14:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UYrrw1LntcoGLD9pXbUI5p+zbTS2Ol4tK4SKWVc7fjI=; b=ZaSmJa5b0MeR4sN1IcO0nKRumR0Z1+F5L7sYaL+SEZ9+EfL8yW6Lg2oCNfywOkch4a /XhamCYIuiEUqdbZfzUSWnTjOasQGgTW7eIeHZqfbGIKs0DpuoyOtdxxvxRdpvBiyuk0 pAPPqywjiTiI4zPiQXcX5wgYpjfyV+eKsJjF93dBp6gBZusO9uO6z3+78Z3pPyIKLytc RDsWfQ2Kgz1Pek00p3AAhsXDUOuvS2VsmWLQKVbHT+tMlI0yfuOa4SXtk9/dLhcFH5DF 7RPgUTjgkiBxLTWVQmHQ2dENYS0uEs37HhsRfa87VSy7oO0FTQfQbS36EHxx3i6ixBZh v7UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UYrrw1LntcoGLD9pXbUI5p+zbTS2Ol4tK4SKWVc7fjI=; b=hxYvRz2slO0B+3mbkqE45l0/qkHy3VW7sAw+2A+dKuwsRTxAmtzj2/smMkJfCY4CWb gcXLcMe7tJDKQLAKxSNEjS4/dgXibrGxRaOchAAG+052r8tQQ0eGlUMd7NuU0J8Klrn0 U3vdHHjaqE+uXDahB7O5tZhDFC+PiA34Hn2xIQTvjGQilIPwrLkfNrw/7klrXNDWCOdV 6HX9elVFxhLlIiSd1egdwFCJhG7h+8bBRQUyVdCRXVC25lfFI+l1tQWQqiJ2aLzSsCRo +P33QyBXXkXHh9Grr79t2XN8TsengF7MLAVDj/7i+LH+242NCgijH05k9JPQE1PzHFBC 6Gnw== X-Gm-Message-State: ALoCoQlxmjkmi4zpyXS2+R5p745rE5gry+Fl6Thb/MzGFcBov3Z52psfUbemmCgH1PhNtp2sqORq MIME-Version: 1.0 X-Received: by 10.28.229.212 with SMTP id c203mr26407257wmh.11.1447107440484; Mon, 09 Nov 2015 14:17:20 -0800 (PST) Received: by 10.194.91.134 with HTTP; Mon, 9 Nov 2015 14:17:20 -0800 (PST) X-Originating-IP: [2001:500:4:15:f24d:a2ff:fe31:a268] In-Reply-To: <29946A12-95CF-451E-8B7E-48A7EA51D62F@icann.org> References: <29946A12-95CF-451E-8B7E-48A7EA51D62F@icann.org> Date: Mon, 9 Nov 2015 17:17:20 -0500 Message-ID: From: Andrew Newton To: Dave Piscitello Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Mountford , Justine Tunney , "weirds@ietf.org" Subject: Re: [weirds] Entity name searches 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, 09 Nov 2015 22:17:23 -0000 Yes, that is certainly doable but what is your initial query? "Give me all your data", even if it is 1000 results at a time, is probably not a good starting point. -andy On Mon, Nov 9, 2015 at 3:45 PM, Dave Piscitello wrote: > Can we clear up one question before we venture into extensions? > > Q: What is the purpose of such an extension versus the ability that is na= turally available if one is able to collect structured data into a local da= ta store? > > For my example, so long as I=E2=80=99m able to gather the 100,000 structu= red records, I and others will happily take structured data, incorporate th= ese into SQL or other databases, and search to our hearts=E2=80=99 content.= What has inhibited the kinds of _domain name_ investigations my example il= lustrates in the past was the combination of non-standard, unstructured dat= a, rate limiting, and other completely non-RDAP related matters. > > Perhaps I=E2=80=99m missing something, but the extension(s) required to d= o what I suggested on a query level would require federated {authentication= ,authorization,auditing=E2=80=A6 } that would be quite remarkable objective= for the numbers world and a monumental undertaking for the domain world, n= o? > >> On Nov 9, 2015, at 3:32 PM, Andrew Newton wrote: >> >> Ok. I understand the use case. It still requires an extension to RDAP. >> That type of search never came up during the standardization process. >> >> At ARIN we do offer more targeted RESTful searches, but it has been my >> experience they are used almost exclusively for data mining. And I >> suspect that if left wide open, that's how it would be used in RDAP >> for DNRs. So to get a "system" to work, there would need to be an >> authorization system... and since we are talking multiple DNRs, that >> would be federated authorization. And because there are multiple DNRs, >> these queries would have to be run in parallel against each one (using >> the bootstrap to find them). And then you have the problem that some >> domain registries are thin. Those are a lot of problems to solve, and >> I'm not sure who has the will to do it. >> >> -andy >> >> On Mon, Nov 9, 2015 at 12:44 PM, Dave Piscitello >> wrote: >>> More generally, if you are looking at 100,000 registration records that= have >>> been associated with spam, you=E2=80=99d want the ability to search or = pivot on any >>> data/string that establish relationships among the domain strings (e.g.= , >>> botnet DGA) but as importantly, _any_ element of the registration recor= d >>> that subsets share: POC, creation date, name server=E2=80=A6 >>> >>> On Nov 9, 2015, at 12:12 PM, Brian Mountford wro= te: >>> >>> Well, for instance, one might want to search the organization. When I d= o a >>> WHOIS query for google.com, the contacts have an organization of Google= Inc. >>> I might want to search for all contacts with that organization. >>> >>> I can try to tailor the interpretation, but since the search string syn= tax >>> does not allow for arbitrary suffix searching, it's not clear what tail= oring >>> is possible. Are you saying that I could take an entity name search str= ing >>> of "McB*" and interpret that as a search for names any of whose words b= egin >>> with McB, so that it would find Joe McBride as well as McBurns Simpson?= That >>> seems to be playing pretty loose with the partial search string rules, = since >>> the RFC takes pains to define that syntax so precisely. >>> >>> Brian >>> >>> On Fri, Nov 6, 2015 at 4:47 PM, Andrew Newton wrote: >>>> >>>> Welcome to the world of internationalization, where the concept of a >>>> last name vs a first name is not universal, and US ASCII is not >>>> representative all the characters used. >>>> >>>> Since you know the data in your database best, you should taylor the >>>> interpretation of the query input to that which works best with your >>>> registry. >>>> >>>> On Sat, Nov 7, 2015 at 5:54 AM, Brian Mountford >>>> wrote: >>>>> >>>>> And only names? There is no provision for searching entities by addre= ss, >>>>> etc.? >>>>> >>>> >>>> I don't think that ever came up. It would require an RDAP extension. I >>>> do question how useful such a thing would be. Why does anybody care >>>> that a particular registry has contacts living on Mumford Lane in East >>>> Westover? Are they searching all the registries for that information? >>>> Do they need a telephone book instead? >>>> >>>> -andy >>> >>> >>> _______________________________________________ >>> weirds mailing list >>> weirds@ietf.org >>> https://www.ietf.org/mailman/listinfo/weirds >>> >>> > From nobody Mon Nov 9 18:51:48 2015 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 A9DAD1A7032 for ; Mon, 9 Nov 2015 18:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 spQXscxfvqkR for ; Mon, 9 Nov 2015 18:51:44 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6B91A7022 for ; Mon, 9 Nov 2015 18:51:44 -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.1044.25; Mon, 9 Nov 2015 18:51:42 -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.1044.021; Mon, 9 Nov 2015 18:51:42 -0800 From: Dave Piscitello To: Andrew Newton Thread-Topic: [weirds] Entity name searches Thread-Index: AQHRGNV/4iTet5vJAke73jAZnpXocZ6QDfAAgARqPACAAAj1gIAALtUAgAADnoCAABmqAIAATJwA Date: Tue, 10 Nov 2015 02:51:42 +0000 Message-ID: <30152CCF-2CB0-45A1-9D3B-7A8A0F7706C2@icann.org> References: <29946A12-95CF-451E-8B7E-48A7EA51D62F@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.236] Content-Type: multipart/signed; boundary="Apple-Mail=_74A5D795-1829-46F4-965F-2783B7E4F2B2"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Brian Mountford , Justine Tunney , "weirds@ietf.org" Subject: Re: [weirds] Entity name searches 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, 10 Nov 2015 02:51:46 -0000 --Apple-Mail=_74A5D795-1829-46F4-965F-2783B7E4F2B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 9, 2015, at 5:17 PM, Andrew Newton wrote: >=20 > Yes, that is certainly doable but what is your initial query? "Give me > all your data", even if it is 1000 results at a time, is probably not > a good starting point. I think we=E2=80=99re losing the thread. I was offering an example to = illustrate how Whois =E2=80=9Csearch" is used in security/operations = today, as a counterpoint to what Brian was asking for (a search on data = other than the domain). Brian asked the original question so he=E2=80=99s best suited to answer = =E2=80=9Cwhat is your initial query=E2=80=9D. >=20 > -andy >=20 > On Mon, Nov 9, 2015 at 3:45 PM, Dave Piscitello > wrote: >> Can we clear up one question before we venture into extensions? >>=20 >> Q: What is the purpose of such an extension versus the ability that = is naturally available if one is able to collect structured data into a = local data store? >>=20 >> For my example, so long as I=E2=80=99m able to gather the 100,000 = structured records, I and others will happily take structured data, = incorporate these into SQL or other databases, and search to our = hearts=E2=80=99 content. What has inhibited the kinds of _domain name_ = investigations my example illustrates in the past was the combination of = non-standard, unstructured data, rate limiting, and other completely = non-RDAP related matters. >>=20 >> Perhaps I=E2=80=99m missing something, but the extension(s) required = to do what I suggested on a query level would require federated = {authentication,authorization,auditing=E2=80=A6 } that would be quite = remarkable objective for the numbers world and a monumental undertaking = for the domain world, no? >>=20 >>> On Nov 9, 2015, at 3:32 PM, Andrew Newton wrote: >>>=20 >>> Ok. I understand the use case. It still requires an extension to = RDAP. >>> That type of search never came up during the standardization = process. >>>=20 >>> At ARIN we do offer more targeted RESTful searches, but it has been = my >>> experience they are used almost exclusively for data mining. And I >>> suspect that if left wide open, that's how it would be used in RDAP >>> for DNRs. So to get a "system" to work, there would need to be an >>> authorization system... and since we are talking multiple DNRs, that >>> would be federated authorization. And because there are multiple = DNRs, >>> these queries would have to be run in parallel against each one = (using >>> the bootstrap to find them). And then you have the problem that some >>> domain registries are thin. Those are a lot of problems to solve, = and >>> I'm not sure who has the will to do it. >>>=20 >>> -andy >>>=20 >>> On Mon, Nov 9, 2015 at 12:44 PM, Dave Piscitello >>> wrote: >>>> More generally, if you are looking at 100,000 registration records = that have >>>> been associated with spam, you=E2=80=99d want the ability to search = or pivot on any >>>> data/string that establish relationships among the domain strings = (e.g., >>>> botnet DGA) but as importantly, _any_ element of the registration = record >>>> that subsets share: POC, creation date, name server=E2=80=A6 >>>>=20 >>>> On Nov 9, 2015, at 12:12 PM, Brian Mountford = wrote: >>>>=20 >>>> Well, for instance, one might want to search the organization. When = I do a >>>> WHOIS query for google.com, the contacts have an organization of = Google Inc. >>>> I might want to search for all contacts with that organization. >>>>=20 >>>> I can try to tailor the interpretation, but since the search string = syntax >>>> does not allow for arbitrary suffix searching, it's not clear what = tailoring >>>> is possible. Are you saying that I could take an entity name search = string >>>> of "McB*" and interpret that as a search for names any of whose = words begin >>>> with McB, so that it would find Joe McBride as well as McBurns = Simpson? That >>>> seems to be playing pretty loose with the partial search string = rules, since >>>> the RFC takes pains to define that syntax so precisely. >>>>=20 >>>> Brian >>>>=20 >>>> On Fri, Nov 6, 2015 at 4:47 PM, Andrew Newton wrote: >>>>>=20 >>>>> Welcome to the world of internationalization, where the concept of = a >>>>> last name vs a first name is not universal, and US ASCII is not >>>>> representative all the characters used. >>>>>=20 >>>>> Since you know the data in your database best, you should taylor = the >>>>> interpretation of the query input to that which works best with = your >>>>> registry. >>>>>=20 >>>>> On Sat, Nov 7, 2015 at 5:54 AM, Brian Mountford = >>>>> wrote: >>>>>>=20 >>>>>> And only names? There is no provision for searching entities by = address, >>>>>> etc.? >>>>>>=20 >>>>>=20 >>>>> I don't think that ever came up. It would require an RDAP = extension. I >>>>> do question how useful such a thing would be. Why does anybody = care >>>>> that a particular registry has contacts living on Mumford Lane in = East >>>>> Westover? Are they searching all the registries for that = information? >>>>> Do they need a telephone book instead? >>>>>=20 >>>>> -andy >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> weirds mailing list >>>> weirds@ietf.org >>>> https://www.ietf.org/mailman/listinfo/weirds >>>>=20 >>>>=20 >>=20 --Apple-Mail=_74A5D795-1829-46F4-965F-2783B7E4F2B2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWQVu4AAoJEGwWiPOSXEFNbcEH/iOUMlOxBmzxMbYNL2kQ6sr2 Us7iAY7x6l/F5MYMKlcK9FEIPZGOCOcmwr+iTV0Enf7l5wRmykO+Ejd9TY2n4Ek/ 5rgDD0w0GQBK2S/ok7YYNLzdoCZVYQYYjlNIS1bGwDZPxyuN2BAbm1rJOyr0aWxt vNG3C/tRIiFd4lC2Q20bSnCcoIxLFHcf72oyg3qigwMqUsFnWNpBpH+bDRPsXy5h zhCtFvCE7sfAImmfQnrCF9fpMf2Z5FBtytaZwp/TU+MjwV8gKccM+eWnXY188lLC RqYuKETiUbiK8REVCpSv1C5zyeqHfc1Tdvr4NS9qPXyam2Vs2tfQo9axuPbfBmg= =6lgc -----END PGP SIGNATURE----- --Apple-Mail=_74A5D795-1829-46F4-965F-2783B7E4F2B2-- From nobody Tue Nov 10 03:55:11 2015 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 A49F01A8982 for ; Tue, 10 Nov 2015 03:55:10 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 lviv4IcJzJDx for ; Tue, 10 Nov 2015 03:55:09 -0800 (PST) Received: from mail-oi0-x263.google.com (mail-oi0-x263.google.com [IPv6:2607:f8b0:4003:c06::263]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359B41A8946 for ; Tue, 10 Nov 2015 03:55:09 -0800 (PST) Received: by oie188 with SMTP id 188so6342553oie.0 for ; Tue, 10 Nov 2015 03:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign_com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=DoqgEMNDdtrD9UHytW/I2R1x3Qpk6tXbncXnVZqumkA=; b=n4lL4zY+s0ReuDfy1oBLlGAkUL7Yy0rt5wrO7JLJ3hnWWgErLx6zV38DbGjuCxCaEL VkafdzmQAp5cvEPxqUuRwQ3mxFd5ATQYex2bxbMFYsJWO0B1UdihbOs9Dl8Pn9DlGi9T rcxajvDiKab/hF5ciR5liTw8TZWn4u/jiXukXIadNSIZNlaqD1swSFYeydk6i4iG8BjE lHu5YEysoFIG1SPN7dEv2xi7zMK2un4bCBH0abG4uYpnmEDMJygkEyJ3AKIpxopi/YEV HekrtZhMGI7nUIek00VzY+GsIoUrpRBBH8jVdWdZdV5CW806jtJsYidmFL1jK3/iEh9V NDJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-transfer-encoding :mime-version; bh=DoqgEMNDdtrD9UHytW/I2R1x3Qpk6tXbncXnVZqumkA=; b=YC6mrcceIkWLAF9BkU1vtSsmoTmhEC5TjjVaV9QiYG9N8LXa+hzyiB6YsVPboo9GgI FUdH0olMmgy10yqLiFgoUuI2x2oFWRMA88AIYDvDSfZ58P3FobMFdajEIWMVOEBUHR/9 p1avFAhu6qyJo7S89wf7Wb2GfmaCPqLz3slPNwXi8OxSOCx6odS/OHz1grD1b4GqtVcl hCwc9+aYjEER3mEcVhzfVd0QwRb7NuEqfkresEHa5KO9Q5EqquW9zJuaIBw/+i/pqLOh ZHX9ellVjCdpEfb+ca4mpnXbfTP+28rbZdRroQQQBKB/YY+Sq0gCt8cxCaXw2NTzkyPa 1osQ== X-Gm-Message-State: ALoCoQlUmX+8FrXUoLTy0sCbChYTUFqyK2Tffw1hzCk4IYQZHjl5PmxMKI3cAC8x7FNKUoY1CxKY5xsMgUB38HLQEYwQXiRTMQ== X-Received: by 10.140.27.171 with SMTP id 40mr3631265qgx.31.1447156508487; Tue, 10 Nov 2015 03:55:08 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id e129sm249645qka.12.2015.11.10.03.55.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 10 Nov 2015 03:55:08 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id tAABt7p5024044 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2015 06:55:07 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 10 Nov 2015 06:55:07 -0500 From: "Hollenbeck, Scott" To: Dave Piscitello , Andrew Newton Thread-Topic: [weirds] Entity name searches Thread-Index: AQHRGy3Hk0G825e9TkK4eJoInixAMZ6UfKKAgACpdTA= Date: Tue, 10 Nov 2015 11:55:07 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A0DED19@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <29946A12-95CF-451E-8B7E-48A7EA51D62F@icann.org> In-Reply-To: <29946A12-95CF-451E-8B7E-48A7EA51D62F@icann.org> 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: Cc: Brian Mountford , Justine Tunney , "weirds@ietf.org" Subject: Re: [weirds] Entity name searches 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, 10 Nov 2015 11:55:10 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB3ZWlyZHMgW21haWx0bzp3ZWly ZHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmUNCj4gUGlzY2l0ZWxsbw0KPiBT ZW50OiBNb25kYXksIE5vdmVtYmVyIDA5LCAyMDE1IDM6NDYgUE0NCj4gVG86IEFuZHJldyBOZXd0 b24NCj4gQ2M6IEJyaWFuIE1vdW50Zm9yZDsgSnVzdGluZSBUdW5uZXk7IHdlaXJkc0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW3dlaXJkc10gRW50aXR5IG5hbWUgc2VhcmNoZXMNCg0KW3NuaXBd DQoNCj4gUGVyaGFwcyBJ4oCZbSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IHRoZSBleHRlbnNpb24o cykgcmVxdWlyZWQgdG8gZG8gd2hhdA0KPiBJIHN1Z2dlc3RlZCBvbiBhIHF1ZXJ5IGxldmVsIHdv dWxkIHJlcXVpcmUgZmVkZXJhdGVkDQo+IHthdXRoZW50aWNhdGlvbixhdXRob3JpemF0aW9uLGF1 ZGl0aW5n4oCmIH0gdGhhdCB3b3VsZCBiZSBxdWl0ZQ0KPiByZW1hcmthYmxlIG9iamVjdGl2ZSBm b3IgdGhlIG51bWJlcnMgd29ybGQgYW5kIGEgbW9udW1lbnRhbCB1bmRlcnRha2luZw0KPiBmb3Ig dGhlIGRvbWFpbiB3b3JsZCwgbm8/DQoNClJlbWFya2FibGU/IE1vbnVtZW50YWw/IEkgZG9uJ3Qg dGhpbmsgc28uIFRoZSB0ZWNobm9sb2d5IGV4aXN0cyBhbmQgaXMgYWxyZWFkeSBkb2N1bWVudGVk IGluIGFuIEludGVybmV0LURyYWZ0IEkgd3JvdGUuIFRoZSBiaWdnZXN0IGNoYWxsZW5nZSBpcyBp biBkZXZlbG9waW5nIHRoZSBhdXRob3JpemF0aW9uIHBvbGljaWVzLCBhbmQgdGhlcmUncyBubyBz aG9ydGFnZSBvZiBwZW9wbGUgZG9pbmcgcG9saWN5IHdvcmsgaW4gdGhpcyBzcGFjZS4gVGhpcyB3 b3VsZCBiZSB0aW1lIHdlbGwgc3BlbnQuDQoNClNjb3R0DQo= From nobody Tue Nov 10 04:59:55 2015 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 0F4281ACD97 for ; Tue, 10 Nov 2015 04:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 dkLOPiPv9Dm8 for ; Tue, 10 Nov 2015 04:59:53 -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 517141ACD96 for ; Tue, 10 Nov 2015 04:59:53 -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.1044.25; Tue, 10 Nov 2015 04:59:51 -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.1044.021; Tue, 10 Nov 2015 04:59:51 -0800 From: Dave Piscitello To: "Hollenbeck, Scott" Thread-Topic: [weirds] Entity name searches Thread-Index: AQHRGNV/4iTet5vJAke73jAZnpXocZ6QDfAAgARqPACAAAj1gIAALtUAgAADnoCAAP4mgIAAEg4A Date: Tue, 10 Nov 2015 12:59:50 +0000 Message-ID: <0EB10A53-C1B0-48F7-B45D-67F4542087E1@icann.org> References: <29946A12-95CF-451E-8B7E-48A7EA51D62F@icann.org> <831693C2CDA2E849A7D7A712B24E257F4A0DED19@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A0DED19@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.236] Content-Type: multipart/signed; boundary="Apple-Mail=_ED003F77-3A6C-4A9B-9548-9E6CA29FEAA7"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Brian Mountford , Justine Tunney , "weirds@ietf.org" Subject: Re: [weirds] Entity name searches 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, 10 Nov 2015 12:59:55 -0000 --Apple-Mail=_ED003F77-3A6C-4A9B-9548-9E6CA29FEAA7 Content-Type: multipart/alternative; boundary="Apple-Mail=_3F342C2F-895D-4C35-B219-12E49D01B46E" --Apple-Mail=_3F342C2F-895D-4C35-B219-12E49D01B46E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is only one of the big challenges and my experience is that = authorization policies in a multi-stakeholder community are difficult = agreements to reach. And there are several degrees of separation between polices and = enforcement through contracts. However, I=E2=80=99ll defer to your view and wish you well in the = endeavor. For now, however, I=E2=80=99ll declare success if I can get sufficiently = unfettered access to RDAP to be able to collect registration data and = search/parse it once I have it. > On Nov 10, 2015, at 6:55 AM, Hollenbeck, Scott = wrote: >=20 > The biggest challenge is in developing the authorization policies, --Apple-Mail=_3F342C2F-895D-4C35-B219-12E49D01B46E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This is only one of the big challenges and my experience is = that authorization policies in a multi-stakeholder community are = difficult agreements to reach.
 
And = there are several degrees of separation between polices and enforcement = through contracts. 

However, I=E2=80=99ll defer to your view and wish you well in = the endeavor. 

For now, however, I=E2=80=99ll declare success if I can get = sufficiently unfettered access to RDAP to be able to collect = registration data and search/parse it once I have it. 

On Nov 10, 2015, at 6:55 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

The biggest challenge is in developing the = authorization policies,

= --Apple-Mail=_3F342C2F-895D-4C35-B219-12E49D01B46E-- --Apple-Mail=_ED003F77-3A6C-4A9B-9548-9E6CA29FEAA7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWQepFAAoJEGwWiPOSXEFNLuUH/jTSUnCSaJv2PuTvucog5FA4 3WDfkvmcFIF4V6NOpCPOBUzXPD6cgyX26Oil3zZkDeoGJWp4lgoCTFjyK1q6dCtM lXUtM+HfmU/+1luBBELRH5vXAV4M/rb0FiWgIzXWpZgNkIcEApAsXrJ3BP4hr716 hbVXpP3PZOAfWF6emPS8I4ZOqF6esNlTNLNf7g04k0rVl17SYiPy4UQYA8O4hpD8 LRatMpTxq98u2rIMeRchr18yrD5bliRRDm0UpY4s1lf7RVwJHKsRXLmyuM3Z4QYP Bm6hmXgxcUFnqorZD2nuQXPj8XDWcw7ACCUJ8qqVvMz31kkzPvoNeROnKk4g9ag= =5pzc -----END PGP SIGNATURE----- --Apple-Mail=_ED003F77-3A6C-4A9B-9548-9E6CA29FEAA7-- From nobody Tue Nov 10 06:07:46 2015 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 64B611B2A83 for ; Tue, 10 Nov 2015 06:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 nvxRK7d1Oeru for ; Tue, 10 Nov 2015 06:07:41 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232B41B2A86 for ; Tue, 10 Nov 2015 06:07:41 -0800 (PST) Received: by wmww144 with SMTP id w144so2223827wmw.0 for ; Tue, 10 Nov 2015 06:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ji1CXXNqZ53z48h+LT/A5EdtEEfxOZXymHncbqQWUY8=; b=FQyqJtdkWIipIXZ1Hs6BHVG8BLGhZqB+muM3tKNhWbQz7Sk4nH7bUty+/e7X5i+u0m bmuf7E+9l0Gm/UURunNMxt0sYDHpitGumdP6itZInk/bBAMEKxA7LvpTGerKgIe7caS0 nlD9RN+dIQkofCTHNlFsc1Jy3Ot4gxjQRsoTF+hltjECjg+Yw8HuwQtIbEereYj9hzSN sYm7TRdCxE40tnu7QULsckv9DaaZZYKXij/1ajexUFpMS2jVJHBiUXvkjjVyAHHJUxNb AqsfwuzTuzlpA8/I1v2ArC24ezbVEQU1DL2cVMnHNnJaoSRRS3EZxNFXIX70dbVGI6t7 pQ7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ji1CXXNqZ53z48h+LT/A5EdtEEfxOZXymHncbqQWUY8=; b=FDw9WEz+ZVKashTIihpH11XzvarW6u8bAR5puuqpoHpOhj2pQaYnm57mvyPXJcAsVB RDSBeuaFT9wUaMOQjZiwHQdbioOvD7E1LU6oQfGTpfTVcpZkn8eYkDJWn6Mrdg2LOQ0i MdIWX4eyeQ5z+C1aNJLZdtGACB8mOSTtPDHiaDl6MG1nMFJtcsITCw8bes6zNl15eeEz QKuqPwjBvsX5Y2GTIJUoSolzrF8EzM32Ks2ZP79VdJORBKk8hOYNjtlO8rp0L3iEUbWn p7AvoAGt5hmCc2WXNayoo9x6X6hjSEvitkDeQTw5Jy5IBjwGQJ+KGi4WMzyv4Uxjnvy0 w0bg== X-Gm-Message-State: ALoCoQnQrGCd0HZYQrQwgT9jCQsTyf9z/7JAfapKmEXILkWVyOFrwSh1rdz8UucQDw51ajrkOHNf MIME-Version: 1.0 X-Received: by 10.28.189.5 with SMTP id n5mr705748wmf.76.1447164458820; Tue, 10 Nov 2015 06:07:38 -0800 (PST) Received: by 10.194.91.134 with HTTP; Tue, 10 Nov 2015 06:07:38 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: <564167D3.7050805@dcrocker.net> References: <564167D3.7050805@dcrocker.net> Date: Tue, 10 Nov 2015 09:07:38 -0500 Message-ID: From: Andrew Newton To: Dave Crocker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "weirds@ietf.org" , eppext Subject: Re: [weirds] RDAP adoption? 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, 10 Nov 2015 14:07:43 -0000 On Mon, Nov 9, 2015 at 10:43 PM, Dave Crocker wrote: > * How much operational deployment of servers supporting it is there? In the RIR space, 4 of the 5 RIRs have production systems with the 5th working on moving their beta into production. > > * How much client deployment in software? At the REGOPS workshop in Prague, I think .CZ mentioned they were working on a client. And perhaps there was one other TLD doing so as well. I've put out NicInfo: https://github.com/arineng/nicinfo And I do have a browser-based, pure Javascript client in proof-of-concept stage awaiting my undivided attention to be completed. >From a server software standpoint, RIPE NCC's code is open sourced and on GitHub. CNNIC has a server implementation developed under contract with ICANN, and ARIN has developed a bootstrap sever (on GitHub) which is also an ARIN service. > * But ultimately how much client/server use of the protocol is > there, so far? > > * Any sense of the adoption/use trends? I ran some stats on the ARIN service back in early September (we deployed in late June, so around 70 days after deployment), and here is what I had: Entity queries: 173 Domain queries: 290 IP queries: 40818 Autnum queries: 9203 Registry queries 50224 Bootstrap queries 608 Total Queries 50817 Top 10 User Agents 23270 "-" 15457 "NicInfo 7712 "curl/7.30.0" 1258 "ColdFusion" 1027 "Mozilla/5.0 395 "python-requests/2.7.0 393 "libwww-perl/6.08" 359 "Apache-HttpAsyncClient/4.0 305 "Python-urllib/2.7" 165 "curl/7.19.7 So that is in the noise when compared to port 43 or even ARIN's proprietary restful service, but it's also new. > > * Any sense of what is delaying more and better adoption/use? > > * Any sense of what might improve things? Yes, movement in the gTLD space. We see a lot of domain queries. -andy From nobody Tue Nov 10 06:30:52 2015 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 C3FCE1B2A31; Tue, 10 Nov 2015 06:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YKgoOwcJh0vV; Tue, 10 Nov 2015 06:30:48 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3C11B2A15; Tue, 10 Nov 2015 06:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:cc:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-mailer:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:mime-version; bh=BdLgRQiwdCyGQWb6SQeHCQCot71XmwD0RqbBj1i2rg8=; b=wM8UFiZntpEFQglBYQSCh6f64zqrcne9qMbnNPbqb1wCOytwYmOuPNJ0MQN+8HEqBpTJetw8OkFstACJRy48e1wnxt6vJy4JLKqvVpCAhv8M38bWvl3LNOyHehuDhIRUUBr/sSLSFNziCQYeEXsCqAKShtKIF7SBbdNHb0I3B5Nc5esAZTHx6r3RWN3pFDOSM9U1xGauJZpKG7hM3ZTF4Q+Vf1QmFPnx9xS6UUYHE9t7lxgkKiPwfh3J7Cpl7yNHEmBdZR6CUErABg5tW3jMK54m2QSuAOjoushnK8e6mxyp3QBghngMXDHJlv/psBxm2C2/c6T5XsKClW7iZA1jdw== Received: from ka-mbx02.SIDN.local ([192.168.2.178]) by arn2-kamx.sidn.nl with ESMTP id tAAEUbkJ012477-tAAEUbkL012477 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Tue, 10 Nov 2015 15:30:37 +0100 Received: from ka-mbx02.SIDN.local (192.168.2.178) by ka-mbx02.SIDN.local (192.168.2.178) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 10 Nov 2015 15:30:41 +0100 Received: from ka-mbx02.SIDN.local ([fe80::9855:369a:1ca4:6549]) by ka-mbx02.SIDN.local ([fe80::9855:369a:1ca4:6549%13]) with mapi id 15.00.1076.000; Tue, 10 Nov 2015 15:30:41 +0100 From: Rik Ribbers To: Andrew Newton , Dave Crocker Thread-Topic: [eppext] RDAP adoption? Thread-Index: AQHRG72MktoDusWQ80yaI1Fg37pA0J6VOhAAgAAGawA= Date: Tue, 10 Nov 2015 14:30:40 +0000 Message-ID: <115DBEF8-0DC9-49C6-ABAD-4BABDC1C0EEC@sidn.nl> References: <564167D3.7050805@dcrocker.net> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3096.5) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.4.218] Content-Type: multipart/signed; boundary="Apple-Mail=_A0A4B030-4033-44A4-BEE3-22807888EB05"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: "weirds@ietf.org" , eppext Subject: Re: [weirds] [eppext] RDAP adoption? 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, 10 Nov 2015 14:30:50 -0000 --Apple-Mail=_A0A4B030-4033-44A4-BEE3-22807888EB05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I also recall from the REGOPS workshop the Brazilians (.br) have an = server side implementation in production and there is a RDAP library for = servers in JAVA available from DNS Belgium (.be). Gr, Rik =20 > On 10 Nov 2015, at 15:07, Andrew Newton wrote: >=20 > On Mon, Nov 9, 2015 at 10:43 PM, Dave Crocker = wrote: >> * How much operational deployment of servers supporting it is = there? >=20 > In the RIR space, 4 of the 5 RIRs have production systems with the 5th > working on moving their beta into production. >=20 >>=20 >> * How much client deployment in software? >=20 > At the REGOPS workshop in Prague, I think .CZ mentioned they were > working on a client. And perhaps there was one other TLD doing so as > well. >=20 > I've put out NicInfo: https://github.com/arineng/nicinfo > And I do have a browser-based, pure Javascript client in > proof-of-concept stage awaiting my undivided attention to be > completed. >=20 >> =46rom a server software standpoint, RIPE NCC's code is open sourced = and > on GitHub. CNNIC has a server implementation developed under contract > with ICANN, and ARIN has developed a bootstrap sever (on GitHub) which > is also an ARIN service. >=20 >> * But ultimately how much client/server use of the protocol is >> there, so far? >>=20 >> * Any sense of the adoption/use trends? >=20 > I ran some stats on the ARIN service back in early September (we > deployed in late June, so around 70 days after deployment), and here > is what I had: >=20 > Entity queries: 173 > Domain queries: 290 > IP queries: 40818 > Autnum queries: 9203 > Registry queries 50224 > Bootstrap queries 608 > Total Queries 50817 >=20 > Top 10 User Agents > 23270 "-" > 15457 "NicInfo > 7712 "curl/7.30.0" > 1258 "ColdFusion" > 1027 "Mozilla/5.0 > 395 "python-requests/2.7.0 > 393 "libwww-perl/6.08" > 359 "Apache-HttpAsyncClient/4.0 > 305 "Python-urllib/2.7" > 165 "curl/7.19.7 >=20 > So that is in the noise when compared to port 43 or even ARIN's > proprietary restful service, but it's also new. >=20 >>=20 >> * Any sense of what is delaying more and better adoption/use? >>=20 >> * Any sense of what might improve things? >=20 > Yes, movement in the gTLD space. We see a lot of domain queries. >=20 > -andy >=20 > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext >=20 --Apple-Mail=_A0A4B030-4033-44A4-BEE3-22807888EB05 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOIzCCBqUw ggWNoAMCAQICExQAAAAF7bkLfK8T9gQAAAAAAAUwDQYJKoZIhvcNAQELBQAwTjEVMBMGCgmSJomT 8ixkARkWBWxvY2FsMRQwEgYKCZImiZPyLGQBGRYEU0lETjEfMB0GA1UEAxMWU0lETiBDb3Jwb3Jh dGUgUm9vdCBDQTAeFw0xNTA5MTYwMzE2NDBaFw0yNTA5MTYwMzI2NDBaME0xFTATBgoJkiaJk/Is ZAEZFgVsb2NhbDEUMBIGCgmSJomT8ixkARkWBFNJRE4xHjAcBgNVBAMTFVNJRE4gRmlyc3QgSXNz dWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJhPMyiRK7G1BITufSSEWoss oJYLohAtocoEFvkI5f/PEw7diBfabzr16xAekwH3XUi8T2XxX2QkBTon/eE4gJlfMwtdYdjnpADS LZf1Bvj74sWM02f6/sdw0PaHzTSVY46KnO7ak8jhVce+RGOZIsYKtZ5DDB0su9G8Ds1PUrIA1OoD 3BQrKkY+40UNhwIGXgXinzSRmEWbPGSYOJ3W1ZTIY6iEuLCkF9cpoTBH0blCKUZnPyrBAKCB3h0s QAiSa5Iw1+D0QnZAHrW9djJ0FBiP4V/QCvm/XqSt0eWoJN8aIP+ERHJmd/AKXIeutNc2IGhi0rYC hm/ordvrQr3BJQECAwEAAaOCA3swggN3MBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBRsvs3+ YzxIFcAlFEBQN8h8oPJy7jCBkgYDVR0gBIGKMIGHMIGEBggqAwSLL0NZBTB4MEIGCCsGAQUFBwIC MDYeNABDAG8AcgBwAG8AcgBhAHQAZQAgAFAAbwBsAGkAYwB5ACAAUwB0AGEAdABlAG0AZQBuAHQw MgYIKwYBBQUHAgEWJmh0dHA6Ly9wa2kuc2lkbi5sb2NhbC9QS0kvcG9saWN5LmFzcHgAMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB8GA1Ud IwQYMBaAFG2HVakRv2kyR8yiDXUg/jw7FEZIMIIBJQYDVR0fBIIBHDCCARgwggEUoIIBEKCCAQyG gcZsZGFwOi8vL0NOPVNJRE4lMjBDb3Jwb3JhdGUlMjBSb290JTIwQ0EsQ049a2Etcm9vdGNhMDEs Q049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy YXRpb24sREM9U0lETixEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2Jq ZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGQWh0dHA6Ly9wa2kuc2lkbi5sb2NhbC9DZXJ0 RW5yb2xsL1NJRE4lMjBDb3Jwb3JhdGUlMjBSb290JTIwQ0EuY3JsMIIBKgYIKwYBBQUHAQEEggEc MIIBGDCBugYIKwYBBQUHMAKGga1sZGFwOi8vL0NOPVNJRE4lMjBDb3Jwb3JhdGUlMjBSb290JTIw Q0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZp Z3VyYXRpb24sREM9U0lETixEQz1sb2NhbD9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBZBggrBgEFBQcwAoZNaHR0cDovL3BraS5zaWRuLmxvY2Fs L2NlcnRlbnJvbGwva2Etcm9vdGNhMDFfU0lETiUyMENvcnBvcmF0ZSUyMFJvb3QlMjBDQS5jcnQw DQYJKoZIhvcNAQELBQADggEBAA/Z9NUAejh5NdqXxwAe5907i9I6hMPfBv83h2ixG+1fsBmsr0xj Skx8P7ZnkDEbQacrQqRYruNA2uyQKfm1lvC3n5hvVZ+YA6upDR3Wvz9MG01CfPKLAj4MmqPu+M0J p/rkQ0WFCW+l86baoa0jNOYoUlG/qDGePdn95kj42ePL7qN/0RD0HtKfn1U9xSYdL6CJPeADKYE/ dCtz1eBscCon7slR5ThcHeuJahTW1r72FiHlkQRWGsSKfXR4aSIDReXHk4o63oDvvW3JR9CLI+Gm 9yw6S3tUXzbQb3jPnbJgqz9Gvp/ryMpbZ89Z9++Frc3cd04Qd3Qia2n4nH28QoMwggd2MIIGXqAD AgECAhM8AAAALSlFHmzmx/3gAAAAAAAtMA0GCSqGSIb3DQEBCwUAME0xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEUMBIGCgmSJomT8ixkARkWBFNJRE4xHjAcBgNVBAMTFVNJRE4gRmlyc3QgSXNzdWlu ZyBDQTAeFw0xNTEwMDUxMDE4MzBaFw0xOTAzMTgxMDE4MzBaMIGYMRUwEwYKCZImiZPyLGQBGRYF bG9jYWwxFDASBgoJkiaJk/IsZAEZFgRTSUROMSEwHwYDVQQLExhTSUROIC0gUHJvZHVjdGllb21n ZXZpbmcxDDAKBgNVBAsTA0lDVDEUMBIGA1UEAxMLUmlrIFJpYmJlcnMxIjAgBgkqhkiG9w0BCQEW E3Jpay5yaWJiZXJzQHNpZG4ubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4xy1X kGNEASkcy5owxNvBckb2EHvmGTsWsC2cIBm5f3A9ZRqYZsoy35LRmwMmonVHrU2BO0IZGPXuJ0/1 rifk1KF782uaLJXi0hIr5Np9DxqfrYawCdQfl42niIJcaJvvCGsPEyCO2x2Hvi3aK8h6pH0QaFyZ gPEEWqH3DtZ3jG50g6XXY669+YW1aOhbX+UpNHM3zoeS+jx4hmwCg1Aotduf1JFnk87dkbMpZaAo Er6+7ZQ2CbE4kR+HA9ExzbXgAmK6+dgX7LWi9q7TLIBZO790Lv0InKDhGO7wjSyAMDc6Kgw78BXV Efj9Sq3opNlbC4O6wz5cBLovVS61Eo31AgMBAAGjggQBMIID/TAdBgNVHQ4EFgQUp6fiVbi7Pn+D PepOpGwwHIsu4HMwHwYDVR0jBBgwFoAUbL7N/mM8SBXAJRRAUDfIfKDycu4wggEiBgNVHR8EggEZ MIIBFTCCARGgggENoIIBCYaBxGxkYXA6Ly8vQ049U0lETiUyMEZpcnN0JTIwSXNzdWluZyUyMENB LENOPUtBLVNVQkNBMDEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZp Y2VzLENOPUNvbmZpZ3VyYXRpb24sREM9U0lETixEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGQGh0dHA6Ly9wa2ku c2lkbi5sb2NhbC9DZXJ0RW5yb2xsL1NJRE4lMjBGaXJzdCUyMElzc3VpbmclMjBDQS5jcmwwggFb BggrBgEFBQcBAQSCAU0wggFJMIG5BggrBgEFBQcwAoaBrGxkYXA6Ly8vQ049U0lETiUyMEZpcnN0 JTIwSXNzdWluZyUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2 aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPVNJRE4sREM9bG9jYWw/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwYgYIKwYBBQUHMAKGVmh0dHA6Ly9w a2kuc2lkbi5sb2NhbC9DZXJ0RW5yb2xsL0tBLVNVQkNBMDEuU0lETi5sb2NhbF9TSUROJTIwRmly c3QlMjBJc3N1aW5nJTIwQ0EuY3J0MCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zaWRuLmxvY2Fs L29jc3AwCwYDVR0PBAQDAgWgMDwGCSsGAQQBgjcVBwQvMC0GJSsGAQQBgjcVCIO+xyuFvbxBhs2T LYzeZYS9tDcKgcjfWIbx5RUCAWQCAQUwKQYDVR0lBCIwIAYKKwYBBAGCNwoDBAYIKwYBBQUHAwQG CCsGAQUFBwMCMDUGCSsGAQQBgjcVCgQoMCYwDAYKKwYBBAGCNwoDBDAKBggrBgEFBQcDBDAKBggr BgEFBQcDAjBDBgNVHREEPDA6oCMGCisGAQQBgjcUAgOgFQwTcmlrLnJpYmJlcnNAU0lETi5ubIET cmlrLnJpYmJlcnNAc2lkbi5ubDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggq hkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQELBQADggEBAD3T2DDI sTAaV5bVFXhFhVrwJ7EgYHvLvluKBvRG7lq5gHiHQ6Joog9IyM/qBqRoLEqESOtot/Qt6s9BxXkA 9ypitNjvwTZAH2bbTRBs/Orr0t0k705+bm+Z+9vH4gyaIWpZlPhNcWGUNKXEGnQi13Hqu9NxtvWr KoRmmYt2+cOIEQKkgfwf+WZN6z9Rrn9aVvTtwYHS29gzhpfxU66laPErG+KW/h0tXGCmOLGuL9SI cfQfLEPHTXQpihHWSqthhgjXlN42MTV+7HywhSqV2fFWJFst/e66jYOvJ2IvRXwNdlDWYogKbaws 3KiE4/Y8Rkb4E9MSg4Z2dkHQzAvWcMIxggLYMIIC1AIBATBkME0xFTATBgoJkiaJk/IsZAEZFgVs b2NhbDEUMBIGCgmSJomT8ixkARkWBFNJRE4xHjAcBgNVBAMTFVNJRE4gRmlyc3QgSXNzdWluZyBD QQITPAAAAC0pRR5s5sf94AAAAAAALTAJBgUrDgMCGgUAoIIBSTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTExMTAxNDMwMzdaMCMGCSqGSIb3DQEJBDEWBBTq8IA/ KzPE33M4PCDMMz85KVj11DBzBgkrBgEEAYI3EAQxZjBkME0xFTATBgoJkiaJk/IsZAEZFgVsb2Nh bDEUMBIGCgmSJomT8ixkARkWBFNJRE4xHjAcBgNVBAMTFVNJRE4gRmlyc3QgSXNzdWluZyBDQQIT PAAAAC0pRR5s5sf94AAAAAAALTB1BgsqhkiG9w0BCRACCzFmoGQwTTEVMBMGCgmSJomT8ixkARkW BWxvY2FsMRQwEgYKCZImiZPyLGQBGRYEU0lETjEeMBwGA1UEAxMVU0lETiBGaXJzdCBJc3N1aW5n IENBAhM8AAAALSlFHmzmx/3gAAAAAAAtMA0GCSqGSIb3DQEBAQUABIIBAH5WWBUL9h2ff10UOCqe EAMXn29u8TWqgxC58Fng3J+h+rGXhzbftmao8uT4S+Q64Rxz2U8gWQ65bpw1t2Ktkq7hG4hEf3Ii AVyz2OioAL1s6uqE0a7oXPLuikP68+4vTN+HBoOzlRoKJn5BfpGTnabXXd58/F67B3DUpFUlSrB1 bZmN+u78OSr+Gd8poNk005MdcJEOoU9E+PETDkZvb/MXUHena69Iyc2FW8f4RurO+5SgNg5Dd6Pc aLIcEcq0vhXnKOBv7xHMJvAsMGQAuwiwXZfxkHDE7IC8QR3gL7bZt4mia7Alx6d9IUpVMGSGZ6At KikX9AN+ZiAL9wTH1DYAAAAAAAA= --Apple-Mail=_A0A4B030-4033-44A4-BEE3-22807888EB05-- From nobody Tue Nov 10 09:07:39 2015 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 5BA851B3AFD for ; Tue, 10 Nov 2015 09:07:38 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=unavailable 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 B_YLMuRQaCIi for ; Tue, 10 Nov 2015 09:07:36 -0800 (PST) Received: from mail-qg0-x262.google.com (mail-qg0-x262.google.com [IPv6:2607:f8b0:400d:c04::262]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE5F1B3AF5 for ; Tue, 10 Nov 2015 09:07:36 -0800 (PST) Received: by qgae107 with SMTP id e107so200017qga.1 for ; Tue, 10 Nov 2015 09:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign_com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=pcvW/tFo8vClYdhwvkgLIv4uK8WIZdYKnfJto42FFU0=; b=nCL2WO6H7IbrJfsW0h5z6z7SPv98C+OmPXptP2i+o8YD++PPVqWL5mR2LUN+Ns7eiG WHZW1u9z1lfCJrYNeXuJv6OjQmlXExppLQBPT10gyZ1rUrpbSLn67Q5uuc2xJ2Ci1d1o v3vFmcCyIiiPZ8qfhXuiMfdVp3BqQqYL3kWIv/WqjZJMJHcfYmkPDSurFnOq9SSyyjgH ion0MiQ+L+wGex5NwPf/7v6qAVekS/I6rD1XkBpqOB9u9hewvPLlyvGo1OVdROfB5bfe z1XRcnthjB3GHG6q56dnM/yXcHq2w2v7M2qfqC0TpIZKs+No5fIyLgLWxxqZQkVx2by/ qp3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-transfer-encoding :mime-version; bh=pcvW/tFo8vClYdhwvkgLIv4uK8WIZdYKnfJto42FFU0=; b=EPXW3rw+dusX7tsPjc9Z0JYlorFwXcJnjGgTabRbP0V6bTKAHWcBGcGPmais/3E2ai Zi5szkm7ZDdAdSwuzlJ09ubMHt77liM+AFQjHLXicNNlDj4nJ2hJNDrKdUhQYAhG2snr iC0AoMp4d/UA5QccyGCkYYKnncDz5x4+cQKIk7nLtL3lCAhNYoDg1LREOFs1Mwwg25BU /90TUaPa/oG23xuYVaB5+QQO9l2gTHEG//gzs7g/abOCziqZX+GvLojAZgSGfTQISEHr eZJ9IiW+Svnd+lxnSORH4PFrJJkC4Qmhry+2LU4dOYg4RBOF2Agd3UtI2JKsyhEsUldM k/Aw== X-Gm-Message-State: ALoCoQkGwDD7BR5fiC0HTO3FhRrIGaGUlJF7dhbucPLec+lkNx2/5lbvKKI9VA2Hv2tX9hg1Auq1MX71oVqwXoMfYtkJlBVCEQ== X-Received: by 10.55.207.139 with SMTP id v11mr5629804qkl.53.1447175255585; Tue, 10 Nov 2015 09:07:35 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id p23sm386786qkl.0.2015.11.10.09.07.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 10 Nov 2015 09:07:35 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id tAAH7YUt017957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Nov 2015 12:07:35 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 10 Nov 2015 12:07:34 -0500 From: "Hollenbeck, Scott" To: "dcrocker@bbiw.net" , Andrew Newton Thread-Topic: [eppext] RDAP adoption? Thread-Index: AQHRG72IKaddwQWbvU6SpkqRtyvmnZ6VnqYAgAAVF4D//8jrYA== Date: Tue, 10 Nov 2015 17:07:34 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A0DF4F1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <564167D3.7050805@dcrocker.net> <56420BDB.6050802@dcrocker.net> In-Reply-To: <56420BDB.6050802@dcrocker.net> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "weirds@ietf.org" , eppext Subject: Re: [weirds] [eppext] RDAP adoption? 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, 10 Nov 2015 17:07:38 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Dave Crocker > Sent: Tuesday, November 10, 2015 10:23 AM > To: Andrew Newton > Cc: weirds@ietf.org; eppext > Subject: Re: [eppext] RDAP adoption? [snip] > We have quite a bit of unfortunate history with good efforts at > producing specs that lacked sustained community effort at adoption. > This one sounds much better than those unfortunate cases, but as DNSSec > demonstrated it is too easy to lose momentum. You might want to have > an > explicit -- if informal -- community effort organized at adoption and > use. RDAP has been the focus of a recent series of operationally-focused worksho= ps that I've helped organize. There will be more in the future. Scott From nobody Tue Nov 10 10:29:27 2015 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 95F6E1B3C71; Tue, 10 Nov 2015 10:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 TBao75qazol7; Tue, 10 Nov 2015 10:29:25 -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 27A7E1B3C6E; Tue, 10 Nov 2015 10:29:25 -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.1044.25; Tue, 10 Nov 2015 10:29:22 -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.1044.021; Tue, 10 Nov 2015 10:29:22 -0800 From: Gustavo Lozano To: "eppext@ietf.org" Thread-Topic: Adding missing RDAP event action types for gTLDs Thread-Index: AQHRG+W3Qkw2SFOjD0GXFX7C2VCvSQ== Date: Tue, 10 Nov 2015 18:29:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.35.2] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3529996154_9293738" MIME-Version: 1.0 Archived-At: Cc: "weirds@ietf.org" Subject: [weirds] Adding missing RDAP event action types for gTLDs 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, 10 Nov 2015 18:29:26 -0000 --B_3529996154_9293738 Content-type: multipart/alternative; boundary="B_3529996154_9277283" --B_3529996154_9277283 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello colleagues, As you may know, two of the open issues in the RDAP profile for gTLDs (http://mm.icann.org/pipermail/gtld-tech/attachments/20150928/35901409/gTLDR DAPOperationalProfile-v06-0001.pdf) are missing event action types in the base RDAP specification for: * Last update time of the RDAP database * Registrar registration expiration date You may find the details in the following I-D: https://www.ietf.org/id/draft-lozano-rdap-gtld-whois-additional-events-00.tx t It's important to promptly add these two event action types based on the timeline for deployment of RDAP in the gTLDs. As this appears to be a minor update, I am planning (in the last week of November) on sending a request to IANA, in order to add these two action event types to the RDAP JSON Values Registry following the Expert Review Registration Procedure. I would like to get feedback from the list regarding this proposal. If you agree with the proposal, it would be great if you can reply to the list in order to show the expert reviewer that there is consensus on the list. Regards, Gustavo --B_3529996154_9277283 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hello colleagues,
<= div>
As you may know, two of the open issues in the RDAP profi= le for gTLDs (http://mm.icann.org/pipermail/gtld-tech/attachments/20150928/3= 5901409/gTLDRDAPOperationalProfile-v06-0001.pdf) are missing event action ty= pes in the base RDAP specification for:
* Last update time of the = RDAP database
* Registrar registration expiration date
<= br>
You may find the details in the following I-D: https://www.iet= f.org/id/draft-lozano-rdap-gtld-whois-additional-events-00.txt
It's important to promptly add these two event action types base= d on the timeline for deployment of RDAP in the gTLDs.

<= div>As this appears to be a minor update, I am planning (in the last week of= November) on sending a request to IANA, in order to add these two action ev= ent types to the RDAP JSON Values Registry following the Expert Review Regis= tration Procedure. I would like to get feedback from the list regarding this= proposal. 

If you agree with the proposal, it= would be great if you can reply to the list in order to show the expert rev= iewer that there is consensus on the list.

Regards,=
Gustavo
--B_3529996154_9277283-- --B_3529996154_9293738 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITsQYJKoZIhvcNAQcCoIITojCCE54CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EX0wggb4MIIF4KADAgECAhAMNMzaaOCLlcX5TdjpURhNMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMzA1MDgwMDAw MDBaFw0xNjA1MDgxMjAwMDBaMIGiMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9u IGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczERMA8GA1UECxMIUmVnaXN0cnkxFzAV BgNVBAMTDkd1c3Rhdm8gTG96YW5vMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 3w18r+IUAk+jj+kX9oTY/E3q0GyAzR+0x8YvIlksG3cKpkVBqjAKnpZL+GaN98aXYqsIDo8g gctjo1fAx8QxgPkGeZ56EP5uaaN65I1guFa/mVTzSGg2WyXVMRjJmcLBBt//k9APKpvl4Qj4 o+ItgJAKcEA9mtErJB1UE6FtX6ubRd7l/t2BlYHaJLEmdtA4hXfE9TYiVSo4J8652aQ1ba7I g/Qzse32X4A6gm2w6EbEt7m8UVcH0pbxOXpi8Vvz1l6qG3+kxdtJUclg3os4mm0/Iz5glFzM a7OvDyGDbRZbL8ewlnsx3+mjNqDy2S5xNSYFKmdo65xJL1HItfJcSQIDAQABo4IDZzCCA2Mw HwYDVR0jBBgwFoAUFQASKxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFDejkLO4b/vTq4z4 /ln0RuaCGgvuMCMGA1UdEQQcMBqBGGd1c3Rhdm8ubG96YW5vQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2 oDSGMmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3Js MDigNqA0hjJodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0x LmNybDCCAcUGA1UdIASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEW Lmh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggr BgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIA dABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQA YQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMA IABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkA IABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkA bgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNl cnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADggEBAGaf7RGm6z5gi7JPp8yiw4JQc1rNztSU2JyQfjy3XtFU rrkK3UhhhYKXVoTRL4bSEx2OTc7ejQ2uMNNKU0ew/hPWhx1jU3AMvf6f3FHFt8X/dAcse+TU QyHT822Kup802tVILAijiq+3SnpNoT2VbI1aw1M4lJpIUezERhbDSRkPXMdIK/nRl57KCXc/ PyM2AD4HvdT1OqXQ1j1baeooPcvofWewjD/WyHkpdVbQ+RJ7F1a9ndagERt4D1kTp1yiZwVH 8gKthT5JXVvA1yTOg8Z8nDl2c12SrVQcP/pIAz8VsTNFlIrcO22XGFfyIfj+WFeLkDJeMccK B1IlFAPPKO0wggbCMIIFqqADAgECAhAKBN8hdF1NK4zqM3IFAFDpMA0GCSqGSIb3DQEBBQUA MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5k aWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0w NjExMTAwMDAwMDBaFw0yMTExMTAwMDAwMDBaMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxE aWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lD ZXJ0IEFzc3VyZWQgSUQgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOiC LZn5ysJClaWAc0Bw0p5WVFypxNJBBo/JM/xNRZFcgZ/tLJz4FlnfnrUkFcKYubR3SdyJxAra r8tea+2tsHEx6886QAxGTZPsi3o2CAOrDDT+GEmC/sfHMUiAfB6iD5IOUMnGh+s2P9gww/+m 9/uizW9zI/6sVgWQ8DIhFonGcIj5BZd9o8dD3QLoOz3tsUGj7T++25VIxO4es/K8DCuZ0MZd EkKB4YNugnM/JksUkK5ZZgrEjb7SzgaurYRvSISbT0C58Uzyr5j79s5AXVz2qPEvr+yJIvJr GGWxwXOt1/HYzx4KdFxCuGh+t9V3CidWfA9ipD8yFGCV/QcEogkCAwEAAaOCA28wggNrMA4G A1UdDwEB/wQEAwIBhjA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMD BggrBgEFBQcDBAYIKwYBBQUHAwgwggHGBgNVHSAEggG9MIIBuTCCAbUGC2CGSAGG/WwBAwAE MIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBv c2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAg AHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABl AHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQBy AHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABs AGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0 AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAPBgNVHRMB Af8EBTADAQH/MH0GCCsGAQUFBwEBBHEwbzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DQUNlcnRz L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDov L2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0 aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAd BgNVHQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGL p6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAIRhTkEeuHYEKrW274/yVYW5XVb+Cpjm5L1l in1AKdP8sV1F/Tq4KlszSyRczbm05HOtYV12rXQzimbVI69MH3JuRdl1QLuiO8+NSS/AQbDi KaNROENQmRSsMwY1Yol9d6lSB+VsIFe2gbpvvLPClO12AoDZfM6FqBzsx0NKS7FXz3LO3/Ul PMsiT/2fUtE3ywi7OD7g1T5veQmtW3wxs3c1w+Rj+WgKmAfnRjh3hNI+l7wKoKisJU9EbpHh 0lqva+8wHI2jREKzEIsj+tfmNXQ3rM/rq1gfyYgj/zbUB+o0akfqnZVsnilPU+3jK5UgTirP lmB6+CyA8JVSzimWgWIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3 DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBD QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMT G0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK 3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lY GDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3La nmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0i rj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNj MGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuC MS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3 DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+Df wWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3 +owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMN FG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB /DCCAfgCAQEwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENB LTECEAw0zNpo4IuVxflN2OlRGE0wCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT5pZkM aRXt1QfaJoP24AiSobV/6DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xNTExMTAxODI5MTRaMA0GCSqGSIb3DQEBAQUABIIBALl5p/S/G9GmmGEqhAuTwcs3 e6e0Sn30Ewn2DWlPGGCF27LaT5qjfLkdz1HAu18zuvUXq6NbCLihD0dB7XTOaHWgZz6Ak1jE MxS5LHpxj0rfxY/bi9U4lLU+DTET02VYjEdJXChLAnPudE2Mbi+2RCOCCCdPrXbTzVDNBjq7 TzSfIfeMAfKAa6JDR5w8birQO9dt1bk7CXCinjKZ7GF10+1BzWCr+8w+h4SZC3PlSlsU0xKg xpq+f+krSL6rbc2SVY0WHWDCMBuEaIWFkkNn0lwXPLll+5Ow8OCWayV+y1QodtjkDR2+Wv3I +xGadcBohxaZ03y0buMsKF6Q5ZGTn0E= --B_3529996154_9293738-- From nobody Tue Nov 10 10:45:38 2015 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 BD6BB1B3CA4 for ; Tue, 10 Nov 2015 10:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 fDF0BbqAbQ8e for ; Tue, 10 Nov 2015 10:45:35 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBFE1A9025 for ; Tue, 10 Nov 2015 10:45:35 -0800 (PST) Received: by wmec201 with SMTP id c201so15387161wme.1 for ; Tue, 10 Nov 2015 10:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bPHlknhRPlvvPXu6TseylS9PnqiKUAHSdSxQyEjka+A=; b=qI6TxuVRQyN4CmjzuG3oiRpOX6+SknkUy1gYCS3f9GaNkpvC0XVDeKFaC13bcp3dgA Oh6JjaLAV0nGMadhwCrvsrSi7Z1yAm9zif+004rHh8PZ2CaiYMuHD8z/llrKS6h3FqJc AN3cZRYVI/OqAw1v2lRNifjqIr/DUVrY8PxH6dVBtq2tYNYYCB9VgAAoSp1lr9Wv1ATE XjnkWG3t+ypbzdaS5OjHTBTr0RH7qMFiiY8lrfu95uI+/1Krfbw2eYdTWiQWlcHkOYOb AhxSMvochCI5bu8pq62PltjgI4zOKr3B8vNduoN1oW4RMVPNraM5aPh59CsebG6zUuh5 Yh9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bPHlknhRPlvvPXu6TseylS9PnqiKUAHSdSxQyEjka+A=; b=l0XYVX9rBKxgADT0mZyyRzjfCAvl879a1ALLf48voe4Y9eaIDB0gSAF6WyHye2psy5 tfOq46TqcfgFzR2yZBEn9ZWo8JWQoRE8zBt+9PpHRjCuCrOU8sA8YhR6fwVRnn4JWo9b C6nH65+4qJRWxVsndxru97wfd+FTfXUYQDGhJ1B3446r+lb8cJCXq8jMVw5NLigkhK1N cMcsWiEioWtzw5VogCN5MAHfmlUwsuv8fwf6YX7+6QVTonHMvzdLgR+9AnNFrBs1fAi6 WMrD698c0oLU5sfiN2JJaqMe1iV1LQb8r5ZIZIx5tHYHmt6y6ePvoPUv/hNjoSLBMd33 IMUQ== X-Gm-Message-State: ALoCoQlL9KP3ovagDX5KKCUpKrcT8y3/cdp+5hbUEeAld9RYOPtkgoS4JJ6ijbY8sHf1ByXXbORK MIME-Version: 1.0 X-Received: by 10.28.143.144 with SMTP id r138mr6899429wmd.100.1447181134088; Tue, 10 Nov 2015 10:45:34 -0800 (PST) Received: by 10.194.91.134 with HTTP; Tue, 10 Nov 2015 10:45:34 -0800 (PST) X-Originating-IP: [2001:500:4:15:84df:8a21:c9ca:e159] In-Reply-To: <56422EE7.5040007@iit.cnr.it> References: <564167D3.7050805@dcrocker.net> <56422EE7.5040007@iit.cnr.it> Date: Tue, 10 Nov 2015 13:45:34 -0500 Message-ID: From: Andrew Newton To: Mario Loffredo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: eppext , Dave Crocker , "weirds@ietf.org" Subject: Re: [weirds] [eppext] RDAP adoption? 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, 10 Nov 2015 18:45:36 -0000 On Tue, Nov 10, 2015 at 12:52 PM, Mario Loffredo wrote: > At the moment, the only way to represent this statuses according to the > RDAP profile is to add an unrecognized member together with a status > reported in RFC7483 Actually, there is an IANA registry for status values. Inventing new JSON members for that need is not the right way to do it. > > - Registrar role publicIDs member > The RDAP profile states that the entity with the registrar role MUST > contain a publicIDs member to identify IANA Registrar ID from the IANA's > Registrar ID registry. > In .it, we have a lot of medium/small registrars registering only .it > domains so none of them appear in the IANA Registrar ID registry. > Furthermore, there are some domains managed by the registry itself (nic.it > for example) or by italian public entities registrars (government, regions, > and so on) > publicId is not a required field. And it can be used for more than just ICANN identifiers. -andy From nobody Tue Nov 10 10:47:49 2015 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 6623C1B3CB6 for ; Tue, 10 Nov 2015 10:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] 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 aAiipsg08CS5 for ; Tue, 10 Nov 2015 10:47:43 -0800 (PST) Received: from mail-oi0-x261.google.com (mail-oi0-x261.google.com [IPv6:2607:f8b0:4003:c06::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142441B3CA4 for ; Tue, 10 Nov 2015 10:47:43 -0800 (PST) Received: by oie188 with SMTP id 188so380726oie.0 for ; Tue, 10 Nov 2015 10:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign_com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=/fdFlAOfj/oELLOggOATEiqAy1TZ7Cr5uirr1jZTRq0=; b=K8vL7pkuxJ6J2WWMp63SH7alOzdXjfZA8FGbKzGLNu2IIJaZzgLQdtILHT14Cj0x+s ynRVxziJXDuAIqFUmDheJLWkDEgnE/8EDE58ph9BZqepW1qBflj3tU/FbK7FC610g2Rh M1QasTtZJ8maXeYAAgxQr2/LzaqsGWxHVShQhejOJK7T1n7Sljqu4qEc1KTOQGiX2xiP 5x0gsAUChsNuZ6v7+EPt+AH0R4JdNTzQY5wPZx77B9GmUw2Rae+DfvEbEJNnig3MbXVu nuymj0Ra58u7iEBscDN87Ye7i18LafvH5MeSacdFbTFtgjQy6bFIBFDVeeI7rw+3sGPZ dmQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=/fdFlAOfj/oELLOggOATEiqAy1TZ7Cr5uirr1jZTRq0=; b=gfg7oIsKL4DGxTHrsTDtqPSTnqW3YMbO+bEFxAOhFgvWj/5rAFAylvTzyg0AJ93NQb TA7isx1wA87uDr/l61j3OLfSGxtusT630wVUfiT8aSex9mjO17/HjwrTS1o4yJVxX/YM IPxUPfogp3nR2fjef0iOiG2FuFtpJKyToR9WIBfOOhI1Zl/ix5T48GZQi1ASCnZfp+fe 5P74gUjMsxo4I/VtbliniV6UpqTFK0uKGIasNun94Zw5q7c9zCgDfJghTQ0F42n5zqRk N+Cnq2/Mc13FkfIHkxu9p+HhaBJHIOUnnqLjpC18E6/tVdI3GKEgnmGJ62uHyPf41smF ti0w== X-Gm-Message-State: ALoCoQnDuPbuA2m561tBxzgW4xDYEgNJmW5H4rzLzmKAT46OZTHX5G3BQaVJp1EbRLZhDXRxy3xzcnddPWQcRp0Dc8Mlsgvpag== X-Received: by 10.140.102.35 with SMTP id v32mr6440430qge.72.1447181262303; Tue, 10 Nov 2015 10:47:42 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id e7sm427341qkj.7.2015.11.10.10.47.42 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 10 Nov 2015 10:47:42 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id tAAIlfoB030084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Nov 2015 13:47:41 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 10 Nov 2015 13:47:41 -0500 From: "Hollenbeck, Scott" To: Gustavo Lozano , "eppext@ietf.org" Thread-Topic: Adding missing RDAP event action types for gTLDs Thread-Index: AQHRG+W3Qkw2SFOjD0GXFX7C2VCvSZ6VmD0g Date: Tue, 10 Nov 2015 18:47:41 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A0DF7DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: 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: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F4A0DF7DDBRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: Cc: "weirds@ietf.org" Subject: Re: [weirds] Adding missing RDAP event action types for gTLDs 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, 10 Nov 2015 18:47:45 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F4A0DF7DDBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Gustavo Lozano Sent: Tuesday, November 10, 2015 1:29 PM To: eppext@ietf.org Cc: weirds@ietf.org Subject: [weirds] Adding missing RDAP event action types for gTLDs Hello colleagues, As you may know, two of the open issues in the RDAP profile for gTLDs (http= ://mm.icann.org/pipermail/gtld-tech/attachments/20150928/35901409/gTLDRDAPO= perationalProfile-v06-0001.pdf) are missing event action types in the base = RDAP specification for: * Last update time of the RDAP database * Registrar registration expiration date You may find the details in the following I-D: https://www.ietf.org/id/draf= t-lozano-rdap-gtld-whois-additional-events-00.txt It's important to promptly add these two event action types based on the ti= meline for deployment of RDAP in the gTLDs. [snip] If a recall what I heard in Dublin and Yokohama, the timeline is *proposed*= and subject to a community review process that is supposed to start later = this month - correct? Scott --_000_831693C2CDA2E849A7D7A712B24E257F4A0DF7DDBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: weirds [= mailto:weirds-bounces@ietf.org] On Behalf Of Gustavo Lozano
Sent: Tuesday, November 10, 2015 1:29 PM
To: eppext@ietf.org
Cc: weirds@ietf.org
Subject: [weirds] Adding missing RDAP event action types for gTLDs

 

Hello colleagues,

 

As you may know, two of the= open issues in the RDAP profile for gTLDs (http://mm.icann.org/pipermail/gtld-tech/attachments/2015092= 8/35901409/gTLDRDAPOperationalProfile-v06-0001.pdf) are missing event action types in the base RDAP specification for:

* Last update time of the R= DAP database

* Registrar registration ex= piration date

 

 

It's important to promptly = add these two event action types based on the timeline for deployment of RD= AP in the gTLDs.

 

[snip]<= /p>

 

If a recall what I heard in Dublin and Yok= ohama, the timeline is *proposed* and subject to a community review = process that is supposed to start later this month – correct?

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F4A0DF7DDBRN1WNEXMBX01vc_-- From nobody Tue Nov 10 13:20:12 2015 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 647C41A8F4D; Tue, 10 Nov 2015 13:20:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 eW_CS4KdoAbI; Tue, 10 Nov 2015 13:19:58 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318FD1A8F49; Tue, 10 Nov 2015 13:19:58 -0800 (PST) Received: from BY2PR0201MB0773.namprd02.prod.outlook.com (10.160.125.139) by BY2PR0201MB0775.namprd02.prod.outlook.com (10.160.125.140) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 21:19:51 +0000 Received: from BY2PR0201MB0773.namprd02.prod.outlook.com ([10.160.125.139]) by BY2PR0201MB0773.namprd02.prod.outlook.com ([10.160.125.139]) with mapi id 15.01.0318.003; Tue, 10 Nov 2015 21:19:51 +0000 From: Roger D Carney To: "eppext@ietf.org" , "weirds@ietf.org" Thread-Topic: Adding missing RDAP event action types for gTLDs Thread-Index: AQHRG+W3Qkw2SFOjD0GXFX7C2VCvSZ6VmD0ggAAbquA= Date: Tue, 10 Nov 2015 21:19:50 +0000 Message-ID: References: <831693C2CDA2E849A7D7A712B24E257F4A0DF7DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A0DF7DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcarney@godaddy.com; x-originating-ip: [64.202.161.57] x-microsoft-exchange-diagnostics: 1; BY2PR0201MB0775; 5:PVcGj/GId1wa04+HS6NXSfkZSsRqYisBc9ZW4ORKv0TY9pTrrZ8KvL32do9MJBKKpKyivD5YRnuQiIxZ5ExzbxfHzwmxlWEr8+8o6tbRaJS9yt+itFE6IgauvObJkFS9dubSG8b2o1yAknsTa1vROQ==; 24:yJMjLLX5J2e26AmV0z99QQjDRvUPQ5Fi9Sjq8ff7tT/AaTIMK9sKfMqgtwB9wpf8YR552eruGm7esosSckiZ25cpr9gbXg5BiE2m6m5MCUA=; 20:+W3yCpt9sBRTLF33lIgl9QN+4iXNSqqq3jx5NDPX7TvPylr3Ngc5PczTkd69Nl1IUXQwNjs/6UFmpV+/eiGT6A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB0775; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB0775; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB0775; x-forefront-prvs: 07562C22DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(52014003)(377454003)(243025005)(36944003)(199003)(189002)(19617315012)(99286002)(122556002)(40100003)(5003600100002)(189998001)(92566002)(86362001)(105586002)(106116001)(106356001)(19300405004)(5002640100001)(19580405001)(2950100001)(19580395003)(5008740100001)(5890100001)(97736004)(77096005)(101416001)(5001920100001)(87936001)(5007970100001)(5001770100001)(76576001)(11100500001)(450100001)(33656002)(5004730100002)(2501003)(19625215002)(81156007)(66066001)(10400500002)(50986999)(76176999)(107886002)(5001960100002)(74316001)(15975445007)(102836002)(16236675004)(2900100001)(54356999)(17423001)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB0775; H:BY2PR0201MB0773.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: godaddy.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB0773F291D96B422DD1224773B1140BY2PR0201MB0773_" MIME-Version: 1.0 X-OriginatorOrg: godaddy.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2015 21:19:50.7302 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d5f1622b-14a3-45a6-b069-003f8dc4851f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB0775 Archived-At: Subject: Re: [weirds] Adding missing RDAP event action types for gTLDs 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, 10 Nov 2015 21:20:09 -0000 --_000_BY2PR0201MB0773F291D96B422DD1224773B1140BY2PR0201MB0773_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Gustavo. I agree with Scott, from what I recall this is just a proposed timeline. As for this I-D, one comment, one clarification: * Comment: in reading Appendix B of RFC 7483 it states that events = represent actions that have taken place against a registered object at a ce= rtain date and time. I don't see that Last Update of RDAP Database is an ac= tion against a registered object, against the "container" of these register= ed objects but not against a registered object. This may be just a definiti= on issue, I don't recall reading a definition of Last Update of RDAP Databa= se so it could be defined as: the date/time of the last change to a registr= ation object (domain, host, contact) in the RDAP database. Lacking a defini= tion I would have defined Last Update of RDAP Database literally, so any ma= intenance including restoration, reference table updates, etc I would say c= hanges the Last Update of RDAP Database. Again maybe just a definition issu= e. * Clarification: this I-D tries to address the lack of some RDAP da= ta modeling in regards to Registrar Expiration Date but there still is work= needed to address getting this data from registrar to registry, correct? I= am not aware of a way to do this currently or of work to make this happen. Thanks Roger From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Hollenbeck, Scot= t Sent: Tuesday, November 10, 2015 12:48 PM To: Gustavo Lozano; eppext@ietf.org Cc: weirds@ietf.org Subject: Re: [eppext] Adding missing RDAP event action types for gTLDs From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Gustavo Lozano Sent: Tuesday, November 10, 2015 1:29 PM To: eppext@ietf.org Cc: weirds@ietf.org Subject: [weirds] Adding missing RDAP event action types for gTLDs Hello colleagues, As you may know, two of the open issues in the RDAP profile for gTLDs (http= ://mm.icann.org/pipermail/gtld-tech/attachments/20150928/35901409/gTLDRDAPO= perationalProfile-v06-0001.pdf) are missing event action types in the base = RDAP specification for: * Last update time of the RDAP database * Registrar registration expiration date You may find the details in the following I-D: https://www.ietf.org/id/draf= t-lozano-rdap-gtld-whois-additional-events-00.txt It's important to promptly add these two event action types based on the ti= meline for deployment of RDAP in the gTLDs. [snip] If a recall what I heard in Dublin and Yokohama, the timeline is *proposed*= and subject to a community review process that is supposed to start later = this month - correct? Scott --_000_BY2PR0201MB0773F291D96B422DD1224773B1140BY2PR0201MB0773_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Gustavo.

 

I agree with Scott, fr= om what I recall this is just a proposed timeline.

 

As for this I-D, one c= omment, one clarification:

·       =   Comment: in re= ading Appendix B of RFC 7483 it states that events represent actions that h= ave taken place against a registered object at a certain date and time. I don’t see that Last Update of RDAP Dat= abase is an action against a registered object, against the “containe= r” of these registered objects but not against a registered object. T= his may be just a definition issue, I don’t recall reading a definition of Last Update of RDAP Database so it could be define= d as: the date/time of the last change to a registration object (domain, ho= st, contact) in the RDAP database. Lacking a definition I would have define= d Last Update of RDAP Database literally, so any maintenance including restoration, reference table updates, etc I would say changes the Last Update of RDAP Database. Again mayb= e just a definition issue.

·       =   Clarification:= this I-D tries to address the lack of some RDAP data modeling in regards t= o Registrar Expiration Date but there still is work needed to address getting this data from registrar to registry, co= rrect? I am not aware of a way to do this currently or of work to make this= happen.

 

 

Thanks

Roger

 

 

From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Hollenbeck, Sc= ott
Sent: Tuesday, November 10, 2015 12:48 PM
To: Gustavo Lozano; eppext@ietf.org
Cc: weirds@ietf.org
Subject: Re: [eppext] Adding missing RDAP event action types for gTL= Ds

 

From: weirds [ma= ilto:weirds-bounces@ietf.org] On Behalf Of Gustavo Lozano
Sent: Tuesday, November 10, 2015 1:29 PM
To: eppext@ietf.org
Cc: weirds@ietf.org
Subject: [weirds] Adding missing RDAP event action types for gTLDs

 

Hello colleagues,

 

As you may know, two of the= open issues in the RDAP profile for gTLDs (http://mm.icann.org/pipermail/gtld-tech/attachments/2015092= 8/35901409/gTLDRDAPOperationalProfile-v06-0001.pdf) are missing event action types in the base RDAP specification for:

* Last update time of the R= DAP database

* Registrar registration ex= piration date

 

 

It's important to promptly = add these two event action types based on the timeline for deployment of RD= AP in the gTLDs.

 

[snip]<= /p>

 

If a recall what I heard in Dublin and Yok= ohama, the timeline is *proposed* and subject to a community review = process that is supposed to start later this month – correct?

 

Scott

--_000_BY2PR0201MB0773F291D96B422DD1224773B1140BY2PR0201MB0773_-- From nobody Wed Nov 11 07:00:58 2015 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 2D1F51AD074 for ; Wed, 11 Nov 2015 07:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 WVo9XpiPxh62 for ; Wed, 11 Nov 2015 07:00:46 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310691AD062 for ; Wed, 11 Nov 2015 07:00:46 -0800 (PST) Received: by wmdw130 with SMTP id w130so116259019wmd.0 for ; Wed, 11 Nov 2015 07:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+HMxFKYbhHXEXmKD0ylKaa/MSwNcoABqrfp2OBQ102Y=; b=u7rqjq6OoY0b1wzvyHhRFuWb0r4lXB98bs63Ibc9Spcyjh920w13UMDPYJYHS9/qLZ x2xJQ/gh1b07g4RCgGC7uSKTr8nxuxRdSWUdT2nmpyHecAvn+Sf+YvXkl8TkZNxi9lGX BHF/r952cAkl5nKnLPC/YdIYMKW/JVq5i45Fl8lWT1qKv2wvYcnKTdiGBrOgpuvva5qk QOIopOqOKKDk5vGHDSK1u2ydwKEAkcL7mnpqAzrqYKyqjNSwm3J/FsuLaOCyJzPyqkfy CJIrZs4cKdueqBKyWohzNy/4gukmOuWul2X4eERxX8Sd1cXjIyZmc2dyfIxENerVcrJv OPFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+HMxFKYbhHXEXmKD0ylKaa/MSwNcoABqrfp2OBQ102Y=; b=DbfrwiirFndhRMCxm86xEi89G93IVBB3VyoPB7RvpxU534o7ge3DqSYjtvbylxpdoI 2GokWSvfkCN7I3YKnikQPpvvlzsoGMZus6CmMaSBMPVSeh9h9WTq2HWw1eRb5hbcsVyB yKvWKKpBGtZhZvKHGXr1Wn/fkcBrQvP305XZd/qY4A8kjXQaFI1vWYOCCY36lMWoNwER OoGAgbfOs0vkLvtkDYInmbz4iRLZ/Q4sD//qyIsABklMVPn+e5gzv3MOG1aSlGlkXhip JSHAYM6YTkmDfOTqzdFrIe8ROO6alq3KyaMm3xKztlGvHaMC3b4YuOWMjMltN9M1xZNT US4A== X-Gm-Message-State: ALoCoQn5EWnVSkMN6VhL7dJae7/86Obp0tL3IADzCWkxxLpMSPj6gltf8etoWc4pxiJKhMNXDHh+ MIME-Version: 1.0 X-Received: by 10.28.130.12 with SMTP id e12mr40790769wmd.76.1447254044243; Wed, 11 Nov 2015 07:00:44 -0800 (PST) Received: by 10.194.91.134 with HTTP; Wed, 11 Nov 2015 07:00:44 -0800 (PST) X-Originating-IP: [192.149.252.137] In-Reply-To: References: Date: Wed, 11 Nov 2015 10:00:44 -0500 Message-ID: From: Andrew Newton To: Gustavo Lozano Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "eppext@ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Adding missing RDAP event action types for gTLDs 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, 11 Nov 2015 15:00:52 -0000 Hi Gustavo, I've looked at your proposed new events, and it makes sense to me. -andy On Tue, Nov 10, 2015 at 1:29 PM, Gustavo Lozano wrote: > Hello colleagues, > > As you may know, two of the open issues in the RDAP profile for gTLDs > (http://mm.icann.org/pipermail/gtld-tech/attachments/20150928/35901409/gTLDRDAPOperationalProfile-v06-0001.pdf) > are missing event action types in the base RDAP specification for: > * Last update time of the RDAP database > * Registrar registration expiration date > > You may find the details in the following I-D: > https://www.ietf.org/id/draft-lozano-rdap-gtld-whois-additional-events-00.txt > > It's important to promptly add these two event action types based on the > timeline for deployment of RDAP in the gTLDs. > > As this appears to be a minor update, I am planning (in the last week of > November) on sending a request to IANA, in order to add these two action > event types to the RDAP JSON Values Registry following the Expert Review > Registration Procedure. I would like to get feedback from the list regarding > this proposal. > > If you agree with the proposal, it would be great if you can reply to the > list in order to show the expert reviewer that there is consensus on the > list. > > Regards, > Gustavo > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From nobody Wed Nov 11 11:48:59 2015 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 E571D1B3941; Wed, 11 Nov 2015 11:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 clnHsSZsdCSh; Wed, 11 Nov 2015 11:48:57 -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 476511B393E; Wed, 11 Nov 2015 11:48:57 -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.1044.25; Wed, 11 Nov 2015 11:48:55 -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.1044.021; Wed, 11 Nov 2015 11:48:55 -0800 From: Francisco Arias To: "Hollenbeck, Scott" , "eppext@ietf.org" Thread-Topic: [eppext] Adding missing RDAP event action types for gTLDs Thread-Index: AQHRHLn/NXOVVXMhD0yCYYw2T2HAfA== Date: Wed, 11 Nov 2015 19:48:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.35.1] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "weirds@ietf.org" Subject: Re: [weirds] [eppext] Adding missing RDAP event action types for gTLDs 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, 11 Nov 2015 19:48:59 -0000 T24gMTEvMTAvMTUsIDEwOjQ3IEFNLCAiRXBwRXh0IG9uIGJlaGFsZiBvZiBIb2xsZW5iZWNrLCBT Y290dCINCjxlcHBleHQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc2hvbGxlbmJlY2tA dmVyaXNpZ24uY29tPiB3cm90ZToNCg0KPklmIGEgcmVjYWxsIHdoYXQgSSBoZWFyZCBpbiBEdWJs aW4gYW5kIFlva29oYW1hLCB0aGUgdGltZWxpbmUgaXMNCj4qcHJvcG9zZWQqIGFuZCBzdWJqZWN0 IHRvIGEgY29tbXVuaXR5IHJldmlldyBwcm9jZXNzIHRoYXQgaXMgc3VwcG9zZWQgdG8NCj5zdGFy dCBsYXRlciB0aGlzIG1vbnRoIOKAkyBjb3JyZWN0Pw0KPiANCj5TY290dA0KDQpIaSBTY290dCwN Cg0KVGhlIHRpbWVsaW5lIHByZXNlbnRlZCBpbiBEdWJsaW4gYW5kIFlva29oYW1hIGlzIGluZGVl ZCB0ZW50YXRpdmUgYW5kDQpzdWJqZWN0IHRvIGhvdyB0aGUgZGlzY3Vzc2lvbiBnb2VzIGluIHJl Z2FyZHMgdG8gdGhlIGdUTEQgUkRBUCBwcm9maWxlLg0KV2hhdCBpcyBpbnRlbmRlZCB0byBnbyBm b3IgcHVibGljIGNvbW1lbnRzIGF0IHRoZSBlbmQgb2YgTm92ZW1iZXIgaXMgdGhlDQpkcmFmdCBw cm9maWxlLg0KDQpSZWdhcmRzLA0KDQotLSANCkZyYW5jaXNjby4NCg0KDQoNCg0K From nobody Wed Nov 11 23:07:55 2015 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 DCDEF1B3067; Mon, 9 Nov 2015 19:43:21 -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, RCVD_IN_DNSWL_MED=-2.3] 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 SIHsK8I7uMQx; Mon, 9 Nov 2015 19:43:21 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD3F1B3066; Mon, 9 Nov 2015 19:43:20 -0800 (PST) Received: from [192.168.11.114] (104-60-96-29.lightspeed.sntcca.sbcglobal.net [104.60.96.29]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id tAA3hIoH018531 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 9 Nov 2015 19:43:19 -0800 From: Dave Crocker To: weirds@ietf.org, eppext@ietf.org X-Enigmail-Draft-Status: N1110 Organization: Brandenburg InternetWorking Message-ID: <564167D3.7050805@dcrocker.net> Date: Mon, 9 Nov 2015 19:43:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 09 Nov 2015 19:43:19 -0800 (PST) Archived-At: X-Mailman-Approved-At: Wed, 11 Nov 2015 23:07:53 -0800 Subject: [weirds] RDAP adoption? X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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, 10 Nov 2015 03:43:22 -0000 (Andy Newton asked me to post this question to these lists...) Hi. I'm trying to discover the current field maturity of RDAP. * How much operational deployment of servers supporting it is there? * How much client deployment in software? * But ultimately how much client/server use of the protocol is there, so far? * Any sense of the adoption/use trends? * Any sense of what is delaying more and better adoption/use? * Any sense of what might improve things? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 11 23:07:56 2015 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 63ED51B38DE; Tue, 10 Nov 2015 07:23:34 -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, RCVD_IN_DNSWL_MED=-2.3] 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 F_1vCDI0K1pX; Tue, 10 Nov 2015 07:23:33 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E376C1B38E9; Tue, 10 Nov 2015 07:23:14 -0800 (PST) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id tAAFNDoU012964 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 10 Nov 2015 07:23:13 -0800 To: Andrew Newton References: <564167D3.7050805@dcrocker.net> From: Dave Crocker X-Enigmail-Draft-Status: N1110 Organization: Brandenburg InternetWorking Message-ID: <56420BDB.6050802@dcrocker.net> Date: Tue, 10 Nov 2015 07:23:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 10 Nov 2015 07:23:14 -0800 (PST) Archived-At: X-Mailman-Approved-At: Wed, 11 Nov 2015 23:07:54 -0800 Cc: "weirds@ietf.org" , eppext Subject: Re: [weirds] RDAP adoption? X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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, 10 Nov 2015 15:23:34 -0000 Andey, et al, Many thanks for the responses. I think what I read summarizes as: There is an active community effort to promote, deploy and use RDAP. It has made good, initial progress and does appear to be on a healthy vector towards widespread use. Adoption by providers is excellent. Adoption in clients is still in the very early stages. There is actual traffic, but it is still quite modest. Does the above give anyone heartburn? inline... On 11/10/2015 6:07 AM, Andrew Newton wrote: > I ran some stats on the ARIN service back in early September (we > deployed in late June, so around 70 days after deployment), and here > is what I had: ... > So that is in the noise when compared to port 43 or even ARIN's > proprietary restful service, but it's also new. It might help folks get a sense of on-going progress to regularly show the changes in traffic, both in terms of the client/server mix and the overall traffic, compared against :43. That is, how widespread is the use and how much use is there? We have quite a bit of unfortunate history with good efforts at producing specs that lacked sustained community effort at adoption. This one sounds much better than those unfortunate cases, but as DNSSec demonstrated it is too easy to lose momentum. You might want to have an explicit -- if informal -- community effort organized at adoption and use. Again, thanks for the followup. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 11 23:08:14 2015 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 524251B3BD5; Tue, 10 Nov 2015 09:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 A2LYqFTv7bBY; Tue, 10 Nov 2015 09:52:56 -0800 (PST) Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DEE1B3BD6; Tue, 10 Nov 2015 09:52:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 1E143B80D20; Tue, 10 Nov 2015 18:52:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEtC8GvnJ7Yy; Tue, 10 Nov 2015 18:52:41 +0100 (CET) Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 14FAEB80BFB; Tue, 10 Nov 2015 18:52:41 +0100 (CET) To: dcrocker@bbiw.net, weirds@ietf.org, eppext@ietf.org References: <564167D3.7050805@dcrocker.net> From: Mario Loffredo Message-ID: <56422EE7.5040007@iit.cnr.it> Date: Tue, 10 Nov 2015 18:52:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564167D3.7050805@dcrocker.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Wed, 11 Nov 2015 23:08:12 -0800 Subject: Re: [weirds] [eppext] RDAP adoption? 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, 10 Nov 2015 17:52:59 -0000 Il 10/11/2015 04:43, Dave Crocker ha scritto: > (Andy Newton asked me to post this question to these lists...) > > > Hi. > > I'm trying to discover the current field maturity of RDAP. > > * How much operational deployment of servers supporting it is there? > > * How much client deployment in software? > > * But ultimately how much client/server use of the protocol is > there, so far? > > * Any sense of the adoption/use trends? > > * Any sense of what is delaying more and better adoption/use? > > * Any sense of what might improve things? > > Thanks. > > d/ Dear Dave, I speak on behalf of .it and it seems to me that there are some big problems we have to face in order to implement a RDAP server. The first three things coming in my mind about RDAP responses are the following: - domain status Due to Italian regulation, we have introduced some statuses in addition to EPP standard and RGP extension statuses. At the moment, the only way to represent this statuses according to the RDAP profile is to add an unrecognized member together with a status reported in RFC7483 - Registrar role publicIDs member The RDAP profile states that the entity with the registrar role MUST contain a publicIDs member to identify IANA Registrar ID from the IANA's Registrar ID registry. In .it, we have a lot of medium/small registrars registering only .it domains so none of them appear in the IANA Registrar ID registry. Furthermore, there are some domains managed by the registry itself (nic.it for example) or by italian public entities registrars (government, regions, and so on) - Registrant/admin/tech role required fields According to .it regulation, each contact cannot give the consent to publish the personal data on WHOIS. Street,City and Country are part of the personal data so they might not appear in a RDAP response Maybe these problems are common to other ccTLDs. In my humble opinion, we need a discussion about the adoption of RDAP from ccTLDs in order to have, at the end, a RDAP profile for ccTLDs . Regards, Mario From nobody Wed Nov 11 23:08:36 2015 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 135A91B2BAF; Tue, 10 Nov 2015 06:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, SPF_FAIL=0.001, SPF_HELO_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 lUBYO-pE6snB; Tue, 10 Nov 2015 06:35:22 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9F31B2BAC; Tue, 10 Nov 2015 06:35:21 -0800 (PST) Received: from clone.registro.br (localhost [127.0.0.1]) by clone.registro.br (Postfix) with ESMTP id 00FDA24C167; Tue, 10 Nov 2015 12:35:20 -0200 (BRST) X-Virus-Scanned: amavisd-new at registro.br Received: from clone.registro.br ([127.0.0.1]) by clone.registro.br (clone.registro.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzXnQ8OP2JOW; Tue, 10 Nov 2015 12:35:18 -0200 (BRST) Received: from rubens.in.registro.br (unknown [IPv6:2001:12ff:0:3a::195]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clone.registro.br (Postfix) with ESMTPS id 14A7B24C070; Tue, 10 Nov 2015 12:35:18 -0200 (BRST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Rubens Kuhl In-Reply-To: <115DBEF8-0DC9-49C6-ABAD-4BABDC1C0EEC@sidn.nl> Date: Tue, 10 Nov 2015 12:35:17 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <564167D3.7050805@dcrocker.net> <115DBEF8-0DC9-49C6-ABAD-4BABDC1C0EEC@sidn.nl> To: Rik Ribbers X-Mailer: Apple Mail (2.3096.5) Archived-At: X-Mailman-Approved-At: Wed, 11 Nov 2015 23:08:32 -0800 Cc: "weirds@ietf.org" , eppext , Dave Crocker Subject: Re: [weirds] [eppext] RDAP adoption? 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, 10 Nov 2015 14:35:23 -0000 > Em 10 de nov de 2015, =C3=A0(s) 12:30:000, Rik Ribbers = escreveu: >=20 > I also recall from the REGOPS workshop the Brazilians (.br) have an = server side implementation in production and there is a RDAP library for = servers in JAVA available from DNS Belgium (.be). https://rdap.beta.registro.br/domain/nic.br https://rdap.beta.registro.br/domain/foo.eng.br https://rdap.beta.registro.br/ip/200.160.0.1 https://rdap.beta.registro.br/ip/2001:12ff::/32 https://rdap.beta.registro.br/autnum/22548 https://rdap.beta.registro.br/entity/h_05506560000136-NICBR Rubens From nobody Wed Nov 11 23:09:01 2015 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 713481B3BFE; Tue, 10 Nov 2015 10:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.838 X-Spam-Level: X-Spam-Status: No, score=0.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 x7dt7k8SA5Ol; Tue, 10 Nov 2015 10:01:50 -0800 (PST) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09E01B3C02; Tue, 10 Nov 2015 10:01:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 0C5D4149EC9; Tue, 10 Nov 2015 16:01:48 -0200 (BRST) X-Virus-Scanned: Debian amavisd-new at mail.nic.br Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euL_hGwHh7f2; Tue, 10 Nov 2015 16:01:41 -0200 (BRST) Received: from rubens.in.registro.br (unknown [IPv6:2001:12ff:0:3a::195]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id B7CB1149EFF; Tue, 10 Nov 2015 16:01:35 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1447178495; bh=s1uVLN/1WSU+/UyerzEj3/JvGa9zCzFl8A0NXfVf2+g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=fdHOnO1JoDo9qLVlh4E9E0pZHJR/PZgaIgo2RvWMMORlJlWlcg5RP+G44uG5phAtI /hlP5YMvzHzowYcpX4AgpNKYCxLpVZYO3Gk2BCmy1c+YjVXCN8HYopn7AkOSaoQ/qp vrXuigo0HfJKcQuHLYLB8wsVhZ3rtFPUMOnSwWeQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Rubens Kuhl In-Reply-To: <56422EE7.5040007@iit.cnr.it> Date: Tue, 10 Nov 2015 16:01:35 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62A1F9F1-08B9-45E2-8443-5748EFF3FF07@nic.br> References: <564167D3.7050805@dcrocker.net> <56422EE7.5040007@iit.cnr.it> To: Mario Loffredo X-Mailer: Apple Mail (2.3096.5) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br B7CB1149EFF Archived-At: X-Mailman-Approved-At: Wed, 11 Nov 2015 23:08:57 -0800 Cc: eppext@ietf.org, dcrocker@bbiw.net, weirds@ietf.org Subject: Re: [weirds] [eppext] RDAP adoption? 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, 10 Nov 2015 18:01:51 -0000 >=20 > I speak on behalf of .it and it seems to me that there are some big = problems we have to face in order to implement a RDAP server. > The first three things coming in my mind about RDAP responses are the = following: >=20 > - domain status > Due to Italian regulation, we have introduced some statuses in = addition to EPP standard and RGP extension statuses. > At the moment, the only way to represent this statuses according to = the RDAP profile is to add an unrecognized member together with a status = reported in RFC7483 It seems gTLDs are facing the same issue, and the same seems to be the = same: an I-D defining those values.=20 >=20 > - Registrar role publicIDs member > The RDAP profile states that the entity with the registrar role MUST = contain a publicIDs member to identify IANA Registrar ID from the IANA's = Registrar ID registry. > In .it, we have a lot of medium/small registrars registering only .it = domains so none of them appear in the IANA Registrar ID registry. > Furthermore, there are some domains managed by the registry itself = (nic.it for example) or by italian public entities registrars = (government, regions, and so on) The gTLD RDAP Profile only applies to gTLDs. ccTLDs don't have follow = any of ICANN's specs in this regard; is there any IETF document = precluding .it from using some kind of internal ID ?=20 > - Registrant/admin/tech role required fields > According to .it regulation, each contact cannot give the consent to = publish the personal data on WHOIS. > Street,City and Country are part of the personal data so they might = not appear in a RDAP response >=20 Empty data might seem to solve it as well, but I wonder whether this = requirement also came from gTLD profile or from a technical standard ?=20= > Maybe these problems are common to other ccTLDs. > In my humble opinion, we need a discussion about the adoption of RDAP = from ccTLDs in order to have, at the end, a RDAP profile for ccTLDs . ccTLDs are known for liking their independence, so it's really up to you = to make the .it RDAP profile... but there are some commonalities in the = EEE (European Economic Area) that might suggest an European ccTLD RDAP = profile that could include VAT, Privacy Laws etc. Perhaps CENTR could be = a venue to that development ?=20 Rubens