From nobody Mon Jan 4 18:32:34 2016 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 C05641ACEA1; Mon, 4 Jan 2016 18:32:31 -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 U9NnwAi4z_HQ; Mon, 4 Jan 2016 18:32:30 -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 8F3B11ACEA0; Mon, 4 Jan 2016 18:32:30 -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, 4 Jan 2016 18:32:28 -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, 4 Jan 2016 18:32:28 -0800 From: Gustavo Lozano To: "gtld-tech@icann.org" Thread-Topic: gTLD RDAP profile - Issue 3 - draft-lozano-rdap-nameservers-sharing-name-00 Thread-Index: AQHRR2FRhyUsRVUIEkaJ7G7ZsqZAbQ== Date: Tue, 5 Jan 2016 02:32:28 +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.9.151119 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.35.1] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3534777137_3229901" MIME-Version: 1.0 Archived-At: Cc: eppext , weirds Subject: [weirds] gTLD RDAP profile - Issue 3 - draft-lozano-rdap-nameservers-sharing-name-00 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, 05 Jan 2016 02:32:31 -0000 --B_3534777137_3229901 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello Colleagues, =20 As you may know, the draft gTLD RDAP profile is now at public comment at: https://www.icann.org/public-comments/rdap-profile-2015-12-03-en =20 The draft gTLD RDAP profile describes four open issues. I uploaded an I-D (https://www.ietf.org/id/draft-lozano-rdap-nameservers-sharing-name-00.txt) in order to address issue 3 =B3Multiple host objects for the same name server name=B2 (p.16). =20 Your feedback is welcomed and appreciated. Regards, Gustavo --B_3534777137_3229901 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 LTECEAw0zNpo4IuVxflN2OlRGE0wCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSop2/T O7xTxSNsS6ozJTFxykgJUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xNjAxMDUwMjMyMTdaMA0GCSqGSIb3DQEBAQUABIIBAGhaXx3r7/PT9kt/EPXGOMI7 1MPuarymlvapfufRBD8UzwsJA+HYH7428LRr87TfLgF9elZdTZH7EkSpQzQsZcS0lLxeM342 LzqJlqa1sk7x7ooxD5nEA03/ycCh3/gtXuXP5BE9g8fltdw2DxSo4ISp0I1NBG7zqhRAv6a5 L1EmSCTXj2C8ZYO5tlBAQahC6dHvMRmpI3jcQLlInU/pcJapQsu45zCA6BOb3UoWxSfei+bM d5TYaH8aObaMSxZ4dmtq0ZWTQQoQchnHgRStKMw61JS5F3+5BE2Z2BVxYYu8dKMM2RYtzovc Nt+vSCrUpel7OqhN1yCr+q8OqxpLM0w= --B_3534777137_3229901-- From nobody Wed Jan 6 03:59:30 2016 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 C91931ACEEF for ; Wed, 6 Jan 2016 03:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.391 X-Spam-Level: * X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FF_IHOPE_YOU_SINK=2.166, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, URIBL_GREY=0.424] 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 2R4n9i1syjgh for ; Wed, 6 Jan 2016 03:59:24 -0800 (PST) Received: from mail-oi0-x264.google.com (mail-oi0-x264.google.com [IPv6:2607:f8b0:4003:c06::264]) (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 574291A92F4 for ; Wed, 6 Jan 2016 03:59:24 -0800 (PST) Received: by mail-oi0-x264.google.com with SMTP id o124so39615544oia.3 for ; Wed, 06 Jan 2016 03:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=EGgUEdrdA8GDMfOifXI47sYSBFlIvTd4XzaGJkuD48E=; b=gzeyBI8t1CS4ails5sDFaY5TA4Nlg+0n9Aoxsl+pmdBk5In/l4PuB3HZazvzvyG+co ivduufpQlgJ9YH/dumQRjI9KxOZLdmPP4kdFt+6I1TqCZugEb+z/Ov7h5ocX6XEwIq0n FBt8aW3QeQKCvERqEP++VUNU1kILIxIEyfNcgjr1oTn6hcncMT/1BwIMcRL5sVUhWTcf wqm8CzOLA6aPD8P0D+XlLwat/fpUvacPuEcIq5QbTjdrKcMZ9o5xIn8WteyKp7kZPzCh +ty1OTYRtIZl4j/5qCUlRxCCEKbNs4x0GhrEKBfS5r1CJBiF6FvIq8LOkCrc8OFjgAfJ hD8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=EGgUEdrdA8GDMfOifXI47sYSBFlIvTd4XzaGJkuD48E=; b=AUgmmRoMbAaDT3mAZqYsIAxYXoudid+K3wj10JXWUfe2bo5C9cvjEvls4tVmg+iptj jNzorHngpu22RheWepxTWt3Xa4sHohLztV6iCKM5TBRk9w75CkrjsC9crZnuRLn0BZOK EtsZp8cJ4o3FWuce8ov+MKOPMMh8D5eBEIP/FPHK4JnJvgVXz7Cj6QU3VdaVonh9LOee YxFhCrntRofbVzggYXQWtSr011njo7k+2VtQ9DTx/gyHz/vq3UYA+KbGpJw8dMgV1xCH AKkCmkHaR+grzncCrysJq+KlTipuILljNMWk6ETA6disJEi28SVh4+JmS8H/Q+KGmxDB pa6g== X-Gm-Message-State: ALoCoQk5/Zh1Rd4sSjx5r5fBu7tdPl1Uu17XvUdctILzufGoTtEWJ0eXYNx3cU3zfhvwN9GWuprw0nVHUDJu6xZnuqYzP82hFxdKjLEI9ZJdyW82NJmTbVw= X-Received: by 10.140.109.247 with SMTP id l110mr72491555qgf.52.1452081563303; Wed, 06 Jan 2016 03:59:23 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id s22sm5380818qki.12.2016.01.06.03.59.23 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 06 Jan 2016 03:59:23 -0800 (PST) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u06BxM6e028605 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jan 2016 06:59:22 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 6 Jan 2016 06:59:20 -0500 From: "Hollenbeck, Scott" To: "regops@nlnetlabs.nl" , "weirds@ietf.org" Thread-Topic: [gtld-tech] FW: ICANN News Alert -- Call for Volunteers: New GNSO Policy Development Process (PDP) Working Group to Establish a Policy Framework for a Next-Generation gTLD Registration Directory Service to Replace WHOIS (Next-Gen RDS) Thread-Index: AQHRR/fZVReRY+9cOEm6zwG5udSG7p7tbRCAgAD2MyA= Date: Wed, 6 Jan 2016 11:59:19 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A126324@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0.0.C2.29A.1D147FEB96E2A58.0@drone118.ral.icpbounce.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0393_01D1484F.C36334D0" MIME-Version: 1.0 Archived-At: Subject: [weirds] FW: [gtld-tech] FW: ICANN News Alert -- Call for Volunteers: New GNSO Policy Development Process (PDP) Working Group to Establish a Policy Framework for a Next-Generation gTLD Registration Directory Service to Replace WHOIS (Next-Gen RDS) 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, 06 Jan 2016 11:59:29 -0000 ------=_NextPart_000_0393_01D1484F.C36334D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0394_01D1484F.C36334D0" ------=_NextPart_001_0394_01D1484F.C36334D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable FYI for anyone who might be interested. =20 Scott =20 From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] = On Behalf Of Francisco Arias Sent: Tuesday, January 05, 2016 4:18 PM To: gtld-tech@icann.org Subject: [gtld-tech] FW: ICANN News Alert -- Call for Volunteers: New = GNSO Policy Development Process (PDP) Working Group to Establish a = Policy Framework for a Next-Generation gTLD Registration Directory = Service to Replace WHOIS (Next-Gen RDS) =20 Colleagues, =20 The below announcement may be of interest to some of you, particularly, = for those interested in having differentiated access in RDAP/Whois. =20 Regards, =20 --=20 Francisco =20 On 1/5/16, 12:29 PM, "ICANN News Alert" = wrote: =20 ICANN News Alert https://www.icann.org/news/announcement-2016-01-04-en _____ =20 Call for Volunteers: New GNSO Policy Development Process (PDP) Working = Group to Establish a Policy Framework for a Next-Generation gTLD = Registration Directory Service to Replace WHOIS (Next-Gen RDS) 4 January 2016 In Brief The Generic Names Supporting Organization (GNSO) Council seeks = volunteers to serve on a PDP Working Group to establish a policy = framework for a next-generation gTLD Registration Directory Service = (RDS) to replace WHOIS (Next-Gen RDS). The GNSO Council approved the = WG's charter on = 19 November 2015, tasking this PDP to address concerns with WHOIS by = creating a new policy framework capable of balancing diverse interests = to meet today's needs for gTLD registration data. What This Team Will Do The PDP WG will use a 3-phase process defined in the approved charter = [PDF, 628 KB] to (1) establish gTLD registration data requirements to = determine if and why a next-generation RDS is needed, (2) design = policies that detail functions that must be provided by a = next-generation RDS to support those requirements, and (3) provide = guidance for how a next-generation RDS should implement those policies, = coexisting with and eventually replacing WHOIS. This PDP WG will provide the GNSO Council with policy recommendations = regarding the issues identified in the Final Issue Report = [PDF, 1.2 MB] and as defined in the = charter approved by the GNSO Council = [PDF, 628 KB]. Specifically, this PDP WG is tasked with analyzing the = purpose of collecting, maintaining and providing access to gTLD = registration data and considering safeguards for protecting that data, = determining if and why a next-generation RDS is needed to replace WHOIS, = and creating policies and coexistence and implementation guidance to = meet those needs. During the first phase of this PDP, the PDP WG will, at a minimum, = attempt to reach consensus recommendations regarding the questions = detailed in the PDP WG's charter. The PDP WG's output will then be = submitted to the GNSO Council for approval of its recommendations = regarding IF and WHY a next-generation RDS is needed to replace WHOIS = before moving to the next phase. If the WG concludes a new policy = framework is needed, this output should include requirements to be = addressed by that new framework and any next-generation RDS. However, if = the WG concludes the existing WHOIS system can adequately address = requirements, the WG's output should confirm this and identify any = necessary changes to the WHOIS policy framework. After Phase 1, if the GNSO Council confirms that a new policy framework = and next-generation RDS are required, the PDP WG will then proceed to = Phases 2 and 3, recommending a new consensus policy framework to satisfy = requirements for a next-generation RDS established in Phase 1, along = with any necessary coexistence and implementation guidance. Further = detail regarding this 3-phase process and questions to be considered can = be found in the PDP WG's charter. How This Team Will Work ICANN WGs use transparent, open processes. The meetings of this PDP WG = will be recorded, and the recordings will be available to the public. = The mailing list for the PDP WG will be archived publicly. The group = will collaborate using a public workspace for draft materials and all = final work products and milestones will be documented on the WG's wiki = . The PDP WG is expected to = follow the GNSO Working Group Guidelines = [PDF, 350 KB] as well as the GNSO PDP Manual. How to participate There are two ways to volunteer: * Individual Members =E2=80=93 anyone interested can volunteer to join = the PDP WG as a WG member, regardless of whether they are members of the = ICANN community. Members are expected to actively contribute to mailing = list conversations as well as meetings =E2=80=93 it is anticipated that = the PDP WG will at a minimum meet on a weekly basis via teleconference. = Members are expected to provide essential input to the process. Members = will be required to provide a Statement of Interest (SOI = ).=20 * Mailing list observers =E2=80=93 for those who are merely interested = in monitoring the WG's conversations, there is the possibility to sign = up as a mailing list "observer" which offers read-only access to the = mailing list. Mailing list observers will not be permitted to post, will = not receive invitations to the various meetings or calls of the WG and = will not have to complete a Statement of Interest. At any point in time, = a mailing list observer can join the WG as a member simply by informing = the GNSO Secretariat.=20 In addition, there will be opportunities to provide input through public = consultations and public comment processes that the PDP WG is expected = to organize. How to Join If you are interested in joining the WG as an individual participant or = mailing list observer, please fill in the sign up form = or send the Word document = [DOCX, 72 KB] filled in to the GNSO Secretariat = =20 All members and observers will be listed on the PDP WG's wiki page. Next steps In its motion, the GNSO Council directed that this call for volunteers = be circulated as widely as possible in order to ensure broad = representation and participation in the WG. This call will remain open = until the WG convenes for the first time. At this juncture, it is = anticipated that the PDP WG may convene online in late January 2015. = Following that, regular online meetings will be scheduled in accordance = with the PDP WG's work plan, which it is expected to develop as one of = its first tasks. Further information and preparation For those interested in volunteering for this effort, you are strongly = encouraged to review the following materials prior to the first meeting = of the PDP WG: * The Final Issue Report = [PDF, 1.2 MB]=20 * The approved charter = [PDF, 628 KB]=20 * Materials available at the PDP WG's wiki = such as the EWG Final Report = and other relevant information.=20 Background Created in the 1980s, WHOIS began as a service to identify and contact = entities responsible for the operation of a network resource on the = Internet. Over the years, ICANN's requirements for gTLD domain name = registration data collection, access and accuracy have undergone some = important changes. Yet, after nearly 15 years of task forces, review = teams, and studies, comprehensive WHOIS policy reform remains the source = of long-running discussion and debate. In 2012, the ICANN Board launched the Expert Working Group on gTLD = Registration Directory Services (EWG) to help redefine the purpose of = gTLD registration data and consider how to safeguard the data, and to = propose a model for gTLD registration directory services (RDS) to = address accuracy, privacy, and access issues. Upon publication of the EWG's Final Report in June, 2014, an informal = group of GNSO Councilors and ICANN Board Members collaborated to propose = a Process Framework for structuring a GNSO PDP to successfully address = these challenging issues. This Process Framework was adopted by the = Board in 2015, along with a reaffirmation of its 2012 request for a PDP = to be convened to define the purpose of collecting, maintaining and = providing access to gTLD registration data. The Board also asked that = the PDP consider safeguards for protecting data, using the = recommendations in the EWG's Final Report as an input to, and, if = appropriate, as the foundation for a new gTLD policy. In preparation for this PDP, a new Preliminary Issue Report = [PDF, 1.4 MB] was published for public comment = = on 13 July 2015. A Final Issue Report = [PDF, 1.2 MB] was subsequently = published on 7 October 2015, including links to all public comments = received, along with a draft charter for the PDP WG. This draft charter = was approved by the GNSO Council on 19 November 2015 = , enabling the formation of a GNSO working group of community = volunteers to progress this PDP. More information can be found on the GNSO PDP on Next-Generation gTLD = Registration Directory Service (RDS) page = and the WG's = wiki = , including the WG's charter, = inputs already provided by all SG/Cs during the public comment period, = and an extensive library of foundational materials to inform the WG's = deliberations. In addition, the WG will reach out to all SG/Cs for = feedback on any items that they believe should be considered that may = not have been specifically called out in the approved charter. As this will be a complex multi-phase PDP, all those interested in = helping to shape the policy framework for a next-generation gTLD RDS are = encouraged to volunteer for this WG. Only with the help of the entire = community can this WG achieve its goal of formally defining an = appropriate purpose of gTLD registration data and establishing a new = policy framework to enable permissible access to that data with improved = privacy and accuracy. =20 This message was sent to francisco.arias@icann.org from: ICANN News Alert | communications@icann.org | ICANN | 12025 Waterfront = Drive Suite 300 | Los Angeles, CA 90094-2536 Email Marketing by iContact - Try = It Free! = Manage Your Subscription=20 = =20 ------=_NextPart_001_0394_01D1484F.C36334D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable ICANN News Alert

FYI for = anyone who might be interested.

 

Scott

 

From:= = gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On = Behalf Of Francisco Arias
Sent: Tuesday, January 05, 2016 = 4:18 PM
To: gtld-tech@icann.org
Subject: [gtld-tech] = FW: ICANN News Alert -- Call for Volunteers: New GNSO Policy Development = Process (PDP) Working Group to Establish a Policy Framework for a = Next-Generation gTLD Registration Directory Service to Replace WHOIS = (Next-Gen RDS)

 

Colleagues,

 

The below announcement may be of interest to some of you, particularly, = for those interested in having differentiated access in = RDAP/Whois.

 

Regards,

 

-- 

Francisco

=

 

On 1/5/16, 12:29 PM, "ICANN News Alert" <communications@icann.org>= wrote:

 

Call for = Volunteers: New GNSO Policy Development Process (PDP) Working Group to = Establish a Policy Framework for a Next-Generation gTLD Registration = Directory Service to Replace WHOIS (Next-Gen = RDS)

4 January = 2016

In = Brief

The Generic Names = Supporting Organization (GNSO) Council seeks volunteers to serve on a = PDP Working Group to establish a policy framework for a next-generation = gTLD Registration Directory Service (RDS) to replace WHOIS (Next-Gen = RDS). The GNSO Council approved = the WG's charter on 19 November 2015, tasking this PDP to address = concerns with WHOIS by creating a new policy framework capable of = balancing diverse interests to meet today's needs for gTLD registration = data.

What This Team = Will Do

The PDP WG will = use a 3-phase process defined in the approved charter [PDF, 628 KB] to (1) establish gTLD = registration data requirements to determine if and why a next-generation = RDS is needed, (2) design policies that detail functions that must be = provided by a next-generation RDS to support those requirements, and (3) = provide guidance for how a next-generation RDS should implement those = policies, coexisting with and eventually replacing = WHOIS.

This PDP WG will = provide the GNSO Council with policy recommendations regarding the = issues identified in the Final Issue Report [PDF, 1.2 = MB] and as defined in the charter approved by the GNSO Council [PDF, 628 KB]. = Specifically, this PDP WG is tasked with analyzing the purpose of = collecting, maintaining and providing access to gTLD registration data = and considering safeguards for protecting that data, determining if and = why a next-generation RDS is needed to replace WHOIS, and creating = policies and coexistence and implementation guidance to meet those = needs.

During the first = phase of this PDP, the PDP WG will, at a minimum, attempt to reach = consensus recommendations regarding the questions detailed in the PDP = WG's charter. The PDP WG's output will then be submitted to the GNSO = Council for approval of its recommendations regarding IF and WHY a = next-generation RDS is needed to replace WHOIS before moving to the next = phase. If the WG concludes a new policy framework is needed, this output = should include requirements to be addressed by that new framework and = any next-generation RDS. However, if the WG concludes the existing WHOIS = system can adequately address requirements, the WG's output should = confirm this and identify any necessary changes to the WHOIS policy = framework.

After Phase 1, if = the GNSO Council confirms that a new policy framework and = next-generation RDS are required, the PDP WG will then proceed to Phases = 2 and 3, recommending a new consensus policy framework to satisfy = requirements for a next-generation RDS established in Phase 1, along = with any necessary coexistence and implementation guidance. Further = detail regarding this 3-phase process and questions to be considered can = be found in the PDP WG's charter.

How This Team = Will Work

ICANN WGs use = transparent, open processes. The meetings of this PDP WG will be = recorded, and the recordings will be available to the public. The = mailing list for the PDP WG will be archived publicly. The group will = collaborate using a public workspace for draft materials and all final = work products and milestones will be documented on the WG's wiki. The PDP = WG is expected to follow the GNSO Working Group Guidelines [PDF, 350 KB] as well as = the GNSO PDP Manual.

How to = participate

There are two = ways to volunteer:

  • Individual = Members = =E2=80=93 anyone interested can volunteer to join the PDP WG as a WG = member, regardless of whether they are members of the ICANN community. = Members are expected to actively contribute to mailing list = conversations as well as meetings =E2=80=93 it is anticipated that the = PDP WG will at a minimum meet on a weekly basis via teleconference. = Members are expected to provide essential input to the process. Members = will be required to provide a Statement of Interest (SOI). =
  • Mailing list = observers =E2=80=93 for those who are = merely interested in monitoring the WG's conversations, there is the = possibility to sign up as a mailing list "observer" which = offers read-only access to the mailing list. Mailing list observers will = not be permitted to post, will not receive invitations to the various = meetings or calls of the WG and will not have to complete a Statement of = Interest. At any point in time, a mailing list observer can join the WG = as a member simply by informing the GNSO Secretariat. =

In addition, = there will be opportunities to provide input through public = consultations and public comment processes that the PDP WG is expected = to organize.

How to = Join

If you are = interested in joining the WG as an individual participant or mailing = list observer, please fill in the sign up form or send the Word document [DOCX, 72 KB] filled in to the GNSO = Secretariat

All members and = observers will be listed on the PDP WG's wiki = page.

Next = steps=

In its motion, = the GNSO Council directed that this call for volunteers be circulated as = widely as possible in order to ensure broad representation and = participation in the WG. This call will remain open until the WG = convenes for the first time. At this juncture, it is anticipated that = the PDP WG may convene online in late January 2015. Following that, = regular online meetings will be scheduled in accordance with the PDP = WG's work plan, which it is expected to develop as one of its first = tasks.

Further = information and preparation=

For those = interested in volunteering for this effort, you are strongly encouraged = to review the following materials prior to the first meeting of the PDP = WG:

Background

Created in the = 1980s, WHOIS began as a service to identify and contact entities = responsible for the operation of a network resource on the Internet. = Over the years, ICANN's requirements for gTLD domain name registration = data collection, access and accuracy have undergone some important = changes. Yet, after nearly 15 years of task forces, review teams, and = studies, comprehensive WHOIS policy reform remains the source of = long-running discussion and debate.

In 2012, the = ICANN Board launched the Expert Working Group on gTLD Registration = Directory Services (EWG) to help redefine the purpose of gTLD = registration data and consider how to safeguard the data, and to propose = a model for gTLD registration directory services (RDS) to address = accuracy, privacy, and access issues.

Upon publication = of the EWG's Final Report in June, 2014, an informal group of GNSO = Councilors and ICANN Board Members collaborated to propose a Process = Framework for structuring a GNSO PDP to successfully address these = challenging issues. This Process Framework was adopted by the Board in = 2015, along with a reaffirmation of its 2012 request for a PDP to be = convened to define the purpose of collecting, maintaining and providing = access to gTLD registration data. The Board also asked that the PDP = consider safeguards for protecting data, using the recommendations in = the EWG's Final Report as an input to, and, if appropriate, as the = foundation for a new gTLD policy.

In preparation = for this PDP, a new Preliminary Issue Report [PDF, 1.4 MB] was = published for public comment on 13 July 2015. A Final Issue Report [PDF, 1.2 = MB] was subsequently published on 7 October 2015, including links to all = public comments received, along with a draft charter for the PDP WG. = This draft charter was approved by the GNSO Council on 19 November 2015, enabling the formation of a GNSO = working group of community volunteers to progress this = PDP.

More information = can be found on the GNSO PDP = on Next-Generation gTLD Registration Directory Service (RDS) page = and the WG's wiki, = including the WG's charter, inputs already provided by all SG/Cs during = the public comment period, and an extensive library of foundational = materials to inform the WG's deliberations. In addition, the WG will = reach out to all SG/Cs for feedback on any items that they believe = should be considered that may not have been specifically called out in = the approved charter.

As this will be a = complex multi-phase PDP, all those interested in helping to shape the = policy framework for a next-generation gTLD RDS are encouraged to = volunteer for this WG. Only with the help of the entire community can = this WG achieve its goal of formally defining an appropriate purpose of = gTLD registration data and establishing a new policy framework to enable = permissible access to that data with improved privacy and = accuracy.

 <= /span>

= This message was sent to francisco.arias@icann.org = from:

= ICANN News Alert | communications@icann.org | = ICANN | 12025 Waterfront Drive Suite 300 | Los Angeles, CA = 90094-2536

= Email Marketing by 3D"iContact

------=_NextPart_001_0394_01D1484F.C36334D0-- ------=_NextPart_000_0393_01D1484F.C36334D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR3zCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdaMIIGQqADAgECAhAVQzwThfXRvG1UcOgkHvdMMA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE1MDEyMDAwMDAwMFoXDTE2MDIxOTIzNTk1 OVowdjEnMCUGCSqGSIb3DQEJARYYc2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tMRowGAYDVQQDDBFI b2xsZW5iZWNrLCBTY290dDEWMBQGA1UECwwNRU5URVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNp Z24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0J7Aqo9kRNpOswBRo+1Zz bOQPmzYjyoXWefTs/Jj2oewbiAGHnX8a8IODZN0F+wK7nSlA6ym/mVbdwJtZxvtfqHjBg3uzp8l6 Wd6Kw7AwH/EvB6nLGb07YXmBCYSQ8yc0o3ijm3lWBilDMDsNdOL2F1shADEQjBQZMmoqp8LAaK0J 8Rmg6zri5xMohYNp1lb1tOkmwXEguGKpsxTqHmdyAqpVRcHbvo5XaeeIXVVuMnsdw8iGXtJBmNcV JPrK3biHNYhO+MaC0ZS27CKAkO8HKDxZEP5OUennAV8/gkZ71VfvblVFszTSZEzC8ZqmssnrhehJ e1EmLeto2OEMsIUpAgMBAAGjggOOMIIDijAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAW BgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4EFgQUVoVKaC1xEPB9EWKq3dWrwskIufkwIwYD VR0RBBwwGoEYc2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tMB8GA1UdIwQYMBaAFNhIKahfKheS4vqe e+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcwAYYbaHR0cDovL3BraS1v Y3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2RpcmVjdG9yeS52ZXJpc2ln bi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNoYXJlZCUyMEludGVybWVk aWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0QlMjBDbGFzcyUyMDIlMjBN YW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBDQSUyQ09VJTIwJTNEJTIw U3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3ltYW50ZWMlMjBDb3Jwb3Jh dGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBdBgNVHR8EVjBUMFKgUKBO hkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3Y2Y0ZjZiZTk2YWYxYjM2 Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3 dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG9w0DBzALBglghkgBZQME AQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARADBB4wHAYSYIZIAYb4RQEQ AQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFIUjBjSE02THk5d2Eya3Rj bUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAKcAuoHFD7pg3zWlKrfKl4Xbl DUb88TJUAgEsGgbLcLkYvA0Zm/UAFMsuG/+haXKoOheyPwZsI2sk4AMZHgNWdHED3l54rjodKQG5 es3HV4MekJoxF23Skn4OQBRXWtmXr2fX9ilmtqFMeCkkfljmlAYan5NVhGtummOJvY8ICAtxsAi2 L5ZKWE3ovoog3v5+yTH8/5SpguWbLfNnDdgmHuwcbikV3TQXWxduvOfBhBwt0wJd3mxZWAA4jriF hupPiAAXi1SIoP2Xdd6jlsGC9z8av6+Ri21QFERd0KqXo+uiU030upYqWxEIE0L1cCJs7GJvF8h7 kYEPvx9zzkPYzTGCBQcwggUDAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 AhAVQzwThfXRvG1UcOgkHvdMMAkGBSsOAwIaBQCgggL9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDEwNjExNTkxOFowIwYJKoZIhvcNAQkEMRYEFOkg+0ysxkIv +zzvfSgNDzLZpdieMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAoGCCqGSIb3DQMH MAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQME AgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEBVDPBOF9dG8bVRw6CQe90wwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhAVQzwThfXRvG1UcOgkHvdM MA0GCSqGSIb3DQEBAQUABIIBACuVy2C8yLC5ZPRB6empnNmhp9F5+DsLzuRxt5xxRjtRl31la0Z9 R/ElRfY5sU/vlCtB+gaXL/R20Ps1rxCEiIG8v3XorT0puaJMy+zDXWvNTh1psoQmailhnrKBQFGo nz5gpakdEC/uI2ZWDBa7LBP4eb0sc/WoSaECHAAn+/KoomWgpTCAcG9TdFB4jmB5TFf/49XW5QPl BmqxxikAxMyM2ge2aJQ5N0SQnTdQcfXc2K2svd/h9eUQDrio9EVsdj1rnLZvf54B3jEaDmdWX/TX e574cijQZTLlkpyKNUDapSvC3B75/O9gV2ESJ34YJmhGFqQamqcTP81r7So8vEQAAAAAAAA= ------=_NextPart_000_0393_01D1484F.C36334D0-- From nobody Thu Jan 21 05:13:01 2016 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 B5D9A1B30F9 for ; Thu, 21 Jan 2016 05:12:51 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMMxLl57oBMU for ; Thu, 21 Jan 2016 05:12:50 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7101B3105 for ; Thu, 21 Jan 2016 05:12:50 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id t15so125158092igr.0 for ; Thu, 21 Jan 2016 05:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Glex15APxWiOEMQyllSn+s158S8ae89rAStwp8ZBjcQ=; b=HIYFU5b+Yu68yy2OPodRNGJgXpM+DyzLkYbvsy6HcB+AON0sOSmzdjfBl8EONpnOPz CTqfg9MY7GsoWjENfZBZq4YreFxTPEoyl0AQPG5dnoWI6ApMRbQdeI4KxONz3f/K8tq4 JA5gG/r/RgqaIhElO4TF3POnh7qtbRI9VE/naolylc9O//kWHr+gve7Tf/aWhWD4/bOb yUbf0i9+/ZYwWPNiN2l8gl9w9EOJodJCvkLyC9QGIRG7VWtBo+dRyuhklyPgFFakLNq1 8eDtK8XheDDFRKVswvZcEe7vmRqUj7kfINriG1Ylgtfu6ZS2ioB6pd0k6UFM2oZdpWku p/6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Glex15APxWiOEMQyllSn+s158S8ae89rAStwp8ZBjcQ=; b=HWv4SkGbMYTCMoC/TGTZhXmZ+X6qO0Wh7k+0HVsEZMoJ32KGQuwToq05inqx2uHchD 6jMWR+7wYwBazdpa5pw1HV5B3Jd/fBwFTmgcsx2CwlucFv5f7ofRL7101d78hrWTxR8N 2oDZnvJbgnMHoZLyDcwWd54DkKg9vGN3XLvWd9mTX11Tp9Nq0icXcEPbpPMM0OzzyNws mgv4SMoQaiZP27GT//qnAmLpxL33rZ8L2faOqpNNQsdJ0ilBqq3BKrTd6s1hSvFS08oH IQmma9yNZELsiGGwvwCYiyhXStU9j+0R+Hu92OaxNCvAS0JsZsb8MfyQhRwoXVbBXSCh 1r2Q== X-Gm-Message-State: AG10YOStVzVZm6PAUlsNilGGRuUlNYgniNNfNtTIVhJPVkBq6edduKI//8e5tMN3HEq4qqjiG9MioL3d40c9JQ== MIME-Version: 1.0 X-Received: by 10.50.138.5 with SMTP id qm5mr9861863igb.53.1453381969718; Thu, 21 Jan 2016 05:12:49 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.117.3 with HTTP; Thu, 21 Jan 2016 05:12:49 -0800 (PST) In-Reply-To: <20151014145826.EB9F218046A@rfc-editor.org> References: <20151014145826.EB9F218046A@rfc-editor.org> Date: Thu, 21 Jan 2016 08:12:49 -0500 X-Google-Sender-Auth: GmPGQBmLlyKCjlMcSj8_ndRpDmk Message-ID: From: Barry Leiba To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: olaf@nlnetlabs.nl, "weirds@ietf.org Group" Subject: Re: [weirds] [Technical Errata Reported] RFC7483 (4503) 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: Thu, 21 Jan 2016 13:12:51 -0000 As I've seen no responses to this three-month-old errata report, and as it was posted by an author, I'm going to mark it "Verified". RFC Editor: When I do that, will you please go in and correct the multiple-backslash problem (which I understand is a tooling issue)? Thanks, Barry On Wed, Oct 14, 2015 at 10:58 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC7483, > "JSON Responses for the Registration Data Access Protocol (RDAP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7483&eid=3D4503 > > -------------------------------------- > Type: Technical > Reported by: Scott Hollenbeck > > Section: 5.2 and 5.3 > > Original Text > ------------- > In Section 5.2: > > \\"ldhName\\" : \\"ns1.xn--fo-5ja.example\\", > \\"unicodeName\\" : \\"ns1.foo.example\\", > > In Section 5.3: > > \\"ldhName\\" : \\"xn--fo-5ja.example\\", > \\"unicodeName\\" : \\"foo.example\\", > > \\"ldhName\\" : \\"xn--fo-cka.example\\", > \\"unicodeName\\" : \\"foo.example\\" > > \\"ldhName\\" : \\"xn--fo-fka.example\\", > \\"unicodeName\\" : \\"foo.example\\" > > \\"ldhName\\": \\"xn--fo-8ja.example\\", > \\"unicodeName\\" : \\"foo.example\\" > > Corrected Text > -------------- > In Section 5.2: > > \\"ldhName\\" : \\"ns1.xn--fo-5ja.example\\", > \\"unicodeName\\" : \\"ns1.f=C3=B3o.example\\", > > In Section 5.3: > > \\"ldhName\\" : \\"xn--fo-5ja.example\\", > \\"unicodeName\\" : \\"f=C3=B3o.example\\", > > \\"ldhName\\" : \\"xn--fo-cka.example\\", > \\"unicodeName\\" : \\"f=C3=B5o.example\\" > > \\"ldhName\\" : \\"xn--fo-fka.example\\", > \\"unicodeName\\" : \\"f=C3=B6o.example\\" > > \\"ldhName\\" : \\"xn--fo-8ja.example\\", > \\"unicodeName\\" : \\"f=C3=B4o.example\\" > > Notes > ----- > The unicodeName examples in RFC 7483 are invalid per RFC 5890. Here\\'s a= n example from Section 5.2 on page 23: > > \\"unicodeName\\" : \\"ns1.foo.example\\", > > Section 3 of 7483 says this about Unicode names: > > \\"Unicode names: Textual representations of DNS names where one or more = of the labels are U-labels as described by [RFC5890].\\" > > 5890 says: \\"A \\"U-label\\" is an IDNA-valid string of Unicode characte= rs, in Normalization Form C (NFC) and including at least one non-ASCII char= acter, expressed in a standard Unicode Encoding Form (such as UTF-8).\\" > > The examples in 7483 contain all ASCII characters. Syntactically valid ex= amples are shown in the corrected text. > > Ignore the backslash characters. They were inserted by the errata submiss= ion tool. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7483 (draft-ietf-weirds-json-response-14) > -------------------------------------- > Title : JSON Responses for the Registration Data Access Pro= tocol (RDAP) > Publication Date : March 2015 > Author(s) : A. Newton, S. Hollenbeck > Category : PROPOSED STANDARD > Source : Web Extensible Internet Registration Data Service > Area : Applications > Stream : IETF > Verifying Party : IESG > From nobody Thu Jan 21 05:13:48 2016 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 7E8A41B30F7; Thu, 21 Jan 2016 05:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2veHLzXtD3Q; Thu, 21 Jan 2016 05:13:41 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id EF6DB1B30F8; Thu, 21 Jan 2016 05:13:40 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6AB19180206; Thu, 21 Jan 2016 05:12:26 -0800 (PST) To: shollenbeck@verisign.com, andy@arin.net, shollenbeck@verisign.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160121131226.6AB19180206@rfc-editor.org> Date: Thu, 21 Jan 2016 05:12:26 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, barryleiba@computer.org, iesg@ietf.org, weirds@ietf.org Subject: [weirds] [Errata Verified] RFC7483 (4503) 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: Thu, 21 Jan 2016 13:13:43 -0000 The following errata report has been verified for RFC7483, "JSON Responses for the Registration Data Access Protocol (RDAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7483&eid=4503 -------------------------------------- Status: Verified Type: Technical Reported by: Scott Hollenbeck Date Reported: 2015-10-14 Verified by: Barry Leiba (IESG) Section: 5.2 and 5.3 Original Text ------------- In Section 5.2: \\"ldhName\\" : \\"ns1.xn--fo-5ja.example\\", \\"unicodeName\\" : \\"ns1.foo.example\\", In Section 5.3: \\"ldhName\\" : \\"xn--fo-5ja.example\\", \\"unicodeName\\" : \\"foo.example\\", \\"ldhName\\" : \\"xn--fo-cka.example\\", \\"unicodeName\\" : \\"foo.example\\" \\"ldhName\\" : \\"xn--fo-fka.example\\", \\"unicodeName\\" : \\"foo.example\\" \\"ldhName\\": \\"xn--fo-8ja.example\\", \\"unicodeName\\" : \\"foo.example\\" Corrected Text -------------- In Section 5.2: \\"ldhName\\" : \\"ns1.xn--fo-5ja.example\\", \\"unicodeName\\" : \\"ns1.fóo.example\\", In Section 5.3: \\"ldhName\\" : \\"xn--fo-5ja.example\\", \\"unicodeName\\" : \\"fóo.example\\", \\"ldhName\\" : \\"xn--fo-cka.example\\", \\"unicodeName\\" : \\"fõo.example\\" \\"ldhName\\" : \\"xn--fo-fka.example\\", \\"unicodeName\\" : \\"föo.example\\" \\"ldhName\\" : \\"xn--fo-8ja.example\\", \\"unicodeName\\" : \\"fôo.example\\" Notes ----- The unicodeName examples in RFC 7483 are invalid per RFC 5890. Here\\'s an example from Section 5.2 on page 23: \\"unicodeName\\" : \\"ns1.foo.example\\", Section 3 of 7483 says this about Unicode names: \\"Unicode names: Textual representations of DNS names where one or more of the labels are U-labels as described by [RFC5890].\\" 5890 says: \\"A \\"U-label\\" is an IDNA-valid string of Unicode characters, in Normalization Form C (NFC) and including at least one non-ASCII character, expressed in a standard Unicode Encoding Form (such as UTF-8).\\" The examples in 7483 contain all ASCII characters. Syntactically valid examples are shown in the corrected text. Ignore the backslash characters. They were inserted by the errata submission tool. -------------------------------------- RFC7483 (draft-ietf-weirds-json-response-14) -------------------------------------- Title : JSON Responses for the Registration Data Access Protocol (RDAP) Publication Date : March 2015 Author(s) : A. Newton, S. Hollenbeck Category : PROPOSED STANDARD Source : Web Extensible Internet Registration Data Service Area : Applications Stream : IETF Verifying Party : IESG From nobody Fri Jan 29 05:34:45 2016 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 E7B251ACD1F for ; Fri, 29 Jan 2016 05:34:42 -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 60YNMa69M4-y for ; Fri, 29 Jan 2016 05:34:40 -0800 (PST) Received: from mail-qg0-x264.google.com (mail-qg0-x264.google.com [IPv6:2607:f8b0:400d:c04::264]) (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 7C3261ACC8D for ; Fri, 29 Jan 2016 05:34:40 -0800 (PST) Received: by mail-qg0-x264.google.com with SMTP id b35so4247651qge.0 for ; Fri, 29 Jan 2016 05:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:content-type :content-transfer-encoding:mime-version; bh=sCffLiYHSitBLsmgYx6H4GfHdXd/DpitP5gPV+LPmt8=; b=mJp5TSkm5iUPvUCHp223D+ItZF8w3H3OenIqEptp15VlIjh/DplQHdHAh3xCvW/aHl 1hZp4DK/VQGqKf0KtVcmlon3v779Gtva9SICNdmKfqR845WIfmD3IWmD8xCU03DBc4qL RdaAp6dwoAtu71tZf3vPewRsdixm2yL55l0qdiZz7MQXgzU2yygdKxlNiq14UypMMeHt w7ZDQjS8SotzWLVQeWJfzg+WyUwZ4+FN5noGV3xyQp55hgjl+KGn9z2iYOubt6uB/gSo fMgXFMuitS9fDxqsN4QrSMmfebkn9nR+sjSdOJuTlcAoSaIc9iWhanIVTWfcpdJG82UT dU1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:content-type :content-transfer-encoding:mime-version; bh=sCffLiYHSitBLsmgYx6H4GfHdXd/DpitP5gPV+LPmt8=; b=fmT1Ev2Z1+Mu6N+6aVR5zUdgQH8kQDQ+9vGNwAmHnMtqH/BUOb8LoZkjQgJQ43BZ8T kE5r+VhZ1GKDd//jPvzp8MsaKT373jqSxFge8sMddvwCdk/fyHqfRtWxdrhSum2SkRVs yhlZvkBmopubQ0u9kOZo0Grn5Tltg0669Yu2t3kyZPWyclwTOxFv19TGcQj5PrcUCFaN +I6EQuM5F76xC50prQsc9jH4pJE9nH8Z0dFqSrxpZf4b22IlhJWBs7p7gb5cgGsL4gOD 3+rvZxndyMUabIUKR9rpCZifvydig06wglGoVsm8xjNm74n3Y6bxGtQcJBsPuK+OzFQJ Nseg== X-Gm-Message-State: AG10YORtE8ur6/+PBXja6B4TZa3vl551MAAAQYgzU+ZlzWuUFUlN2FfVOyw59s05RtVghg1s9tEhnBJAULZqZQwcMhPlaaif X-Received: by 10.55.26.217 with SMTP id l86mr10183049qkh.103.1454074479621; Fri, 29 Jan 2016 05:34:39 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id z142sm1449891qka.11.2016.01.29.05.34.39 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 29 Jan 2016 05:34:39 -0800 (PST) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u0TDYd1k009430 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Jan 2016 08:34:39 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 29 Jan 2016 08:34:36 -0500 From: "Hollenbeck, Scott" To: "weirds@ietf.org" , "regops@nlnetlabs.nl" , "gtld-tech@icann.org" Thread-Topic: Search Engines Indexing RDAP Server Content Thread-Index: AdFamcnpcIqNwxGiSxmdhJxaDQVVfw== Date: Fri, 29 Jan 2016 13:34:35 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A149BDE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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: Subject: [weirds] Search Engines Indexing RDAP Server Content 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, 29 Jan 2016 13:34:43 -0000 (cross-posting to multiple lists - sorry if that's inconvenient) So I saw a tweet from Gavin Brown (@GavinBrown) that describes how one part= icular search engine has indexed the RDAP server of a gTLD registry operato= r: https://twitter.com/GavinBrown/status/692718904058191872 This is all the more reason to work on a client authentication specificatio= n that includes support for varying responses based on client identity and = authorization. I've been working on such a specification and welcome feedba= ck on the approach: https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ It also begs the question of the need for a BCP describing operational prac= tices for server operators. There are ways for web servers to influence or = restrict crawler behavior, but what's appropriate in this context? Scott From nobody Fri Jan 29 07:14:42 2016 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 B583D1A870E for ; Fri, 29 Jan 2016 07:14:40 -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 fgK8X5X5Te9N for ; Fri, 29 Jan 2016 07:14:39 -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 82C5F1A8703 for ; Fri, 29 Jan 2016 07:14:39 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id r129so72800809wmr.0 for ; Fri, 29 Jan 2016 07:14: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=XDodzk/cmAWhPav8sSjobxEqe3z7XFvzP+mhRZ4kpsc=; b=rqY3SnHjrEbD9UfBmC2Mcrw8R09/AlUIbrMa1GPIgXUxwpinxFrHl1F8pZVUBx7j/s jgcp9akBbHS9H11RuWShuIvgMFT7ocCO+cEWj5BACkihwp9UuxDWGqsqqaqkutuiy/AT TpsXBUquQLSm0KFhMeBjMtWjJoeMfAduuTPyHGKFjBbha7bfDrQPY47ptAVHGi5HvuBY 1TGsR23AJ5bUhjj1ayA9gqW2QNS1lylMB8Ovuq8Sqzdx8wCAA/ftECKnxIZYvmHOwVJy aU+2CiwU7uL3gQDDlGOX5bept0RUI/tPPXTxKaSOjH7k52GGjM43wr5xe384z/U+GxEn 2ndQ== 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=XDodzk/cmAWhPav8sSjobxEqe3z7XFvzP+mhRZ4kpsc=; b=EYLavUKbkWB6zQtk6fww3jOek/2nWt8wyqs4zTc/oaPv01WgpcRY3IeVw2ynOOP33C ISdki73Nh+ERM9jni0pCqwin4ddQmsRGOEwvGEZabxtl0X4RzUpfU8172PsGTlOxC/r7 Gob7Ms8nxVOJT9Ef4h0Ch72oB2Ygz0f8Bm483mL4spIS//xFIEshpmRWvh72X1cEnB31 fxdv2APKWXgmHRYJ/coPKDWSzZ8Txzx62puHFUcoIBITxu3unE8XUuG3eRNCS7Kg+E65 PtlhOnJqt9wMu/FfTvtLd1VuPe+3+s4j5W2Hs0tKAiLmtieNtLwmTK0OkVhMzOoVeICQ 9w5Q== X-Gm-Message-State: AG10YOSzaz5ldwZGyKoxztduUbmeMap86RVK83Rl18HkMeEdJlVtM32dlrzhkC2IeYXby/lOGB5Hqq5NZOkoMg== MIME-Version: 1.0 X-Received: by 10.28.12.9 with SMTP id 9mr9915514wmm.76.1454080478050; Fri, 29 Jan 2016 07:14:38 -0800 (PST) Received: by 10.194.10.166 with HTTP; Fri, 29 Jan 2016 07:14:37 -0800 (PST) X-Originating-IP: [192.149.252.137] In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A149BDE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4A149BDE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Fri, 29 Jan 2016 10:14:37 -0500 Message-ID: From: Andrew Newton To: "Hollenbeck, Scott" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "regops@nlnetlabs.nl" , "gtld-tech@icann.org" , "weirds@ietf.org" Subject: Re: [weirds] Search Engines Indexing RDAP Server Content 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, 29 Jan 2016 15:14:40 -0000 On Fri, Jan 29, 2016 at 8:34 AM, Hollenbeck, Scott wrote: > (cross-posting to multiple lists - sorry if that's inconvenient) > > So I saw a tweet from Gavin Brown (@GavinBrown) that describes how one particular search engine has indexed the RDAP server of a gTLD registry operator: > > https://twitter.com/GavinBrown/status/692718904058191872 Interesting... especially that most of the results are entities but it doesn't seem to be that many. > > This is all the more reason to work on a client authentication specification that includes support for varying responses based on client identity and authorization. I've been working on such a specification and welcome feedback on the approach: > > https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ +1 -andy From nobody Fri Jan 29 08:47:55 2016 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 C3F801A8747 for ; Fri, 29 Jan 2016 08:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syVBA3kQ3DUB for ; Fri, 29 Jan 2016 08:47:52 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0E31A8741 for ; Fri, 29 Jan 2016 08:47:52 -0800 (PST) Received: (qmail 76420 invoked from network); 29 Jan 2016 16:47:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=12a83.56ab97b7.k1601; bh=3aPVW89ccftl28CoMZylXmPPXihvtD8rOzCv2VmbhK0=; b=u+cPASgc3xUpSd36QGj5rcV4O4Zfz+XEfn/hilx6dTBVV+nkzMgy1N3a/+99L1CAqha9cAyMgmsl1Y8RBIjGDpXPKVQDvaAPfLO0aJlySBz+E7KuKA1JlPAQ2Ltaua1IcsPWu0iC4+z+Lcm7FjSbFroo5VU/VXLQFXHPzi8KyF7oUSUIiTK3IDSnXywzuKSZfHV8emOdwJM16SZgv/emcciZ/1xPocO+s0h5XlK9Yf1zK5HzbJG0hmJE9CPSe/Yv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=12a83.56ab97b7.k1601; bh=3aPVW89ccftl28CoMZylXmPPXihvtD8rOzCv2VmbhK0=; b=Gm7qgvAk7C2xTgmtEYTV+P4ukdAp/uwpZ5ZWaWEMDJu5njkTx2pJ0/iJnfyHkdpychAmtfFd6Gy8z4bKyl2Z4t9P3gFuoH6pVqORA5MTRfVyGb0w4tocQAxRYueSTr4CDSfUxzxmld0h/W0d8TcLrKcZPVONWFrO8cGFTtZ+gJjl+P6iNbliRURG69fDWSXSHg/3tutT01NWF0rYOYqOY0+hrl5Ct1grfvUgcAsKaKiBg/gc1ngGiNI1EBeszkMM Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 29 Jan 2016 16:47:51 -0000 Date: 29 Jan 2016 11:47:50 -0500 Message-ID: From: "John R Levine" To: weirds@ietf.org User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [weirds] [Regops] Search Engines Indexing RDAP Server Content 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, 29 Jan 2016 16:47:53 -0000 > So I saw a tweet from Gavin Brown (@GavinBrown) that describes how one > particular search engine has indexed the RDAP server of a gTLD registry > operator: > > https://twitter.com/GavinBrown/status/692718904058191872 > > This is all the more reason to work on a client authentication specification > that includes support for varying responses based on client identity and > authorization. I've been working on such a specification and welcome feedback > on the approach: I don't see what the problem is. If you set up an http server that returns interlinked data, search engines will find it and index it. All the information RDAP returns to an unauthenticated query is presumably public, so what's the harm in making it easier to find? But anyway, if you don't want them to do that, there's plenty of ways to keep them out. The easiest is to publish a /robots.txt file. All legit search engines will stay out if that's what it says. Another is to look at the agent string the client sends. Google's is googlebot, Bing's is bingbot, Yahoo's is scooter. It's easy enough to find a list of common spider names. If the agent is a spider, tell it to go away or redirect it to a help page. Another is to look at the Accept: header. An RDAP client should ask for a JSON media type. For a client that asks for html or anything else, return an html version with meta fields in the header saying NOINDEX and NOFOLLOW. The big search engines spider at low speed from hosts all over the world to avoid overloading the sites they index. You're not going to keep them out via authentication without also keeping out everyone else who doesn't have a password. I don't think that's a good idea. R's, John From nobody Fri Jan 29 08:54:42 2016 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 18F3E1A87C8 for ; Fri, 29 Jan 2016 08:54:41 -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 WeCkCXqGgkHI for ; Fri, 29 Jan 2016 08:54:39 -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 44C901A87C7 for ; Fri, 29 Jan 2016 08:54:39 -0800 (PST) Received: by mail-qg0-x262.google.com with SMTP id i20so4605300qgd.2 for ; Fri, 29 Jan 2016 08:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=p5eAeop13g9YIhieSsn2DZ9fHAlvQTFt8vXTzXkte/M=; b=uIzCbPajVZ8FDQV/RVVnXCzAwhi54UOl9aFSoq8NnVGytoSY+a7xmAoCLdk0L5m/tq Myh0SAPPMJzrD+69elUmkh8zEVcMKFQj1n9MHfT17aueiC1gUrTJSK3TRML5tpl730Ca iSxpwVcAkp2yiZhCAUTsW/i4xhxB7prBSJvTOqZFMtKAQxed2N/+LPxCppmPGFAz4f1N nH6tyu6MAFR7KmhhMcP9ffeOUc5tEDnroHEzahKUHPORuo53osguJwWtzfbRA0lCUwg+ jGVAz5IbO/XmARczNXXFDAo1kjgMtI6L8+Bz4C9u9r1GZXLBE8Hbb1bPq/jR3OYZ6pD6 uIOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=p5eAeop13g9YIhieSsn2DZ9fHAlvQTFt8vXTzXkte/M=; b=Q4z3/MilOzmovTafJJRP3l5wJCtzwCECS5CeRhpb1uJVRMzCPwEMq8HplVOgzw96gX ogLc5ymUh/Nx6naWaG2Oskvuz5aeYMFMgqbGhKCOyyACQqFIJpxkI4joAJO8MOKxRV76 bwWNx+wgKIWYWjifwOGM4wCqPxh446uzVfZtbCARRiH2v6O09b3Oey0+F5rONhAI/J4+ nOsLQW744L1r851OIIg6EYZGKApokPod6QQGS7/Po8vsm0UoXAUTgPbP0wxwQO7xXCQs REwOgUGekXYOKid0lJNliJQik6Xw2Rd+1XkrbsHLDDZbJD2drIg4vu9L2k64gjsKbwSb TRiw== X-Gm-Message-State: AG10YOSTVwkzJjTdy7bAEbTeBrePdhd2PtiToGZV1ROwsnAsivIR8UGubwrSGzyMU9C7eURPbrCLACtVccQLAUlnXsJ6tiUG X-Received: by 10.55.56.134 with SMTP id f128mr11782201qka.92.1454086478404; Fri, 29 Jan 2016 08:54:38 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id d123sm1486056qka.12.2016.01.29.08.54.38 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 29 Jan 2016 08:54:38 -0800 (PST) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u0TGsbS9010103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Jan 2016 11:54:37 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 29 Jan 2016 11:54:35 -0500 From: "Hollenbeck, Scott" To: John R Levine , "weirds@ietf.org" Thread-Topic: [weirds] [Regops] Search Engines Indexing RDAP Server Content Thread-Index: AQHRWrTPLeNZLPJOwEOzSCpB2y+X758StVFw Date: Fri, 29 Jan 2016 16:54:35 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A14C08E@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [weirds] [Regops] Search Engines Indexing RDAP Server Content 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, 29 Jan 2016 16:54:41 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of John R > Levine > Sent: Friday, January 29, 2016 11:48 AM > To: weirds@ietf.org > Subject: Re: [weirds] [Regops] Search Engines Indexing RDAP Server > Content >=20 > > So I saw a tweet from Gavin Brown (@GavinBrown) that describes how > one > > particular search engine has indexed the RDAP server of a gTLD > registry > > operator: [snip] > The big search engines spider at low speed from hosts all over the > world > to avoid overloading the sites they index. You're not going to keep > them > out via authentication without also keeping out everyone else who > doesn't > have a password. I don't think that's a good idea. We have a difference of opinion, because I tend to think that it's a *good*= idea to restrict access to *some* data based on a client's identify and le= vel of authorization. I do not want *my* PII appearing in search engine sea= rch results because it's accessible via RDAP. Scott From nobody Fri Jan 29 08:54:55 2016 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 978FE1A87D4 for ; Fri, 29 Jan 2016 08:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2wMd9T60uzA for ; Fri, 29 Jan 2016 08:54:51 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9311A87C7 for ; Fri, 29 Jan 2016 08:54:51 -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.1130.7; Fri, 29 Jan 2016 08:54:49 -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.1130.005; Fri, 29 Jan 2016 08:54:49 -0800 From: Francisco Arias To: "Hollenbeck, Scott" , "weirds@ietf.org" , "regops@nlnetlabs.nl" , "gtld-tech@icann.org" Thread-Topic: [weirds] Search Engines Indexing RDAP Server Content Thread-Index: AQHRWrXDcIqNwxGiSxmdhJxaDQVVfw== Date: Fri, 29 Jan 2016 16:54:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160109 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.35.2] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [weirds] Search Engines Indexing RDAP Server Content 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, 29 Jan 2016 16:54:53 -0000 SGkgU2NvdHQsDQoNCkluIGFsbCB0aGUgY3Jvc3MtcG9zdGluZywgaXQgc2VlbXMgeW91IG1heSBo YXZlIGxlZnQgb3V0IHRoZSBsaXN0IHdoZXJlIHBlb3BsZSBoYXZlIGN1cnJlbnRseSBpbiBzY29w ZSBkb2luZyBzb21ldGhpbmcgYWJvdXQgdGhpcyBodHRwczovL2NvbW11bml0eS5pY2Fubi5vcmcv ZGlzcGxheS9nVExEUkRTL05leHQtR2VuZXJhdGlvbitnVExEK1JlZ2lzdHJhdGlvbitEaXJlY3Rv cnkrU2VydmljZXMrdG8rUmVwbGFjZStXaG9pcw0KDQpSZWdhcmRzLA0KDQotLSANCkZyYW5jaXNj bw0KDQoNCg0KDQoNCg0KDQpPbiAxLzI5LzE2LCA1OjM0IEFNLCAid2VpcmRzIG9uIGJlaGFsZiBv ZiBIb2xsZW5iZWNrLCBTY290dCIgPHdlaXJkcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBzaG9sbGVuYmVja0B2ZXJpc2lnbi5jb20+IHdyb3RlOg0KDQo+KGNyb3NzLXBvc3RpbmcgdG8g bXVsdGlwbGUgbGlzdHMgLSBzb3JyeSBpZiB0aGF0J3MgaW5jb252ZW5pZW50KQ0KPg0KPlNvIEkg c2F3IGEgdHdlZXQgZnJvbSBHYXZpbiBCcm93biAoQEdhdmluQnJvd24pIHRoYXQgZGVzY3JpYmVz IGhvdyBvbmUgcGFydGljdWxhciBzZWFyY2ggZW5naW5lIGhhcyBpbmRleGVkIHRoZSBSREFQIHNl cnZlciBvZiBhIGdUTEQgcmVnaXN0cnkgb3BlcmF0b3I6DQo+DQo+aHR0cHM6Ly90d2l0dGVyLmNv bS9HYXZpbkJyb3duL3N0YXR1cy82OTI3MTg5MDQwNTgxOTE4NzINCj4NCj5UaGlzIGlzIGFsbCB0 aGUgbW9yZSByZWFzb24gdG8gd29yayBvbiBhIGNsaWVudCBhdXRoZW50aWNhdGlvbiBzcGVjaWZp Y2F0aW9uIHRoYXQgaW5jbHVkZXMgc3VwcG9ydCBmb3IgdmFyeWluZyByZXNwb25zZXMgYmFzZWQg b24gY2xpZW50IGlkZW50aXR5IGFuZCBhdXRob3JpemF0aW9uLiBJJ3ZlIGJlZW4gd29ya2luZyBv biBzdWNoIGEgc3BlY2lmaWNhdGlvbiBhbmQgd2VsY29tZSBmZWVkYmFjayBvbiB0aGUgYXBwcm9h Y2g6DQo+DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaG9sbGVuYmVj ay13ZWlyZHMtcmRhcC1vcGVuaWQvDQo+DQo+SXQgYWxzbyBiZWdzIHRoZSBxdWVzdGlvbiBvZiB0 aGUgbmVlZCBmb3IgYSBCQ1AgZGVzY3JpYmluZyBvcGVyYXRpb25hbCBwcmFjdGljZXMgZm9yIHNl cnZlciBvcGVyYXRvcnMuIFRoZXJlIGFyZSB3YXlzIGZvciB3ZWIgc2VydmVycyB0byBpbmZsdWVu Y2Ugb3IgcmVzdHJpY3QgY3Jhd2xlciBiZWhhdmlvciwgYnV0IHdoYXQncyBhcHByb3ByaWF0ZSBp biB0aGlzIGNvbnRleHQ/DQo+DQo+U2NvdHQNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPndlaXJkcyBtYWlsaW5nIGxpc3QNCj53ZWlyZHNAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlaXJkcw0K From nobody Fri Jan 29 09:24:05 2016 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 CFA9A1A88BD for ; Fri, 29 Jan 2016 09:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0E_-SFJjY7C for ; Fri, 29 Jan 2016 09:24:02 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34A81A88B4 for ; Fri, 29 Jan 2016 09:24:01 -0800 (PST) Received: (qmail 83775 invoked from network); 29 Jan 2016 17:24:00 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 29 Jan 2016 17:24:00 -0000 Date: 29 Jan 2016 17:23:38 -0000 Message-ID: <20160129172338.51466.qmail@ary.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A14C08E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [weirds] [Regops] Search Engines Indexing RDAP Server Content 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, 29 Jan 2016 17:24:04 -0000 >We have a difference of opinion, because I tend to think that it's a *good* idea to restrict access >to *some* data based on a client's identify and level of authorization. I do not want *my* PII >appearing in search engine search results because it's accessible via RDAP. Sorry, but I really don't understand what you want here. There have been vertical WHOIS search engines forever that let you search WHOIS data in various ways. Most of them charge money, but as often as not some access is free. That horse left the barn a decade ago. The stuff that search engines can see is exactly the same as what casual users see. If you're saying that you want to make some stuff unavailable to anyone who doesn't have a password, OK, but now aren't you running into the whole ICANN mess of what's in WHOIS and what isn't? R's, John PS: On the third hand, if you want to make it slightly harder for casual searches to find RDAP info, publishing a robots.txt that says "Disallow: /" should take about 30 seconds. and will keep the entire site out of all of the legit search engines. From nobody Fri Jan 29 09:30:20 2016 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 EAB621A88C1 for ; Fri, 29 Jan 2016 09:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.063 X-Spam-Level: * X-Spam-Status: No, score=1.063 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CeNeTa18-BC for ; Fri, 29 Jan 2016 09:30:17 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E549D1A88D0 for ; Fri, 29 Jan 2016 09:30:16 -0800 (PST) Received: (qmail 84918 invoked from network); 29 Jan 2016 17:30:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14bb4.56aba1a7.k1601; bh=E/dbfVJrzxMds0b65c14mVbqNlvM9SwGJw1eWih0gpo=; b=1GNy9b+teBXEhdvG3nCzlnxPzD152JYb8IS0lO1LE/chT2derP8I4j1Fygx5D80MOXhjr1NV1KIf4TM4XuIWLf2F95weuIC2GUOQGI+B6Pw40LTgDE0pyjRSmmTT0ZxUHXE2u+apqfSpv4FVQuHCkZ+w1d6UDQJAZksiJrjqEUHRevPqSgvw0liP0myq2CZHSrsC3pXe6SW4oxqfHmc2KvM3HjC4DQWYiFX+DMTaJamgcnoMxfsF65criKk3/8uT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14bb4.56aba1a7.k1601; bh=E/dbfVJrzxMds0b65c14mVbqNlvM9SwGJw1eWih0gpo=; b=efKAep6Jqwax7Z5fydGrnt0KBkFL487l0c+9Lo+acIXr6Q3BWqTEwxMYK1aH7tcWsPQIuZsG7Ir57Qx96hGWbqNesooD/knai3NQ2WxPPIk/HWluN3FDxqgBwOycdmQYA8ZRQuSAlX90quTqE3eLmOmrhfycfuEqj5D7mQTXmBcAur1c0ghsZQi08woYNK5uK8orUijyUubeIDY0qKsxaL/4PR8LlP2bUxY7u50ZYIKnCW7xQ7fgwYwptNDW5sPp Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 29 Jan 2016 17:30:15 -0000 Date: 29 Jan 2016 12:30:15 -0500 Message-ID: From: "John R Levine" To: "=?UTF-8?Q?Luis_E=2E_Mu=C3=B1oz?=" In-Reply-To: <3F908F99-CC9C-4D7B-83CB-B6F8A8B16EA3@uniregistry.link> References: <831693C2CDA2E849A7D7A712B24E257F4A149BDE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <3F908F99-CC9C-4D7B-83CB-B6F8A8B16EA3@uniregistry.link> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1363064330-1454088615=:27475" Archived-At: Cc: "regops@nlnetlabs.nl" , "gtld-tech@icann.org" , "weirds@ietf.org" Subject: Re: [weirds] [Regops] Search Engines Indexing RDAP Server Content 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, 29 Jan 2016 17:30:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1363064330-1454088615=:27475 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT >> It also begs the question of the need for a BCP describing operational >> practices for server operators. There are ways for web servers to influence >> or restrict crawler behavior, but what's appropriate in this context? > > It would be good to keep in mind that respecting mechanisms such as > robots.txt is entirely voluntary on the crawler’s side. Right -- the only reasonable assumption is that if casual users can find it with http, evil search engines (of which there are plenty) will too. The search engines that most people use such as Google and Bing all obey robots.txt so it will keep info out of casual searches. But I'd want to understand what the threat model is before inventing solutions. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. --0-1363064330-1454088615=:27475-- From nobody Fri Jan 29 09:31:27 2016 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 D42ED1A88BD for ; Fri, 29 Jan 2016 09:31:25 -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 qEYIiYhefoUf for ; Fri, 29 Jan 2016 09:31:24 -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 25D411A886B for ; Fri, 29 Jan 2016 09:31:24 -0800 (PST) Received: by mail-oi0-x261.google.com with SMTP id s2so4623451oie.0 for ; Fri, 29 Jan 2016 09:31:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=9/co6nBqPl9fCAYN0M0G8xngaDerxNx99pgFZ55nLHM=; b=qrj/7nmQMqxu8N5Cixz9DUr3cDkxihMZvrpm83dcA7JC08O1PEDVaGbku9La2F39TS UCXRb2WopBWmV9KB0s7xolaTkqN9AsAfI19FRBySN7M3bV4FfYVF8e2dqm7ggS4ytlXT UsCVfwpPuvS7/C3rxrjOSvRa3wm95qHdc61LPRCsxETMJpbcnVFeSeIK+vGRbJL1Kthl UeGBUO8aOMoPFSqV6ATBnBuwoQCnIQDmosXHmXuRHZCZGOo3SbXO0MF5NOO+UjWqqIDl Xvku5VrXN9VyDCjCd7gLOXUrhXZoclOCXrFknNEdwSl7M0EnNn+AqTPvZrS2FIJ8YWKJ vpxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=9/co6nBqPl9fCAYN0M0G8xngaDerxNx99pgFZ55nLHM=; b=WAb4TlHS7iO4qLijBiLaCK+t4+Ru85iHs2iyw038u+TSureTaLwSUdfrDY9J9sFiHZ BoYvg1ND9MnlZlU6idsMRtMMknAf7qs34246SyKuOcrK9mhF5UW2+ycxBooh78GvrJUp E0QnRANb0FJ8drMu5e7ov6cOBCQ4KokHQwua25ve5ZICUpVDdeRgS3TAOViNNMOolUdY qO+WwjiCTM3TLdpDhsiOlWCdlSE8TpeHMuSzdswGbSmBsSfkqbgYbqHK0DfBqZTa+dYL z7Q3qWwyLFYffHlu9aBToV3tkJPzKdx1BbqWtsUmsIDrSHee8tnv7jkyNGtlT4+YjBZN OiiA== X-Gm-Message-State: AG10YOTukv7DogU8UMvgfO5HjoxbrEC/bIIFeRPkLfIAusyxAzzI5yj6M5gaEqNq4mCb2ri+ZHZ5G5rMiVeu1Fd1wrds0juI X-Received: by 10.141.2.68 with SMTP id e65mr12947047qhd.64.1454088683423; Fri, 29 Jan 2016 09:31:23 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id x75sm1726919qkx.7.2016.01.29.09.31.23 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 29 Jan 2016 09:31:23 -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 u0THVNAi026582 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Jan 2016 12:31:23 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 29 Jan 2016 12:31:22 -0500 From: "Hollenbeck, Scott" To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] [Regops] Search Engines Indexing RDAP Server Content Thread-Index: AQHRWrTPLeNZLPJOwEOzSCpB2y+X758StVFwgABcqwD//63pkA== Date: Fri, 29 Jan 2016 17:31:21 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A14C32F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4A14C08E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20160129172338.51466.qmail@ary.lan> In-Reply-To: <20160129172338.51466.qmail@ary.lan> 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: Subject: Re: [weirds] [Regops] Search Engines Indexing RDAP Server Content 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, 29 Jan 2016 17:31:26 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDI5LCAyMDE2IDEyOjI0 IFBNDQo+IFRvOiB3ZWlyZHNAaWV0Zi5vcmcNCj4gQ2M6IEhvbGxlbmJlY2ssIFNjb3R0DQo+IFN1 YmplY3Q6IFJlOiBbd2VpcmRzXSBbUmVnb3BzXSBTZWFyY2ggRW5naW5lcyBJbmRleGluZyBSREFQ IFNlcnZlcg0KPiBDb250ZW50DQo+IA0KPiA+V2UgaGF2ZSBhIGRpZmZlcmVuY2Ugb2Ygb3Bpbmlv biwgYmVjYXVzZSBJIHRlbmQgdG8gdGhpbmsgdGhhdCBpdCdzIGENCj4gKmdvb2QqIGlkZWEgdG8g cmVzdHJpY3QgYWNjZXNzDQo+ID50byAqc29tZSogZGF0YSBiYXNlZCBvbiBhIGNsaWVudCdzIGlk ZW50aWZ5IGFuZCBsZXZlbCBvZg0KPiBhdXRob3JpemF0aW9uLiBJIGRvIG5vdCB3YW50ICpteSog UElJDQo+ID5hcHBlYXJpbmcgaW4gc2VhcmNoIGVuZ2luZSBzZWFyY2ggcmVzdWx0cyBiZWNhdXNl IGl0J3MgYWNjZXNzaWJsZSB2aWENCj4gUkRBUC4NCj4gDQo+IFNvcnJ5LCBidXQgSSByZWFsbHkg ZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlvdSB3YW50IGhlcmUuICBUaGVyZSBoYXZlDQo+IGJlZW4g dmVydGljYWwgV0hPSVMgc2VhcmNoIGVuZ2luZXMgZm9yZXZlciB0aGF0IGxldCB5b3Ugc2VhcmNo IFdIT0lTDQo+IGRhdGEgaW4gdmFyaW91cyB3YXlzLiAgTW9zdCBvZiB0aGVtIGNoYXJnZSBtb25l eSwgYnV0IGFzIG9mdGVuIGFzIG5vdA0KPiBzb21lIGFjY2VzcyBpcyBmcmVlLiAgVGhhdCBob3Jz ZSBsZWZ0IHRoZSBiYXJuIGEgZGVjYWRlIGFnby4NCj4gDQo+IFRoZSBzdHVmZiB0aGF0IHNlYXJj aCBlbmdpbmVzIGNhbiBzZWUgaXMgZXhhY3RseSB0aGUgc2FtZSBhcyB3aGF0DQo+IGNhc3VhbCB1 c2VycyBzZWUuICBJZiB5b3UncmUgc2F5aW5nIHRoYXQgeW91IHdhbnQgdG8gbWFrZSBzb21lIHN0 dWZmDQo+IHVuYXZhaWxhYmxlIHRvIGFueW9uZSB3aG8gZG9lc24ndCBoYXZlIGEgcGFzc3dvcmQs IE9LLCBidXQgbm93IGFyZW4ndA0KPiB5b3UgcnVubmluZyBpbnRvIHRoZSB3aG9sZSBJQ0FOTiBt ZXNzIG9mIHdoYXQncyBpbiBXSE9JUyBhbmQgd2hhdA0KPiBpc24ndD8NCg0KWWVzLCBkZWZpbml0 ZWx5LiBJIHNlZSBsaXR0bGUgcG9pbnQgaW4gZGVwbG95aW5nIFJEQVAgaWYgYWxsIHdlIGdldCBp cyBKU1BPTi1lbmNvZGVkIFdIT0lTIGRhdGEuIFdlIGhhdmUgYSB0b29sIHRoYXQgbGV0J3MgdXMg Zml4IHRoZSB3aG9sZSAiYWxsIGRhdGEgdmlzaWJsZSB0byBldmVyeW9uZSIgcHJvYmxlbS4gV2Ug c2hvdWxkIHRyeSB0byB1c2UgaXQuDQoNClNjb3R0DQo=