From andy@arin.net Tue Sep 4 14:21:35 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2CF21E8040 for ; Tue, 4 Sep 2012 14:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLpQDd-1Sdxh for ; Tue, 4 Sep 2012 14:21:35 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id BB76921E8083 for ; Tue, 4 Sep 2012 14:21:34 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id A3B4E21364C; Tue, 4 Sep 2012 17:21:33 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id D761D213588; Tue, 4 Sep 2012 17:21:32 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 4 Sep 2012 17:21:23 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 17:21:32 -0400 From: Andy Newton To: "Murray S. Kucherawy" , "Hollenbeck, Scott" Thread-Topic: Call for Adoption (was Re: [weirds] New Unified DNR/RIR Internet-Drafts) Thread-Index: AQHNiuNALQv7EKjNhk6vel4ncYse+A== Date: Tue, 4 Sep 2012 21:21:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.35.153] Content-Type: text/plain; charset="us-ascii" Content-ID: <49CDBCE940BE2D42A9C7B5F811DB1424@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:21:35 -0000 As unsurprizing as this may be, I support these documents for adoption as working group items. -andy On 8/31/12 4:18 PM, "Murray S. Kucherawy" wrote: >On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott > wrote: >> So, a question for the chairs and group: combined with the "using http" >>and redirection drafts, do we now have a set that's ready to become >>working group documents? > >Having not yet spoken to Olaf (who is on vacation), my view is that >this is in line with the vision the chairs presented in Vancouver for >a path forward. Kudos to you and Andy for taking this initiative. > >To the WG: I propose that we adopt these as initial working group >documents toward our milestones. Note, as usual, that they are merely >starting points and foci for discussion; we need to develop them and >reach working group consensus before they will be advanced for >publication. > >I'll place them in Call For Adoption state now. Please review them >and comment as to whether you believe they are reasonable starting >points for development. > >-MSK >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From markk@arin.net Tue Sep 4 14:32:28 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3A521E8092 for ; Tue, 4 Sep 2012 14:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2BMkjqEpCCu for ; Tue, 4 Sep 2012 14:32:27 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1D221E8082 for ; Tue, 4 Sep 2012 14:32:27 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 7AF1321364C; Tue, 4 Sep 2012 17:32:26 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id C53C9213596 for ; Tue, 4 Sep 2012 17:32:23 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 4 Sep 2012 17:32:12 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 17:32:21 -0400 From: Mark Kosters To: Andy Newton Thread-Topic: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) Thread-Index: AQHNiuNALQv7EKjNhk6vel4ncYse+Jd6s7OA Date: Tue, 4 Sep 2012 21:32:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.185] Content-Type: text/plain; charset="us-ascii" Content-ID: <714EA3B58EBC7C458685695BBC707B49@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:32:28 -0000 I support adoption of these docs as well. Mark On 9/4/12 5:21 PM, "Andy Newton" wrote: >As unsurprizing as this may be, I support these documents for adoption as >working group items. > >-andy > >On 8/31/12 4:18 PM, "Murray S. Kucherawy" wrote: > >>On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott >> wrote: >>> So, a question for the chairs and group: combined with the "using http" >>>and redirection drafts, do we now have a set that's ready to become >>>working group documents? >> >>Having not yet spoken to Olaf (who is on vacation), my view is that >>this is in line with the vision the chairs presented in Vancouver for >>a path forward. Kudos to you and Andy for taking this initiative. >> >>To the WG: I propose that we adopt these as initial working group >>documents toward our milestones. Note, as usual, that they are merely >>starting points and foci for discussion; we need to develop them and >>reach working group consensus before they will be advanced for >>publication. >> >>I'll place them in Call For Adoption state now. Please review them >>and comment as to whether you believe they are reasonable starting >>o/weirds From dblumenthal@pir.org Tue Sep 4 15:43:35 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAB821E8092 for ; Tue, 4 Sep 2012 15:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.076 X-Spam-Level: X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9KxyXUpSidm for ; Tue, 4 Sep 2012 15:43:34 -0700 (PDT) Received: from mail.pir.org (173-10-164-41-BusName-washingtonDC.hfc.comcastbusiness.net [173.10.164.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6E32E21E8082 for ; Tue, 4 Sep 2012 15:43:34 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Tue, 4 Sep 2012 18:43:33 -0400 From: Don Blumenthal To: "weirds@ietf.org" Date: Tue, 4 Sep 2012 18:43:29 -0400 Thread-Topic: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) Thread-Index: Ac2K7rYHPqpfkUnqSKa3tXl23rEsjQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 22:43:35 -0000 I'll add my support. Don On 9/4/12 5:32 PM, "Mark Kosters" wrote: >I support adoption of these docs as well. > >Mark > >On 9/4/12 5:21 PM, "Andy Newton" wrote: > >>As unsurprizing as this may be, I support these documents for adoption as >>working group items. >> >>-andy >> >>On 8/31/12 4:18 PM, "Murray S. Kucherawy" wrote: >> >>>On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott >>> wrote: >>>> So, a question for the chairs and group: combined with the "using >>>>http" >>>>and redirection drafts, do we now have a set that's ready to become >>>>working group documents? >>> >>>Having not yet spoken to Olaf (who is on vacation), my view is that >>>this is in line with the vision the chairs presented in Vancouver for >>>a path forward. Kudos to you and Andy for taking this initiative. >>> >>>To the WG: I propose that we adopt these as initial working group >>>documents toward our milestones. Note, as usual, that they are merely >>>starting points and foci for discussion; we need to develop them and >>>reach working group consensus before they will be advanced for >>>publication. >>> >>>I'll place them in Call For Adoption state now. Please review them >>>and comment as to whether you believe they are reasonable starting >>>o/weirds > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From steve.sheng@icann.org Tue Sep 4 15:53:18 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405C521F8557 for ; Tue, 4 Sep 2012 15:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzPfnYyiwunj for ; Tue, 4 Sep 2012 15:53:17 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id B9D3C21F8555 for ; Tue, 4 Sep 2012 15:53:17 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 4 Sep 2012 15:53:17 -0700 From: Steve Sheng To: Mark Kosters , Andy Newton Date: Tue, 4 Sep 2012 15:53:15 -0700 Thread-Topic: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) Thread-Index: Ac2K8BJDlXJlAhPPTSO/aeWn7hyliw== Message-ID: 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.2.2.120421 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3429618795_36835976" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 22:53:18 -0000 --B_3429618795_36835976 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1, support for adoption. -----Original Message----- From: Mark Kosters To: Andy Newton Cc: "weirds@ietf.org" Subject: Re: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) >I support adoption of these docs as well. > >Mark > >On 9/4/12 5:21 PM, "Andy Newton" wrote: > >>As unsurprizing as this may be, I support these documents for adoption as >>working group items. >> >>-andy >> >>On 8/31/12 4:18 PM, "Murray S. Kucherawy" wrote: >> >>>On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott >>> wrote: >>>> So, a question for the chairs and group: combined with the "using >>>>http" >>>>and redirection drafts, do we now have a set that's ready to become >>>>working group documents? >>> >>>Having not yet spoken to Olaf (who is on vacation), my view is that >>>this is in line with the vision the chairs presented in Vancouver for >>>a path forward. Kudos to you and Andy for taking this initiative. >>> >>>To the WG: I propose that we adopt these as initial working group >>>documents toward our milestones. Note, as usual, that they are merely >>>starting points and foci for discussion; we need to develop them and >>>reach working group consensus before they will be advanced for >>>publication. >>> >>>I'll place them in Call For Adoption state now. Please review them >>>and comment as to whether you believe they are reasonable starting >>>o/weirds > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds --B_3429618795_36835976 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITmwYJKoZIhvcNAQcCoIITjDCCE4gCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EWcwggbiMIIFyqADAgECAhABZMwilD7GxArmntmcL5R/MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjA2MDcwMDAw MDBaFw0xNTA2MDcxMjAwMDBaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAk0LP2kd68QahDa0JHYITr25S nDBvdGo1ipsN1/W/XOD3D/TsHIwLW6fJGxggQe20WSP0z4C2bAwxm/86a7LgTSHFVHID6NCU wI3FjTukn1NKepT1qLFYJ+F+6Fr+PGXxAqkHjgtxvH6D6/i6CBVx23nhikAZZ9kohGXmrAeu q7WfAIKziZel8gESFvnlwl0ddgUB2onbPnytNSTkE7YadrP+seY5q8pH52M5m5BL5j6Ov6DS ix78Yx7rqRclE2MCTsRtlxy9MCQMf95/5Jhy+ZR6Hm+7kSXdosckMmqitzqw/sE6FNA+ChLQ PYA4KkmnRFZXjNLy0z3CqNOPj4hPAgMBAAGjggNkMIIDYDAfBgNVHSMEGDAWgBQVABIrE5iy mQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUz5w5ABV+GwM+WrkNqgAws9jssIwwIAYDVR0RBBkw F4EVc3RldmUuc2hlbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgw ggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5j b20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkA IAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUA IABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUA bAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgA IABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUA bgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj ZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEA zZA8H8eHQfdut5RjlHklXuWQYdnPAwmXRjcuqwhmvlsAghGxLyfQ6+glnd3TsSue+ighPszj 4i1ryRnBN4/SkywV+5gcP88BU94zAZJvSxmNeD5kR9HjZsL44PrpvgtDv0Q4Ap6PA3K9pals EPORzu1f+QcLFmSY/1E6nunOOjhAaSKwLKU8ThkwUmczI9Wm74SVNMjWJZlsHJsG4AoEUJe7 HG04zMo3/vadmoywbDHtmQjLZWNu/1OvBH0xaXnPW+meS8HaPALX6wDKPeUCxWq4/GLEqUWV L6IKJ3yRjbYrAjjGu1P4KTv9UsH0iEowiq+7ewjbD+dXexWsaXh8bTCCBsIwggWqoAMCAQIC EAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYI A6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkF l32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLO Bq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcK J1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0 MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCC AcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEE cTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+i vlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUF AAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTk c61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5Wwg V7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1b fDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDes z+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKf oAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMx MTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlx EqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gy NnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgv GP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgz bCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKm VrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgw FoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6 ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLY Z4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVt X4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83 fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKj JqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQAWTMIpQ+xsQK5p7ZnC+UfzAJ BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFDp2DlsBusi+uTsESKlvzwgvbEnPMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkwNDIyNTMxNVowDQYJ KoZIhvcNAQEBBQAEggEAN9R3laxeOFDxiTWBqxB9Ik10V2Sr19GmorC3X/iUAxJKZd8VI37I z4Dx7CEgi1nptSNtHF7wlNGaB8gcOkqVWBdgEUxJazkbTPTWnPQ4FmLtwgKPkXT+JkMh+7P4 dZcQO2ceh5GP8lrf1C4mHKZOc66VyXGYKAFdyCEEb82g/tWmUV9EnHugez7BpamsWWGecKjs SK6d5/06ye5hC7qScxArSJth8KTv2MOTlpylxHlYL6h97/46pqY+nKO3zNg85Cz28zkPm48T ODdJssCMxz4seCi338rFy5RwOpZ0KwIG1NMlMFSm+A8gKmbCqOGuG6omCiQ1pNarXYlrTLD5 BA== --B_3429618795_36835976-- From bje@apnic.net Tue Sep 4 19:53:40 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE5D21F85A8 for ; Tue, 4 Sep 2012 19:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGeIojy7Jdqi for ; Tue, 4 Sep 2012 19:53:39 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 2F12821F84BF for ; Tue, 4 Sep 2012 19:53:38 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1] (unknown [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2748AB6867 for ; Wed, 5 Sep 2012 12:53:36 +1000 (EST) From: Byron Ellacott Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_EFA1F04B-DD6D-4CE4-A158-6C0E4DED3B4E"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 5 Sep 2012 12:53:34 +1000 In-Reply-To: To: weirds@ietf.org References: Message-Id: <048A8A0F-90C6-44C1-8C6C-59DAD5454C55@apnic.net> X-Mailer: Apple Mail (2.1278) Subject: Re: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 02:53:40 -0000 --Apple-Mail=_EFA1F04B-DD6D-4CE4-A158-6C0E4DED3B4E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii +1, support adoption Byron On 05/09/2012, at 8:53 AM, Steve Sheng wrote: > +1, support for adoption. > > -----Original Message----- > From: Mark Kosters > To: Andy Newton > Cc: "weirds@ietf.org" > Subject: Re: [weirds] Call for Adoption (was Re: New Unified DNR/RIR > Internet-Drafts) > >> I support adoption of these docs as well. >> >> Mark >> >> On 9/4/12 5:21 PM, "Andy Newton" wrote: >> >>> As unsurprizing as this may be, I support these documents for adoption as >>> working group items. >>> >>> -andy >>> >>> On 8/31/12 4:18 PM, "Murray S. Kucherawy" wrote: >>> >>>> On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott >>>> wrote: >>>>> So, a question for the chairs and group: combined with the "using >>>>> http" >>>>> and redirection drafts, do we now have a set that's ready to become >>>>> working group documents? >>>> >>>> Having not yet spoken to Olaf (who is on vacation), my view is that >>>> this is in line with the vision the chairs presented in Vancouver for >>>> a path forward. Kudos to you and Andy for taking this initiative. >>>> >>>> To the WG: I propose that we adopt these as initial working group >>>> documents toward our milestones. Note, as usual, that they are merely >>>> starting points and foci for discussion; we need to develop them and >>>> reach working group consensus before they will be advanced for >>>> publication. >>>> >>>> I'll place them in Call For Adoption state now. Please review them >>>> and comment as to whether you believe they are reasonable starting >>>> o/weirds >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds -- Byron Ellacott email: bje@apnic.net Technical Director, APNIC sip: bje@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary. --Apple-Mail=_EFA1F04B-DD6D-4CE4-A158-6C0E4DED3B4E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MDUwMjUzMzVaMCMGCSqGSIb3DQEJBDEWBBQc 3lu5pissZQOhdukCNE3WOFhikDCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQCM9MgqgTTwXovK Qqy5cUOALvinwBqXTmxsDAPs5jDBisQPXqYOMrze1skftRWW87N7ng7qwBscy2l37J+4CclRIwEl 9/603mH9Q4p1Iqyk4ccEEemGcVXZf3wS7QGFZ2iE5KG5Rqk7M36NzPYG1rGpgdsXx0dC7O0ocSHO qD7BwAT/uVs9cYQu7GgukLI5rjFf5VNvyc5wSb0wrCZlekSnINSvTKKeOsp5yD93/e55rQ/pcOpc RM8c7U+2grhCZQsPmVSKdkIBjcpUMAywrUBxWgRa3gndmYsk/G8bPRa07reJBS/Ish52BLu90aQu oRnf86JuWoeaV7JBz9K49WV+AAAAAAAA --Apple-Mail=_EFA1F04B-DD6D-4CE4-A158-6C0E4DED3B4E-- From zhoulinlin@cnnic.cn Tue Sep 4 20:00:29 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E7121F85A7 for ; Tue, 4 Sep 2012 20:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rhbiGQIxxB8 for ; Tue, 4 Sep 2012 20:00:28 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 59C1D21F84EA for ; Tue, 4 Sep 2012 20:00:27 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 05 Sep 2012 11:00:18 +0800 From: "Linlin Zhou" To: "'Murray S. Kucherawy'" , "'Hollenbeck, Scott'" References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Date: Wed, 5 Sep 2012 11:00:18 +0800 Message-ID: <002b01cd8b12$9527fb30$bf77f190$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2Htd7GNylVY5e5TxG5d2b5ZfBvagDTU9jw Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 03:00:29 -0000 The charter says "...producing a grand unified specification for both numbers and names...". The working approach of unifying the names and numbers makes sense. It can help the names improve the response draft. We have a few comments for the unified response draft. 1. The unified response draft just enumerates and combines the data elements of names and numbers. We think the coders of IP Whois and domain Whois may different. This draft easily makes them confused and asks the readers especially coders to identify which sections belong to names and which sections belong to numbers. Most parts of DNR objects inherit the naming or structure style from RIR response draft. Domain elements may not suitable to be expressed in the numbers way. For example, some elements are not available for names. See section 5.2 DNR domain object. "delegationKeys" : [ { "algorithm": 7, "digest" : "E68C017BD813B9AE2F4DD28E61AD014F859ED44C", "digestType" : 1, "keyTag" : 53814 } ] "uris" : [ ... { "type" : "held", "uri" : "http://example.net/location/xxxx" } ] I wonder why we need keys and location information in domain Whois information. 2. Names don't have consensus on common elements. In the Vancouver meeting, object inventory work just begun and design team for names object selection was asked to be formed by the chair. The element listed in the draft such as "resoldBy", unfortunately I did not find any registry support it in 104 ccTLDs and 18 gTLDs Whois data we collected. There are more than 200 name registries. The common elements selection work is far more complex than RIR. We need time to do this. 3. We suggest a high level structure for the unified response. { registrationObject: { /*common*/ /*unique*/ } registrationObject: { /*common*/ /*unique*/ } } registrationObject may refer to registration , nameserver or contact information. "Common" refers to the common part of names and numbers. "Unique" is the respective unique elements of each other. In our opinion, the unified response draft should focus on the true common elements of numbers and names, not just list them all. The unique elements should be defined by RIR and domain registries separately. We support unified draft + redirection draft + query drafts of RIR/Domain + response drafts of RIR/Domain as working group documents. We are willing to do more further work on object inventory. Hopefully more domain registries will participate in this work to refine our domain common elements. Based on the inventory result and unified approach, we would like to update our domain response draft. Linlin CNNIC > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of > Murray S. Kucherawy > Sent: Saturday, September 01, 2012 4:19 AM > To: Hollenbeck, Scott > Cc: weirds@ietf.org > Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts > > On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott > wrote: > > So, a question for the chairs and group: combined with the "using http" and > redirection drafts, do we now have a set that's ready to become working group > documents? > > Having not yet spoken to Olaf (who is on vacation), my view is that this is in line > with the vision the chairs presented in Vancouver for a path forward. Kudos > to you and Andy for taking this initiative. > > To the WG: I propose that we adopt these as initial working group documents > toward our milestones. Note, as usual, that they are merely starting points > and foci for discussion; we need to develop them and reach working group > consensus before they will be advanced for publication. > > I'll place them in Call For Adoption state now. Please review them and > comment as to whether you believe they are reasonable starting points for > development. > > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From fobispo@isc.org Tue Sep 4 20:11:22 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8349A21F8629 for ; Tue, 4 Sep 2012 20:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3Uu265kfeJK for ; Tue, 4 Sep 2012 20:11:21 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 630D511E808D for ; Tue, 4 Sep 2012 20:11:21 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 488BA5F984C; Wed, 5 Sep 2012 03:11:04 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:470:1f05:1326:444a:38d9:f421:cc5b] (unknown [IPv6:2001:470:1f05:1326:444a:38d9:f421:cc5b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1FC5E216C25; Wed, 5 Sep 2012 03:11:03 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: <002b01cd8b12$9527fb30$bf77f190$@cn> Date: Tue, 4 Sep 2012 20:11:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <195B86F6-50C8-4708-851F-047D14E8004B@isc.org> References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <002b01cd8b12$9527fb30$bf77f190$@cn> To: "Linlin Zhou" X-Mailer: Apple Mail (2.1486) Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 03:11:22 -0000 Hi Linlin, I support your comments, In fact, I had originally suggested to use an enclosure format with = namespace-like attributes to identify registry object regardless whether = they were domain or number elements, that way, number registries could = work on their own object format at the same time that domain registries, = on a common architecture -not a common object format- In addition, I believe that an extension mechanism for the protocol is = necessary to model those unique requirements, specially in the ccTLD = world. This hasn't been addressed as far as I know. Lastly, I also suggested that the response should stand on its own, that = is, if someone wanted to change the transport, or even store the = documents for later use, they could do so without needing the HTTP = headers. I expect to see these suggestions incorporated into the proposal, in the = mean time, I don't believe this is production ready. Francisco On Sep 4, 2012, at 8:00 PM, "Linlin Zhou" wrote: > The charter says "...producing a grand unified specification for both > numbers and names...". The working approach of unifying the names and > numbers makes sense. It can help the names improve the response draft. >=20 > We have a few comments for the unified response draft. >=20 > 1. The unified response draft just enumerates and combines the data = elements > of names and numbers. We think the coders of IP Whois and domain Whois = may > different. This draft easily makes them confused and asks the readers > especially coders to identify which sections belong to names and which > sections belong to numbers.=20 > Most parts of DNR objects inherit the naming or structure style from = RIR > response draft. Domain elements may not suitable to be expressed in = the > numbers way. For example, some elements are not available for names. = See > section 5.2 DNR domain object. >=20 > "delegationKeys" : [ > { > "algorithm": 7, > "digest" : "E68C017BD813B9AE2F4DD28E61AD014F859ED44C", > "digestType" : 1, > "keyTag" : 53814 > } > ] >=20 > "uris" : [ > ... > { > "type" : "held", > "uri" : "http://example.net/location/xxxx" > } > ] > I wonder why we need keys and location information in domain Whois > information. >=20 > 2. Names don't have consensus on common elements.=20 > In the Vancouver meeting, object inventory work just begun and design = team > for names object selection was asked to be formed by the chair. The = element > listed in the draft such as "resoldBy", unfortunately I did not find = any > registry support it in 104 ccTLDs and 18 gTLDs Whois data we = collected.=20 > There are more than 200 name registries. The common elements selection = work > is far more complex than RIR. We need time to do this. >=20 > 3. We suggest a high level structure for the unified response. > { > registrationObject: > { > /*common*/ > /*unique*/ > } > registrationObject: > { > /*common*/ > /*unique*/ > } > } >=20 > registrationObject may refer to registration , nameserver or contact > information. "Common" refers to the common part of names and numbers. > "Unique" is the respective unique elements of each other. >=20 > In our opinion, the unified response draft should focus on the true = common > elements of numbers and names, not just list them all. The unique = elements > should be defined by RIR and domain registries separately. We support > unified draft + redirection draft + query drafts of RIR/Domain + = response > drafts of RIR/Domain as working group documents. >=20 > We are willing to do more further work on object inventory. Hopefully = more > domain registries will participate in this work to refine our domain = common > elements. Based on the inventory result and unified approach, we would = like > to update our domain response draft. >=20 > Linlin > CNNIC >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On = Behalf > Of >> Murray S. Kucherawy >> Sent: Saturday, September 01, 2012 4:19 AM >> To: Hollenbeck, Scott >> Cc: weirds@ietf.org >> Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts >>=20 >> On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott > >> wrote: >>> So, a question for the chairs and group: combined with the "using = http" > and >> redirection drafts, do we now have a set that's ready to become = working > group >> documents? >>=20 >> Having not yet spoken to Olaf (who is on vacation), my view is that = this > is in line >> with the vision the chairs presented in Vancouver for a path forward. > Kudos >> to you and Andy for taking this initiative. >>=20 >> To the WG: I propose that we adopt these as initial working group > documents >> toward our milestones. Note, as usual, that they are merely starting > points >> and foci for discussion; we need to develop them and reach working = group >> consensus before they will be advanced for publication. >>=20 >> I'll place them in Call For Adoption state now. Please review them = and >> comment as to whether you believe they are reasonable starting points = for >> development. >>=20 >> -MSK >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From xiejiagui@cnnic.cn Tue Sep 4 20:29:47 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A74311E80CC for ; Tue, 4 Sep 2012 20:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BgthMR7odj1 for ; Tue, 4 Sep 2012 20:29:46 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 8B5C411E80BA for ; Tue, 4 Sep 2012 20:29:44 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: xiejiagui@cnnic.cn Received: from unknown218.241.111.81 (HELO [218.241.111.81]) (218.241.111.81) by 159.226.7.146 with SMTP; Wed, 05 Sep 2012 11:29:34 +0800 From: Kevin Tse To: Francisco Obispo In-Reply-To: <195B86F6-50C8-4708-851F-047D14E8004B@isc.org> References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <002b01cd8b12$9527fb30$bf77f190$@cn> <195B86F6-50C8-4708-851F-047D14E8004B@isc.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-m86rXQH6nAhQIE5kBIwM" Organization: CNNIC Date: Wed, 05 Sep 2012 11:29:33 +0800 Message-ID: <1346815773.1830.43.camel@zenus> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiejiagui@cnnic.cn List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 03:29:47 -0000 --=-m86rXQH6nAhQIE5kBIwM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francisco,Linlin, I support your comments. The working of unifying NAME and NUMBER makes sense, but except the 'structure' i did not get the 'common' section for both NAME and NUMBER.I wonder why. I think the work of object inventory is still needed until we have consensus on common elements. =20 Kevin. On Tue, 2012-09-04 at 20:11 -0700, Francisco Obispo wrote: > Hi Linlin, >=20 > I support your comments, >=20 > In fact, I had originally suggested to use an enclosure format with names= pace-like attributes to identify registry object regardless whether they we= re domain or number elements, that way, number registries could work on the= ir own object format at the same time that domain registries, on a common a= rchitecture -not a common object format- >=20 > In addition, I believe that an extension mechanism for the protocol is ne= cessary to model those unique requirements, specially in the ccTLD world. T= his hasn't been addressed as far as I know. >=20 > Lastly, I also suggested that the response should stand on its own, that = is, if someone wanted to change the transport, or even store the documents = for later use, they could do so without needing the HTTP headers. >=20 > I expect to see these suggestions incorporated into the proposal, in the = mean time, I don't believe this is production ready. >=20 > Francisco >=20 >=20 >=20 > On Sep 4, 2012, at 8:00 PM, "Linlin Zhou" wrote: >=20 > > The charter says "...producing a grand unified specification for both > > numbers and names...". The working approach of unifying the names and > > numbers makes sense. It can help the names improve the response draft. > >=20 > > We have a few comments for the unified response draft. > >=20 > > 1. The unified response draft just enumerates and combines the data ele= ments > > of names and numbers. We think the coders of IP Whois and domain Whois = may > > different. This draft easily makes them confused and asks the readers > > especially coders to identify which sections belong to names and which > > sections belong to numbers.=20 > > Most parts of DNR objects inherit the naming or structure style from RI= R > > response draft. Domain elements may not suitable to be expressed in the > > numbers way. For example, some elements are not available for names. Se= e > > section 5.2 DNR domain object. > >=20 > > "delegationKeys" : [ > > { > > "algorithm": 7, > > "digest" : "E68C017BD813B9AE2F4DD28E61AD014F859ED44C", > > "digestType" : 1, > > "keyTag" : 53814 > > } > > ] > >=20 > > "uris" : [ > > ... > > { > > "type" : "held", > > "uri" : "http://example.net/location/xxxx" > > } > > ] > > I wonder why we need keys and location information in domain Whois > > information. > >=20 > > 2. Names don't have consensus on common elements.=20 > > In the Vancouver meeting, object inventory work just begun and design t= eam > > for names object selection was asked to be formed by the chair. The ele= ment > > listed in the draft such as "resoldBy", unfortunately I did not find an= y > > registry support it in 104 ccTLDs and 18 gTLDs Whois data we collected.= =20 > > There are more than 200 name registries. The common elements selection = work > > is far more complex than RIR. We need time to do this. > >=20 > > 3. We suggest a high level structure for the unified response. > > { > > registrationObject: > > { > > /*common*/ > > /*unique*/ > > } > > registrationObject: > > { > > /*common*/ > > /*unique*/ > > } > > } > >=20 > > registrationObject may refer to registration , nameserver or contact > > information. "Common" refers to the common part of names and numbers. > > "Unique" is the respective unique elements of each other. > >=20 > > In our opinion, the unified response draft should focus on the true com= mon > > elements of numbers and names, not just list them all. The unique eleme= nts > > should be defined by RIR and domain registries separately. We support > > unified draft + redirection draft + query drafts of RIR/Domain + respon= se > > drafts of RIR/Domain as working group documents. > >=20 > > We are willing to do more further work on object inventory. Hopefully m= ore > > domain registries will participate in this work to refine our domain co= mmon > > elements. Based on the inventory result and unified approach, we would = like > > to update our domain response draft. > >=20 > > Linlin > > CNNIC > >> -----Original Message----- > >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Beha= lf > > Of > >> Murray S. Kucherawy > >> Sent: Saturday, September 01, 2012 4:19 AM > >> To: Hollenbeck, Scott > >> Cc: weirds@ietf.org > >> Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts > >>=20 > >> On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott > > > >> wrote: > >>> So, a question for the chairs and group: combined with the "using htt= p" > > and > >> redirection drafts, do we now have a set that's ready to become workin= g > > group > >> documents? > >>=20 > >> Having not yet spoken to Olaf (who is on vacation), my view is that th= is > > is in line > >> with the vision the chairs presented in Vancouver for a path forward. > > Kudos > >> to you and Andy for taking this initiative. > >>=20 > >> To the WG: I propose that we adopt these as initial working group > > documents > >> toward our milestones. Note, as usual, that they are merely starting > > points > >> and foci for discussion; we need to develop them and reach working gro= up > >> consensus before they will be advanced for publication. > >>=20 > >> I'll place them in Call For Adoption state now. Please review them an= d > >> comment as to whether you believe they are reasonable starting points = for > >> development. > >>=20 > >> -MSK > >> _______________________________________________ > >> weirds mailing list > >> weirds@ietf.org > >> https://www.ietf.org/mailman/listinfo/weirds > >=20 > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds >=20 > Francisco Obispo=20 > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID =3D B38DB1BE >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --=-m86rXQH6nAhQIE5kBIwM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iJsEAAECAAYFAlBGxx0ACgkQatMoyEN1mK8TYwP3WYM8fJ6qxzlqrkchic02LyYz eX0cWsN4pb6j9M8ccvmosHx+5RV5NdfFtfPQjI+ucfNR5UpL5Br+c2bWQdPy+2aj zTQ0zURfdL3p4H/lKAuE35HPkwZ/QkULZdj89Rt7r09geVCt9Slg7/Y01PPFgOW3 tGfyvD2VeiRBtwOo9w== =dgWh -----END PGP SIGNATURE----- --=-m86rXQH6nAhQIE5kBIwM-- From superuser@gmail.com Wed Sep 5 00:03:18 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B672921F8460 for ; Wed, 5 Sep 2012 00:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ+UOA04XBmf for ; Wed, 5 Sep 2012 00:03:18 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E85A721F8453 for ; Wed, 5 Sep 2012 00:03:17 -0700 (PDT) Received: by lahm15 with SMTP id m15so129517lah.31 for ; Wed, 05 Sep 2012 00:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RRRVLzZtLP2AirtsQR9863TjGWS5Fi7SRSY5sSNdcAI=; b=uN7VFkHlVoiWVYU+huKQjIQbrBexiQVgfNuZ0f8gjJ7fE5LzwOtu6ocLFi3dgNkYAw TkfUM7j4vYOR1CvS6sPfZgmcYAllpNbfvI8dSERNhCWZE2fqLzBS8t/p2RC9h2aikR1g B71xu5W2gtbR8Yub/DxKlTJ86gzBiDUYP8F8y/WOxBjLO2jc0Lt1WG+LeJSWg5lB+NwH QRq/VMdGVpvS2bHHNXfGlS5LvjgkTrQLu7XRdouZjq7vrjk/KajSFbI+ci/cvHTVN+tV mw3q2RAetlO6lVBHc0nBkkRcVo75jgvoeYFKPmneoTNcvkqYaOK0H35wB5H91HgXj9iP M5Mg== MIME-Version: 1.0 Received: by 10.112.25.106 with SMTP id b10mr7376455lbg.28.1346828596799; Wed, 05 Sep 2012 00:03:16 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 5 Sep 2012 00:03:16 -0700 (PDT) In-Reply-To: <1346815773.1830.43.camel@zenus> References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <002b01cd8b12$9527fb30$bf77f190$@cn> <195B86F6-50C8-4708-851F-047D14E8004B@isc.org> <1346815773.1830.43.camel@zenus> Date: Wed, 5 Sep 2012 00:03:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: xiejiagui@cnnic.cn Content-Type: text/plain; charset=ISO-8859-1 Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:03:18 -0000 On Tue, Sep 4, 2012 at 8:29 PM, Kevin Tse wrote: > Hi Francisco,Linlin, > > I support your comments. > The working of unifying NAME and NUMBER makes sense, but except the > 'structure' i did not get the 'common' section for both NAME and > NUMBER.I wonder why. > > I think the work of object inventory is still needed until we have > consensus on common elements. Just to be clear: I'm not proposing adoption of these documents as completed working group items, but merely as starting points for working on our deliverables. Working group development would follow, of course. A fairly complete set would appear to be something like: draft-designteam-weirds-using-http draft-hollenbeck-weirds-rdap-sec draft-hollenbeck-weirds-unified-rdap-query draft-newton-weirds-unified-json-response draft-kucherawy-weirds-requirements (but only if we want to keep a requirements document going) The issues of redirection and service discovery don't appear to be covered in this set. I seem to recall consensus ion Vancouver swinging in the direction of deciding that we don't want to tackle discovery on a first pass, but I can't recall where we landed on redirection. (I also admit I haven't yet reviewed the JSON response document to know if it covers redirection.) Please correct me if I'm wrong there. So far response to the middle three has been entirely positive. Can I get some comments on the first and last, and also on the issue of redirection, and a few more comments from people representing the name registries? If there's consensus supporting these as starting point documents, we'll invite the authors to submit them as WG items in another week or so, and then we can get to work. -MSK, WEIRDS co-chair From bje@apnic.net Wed Sep 5 00:26:56 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A48C21F8513 for ; Wed, 5 Sep 2012 00:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtDUt84UE6lJ for ; Wed, 5 Sep 2012 00:26:56 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id B702021F84F6 for ; Wed, 5 Sep 2012 00:26:55 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1] (unknown [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 158E1B68FD; Wed, 5 Sep 2012 17:26:54 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_6CA4C5C6-B117-414A-918B-E96578024805"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Wed, 5 Sep 2012 17:26:53 +1000 Message-Id: <5DDEE74E-FE2F-42FD-AA75-C3AC9BC4FF4E@apnic.net> References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <002b01cd8b12$9527fb30$bf77f190$@cn> <195B86F6-50C8-4708-851F-047D14E8004B@isc.org> <1346815773.1830.43.camel@zenus> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1278) Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:26:56 -0000 --Apple-Mail=_6CA4C5C6-B117-414A-918B-E96578024805 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Murray, On 05/09/2012, at 5:03 PM, Murray S. Kucherawy wrote: > A fairly complete set would appear to be something like: >=20 > draft-designteam-weirds-using-http > draft-hollenbeck-weirds-rdap-sec > draft-hollenbeck-weirds-unified-rdap-query > draft-newton-weirds-unified-json-response > draft-kucherawy-weirds-requirements (but only if we want to keep a > requirements document going) >=20 > The issues of redirection and service discovery don't appear to be > covered in this set. I seem to recall consensus ion Vancouver > swinging in the direction of deciding that we don't want to tackle > discovery on a first pass, but I can't recall where we landed on > redirection. (I also admit I haven't yet reviewed the JSON response > document to know if it covers redirection.) Please correct me if I'm > wrong there. Redirects can be found here: = http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-5= .2 > So far response to the middle three has been entirely positive. Can I > get some comments on the first and last, and also on the issue of > redirection, and a few more comments from people representing the name > registries? I think I missed a call or two here, so to be clear, I support WG = adoption of all five drafts. Regarding redirection, the text in using-http suggests 301 for permanent = relocations, and 307 for all other situations. I am in favour of = specifying only this much about redirection, leaving matters like = authentication to be dealt with by each server-client interaction = separately. Byron --Apple-Mail=_6CA4C5C6-B117-414A-918B-E96578024805 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MDUwNzI2NTRaMCMGCSqGSIb3DQEJBDEWBBTM hti7bc2CW0t1x7OuWuUxxH7J7DCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQBU1Ph+KzHP/2EB 33iXbnHuNJJmGISZZstzyNduoMXJ0AOUZ045xMFNvwNdplZPz4NVhvGnRw8xgqS4N9kERhUWONkc K2BmJSqsBZesSHWzSq9pi682tf5vtbOSvg1dFgF1984fX7E5K/+Mt710/JxfD/iJuExJM9/WXrf4 2p1tZciXTZlZZfajXEb79cpnxAQIrNEHmV0Ln4dRLdZmZHgs0x8OPmgN+/AemU+rlM4mZ84j2GNb vbSQswQv43I94u5epGsB/91Zl9x17q4WiVPHGPpTlVEs0XgFV8SXjxMLvRA5YEaspHRQ7bo3w9Dz +h8VgpXSe2hPMHBfEjduglvqAAAAAAAA --Apple-Mail=_6CA4C5C6-B117-414A-918B-E96578024805-- From bje@apnic.net Wed Sep 5 00:32:21 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B75221F854E for ; Wed, 5 Sep 2012 00:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTZWKL6ByauB for ; Wed, 5 Sep 2012 00:32:20 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 38DDF21F84EB for ; Wed, 5 Sep 2012 00:32:19 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1] (unknown [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 03BFFB68B6; Wed, 5 Sep 2012 17:32:17 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_53AD82EC-6F4C-4CA0-AC24-BC0D8AF581C6"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: <195B86F6-50C8-4708-851F-047D14E8004B@isc.org> Date: Wed, 5 Sep 2012 17:32:17 +1000 Message-Id: <638F88FD-42E0-43DA-A3FA-2F4DB5E15F98@apnic.net> References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <002b01cd8b12$9527fb30$bf77f190$@cn> <195B86F6-50C8-4708-851F-047D14E8004B@isc.org> To: Francisco Obispo X-Mailer: Apple Mail (2.1278) Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:32:21 -0000 --Apple-Mail=_53AD82EC-6F4C-4CA0-AC24-BC0D8AF581C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Francisco, On 05/09/2012, at 1:11 PM, Francisco Obispo wrote: > In addition, I believe that an extension mechanism for the protocol is = necessary to model those unique requirements, specially in the ccTLD = world. This hasn't been addressed as far as I know. The using-http draft hasn't yet been updated to refer to the unified = query and response drafts, but in section 9 there is some text to this = end. = http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-9= > Lastly, I also suggested that the response should stand on its own, = that is, if someone wanted to change the transport, or even store the = documents for later use, they could do so without needing the HTTP = headers. I think that the rdapConformance data structure should achieve this. = The only meta-data in headers is the response code, and the level = attribute of the mime-type; the level information should be replicated = in the rdapConformance information. I agree with your reasoning here, = so if I've missed something that is only stored in the HTTP headers, = please let me know! I will respond to some of Linlin's comments separately. Byron= --Apple-Mail=_53AD82EC-6F4C-4CA0-AC24-BC0D8AF581C6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MDUwNzMyMThaMCMGCSqGSIb3DQEJBDEWBBTO OzOQeEp40V+dUUE0BRrGKd5cNDCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQBzfK/7ybHKWyFc ngmqUVDrh9ZIP7lyxDJUVjJa5OQT0tnbj93MuwcPiyaeeGpjkK0VvCFhYKYteFSqvNi2q33d/P7x n4UgC2ifPqxaauZxfjos9QK45/kVNtEQCkVhHQou3C548C1tBFC52B/ASv53GycxxAySdil40YzA yQJUcefAJjKoMaLqELS6PoS2m+Lph4OOYHKeOMhQP/a0w1tgUKIqqH67nPsWrtvXbyO+rC9UUVLE nfBxhF5orlQHzp46+AaVRy0NFFkLuP+BVkqq0wXbs1PED3kUyzbEPD7DMcO8oyEyyDyHG1ipgDs8 zxWT1OUjImeXeViteVUNocVcAAAAAAAA --Apple-Mail=_53AD82EC-6F4C-4CA0-AC24-BC0D8AF581C6-- From aservin@lacnic.net Wed Sep 5 00:48:54 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D05421F865F for ; Wed, 5 Sep 2012 00:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSFqUsA+VXWr for ; Wed, 5 Sep 2012 00:48:54 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1F621F865C for ; Wed, 5 Sep 2012 00:48:53 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.90]) by mail.lacnic.net.uy (Postfix) with ESMTP id DA512308424; Wed, 5 Sep 2012 04:48:48 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_27706554-B6D5-4199-8BE9-C0732C4D90F4" From: Arturo Servin In-Reply-To: Date: Wed, 5 Sep 2012 08:48:40 +0100 Message-Id: <3737FD10-1816-4846-BB09-310D2D78A316@lacnic.net> References: To: "" X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:48:54 -0000 --Apple-Mail=_27706554-B6D5-4199-8BE9-C0732C4D90F4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Support. Regards, as On 4 Sep 2012, at 22:21, Andy Newton wrote: > On 8/31/12 4:18 PM, "Murray S. Kucherawy" wrote: > >> On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott >> wrote: >>> So, a question for the chairs and group: combined with the "using http" >>> and redirection drafts, do we now have a set that's ready to become >>> working group documents? >> >> Having not yet spoken to Olaf (who is on vacation), my view is that >> this is in line with the vision the chairs presented in Vancouver for >> a path forward. Kudos to you and Andy for taking this initiative. >> >> To the WG: I propose that we adopt these as initial working group >> documents toward our milestones. Note, as usual, that they are merely >> starting points and foci for discussion; we need to develop them and >> reach working group consensus before they will be advanced for >> publication. >> >> I'll place them in Call For Adoption state now. Please review them >> and comment as to whether you believe they are reasonable starting >> points for development. >> >> -MSK >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > --Apple-Mail=_27706554-B6D5-4199-8BE9-C0732C4D90F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = Support.

Regards,
as

On 4 Sep 2012, at 22:21, Andy Newton wrote:

On 8/31/12 = 4:18 PM, "Murray S. Kucherawy" <superuser@gmail.com> = wrote:

On Fri, Aug 31, 2012 at 5:35 AM, = Hollenbeck, Scott
<shollenbeck@verisign.com> = wrote:
So, a question for the chairs and group: combined with the = "using http"
and redirection drafts, do we = now have a set that's ready to = become
working group = documents?

Having not yet = spoken to Olaf (who is on vacation), my view is = that
this is in line with the = vision the chairs presented in Vancouver for
a path forward.  Kudos to you and Andy for taking = this initiative.

To the WG: I = propose that we adopt these as initial working = group
documents toward our = milestones.  Note, as usual, that they are = merely
starting points and = foci for discussion; we need to develop them = and
reach working group = consensus before they will be advanced for
publication.

I'll place them = in Call For Adoption state now.  Please review = them
and comment as to whether = you believe they are reasonable starting
points for development.

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


= --Apple-Mail=_27706554-B6D5-4199-8BE9-C0732C4D90F4-- From bje@apnic.net Wed Sep 5 00:49:46 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4B121F8540 for ; Wed, 5 Sep 2012 00:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+6KGdnMuXtG for ; Wed, 5 Sep 2012 00:49:45 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id DE37321F84AE for ; Wed, 5 Sep 2012 00:49:44 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1] (unknown [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A41BDB6867; Wed, 5 Sep 2012 17:49:43 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_CA628417-E98A-46C4-8077-ECBB30E17EE3"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: <002b01cd8b12$9527fb30$bf77f190$@cn> Date: Wed, 5 Sep 2012 17:49:43 +1000 Message-Id: <23C3F8BD-0A07-4F23-BEC4-9F20BD44F4A4@apnic.net> References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <002b01cd8b12$9527fb30$bf77f190$@cn> To: Linlin Zhou X-Mailer: Apple Mail (2.1278) Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:49:46 -0000 --Apple-Mail=_CA628417-E98A-46C4-8077-ECBB30E17EE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Linlin, On 05/09/2012, at 1:00 PM, Linlin Zhou wrote: > We have a few comments for the unified response draft. > Most parts of DNR objects inherit the naming or structure style from = RIR > response draft. Domain elements may not suitable to be expressed in = the > numbers way. For example, some elements are not available for names. = See > section 5.2 DNR domain object. All elements of the response are optional, at the server's discretion. > I wonder why we need keys and location information in domain Whois > information. If you do not need or have or want to publish that information, then = omit it. You might need DNSSEC keys if you support DNSSEC for your = domains, though. APNIC does not currently have HELD location = information, and would not include a "held" type link in a response. > 2. Names don't have consensus on common elements.=20 > In the Vancouver meeting, object inventory work just begun and design = team > for names object selection was asked to be formed by the chair. The = element > listed in the draft such as "resoldBy", unfortunately I did not find = any > registry support it in 104 ccTLDs and 18 gTLDs Whois data we = collected.=20 > There are more than 200 name registries. The common elements selection = work > is far more complex than RIR. We need time to do this. I would be very interested to see what common elements are not = represented in the unified response draft. Part of it may depend on = what you mean by "common," but I think the draft is really quite = flexible in what it allows - any type of entity may be represented, = because the "type" attribute is an array of strings, with no explicit = enumeration of what is and is not allowed. > 3. We suggest a high level structure for the unified response. > { > registrationObject: > { > /*common*/ > /*unique*/ > } > registrationObject: > { > /*common*/ > /*unique*/ > } > } How does this relate to the query issued? The proposed unified query = syntax asks that the user explicitly fetch a specific resource, such as = http://rdap.example.com/domain/example.com/ - would you envisage the = returned response being a collection of objects related to that domain? What's the advantage you see in returning a set of objects in the top = level of the structure, instead of returning a domain object containing = other objects as necessary? What's the advantage, moreover, in having = different structures for domains and numbers? > In our opinion, the unified response draft should focus on the true = common > elements of numbers and names, not just list them all. The unique = elements > should be defined by RIR and domain registries separately. We support > unified draft + redirection draft + query drafts of RIR/Domain + = response > drafts of RIR/Domain as working group documents. I'm sorry, I'm not sure I understand what you're trying to say here. = What do you mean by "true common elements" and "unique elements" ? What = do you mean by "unified draft" - is this the using-http draft? What do = you expect to see in a redirection draft, beyond just "301/307 Location = header" ? And finally, do you expect to see a separate query draft for = each of RIRs and DNRs, and a separate response draft for each of RIRs = and DNRs? > We are willing to do more further work on object inventory. Hopefully = more > domain registries will participate in this work to refine our domain = common > elements. Based on the inventory result and unified approach, we would = like > to update our domain response draft. I would like to see your object inventory work progressed, and if = possible, submitted as an informational draft. Helping people who come = later understand how we arrive at our eventual conclusion will be = useful. Having clarity on whether there's any object data that's not = represented in the unified response draft, and how common that object = data is, would be very useful. >=20 > Linlin > CNNIC >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On = Behalf > Of >> Murray S. Kucherawy >> Sent: Saturday, September 01, 2012 4:19 AM >> To: Hollenbeck, Scott >> Cc: weirds@ietf.org >> Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts >>=20 >> On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott > >> wrote: >>> So, a question for the chairs and group: combined with the "using = http" > and >> redirection drafts, do we now have a set that's ready to become = working > group >> documents? >>=20 >> Having not yet spoken to Olaf (who is on vacation), my view is that = this > is in line >> with the vision the chairs presented in Vancouver for a path forward. > Kudos >> to you and Andy for taking this initiative. >>=20 >> To the WG: I propose that we adopt these as initial working group > documents >> toward our milestones. Note, as usual, that they are merely starting > points >> and foci for discussion; we need to develop them and reach working = group >> consensus before they will be advanced for publication. >>=20 >> I'll place them in Call For Adoption state now. Please review them = and >> comment as to whether you believe they are reasonable starting points = for >> development. >>=20 >> -MSK >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --=20 Byron Ellacott email: bje@apnic.net Technical Director, APNIC sip: bje@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary. --Apple-Mail=_CA628417-E98A-46C4-8077-ECBB30E17EE3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MDUwNzQ5NDRaMCMGCSqGSIb3DQEJBDEWBBQ1 aq2D0qvW2feKXnqBYl6iTtwVRjCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQAsG+JlxWkLUhrb YV5hDYS0KYRAgf5553l9FMU7RxfrbKT3loKHS0avjF//jmodc42Bmr1IOViXxy63u3AvbX0tQOCV SAe31lpTOygB7QldsgcSTRuQmG3XS8z/XwlbU/IxfPxsq+n6KqKPB/klRlpsa5Cbw5BKZrt57aMC C9D3A+7JAh9I7BIX2K8ISFU14iuIZs/UqjqbmHKnYwhQhM7Rvf7ThOrFZ9Ov1e9ukE0zz+z0tmwA F4STcXhextXOpfYfaRyLNGLlRuFqVIY8Cq70+QDA9T43yx+Ib2iGNdj0E+hLTsq1P9Wrlq5seYrq X2lECa6Fug5Lu40QW2RTnipCAAAAAAAA --Apple-Mail=_CA628417-E98A-46C4-8077-ECBB30E17EE3-- From xiejiagui@cnnic.cn Wed Sep 5 00:55:40 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE52421F866C for ; Wed, 5 Sep 2012 00:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.254 X-Spam-Level: *** X-Spam-Status: No, score=3.254 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn1pAZNzxD+o for ; Wed, 5 Sep 2012 00:55:37 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 76ED621F8668 for ; Wed, 5 Sep 2012 00:55:35 -0700 (PDT) Received: from 159.226.45.118 by mail.cnnic.cn with HTTP; Wed, 05 Sep 2012 15:55:22 +0800 X-WebMAIL-MUA: [159.226.45.118] X-eYou-Client: 159.226.45.118 From: "=?gb2312?B?0Lu80rnz?=" To: superuser@gmail.com, fobispo@isc.org, weirds@ietf.org Date: Wed, 05 Sep 2012 15:55:22 +0800 Message-ID: X-Priority: 3 X-Mailer: eYou MUA Subsystem 4.1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?gb2312?B?0Lu80rnz?= List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:55:40 -0000 SGVsbG8gS3VjaGVyYXd5LA0KDQo+U28gZmFyIHJlc3BvbnNlIHRvIHRoZSBtaWRkbGUgdGhy ZWUgaGFzIGJlZW4gZW50aXJlbHkgcG9zaXRpdmUuIA0KSSBkbyBub3QgdGhpbmsgc28uIElN TywgbW9zdCBvZiB0aGUgcG9zaXRpdmUgZmVlZGJhY2tzIGFyZSBmcm9tIG51bWJlciBndXlz LlNvIGZhcixtb3N0IGZlZWRiYWNrcyBmcm9tIG5hbWUgZ3V5cywgc3VjaCBhcyBMaW5saW4s IEZyYW5jaXNjbyBhbmQgbXlzZWxmLCANCnNob3cgdGhhdCBhdCBsZWFzdCB0aGUgZHJhZnQt bmV3dG9uLXdlaXJkcy11bmlmaWVkLWpzb24tcmVzcG9uc2UgaXMgbm90IHN1aXRhYmxlIGFz IHRoZSBzdGFydGluZyBwb2ludCBmb3Igd29ya2luZyBvbiBvdXIgd2VpcmRzIHJlc3BvbnNl IGRlbGl2ZXJhYmxlcy4gTW9yZSBkZXRhaWxlZCBleHBsYW5hdGlvbnMsIHBsZWFzZSByZWZl ciB0byBMaW5saW4gWmhvdSBhbmQgRnJhbmNpc2NvIE9iaXNwbydzIG1haWxzLg0KDQpLZXZp bi4= From superuser@gmail.com Wed Sep 5 01:39:17 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9924721F86BA for ; Wed, 5 Sep 2012 01:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-1.575, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5RaUUoEitMp for ; Wed, 5 Sep 2012 01:39:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF34321F86B9 for ; Wed, 5 Sep 2012 01:39:12 -0700 (PDT) Received: by lbky2 with SMTP id y2so247687lbk.31 for ; Wed, 05 Sep 2012 01:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=q/aPhQGOcZIi4XDkx2l3yltukh3rA2GRwo+axbC0VHY=; b=zavKU2xl6oUNnyiYLTCT0Uw3mKdj/VmfjXDAoJQmjRtw/X9hv/qOv+FbuYBtpmfcjM WPAy4GX/U1y8kA1L912LZVUhZkM3Kkh/3I/DqEx/6FeS6oOtod9LNybK1twh0Ye+a5xM JHw4aihCk7CppVemdBUeuTFBgG0k1AMQqmcKG2KvW+BeOkHOOSrxnf4AnARuF81TS+Q0 pDySMnH9GAFei1Nn1+Pj8Aikxv6ZErausw0Ya2aKTuaBq47OXaVCD0VJ/2WHOAkkW75g SpPwe0WgEvVgQ5exaTnIk4U9N6uOJ9NZ38uRcQ4DL3IHgdXWEKY60iplNMf46Veti6dy ZQjA== MIME-Version: 1.0 Received: by 10.152.148.1 with SMTP id to1mr19295030lab.34.1346834351632; Wed, 05 Sep 2012 01:39:11 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 5 Sep 2012 01:39:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Sep 2012 01:39:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: =?GB2312?B?0Lu80rnz?= Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 08:39:17 -0000 On Wed, Sep 5, 2012 at 12:55 AM, =D0=BB=BC=D2=B9=F3 wr= ote: >>So far response to the middle three has been entirely positive. > > I do not think so. IMO, most of the positive feedbacks are from number gu= ys.So far,most feedbacks from name guys, such as Linlin, Francisco and myse= lf, > show that at least the draft-newton-weirds-unified-json-response is not s= uitable as the starting point for working on our weirds response deliverabl= es. More detailed explanations, please refer to Linlin Zhou and Francisco O= bispo's mails. Linlin's comments, with which Francisco concurred, did not include objection, merely feedback. Can you explain why this document is not even suitable as a starting point for work? -MSK From xiejiagui@cnnic.cn Wed Sep 5 02:30:39 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895D621F8624 for ; Wed, 5 Sep 2012 02:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V39r8hbGy-Z for ; Wed, 5 Sep 2012 02:30:39 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id A501821F855F for ; Wed, 5 Sep 2012 02:30:36 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: xiejiagui@cnnic.cn Received: from unknown218.241.111.81 (HELO [218.241.111.81]) (218.241.111.81) by 159.226.7.146 with SMTP; Wed, 05 Sep 2012 17:30:28 +0800 From: Kevin Tse To: "Murray S. Kucherawy" In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-F5jeAAyYB5y60yEBSmRR" Organization: CNNIC Date: Wed, 05 Sep 2012 17:30:26 +0800 Message-ID: <1346837426.1830.59.camel@zenus> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiejiagui@cnnic.cn List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 09:30:39 -0000 --=-F5jeAAyYB5y60yEBSmRR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, --=20 Kevin Tse CNNIC On Wed, 2012-09-05 at 01:39 -0700, Murray S. Kucherawy wrote: > Linlin's comments, with which Francisco concurred, did not include > objection, merely feedback. >=20 > Can you explain why this document is not even suitable as a starting > point for work? Firstly speaking,we already have two response documents for both RIR(draft-newton-et-al-weirds-rir-json-response-00) and DNR.(draft-kong-dnrd-ap-response-json-00). Secondly,this document should act as the role to help both the names and numbers improve the response drafts synchronous. Kevin. >=20 > -MSK --=-F5jeAAyYB5y60yEBSmRR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAAECAAYFAlBHG7IACgkQatMoyEN1mK8lCQP/R+uDYpyvtmsChzdknisxrDzK cMdoB8f+Mol5xEXWHMV6s6WmkqsjkIR7jGrSwrkzJmMnwN+XLU17DsSZDPqdYVPy QQ5H7SRWYw/8mMVHderahoPIyB+kuDPU6KjcG+e2RRJ3/YWhrofnXEwFyxVJO4Pn 3F77Cg2gA35N1mXS6Ro= =jI9h -----END PGP SIGNATURE----- --=-F5jeAAyYB5y60yEBSmRR-- From zhoulinlin@cnnic.cn Wed Sep 5 02:44:45 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB2821F84FC for ; Wed, 5 Sep 2012 02:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsnCscn-sIRw for ; Wed, 5 Sep 2012 02:44:44 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 4C53E21F8445 for ; Wed, 5 Sep 2012 02:44:43 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 05 Sep 2012 17:44:36 +0800 From: "Linlin Zhou" To: "'Byron Ellacott'" References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <002b01cd8b12$9527fb30$bf77f190$@cn> <23C3F8BD-0A07-4F23-BEC4-9F20BD44F4A4@apnic.net> In-Reply-To: <23C3F8BD-0A07-4F23-BEC4-9F20BD44F4A4@apnic.net> Date: Wed, 5 Sep 2012 17:44:35 +0800 Message-ID: <007001cd8b4b$0f282670$2d787350$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2LOwUwZ7AW0TuAQsKdIVm9cY+NZQAAom2Q Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 09:44:45 -0000 Hello Byron, My comments are embedded. > > Most parts of DNR objects inherit the naming or structure style from RIR > > response draft. Domain elements may not suitable to be expressed in the > > numbers way. For example, some elements are not available for names. See > > section 5.2 DNR domain object. > > All elements of the response are optional, at the server's discretion. > We absolutely understand they may be optional. Our key point is some RIR elements, which are not useful for names, should not be included in the DNR objects. Vice versa, it does not make sense that the DNR elements like "registrar" should be included in the RIR objects, even if these elements are optional. > I would be very interested to see what common elements are not represented > in the unified response draft. Me too. I am also very interested to see what common elements are not represented in the name response draft (draft-kong-dnrd-ap-response-json). Based on our current whois data collection result, there are 392 self-designed elements in different name registries. I believe that there should be a few common elements among the 392 items which are still not clear. It's hard for us to get answers before finishing the object inventory work. >Part of it may depend on what you mean by > "common," but I think the draft is really quite flexible in what it allows - any > type of entity may be represented, because the "type" attribute is an array of > strings, with no explicit enumeration of what is and is not allowed. > I think the most difficult work for us is to define the common elements and structure. To be flexible is relatively easy. I also think our draft is quite flexible to be extended. > > 3. We suggest a high level structure for the unified response. > > { > > registrationObject: > > { > > /*common*/ > > /*unique*/ > > } > > registrationObject: > > { > > /*common*/ > > /*unique*/ > > } > > } > > How does this relate to the query issued? The proposed unified query syntax > asks that the user explicitly fetch a specific resource, such as > http://rdap.example.com/domain/example.com/ - would you envisage the > returned response being a collection of objects related to that domain? > > What's the advantage you see in returning a set of objects in the top level of > the structure, instead of returning a domain object containing other objects as > necessary? What's the advantage, moreover, in having different structures > for domains and numbers? > I think you misunderstood my point. The registrationObject is based on nested structure. The common and unique parts are logical concept. Both of these two parts can include nested objects or elements. The unified response draft should only focus on the common part, while the unique part should "stand on its own" by names or numbers. > > In our opinion, the unified response draft should focus on the true common > > elements of numbers and names, not just list them all. The unique elements > > should be defined by RIR and domain registries separately. We support > > unified draft + redirection draft + query drafts of RIR/Domain + response > > drafts of RIR/Domain as working group documents. > > I'm sorry, I'm not sure I understand what you're trying to say here. What do > you mean by "true common elements" and "unique elements" ? What do you > mean by "unified draft" - is this the using-http draft? What do you expect to > see in a redirection draft, beyond just "301/307 Location header" ? And finally, > do you expect to see a separate query draft for each of RIRs and DNRs, and a > separate response draft for each of RIRs and DNRs? > My mainly concern is the response drafts. I think draft-newton-weirds-unified-json-response and separated response drafts by RIR and DNR (draft-newton-et-al-weirds-rir-json-response and draft-kong-dnrd-ap-response-json) should be the starting points for the WG. > I would like to see your object inventory work progressed, and if possible, > submitted as an informational draft. Helping people who come later > understand how we arrive at our eventual conclusion will be useful. Having > clarity on whether there's any object data that's not represented in the unified > response draft, and how common that object data is, would be very useful. > Agreed. Thanks for your comments. > > Linlin From aservin@lacnic.net Wed Sep 5 03:13:04 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2160421F86A4 for ; Wed, 5 Sep 2012 03:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g67Syo8Ys4GT for ; Wed, 5 Sep 2012 03:13:03 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC8A21F8575 for ; Wed, 5 Sep 2012 03:13:03 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.90]) by mail.lacnic.net.uy (Postfix) with ESMTP id 11C43308432; Wed, 5 Sep 2012 07:12:56 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <007001cd8b4b$0f282670$2d787350$@cn> Date: Wed, 5 Sep 2012 11:12:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <002b01cd8b12$9527fb30$bf77f190$@cn> <23C3F8BD-0A07-4F23-BEC4-9F20BD44F4A4@apnic.net> <007001cd8b4b$0f282670$2d787350$@cn> To: "Linlin Zhou" X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 10:13:04 -0000 Linlin, On 5 Sep 2012, at 10:44, Linlin Zhou wrote: > Hello Byron, >=20 > My comments are embedded. >=20 >>> Most parts of DNR objects inherit the naming or structure style from = RIR >>> response draft. Domain elements may not suitable to be expressed in = the >>> numbers way. For example, some elements are not available for names. = See >>> section 5.2 DNR domain object. >>=20 >> All elements of the response are optional, at the server's = discretion. >>=20 > We absolutely understand they may be optional.=20 > Our key point is some RIR elements, which are not useful for names, = should > not be included in the DNR objects. > Vice versa, it does not make sense that the DNR elements like = "registrar" > should be included in the RIR objects, even if these elements are = optional. The trade-off is to have more documents and some of those with = only one or two elements. I prefer just one document with optional = elements that may be common. >=20 >> I would be very interested to see what common elements are not = represented >> in the unified response draft. =20 >=20 > Me too. I am also very interested to see what common elements are not > represented in the name response draft = (draft-kong-dnrd-ap-response-json). > Based on our current whois data collection result, there are 392 > self-designed elements in different name registries. I believe that = there > should be a few common elements among the 392 items which are still = not > clear. It's hard for us to get answers before finishing the object = inventory > work. If you find one that it is very common to names, we can include = it. This is a WG call for adoption, not for publishing, so there is a = lot of room to add more objects if we found and agree on them. >=20 >> Part of it may depend on what you mean by >> "common," but I think the draft is really quite flexible in what it = allows > - any >> type of entity may be represented, because the "type" attribute is an > array of >> strings, with no explicit enumeration of what is and is not allowed. >>=20 > I think the most difficult work for us is to define the common = elements and > structure. To be flexible is relatively easy. I also think our draft = is > quite flexible to be extended. >=20 >>> 3. We suggest a high level structure for the unified response. >>> { >>> registrationObject: >>> { >>> /*common*/ >>> /*unique*/ >>> } >>> registrationObject: >>> { >>> /*common*/ >>> /*unique*/ >>> } >>> } I think that this is more complex for users. >=20 >>> In our opinion, the unified response draft should focus on the true > common >>> elements of numbers and names, not just list them all. The unique > elements >>> should be defined by RIR and domain registries separately. We = support >>> unified draft + redirection draft + query drafts of RIR/Domain + > response >>> drafts of RIR/Domain as working group documents. >>=20 >> I'm sorry, I'm not sure I understand what you're trying to say here. = What > do >> you mean by "true common elements" and "unique elements" ? What do = you >> mean by "unified draft" - is this the using-http draft? What do you > expect to >> see in a redirection draft, beyond just "301/307 Location header" ? = And > finally, >> do you expect to see a separate query draft for each of RIRs and = DNRs, and > a >> separate response draft for each of RIRs and DNRs? >>=20 > My mainly concern is the response drafts. I think > draft-newton-weirds-unified-json-response and separated response = drafts by > RIR and DNR (draft-newton-et-al-weirds-rir-json-response and > draft-kong-dnrd-ap-response-json) should be the starting points for = the WG. That was the original idea but we decided (the WG and chairs) = other approach in Vancouver. You could use draft-kong-dnrd-ap-response-json/query to extend = the common objects or if they are very common in names and the WG agrees = we could add it to draft-hollenbeck-weirds-unified-rdap-query. Regards, as= From zhoulinlin@cnnic.cn Wed Sep 5 03:24:52 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FD321F8620 for ; Wed, 5 Sep 2012 03:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6fpTUhniC9o for ; Wed, 5 Sep 2012 03:24:48 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id CABE421F85ED for ; Wed, 5 Sep 2012 03:24:47 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 05 Sep 2012 18:24:30 +0800 From: "Linlin Zhou" To: "'Murray S. Kucherawy'" , =?gb2312?B?J9C7vNK58yc=?= References: In-Reply-To: Date: Wed, 5 Sep 2012 18:24:29 +0800 Message-ID: <007101cd8b50$a25f1fc0$e71d5f40$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2LQfQ3p3fhhztDRjCcF8RIFrUhywACY5eA Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 10:24:52 -0000 Hello Murray, > > I do not think so. IMO, most of the positive feedbacks are from number > > guys.So far,most feedbacks from name guys, such as Linlin, Francisco and > myself, show that at least the draft-newton-weirds-unified-json-response is > not suitable as the starting point for working on our weirds response > deliverables. More detailed explanations, please refer to Linlin Zhou and > Francisco Obispo's mails. > > Linlin's comments, with which Francisco concurred, did not include objection, > merely feedback. > Actually my feedback is not positive. > Can you explain why this document is not even suitable as a starting point for > work? > We already have two separated response drafts by RIR and DNR. These two drafts have been reviewed and improved by the design team and the working group. A lot of efforts are made for response drafts. So I think these drafts are definitely worth to be the starting points for working on our weirds response deliverables. IMO, the substantial key point for us is to coordinate the RIR draft with the DNR draft, not to have a nominal unified document. So my strong suggestion is adopting the following two drafts as working group documents. draft-newton-et-al-weirds-rir-json-response draft-kong-dnrd-ap-response-json In the same time, I don't think it's necessary to adopt draft-newton-weirds-unified-json-response as WG document. It's better to be informational reference document to help us coordinate the RIR response draft with DNR's. From aservin@lacnic.net Wed Sep 5 03:36:37 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386C021F86AD for ; Wed, 5 Sep 2012 03:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_34=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB+e57Tqe2Ng for ; Wed, 5 Sep 2012 03:36:33 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1A721F8694 for ; Wed, 5 Sep 2012 03:36:33 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.90]) by mail.lacnic.net.uy (Postfix) with ESMTP id 695C530844C; Wed, 5 Sep 2012 07:36:16 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <007101cd8b50$a25f1fc0$e71d5f40$@cn> Date: Wed, 5 Sep 2012 11:36:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A75247F-AEF5-4A2D-A45A-C5786C39AD21@lacnic.net> References: <007101cd8b50$a25f1fc0$e71d5f40$@cn> To: Linlin Zhou X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 10:36:37 -0000 Linlin, As mentioned, in Vancouver the WG chose to go in another = direction for the object inventory, I suppose that applies for query and = response. /as On 5 Sep 2012, at 11:24, Linlin Zhou wrote: > Hello Murray, >>> I do not think so. IMO, most of the positive feedbacks are from = number >>> guys.So far,most feedbacks from name guys, such as Linlin, Francisco = and >> myself, show that at least the = draft-newton-weirds-unified-json-response > is >> not suitable as the starting point for working on our weirds response >> deliverables. More detailed explanations, please refer to Linlin Zhou = and >> Francisco Obispo's mails. >>=20 >> Linlin's comments, with which Francisco concurred, did not include > objection, >> merely feedback. >>=20 > Actually my feedback is not positive. >=20 >> Can you explain why this document is not even suitable as a starting = point > for >> work? >>=20 > We already have two separated response drafts by RIR and DNR. These = two > drafts have been reviewed and improved by the design team and the = working > group. A lot of efforts are made for response drafts. So I think = these > drafts are definitely worth to be the starting points for working on = our > weirds response > deliverables. IMO, the substantial key point for us is to coordinate = the RIR > draft with the DNR draft, not to=20 > have a nominal unified document. >=20 > So my strong suggestion is adopting the following two drafts as = working > group documents. >=20 > draft-newton-et-al-weirds-rir-json-response > draft-kong-dnrd-ap-response-json >=20 > In the same time, I don't think it's necessary to adopt > draft-newton-weirds-unified-json-response as WG document. It's better = to be > informational reference document to help us coordinate the RIR = response > draft with DNR's. >=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From shollenbeck@verisign.com Wed Sep 5 04:00:54 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B5321F86C8 for ; Wed, 5 Sep 2012 04:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-vndot7Cfqc for ; Wed, 5 Sep 2012 04:00:54 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8321F847A for ; Wed, 5 Sep 2012 04:00:52 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUEcw48Tc8xRlDaRTH+jT1BN2dJ8mNC1d@postini.com; Wed, 05 Sep 2012 04:00:54 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q85B0ldX011152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Sep 2012 07:00:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Wed, 5 Sep 2012 07:00:46 -0400 From: "Hollenbeck, Scott" To: "xiejiagui@cnnic.cn" Thread-Topic: [weirds] New Unified DNR/RIR Internet-Drafts Thread-Index: AQHNizvMEFIzkQxfBUOgtYDEIz6325d7sG6AgAAOUQD//9U9kA== Date: Wed, 5 Sep 2012 11:00:46 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D67845F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <1346837426.1830.59.camel@zenus> In-Reply-To: <1346837426.1830.59.camel@zenus> 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 Cc: "weirds@ietf.org" Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 11:00:54 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB3ZWlyZHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOndlaXJkcy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgS2V2 aW4gVHNlDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDA1LCAyMDEyIDU6MzAgQU0NCj4g VG86IE11cnJheSBTLiBLdWNoZXJhd3kNCj4gQ2M6IHdlaXJkc0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW3dlaXJkc10gTmV3IFVuaWZpZWQgRE5SL1JJUiBJbnRlcm5ldC1EcmFmdHMNCj4gDQo+ IEhlbGxvLA0KPiAtLQ0KPiBLZXZpbiBUc2UgPHhpZWppYWd1aUBjbm5pYy5jbj4NCj4gQ05OSUMN Cj4gDQo+IE9uIFdlZCwgMjAxMi0wOS0wNSBhdCAwMTozOSAtMDcwMCwgTXVycmF5IFMuIEt1Y2hl cmF3eSB3cm90ZToNCj4gPiBMaW5saW4ncyBjb21tZW50cywgd2l0aCB3aGljaCBGcmFuY2lzY28g Y29uY3VycmVkLCBkaWQgbm90IGluY2x1ZGUNCj4gPiBvYmplY3Rpb24sIG1lcmVseSBmZWVkYmFj ay4NCj4gPg0KPiA+IENhbiB5b3UgZXhwbGFpbiB3aHkgdGhpcyBkb2N1bWVudCBpcyBub3QgZXZl biBzdWl0YWJsZSBhcyBhIHN0YXJ0aW5nDQo+ID4gcG9pbnQgZm9yIHdvcms/DQo+IEZpcnN0bHkg c3BlYWtpbmcsd2UgYWxyZWFkeSBoYXZlIHR3byByZXNwb25zZSBkb2N1bWVudHMgZm9yIGJvdGgN Cj4gUklSKGRyYWZ0LW5ld3Rvbi1ldC1hbC13ZWlyZHMtcmlyLWpzb24tcmVzcG9uc2UtMDApIGFu ZCBETlIuKGRyYWZ0LQ0KPiBrb25nLWRucmQtYXAtcmVzcG9uc2UtanNvbi0wMCkuDQoNCk5laXRo ZXIgb2YgdGhlc2UgdHdvIGRvY3VtZW50cyBhdHRlbXB0cyB0byBzcGVjaWZ5IGEgdW5pZmllZCBu YW1lcy9udW1iZXJzIGFwcHJvYWNoLiBUaGV5IHdlcmUgZ29vZCBzdGFydGluZyBwb2ludHMgdG8g Y2FwdHVyZSBpZGVhcyBhbmQgcHJvbW90ZSBkaXNjdXNzaW9uLCBidXQgdGhleSBhcmUgZXZvbHV0 aW9uYXJ5IGRlYWQgZW5kcy4NCg0KPiBTZWNvbmRseSx0aGlzIGRvY3VtZW50IHNob3VsZCBhY3Qg YXMgdGhlIHJvbGUgdG8gaGVscCBib3RoIHRoZSBuYW1lcw0KPiBhbmQgbnVtYmVycyBpbXByb3Zl IHRoZSByZXNwb25zZSBkcmFmdHMgc3luY2hyb25vdXMuDQoNClRoYXQncyBleGFjdGx5IHdoYXQg d2UncmUgdHJ5aW5nIHRvIGRvIHdpdGggZHJhZnQtbmV3dG9uLXdlaXJkcy11bmlmaWVkLWpzb24t cmVzcG9uc2UuDQoNClNjb3R0DQo= From shollenbeck@verisign.com Wed Sep 5 04:11:29 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E3021F84E2 for ; Wed, 5 Sep 2012 04:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Cp8662Wqlos for ; Wed, 5 Sep 2012 04:11:25 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id D9DBA21F84D7 for ; Wed, 5 Sep 2012 04:11:24 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUEczXOxhh14+oQqZK/f0sKcMiZVv0BKY@postini.com; Wed, 05 Sep 2012 04:11:24 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q85BBI2R011462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Sep 2012 07:11:22 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Wed, 5 Sep 2012 07:11:05 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] New Unified DNR/RIR Internet-Drafts Thread-Index: AQHNizvMEFIzkQxfBUOgtYDEIz6325d7libA Date: Wed, 5 Sep 2012 11:11:18 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6784B5@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 Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 11:11:29 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of ??? > Sent: Wednesday, September 05, 2012 3:55 AM > To: superuser@gmail.com; fobispo@isc.org; weirds@ietf.org > Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts >=20 > Hello Kucherawy, >=20 > >So far response to the middle three has been entirely positive. > I do not think so. IMO, most of the positive feedbacks are from number > guys.So far,most feedbacks from name guys, such as Linlin, Francisco > and myself, show that at least the draft-newton-weirds-unified-json- > response is not suitable as the starting point for working on our > weirds response deliverables. More detailed explanations, please refer > to Linlin Zhou and Francisco Obispo's mails. This names person supports the proposed "unified" approach. If the new unif= ied response draft isn't quite right (no one should expect a -00 draft to b= e perfect), it can be modified. Scott From superuser@gmail.com Wed Sep 5 07:00:17 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9A621F8508 for ; Wed, 5 Sep 2012 07:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNTTVh-ye6FB for ; Wed, 5 Sep 2012 07:00:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 434E221F8468 for ; Wed, 5 Sep 2012 07:00:16 -0700 (PDT) Received: by lahm15 with SMTP id m15so419983lah.31 for ; Wed, 05 Sep 2012 07:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A1kInaB2dRnFgDE9DSyQgf3YP7bLFl89/8tilUqLJ3M=; b=h+YeH5RGTe1N6YCrJxTTDkC69zVSGR0eRg20wSz4cVf1icAYtE3BgQJmynAQ3GX7FX 1Z0RTUA1BCN0tSPcJlQW/WMR7FFaZ+XM2vbEOSl+dRP8xk+G8e++Wz6Pz5wojU7PKtMF kSI28cr+UXaxuvfbJ1LH3fqlgYIbBKiBgaZsqkIlduUVoDhknQTh+m65HipK+NP04AfP KRiBZx3MI/aoQJT17gddwEh0QNgbo3E4SozuM9TY4coLrdub0/JFby6bNUD1wTjOTx5H jpEHzbd/rHwRh1VL9GV643UvQuCaZ8dEHscxEGVcKWV43pkgJFOcW85nsP6ZPfMObeD3 JiNQ== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr7839984lbh.85.1346853614782; Wed, 05 Sep 2012 07:00:14 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 5 Sep 2012 07:00:14 -0700 (PDT) In-Reply-To: <007101cd8b50$a25f1fc0$e71d5f40$@cn> References: <007101cd8b50$a25f1fc0$e71d5f40$@cn> Date: Wed, 5 Sep 2012 07:00:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Linlin Zhou Content-Type: text/plain; charset=ISO-8859-1 Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:00:17 -0000 On Wed, Sep 5, 2012 at 3:24 AM, Linlin Zhou wrote: > Actually my feedback is not positive. Understood. The words you chose didn't seem like objection to me, only suggestions for development. >> Can you explain why this document is not even suitable as a starting point for >> work? > > We already have two separated response drafts by RIR and DNR. These two > drafts have been reviewed and improved by the design team and the working > group. A lot of efforts are made for response drafts. So I think these > drafts are definitely worth to be the starting points for working on our > weirds response > deliverables. IMO, the substantial key point for us is to coordinate the RIR > draft with the DNR draft, not to > have a nominal unified document. I understand we could certainly do it that way, but I'm so far not understanding why it's better for this working group to produce two response documents rather than a single one that covers both cases. I don't recall hearing in Vancouver any objection to the goal of maintaining only a single set of documents as far "up the stack" as possible, and trying to produce a unified response document would be consistent with that vision. I stress here that there's been no suggestion to discard any of the design team's work to date. The suggestion we're discussing is merely to work toward having their results in a single response document rather than having two. Can you explain why producing two response documents is the necessary path forward? -MSK From andy@arin.net Wed Sep 5 07:48:41 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EDC21F84E1 for ; Wed, 5 Sep 2012 07:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucrIdoOyXKn0 for ; Wed, 5 Sep 2012 07:48:40 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 564C821F84C8 for ; Wed, 5 Sep 2012 07:48:40 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 5EFD2213640; Wed, 5 Sep 2012 10:48:35 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id CB9FD213629; Wed, 5 Sep 2012 10:48:34 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 5 Sep 2012 10:48:16 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 10:48:28 -0400 From: Andy Newton To: "Murray S. Kucherawy" , Linlin Zhou Thread-Topic: [weirds] New Unified DNR/RIR Internet-Drafts Thread-Index: AQHNi0HrzuLcqmYKTG2sVLh3JJzaWZd7zc2AgAA8SAD//8pnAA== Date: Wed, 5 Sep 2012 14:48:25 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.35.153] Content-Type: text/plain; charset="us-ascii" Content-ID: <6474AAE16BBEE94B964861C7EF794013@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:48:41 -0000 On 9/5/12 10:00 AM, "Murray S. Kucherawy" wrote: > I >don't recall hearing in Vancouver any objection to the goal of >maintaining only a single set of documents as far "up the stack" as >possible, and trying to produce a unified response document would be >consistent with that vision. For the record, I did object though not strenuously. But I believe I was the only one. I withdraw that objection. Once again, I've seen the light. Unfortunately, we accidentally published a version of the unified-response draft that was not the latest edit. The latest edit contained text to address some of the issues Linlin brought up. We will roll that edit as -01 (and if the chairs so desire, I can push that ASAP if they feel it will aid discussion). But I'll excerpt some of that here. If I understand Linlin's objection of the unified data model, it is that since the RIR model is a complete subset of the DNR model where overlap exists then the two might as well be separate models. The notion that they one is a "subset" of the other is about the presentation of the idea to the different communities. However, from a client perspective it is one model. Our introduction has been updated to note this: The data model for the responses consists of two major categories: responses returned by Regional Internet Registries (RIRs) for registrations data related to IP addresses, reverse DNS names, and Autonomous System numbers; and responses returned by Domain Name Registries (DNRs) for registration data related to forward DNS names. Where overlap exists between RIR and DNR reponse object classes, the RIR object classes are a proper subset of the DNR object classes. The current division between RIR and DNR object classes is given to illustrate an expectation of what data may be expected from an RIR vs a DNR. However, implementers should be aware that RIRs are not limited to the data in the RIR object classes (as an example, some RIRs have a notion of "status" for entities as defined in the DNR entity object class and may at some point start publishing that data). -andy From andy@arin.net Wed Sep 5 08:08:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A5721F869A for ; Wed, 5 Sep 2012 08:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y67+BAS-n0Gz for ; Wed, 5 Sep 2012 08:08:42 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id AB93F21F8692 for ; Wed, 5 Sep 2012 08:08:42 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 15BCA213663; Wed, 5 Sep 2012 11:08:40 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 8F2AB213649; Wed, 5 Sep 2012 11:08:31 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 5 Sep 2012 11:08:19 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 11:08:30 -0400 From: Andy Newton To: Linlin Zhou , "'Murray S. Kucherawy'" , "'Hollenbeck, Scott'" Thread-Topic: [weirds] New Unified DNR/RIR Internet-Drafts Thread-Index: Ac2HdRuzzuLcqmYKTG2sVLh3JJzaWQAYkX6AANcudgAAEQyzgA== Date: Wed, 5 Sep 2012 15:08:29 +0000 Message-ID: In-Reply-To: <002b01cd8b12$9527fb30$bf77f190$@cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.35.153] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:08:43 -0000 On 9/4/12 11:00 PM, "Linlin Zhou" wrote: >We have a few comments for the unified response draft. > >1. The unified response draft just enumerates and combines the data >elements >of names and numbers. We think the coders of IP Whois and domain Whois may >different. This draft easily makes them confused and asks the readers >especially coders to identify which sections belong to names and which >sections belong to numbers. >Most parts of DNR objects inherit the naming or structure style from RIR >response draft. Domain elements may not suitable to be expressed in the >numbers way. For example, some elements are not available for names. See >section 5.2 DNR domain object. > >"delegationKeys" : [ > { > "algorithm": 7, > "digest" : "E68C017BD813B9AE2F4DD28E61AD014F859ED44C", > "digestType" : 1, > "keyTag" : 53814 > } > ] > >"uris" : [ > ... > { > "type" : "held", > "uri" : "http://example.net/location/xxxx" > } >] >I wonder why we need keys and location information in domain Whois >information. Some domain registries do have DNSSEC key information in Whois, so this is completely appropriate for both DNRs and RIRs to the best of my knowledge. I would invite DNSSEC people to look over what we have done here. As for location, that notion gets conflated with the postal address information. That is one reason to call it out (other than the fact that some Whois services point to location services). This is an appendix from the latest edit of our draft (which unfortunately was not published): The postal address data listed in the entity object class (Section 4) does not necessarily represent location. The intent of this information is to provide a means to send postal mail to an entity. While in some cases it may also be the location of the entity, there is no gaurantee that the two are the same. Accurate representation of location is topic unto itself, and registries wishing to show location of object instances should use the 'geo' or 'held' URI types as meantioned in Appendix A.3. >2. Names don't have consensus on common elements. >In the Vancouver meeting, object inventory work just begun and design team >for names object selection was asked to be formed by the chair. The >element >listed in the draft such as "resoldBy", unfortunately I did not find any >registry support it in 104 ccTLDs and 18 gTLDs Whois data we collected. >There are more than 200 name registries. The common elements selection >work >is far more complex than RIR. We need time to do this. resoldBy is from an ICANN SSAC document on Whois data models. When I looked at what ICANN had recommended, this was the only missing element. >3. We suggest a high level structure for the unified response. >{ > registrationObject: > { > /*common*/ > /*unique*/ > } > registrationObject: > { > /*common*/ > /*unique*/ > } >} > >registrationObject may refer to registration , nameserver or contact >information. "Common" refers to the common part of names and numbers. >"Unique" is the respective unique elements of each other. This is addressed by the prefix notion in Section 6.2 of draft-designteam-weirds-using-http-01 (http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-6 .2). The unified-response draft references it. -andy From carlosm3011@gmail.com Wed Sep 5 08:52:24 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD1521F84CE for ; Wed, 5 Sep 2012 08:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bgpMes3CDqp for ; Wed, 5 Sep 2012 08:52:23 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAB521F84CD for ; Wed, 5 Sep 2012 08:52:23 -0700 (PDT) Received: by ggnh4 with SMTP id h4so111912ggn.31 for ; Wed, 05 Sep 2012 08:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=IL/0Fll2BuCWipTr5THPEOJ9vcEbK/kdYTrTLJNkLio=; b=iEsMhNpWEfWK4tkhKGtaAep9gAvq5nLFp5zUbFTm2v89DC3qmqaV6pIbrSxyRvz56L TGjAphGAoD5v4He+swRQOAzLmYbDgJTloAnjkT9RXdeyFJ+6yU+l+3bmtgXs6dw0o2KN DYd3bYJOKqsHUIUhIfH39XEThYPN5uDOTMeuJSx2mc/yDIzKG1Qeo2sd3PiX66DIdq8M lItZ/2wu3nv1qpIRej2/aSmudJ6toMf1CHBgrwElUN81QN7Pu+OoICHXa9haRPA1eJ3L EsjgT6P5lC027+xe+c7Pg9q7DZS+ZtztDWIF+P6vRLyPkMiRZymewjElZOWR4pduBN7x FMFQ== Received: by 10.236.200.132 with SMTP id z4mr23568712yhn.93.1346860342903; Wed, 05 Sep 2012 08:52:22 -0700 (PDT) Received: from europa.local ([200.7.87.205]) by mx.google.com with ESMTPS id p36sm3587443yhe.20.2012.09.05.08.52.20 (version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 08:52:21 -0700 (PDT) Message-ID: <50477532.4040103@gmail.com> Date: Wed, 05 Sep 2012 12:52:18 -0300 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: weirds@ietf.org References: <048A8A0F-90C6-44C1-8C6C-59DAD5454C55@apnic.net> In-Reply-To: <048A8A0F-90C6-44C1-8C6C-59DAD5454C55@apnic.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:52:24 -0000 I support adoption. I'd like to point out that the drafts need not be perfect at this time, what we need to agree in this call for adoption is whether they are _good enough_ as _starting points_ for the task at hand. IMO, they are. regards Carlos On 9/4/12 11:53 PM, Byron Ellacott wrote: > +1, support adoption > > Byron > > On 05/09/2012, at 8:53 AM, Steve Sheng wrote: > >> +1, support for adoption. >> >> -----Original Message----- >> From: Mark Kosters >> To: Andy Newton >> Cc: "weirds@ietf.org" >> Subject: Re: [weirds] Call for Adoption (was Re: New Unified DNR/RIR >> Internet-Drafts) >> >>> I support adoption of these docs as well. >>> >>> Mark >>> >>> On 9/4/12 5:21 PM, "Andy Newton" wrote: >>> >>>> As unsurprizing as this may be, I support these documents for adoption as >>>> working group items. >>>> >>>> -andy >>>> >>>> On 8/31/12 4:18 PM, "Murray S. Kucherawy" wrote: >>>> >>>>> On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott >>>>> wrote: >>>>>> So, a question for the chairs and group: combined with the "using >>>>>> http" >>>>>> and redirection drafts, do we now have a set that's ready to become >>>>>> working group documents? >>>>> >>>>> Having not yet spoken to Olaf (who is on vacation), my view is that >>>>> this is in line with the vision the chairs presented in Vancouver for >>>>> a path forward. Kudos to you and Andy for taking this initiative. >>>>> >>>>> To the WG: I propose that we adopt these as initial working group >>>>> documents toward our milestones. Note, as usual, that they are merely >>>>> starting points and foci for discussion; we need to develop them and >>>>> reach working group consensus before they will be advanced for >>>>> publication. >>>>> >>>>> I'll place them in Call For Adoption state now. Please review them >>>>> and comment as to whether you believe they are reasonable starting >>>>> o/weirds >>> >>> _______________________________________________ >>> weirds mailing list >>> weirds@ietf.org >>> https://www.ietf.org/mailman/listinfo/weirds >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Wed Sep 5 12:54:01 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418BC21F86D0 for ; Wed, 5 Sep 2012 12:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhG4WKhKV4Dz for ; Wed, 5 Sep 2012 12:54:00 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 844DA21F86CF for ; Wed, 5 Sep 2012 12:54:00 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id CC4871650E6; Wed, 5 Sep 2012 15:53:57 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 3C3351650E7; Wed, 5 Sep 2012 15:53:57 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 5 Sep 2012 15:53:42 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 15:53:54 -0400 From: Andy Newton To: Linlin Zhou , "'Murray S. Kucherawy'" , =?gb2312?B?J9C7vNK58yc=?= Thread-Topic: [weirds] New Unified DNR/RIR Internet-Drafts Thread-Index: AQHNi0HrzuLcqmYKTG2sVLh3JJzaWZd7zc2AgABcCYA= Date: Wed, 5 Sep 2012 19:53:54 +0000 Message-ID: In-Reply-To: <007101cd8b50$a25f1fc0$e71d5f40$@cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.35.153] Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 19:54:01 -0000 DQoNCk9uIDkvNS8xMiA2OjI0IEFNLCAiTGlubGluIFpob3UiIDx6aG91bGlubGluQGNubmljLmNu PiB3cm90ZToNCg0KPklNTywgdGhlIHN1YnN0YW50aWFsIGtleSBwb2ludCBmb3IgdXMgaXMgdG8g Y29vcmRpbmF0ZSB0aGUgUklSDQo+ZHJhZnQgd2l0aCB0aGUgRE5SIGRyYWZ0LCBub3QgdG8NCj5o YXZlIGEgbm9taW5hbCB1bmlmaWVkIGRvY3VtZW50Lg0KDQpTb3JyeSB0byByZXNwb25kIGluIHN1 Y2ggYSBzcG9yYWRpYyBtYW5uZXIsIGJ1dCB0aGVyZSBpcyBvbmUgbW9yZSB0aGluZyBJDQp3YW50 IHRvIHBvaW50IG91dC4gVGhlIHVuaWZpZWQgcmVzcG9uc2UgZHJhZnQgbm90IG9ubHkgdW5pZmll cyB0aGUgUklSIGFuZA0KRE5SIG1vZGVscyBidXQgYWxzbyB0aGUgZGlmZmVyaW5nIG5hbWVzZXJ2 ZXIvaG9zdCBtb2RlbHMgZm9yIEROUnMgKHNlZQ0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbmV3dG9uLXdlaXJkcy11bmlmaWVkLWpzb24tcmVzcG9uc2UtMDAjc2VjDQp0aW9uLTQp LiBUaGF0IGNhbWUgYWJvdXQgd2hpbGUgdGFraW5nIGEgc3RlcCBiYWNrIGFuZCBsb29raW5nIGF0 IHRoZQ0KY29tbW9uYWxpdGllcyBiZXR3ZWVuIHRoZSBSSVIgYW5kIEROUiBtb2RlbHMuIFRoZXJl IGlzIGJlbmVmaXQgaW4gYmVpbmcNCmFibGUgdG8gdGFrZSB0aGUgcGVyc3BlY3RpdmUuDQoNCi1h bmR5DQoNCg== From sm@resistor.net Thu Sep 6 00:26:50 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB3021F849A for ; Thu, 6 Sep 2012 00:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPIzb4zE7T+T for ; Thu, 6 Sep 2012 00:26:49 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7A921F849B for ; Thu, 6 Sep 2012 00:26:49 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q867Qc2Q012337; Thu, 6 Sep 2012 00:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346916404; bh=qUzkxf/5GGTchgMNv7q21reZfheqGSJg+DUZhtNJmmw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=C8vjLkDiYzxxw904UrFs33Iul+f7tHOw9fDFfbhefihrVF/lk5TxlhVt8+7FoIwI8 URdfTb+VpqyzLg2BbMIvdM4l3dGexQy93FB1Ub74aQ4Mdz0DWmT+bnroEgMA3SoOZI biuFv5lpBk1YFTWtb0PBIDH9cs16cH/faBIJwGQc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1346916404; i=@resistor.net; bh=qUzkxf/5GGTchgMNv7q21reZfheqGSJg+DUZhtNJmmw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XCb7kI7ZFpPhvcpiB+dla5jNmnVZw8SYpYpYvh9+VgLMVjzREyO9ioACHh/SqDwBM ka6bwat2s5he2VUp2fpHM37yL/EhufknrZ+ous2QKlO6G3dKCDbaSwQcxVD9w4yPY/ ldoIxkeJuymccB2S1gzBXwCFN6HBfo8dLSH+uhoI= Message-Id: <6.2.5.6.2.20120905233231.0ac78d50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Sep 2012 00:26:36 -0700 To: Linlin Zhou From: SM In-Reply-To: <007101cd8b50$a25f1fc0$e71d5f40$@cn> References: <007101cd8b50$a25f1fc0$e71d5f40$@cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 07:26:50 -0000 Hi Linlin, At 03:24 05-09-2012, Linlin Zhou wrote: >We already have two separated response drafts by RIR and DNR. These two >drafts have been reviewed and improved by the design team and the working >group. A lot of efforts are made for response drafts. So I think these >drafts are definitely worth to be the starting points for working on our >weirds response Some individuals may have grouped together and called it a design team but it is not the WG design team. The drafts were discussed informally on the mailing list even though they were not WG drafts. >deliverables. IMO, the substantial key point for us is to coordinate the RIR >draft with the DNR draft, not to >have a nominal unified document. Scott Hollenbeck [1] asked for a set of drafts to be considered for adoption as working group drafts. There was a message [2] that they were in line with vision the chairs presented in Vancouver for a path forward. Drafts does not require approval by name and/or numbers people as participation is as individuals. There aren't constituencies as such. The point, in my humble opinion, is to get the work done. The work is performed by individuals instead of representatives of organizations. There seems to be a misunderstanding about how the IETF works. Regards, -sm 1. http://www.ietf.org/mail-archive/web/weirds/current/msg01489.html 2. http://www.ietf.org/mail-archive/web/weirds/current/msg01491.html From zhoulinlin@cnnic.cn Thu Sep 6 01:11:41 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616FF21F8545 for ; Thu, 6 Sep 2012 01:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-K+hZqZD12S for ; Thu, 6 Sep 2012 01:11:40 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6366621F84E1 for ; Thu, 6 Sep 2012 01:11:38 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 06 Sep 2012 16:11:15 +0800 From: "Linlin Zhou" To: "'Murray S. Kucherawy'" References: <007101cd8b50$a25f1fc0$e71d5f40$@cn> In-Reply-To: Date: Thu, 6 Sep 2012 16:11:11 +0800 Message-ID: <008501cd8c07$2e909760$8bb1c620$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2LbspI1GlDRoXRQm+5O7CKG01GsAAbkZ3Q Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 08:11:41 -0000 Dear Murray, > I understand we could certainly do it that way, but I'm so far not understanding > why it's better for this working group to produce two response = documents rather > than a single one that covers both cases. I don't recall hearing in Vancouver any > objection to the goal of maintaining only a single set of documents as = far "up the > stack" as possible, and trying to produce a unified response document would be > consistent with that vision. >=20 > I stress here that there's been no suggestion to discard any of the = design team's > work to date. The suggestion we're discussing is merely to work = toward having > their results in a single response document rather than having two. >=20 > Can you explain why producing two response documents is the necessary = path > forward? >=20 IMO, names and numbers not only have common elements but also their own unique elements of each other. Our following work should focus on both = kinds of elements since each kind of elements are important and necessary. As for the common elements, I definitely hope names and numbers adopt = the same design. Such goal can be achieved in two ways, whether having a = unified response draft or coordinating the existing two RIR and DNR response = drafts by communication between names and numbers. They all can lead to the = same destination, just different working approaches. So I don=A1=AFt care too = much about the working form. As for unique elements, I believe there will be tough works need to do especially for names. These works also need to be started in the = beginning. For example, a tough object inventory for names raised by WG chairs is = now in progress. I think numbers are almost ready now and the names = situations are more complex than numbers and need more time. If we put all the = unique parts in one unified draft, names part will delay the whole progress. According to the milestone in WG charter, the RIR drafts will be = published almost half a year earlier than DNR. Will the unified response draft be divided eventually? If so, why don't we directly keep the two existing = RIR and DNR response drafts at the very start? As I said in previous emails, = a lot of efforts are made for the existing response drafts. These two = existing response drafts are more worthy than the new unified response draft to = be the starting points for working on unique elements. So, I strongly suggest the RIR and DNR response drafts which specify the unique elements of its own to be starting points of WG. Our next work = may focus on the coordination and improvement of these two drafts. If most = guys of WG think a new individual draft is necessary for coordination, I may = also agree to use such a draft as a reference to achieve our goal. From superuser@gmail.com Thu Sep 6 14:39:20 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEA021F8751 for ; Thu, 6 Sep 2012 14:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFh7WPK4ISEs for ; Thu, 6 Sep 2012 14:39:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D07821F8746 for ; Thu, 6 Sep 2012 14:39:19 -0700 (PDT) Received: by lbky2 with SMTP id y2so1640132lbk.31 for ; Thu, 06 Sep 2012 14:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2DYHKeUhun1zbLqwUFoRJyC/NR6VMbHYWLpy7PVq8yM=; b=CCDs4VSN8k+p1GSR2d3a/RDFOZThI7DWT9RTQXi6PN9PlpySEAqg4tuiGJ6TsiUPw9 vFCYCmANiOdCOTwP3UAWM6CYZb3/xGny0+hwWwruI6ieT59ndI0k+gyVwQNLpA86nQ/P iy+1wgBKSjdP6GcHFSEShdppCJ/AKIJ/2jmDSgMLHqLRnLey336Z5KVarxvkz+dgeYG0 XgnzXDdvw5eswBO5FA2S5olSxl7sjR+s9AL33X/PJN/oHAHf1Txl4JL0jXexufqwLdcn txvriRZR3e90B97F+zHwznA/VA5VVqPHjM491viBgvxXjnF/vBQYFLFkwqmPjEPE1Uer RHBg== MIME-Version: 1.0 Received: by 10.152.125.116 with SMTP id mp20mr3282476lab.19.1346967558261; Thu, 06 Sep 2012 14:39:18 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Thu, 6 Sep 2012 14:39:18 -0700 (PDT) In-Reply-To: <008501cd8c07$2e909760$8bb1c620$@cn> References: <007101cd8b50$a25f1fc0$e71d5f40$@cn> <008501cd8c07$2e909760$8bb1c620$@cn> Date: Thu, 6 Sep 2012 14:39:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Linlin Zhou Content-Type: text/plain; charset=ISO-8859-1 Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 21:39:21 -0000 On Thu, Sep 6, 2012 at 1:11 AM, Linlin Zhou wrote: > IMO, names and numbers not only have common elements but also their own > unique elements of each other. Our following work should focus on both kinds > of elements since each kind of elements are important and necessary. There is absolutely no intent to disregard this point. The question for the WG comes down to whether the number of unique things for either camp is substantial and, if so, how to go about publishing them. I think to emphasize the goal of sticking as much as possible to a common solution, we should aim to produce common documents as much as possible. If the hard work of the design team reveals a manageable number of differences, then I believe they could be merged into the unified documents; if not, then the working group can decide it would prefer to create a separate draft that presents the differences, preferably as extensions to a base document set. What I would like us not to do is pre-emptively decide that by creating working group documents which anticipate the division. We should only do so later, after the design team's analysis is complete and the team concludes (and the WG agrees) that the division is indeed necessary and substantial. > As for unique elements, I believe there will be tough works need to do > especially for names. These works also need to be started in the beginning. > For example, a tough object inventory for names raised by WG chairs is now > in progress. I think numbers are almost ready now and the names situations > are more complex than numbers and need more time. If we put all the unique > parts in one unified draft, names part will delay the whole progress. > According to the milestone in WG charter, the RIR drafts will be published > almost half a year earlier than DNR. Will the unified response draft be > divided eventually? If so, why don't we directly keep the two existing RIR > and DNR response drafts at the very start? As I said in previous emails, a > lot of efforts are made for the existing response drafts. These two existing > response drafts are more worthy than the new unified response draft to be > the starting points for working on unique elements. As I also said in previous messages, there is absolutely no intent to discard the hard work put into existing drafts. That is especially true of the design team doing WHOIS response analysis. The people who are appointed editors of those documents the WG adopts are required to record consensus of the WG, and if consensus is to incorporate work from other individual submissions, then that will happen. You will be quite within your rights to advocate for addition of important points to the drafts that are adopted, but I imagine that will be pretty much automatic for work that moves us toward our stated goals. Naturally the authors of the original drafts will receive appropriate credit when their work is incorporated. The matter of editor selection also still needs resolution. I am not attempting to hold up any one draft's content or any one person's work as "more worthy" than any other. Rather, I've proposed to adopt documents whose directions align with what I believe to be the desired direction of the working group. The charter text doesn't require division of the work, but rather presents it as a last resort option. As I read it, most of the text talks about framework and format in the singular. It also says that the number registry work is more fully developed so far, so their work should be the basis for the WG input documents. I think the proposed unified drafts to a good job of finding common starting points based on those points. However, you are correct about the milestones; the charter text is focused on providing a single solution, while the milestones show clear division. This should have been caught sooner, and I apologize if it has led to some confusion about our direction. I think given the goal of unifying work as much as practical, we should petition to change the milestones accordingly to focus on producing the common stuff first and the divergent stuff later. Assuming the base proposed set of documents, something like this could work: Feb 2013 draft-designteam-weirds-using-http to the IESG Apr 2013 draft-hollenbeck-weirds-rdap-sec to the IESG Jun 2013 draft-hollenbeck-weirds-unified-rdap-query to the IESG Sep 2013 draft-newton-weirds-unified-json-response to the IESG Dec 2013 extension drafts (if needed) to the IESG Does anyone think those are unreasonable? -MSK From superuser@gmail.com Thu Sep 6 14:45:29 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5183021F854C for ; Thu, 6 Sep 2012 14:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIgyrC9LLH5B for ; Thu, 6 Sep 2012 14:45:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8625421F8578 for ; Thu, 6 Sep 2012 14:45:28 -0700 (PDT) Received: by lbky2 with SMTP id y2so1643031lbk.31 for ; Thu, 06 Sep 2012 14:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XvgFUx0bA8l3SvD0EEbq6W5hT22GIpt4JTFfvnhJBMY=; b=iT8NJLqAOXJYK3harJy007iX1sTL9Jq0kbPr/6YvHA0TJjxN5liZeTKrtqLqKQbUES Gn86q3QTEP5ZSepCCRUdBykEO+rsLL57Xgm9eQsQm7hZ1rO3qEMvr/e7AQbJgws2TI4N S6PQ5ci3wD6EEY97IRy/PxYmAlMEW9kzMoHgU0H1JqRYLy4r0qp9tVZ/Kk36Fm8l0eju mXtUrECqECD1vixpcD9FsjPb2EobVKwoje58e2XqGxpu6LkJxJCgu+Tbctrt67iG3k+f wqfJYM9yi6HC94MKzHjnuVp2nAjdiI3EiRajlrRyJ68paALgcQAfLDm/NAZWoXDjVh+Y HEaw== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr1400004lbo.55.1346967927547; Thu, 06 Sep 2012 14:45:27 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Thu, 6 Sep 2012 14:45:27 -0700 (PDT) Date: Thu, 6 Sep 2012 14:45:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: weirds@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [weirds] Obsoleting conventional WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 21:45:29 -0000 I was just asked an interesting question: Are we planning to declare RFC 3912 (plain old WHOIS) obsolete and/or historic as a result of this work? Should we? -MSK From andy@arin.net Thu Sep 6 15:40:30 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E375F21F861D for ; Thu, 6 Sep 2012 15:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q37fYdWtjMl8 for ; Thu, 6 Sep 2012 15:40:30 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 3568A21F861C for ; Thu, 6 Sep 2012 15:40:30 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 9228716520B; Thu, 6 Sep 2012 18:40:29 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 62D1016520F; Thu, 6 Sep 2012 18:40:28 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 6 Sep 2012 18:40:09 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Thu, 6 Sep 2012 18:40:27 -0400 From: Andy Newton To: "Murray S. Kucherawy" , Linlin Zhou Thread-Topic: [weirds] New Unified DNR/RIR Internet-Drafts Thread-Index: AQHNi0HrzuLcqmYKTG2sVLh3JJzaWZd7zc2AgAA8SACAATDPgIAA4ckA///OCoA= Date: Thu, 6 Sep 2012 22:40:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <76B5481521FA2040970D5F8F91F8A857@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 22:40:31 -0000 On 9/6/12 5:39 PM, "Murray S. Kucherawy" wrote: >However, you are correct about the milestones; the charter text is >focused on providing a single solution, while the milestones show >clear division. This should have been caught sooner, and I apologize >if it has led to some confusion about our direction. I think given >the goal of unifying work as much as practical, we should petition to >change the milestones accordingly to focus on producing the common >stuff first and the divergent stuff later. Assuming the base proposed >set of documents, something like this could work: > >Feb 2013 draft-designteam-weirds-using-http to the IESG >Apr 2013 draft-hollenbeck-weirds-rdap-sec to the IESG >Jun 2013 draft-hollenbeck-weirds-unified-rdap-query to the IESG >Sep 2013 draft-newton-weirds-unified-json-response to the IESG >Dec 2013 extension drafts (if needed) to the IESG > >Does anyone think those are unreasonable? My comments: 1) So long as the last paragraph of the charter remains, I have no objection for seeking this change. 2) I see no reason why the first 4 drafts can't all be due Apr 2013, unless the chairs are seeking implementation experience before moving the documents to the IESG. 3) There is no mention of the requirements draft. Perhaps it should be added with the same "(if needed)" qualifier. -andy From andy@arin.net Thu Sep 6 15:44:26 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEAE21E803D for ; Thu, 6 Sep 2012 15:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs5s3BcQYlds for ; Thu, 6 Sep 2012 15:44:26 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id EA0BC21E803A for ; Thu, 6 Sep 2012 15:44:25 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 6D9FB16520F; Thu, 6 Sep 2012 18:44:25 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id E5B6D16520B; Thu, 6 Sep 2012 18:44:24 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 6 Sep 2012 18:43:55 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Thu, 6 Sep 2012 18:44:11 -0400 From: Andy Newton To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Obsoleting conventional WHOIS Thread-Index: AQHNjHj45Q6LSCWGAUe6OUQCRgwg9pd96VSA Date: Thu, 6 Sep 2012 22:44:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Obsoleting conventional WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 22:44:27 -0000 On 9/6/12 5:45 PM, "Murray S. Kucherawy" wrote: >Are we planning to declare RFC 3912 (plain old WHOIS) obsolete and/or >historic as a result of this work? Should we? Given that Whois port 43 is still in use and will be when our work product goes to RFC, historic would be premature. I don't know if obsolete is in the same spirit as it is used in RFCs, as my understanding is that an RFC that obsoletes another does so for the same protocol. But I could be wrong about that. Will web-finger obsolete finger? -andy From AMaitland@Commerco.Com Thu Sep 6 15:52:06 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634E321F869C for ; Thu, 6 Sep 2012 15:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNRg6gwS1h1c for ; Thu, 6 Sep 2012 15:52:05 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id C34A321F8699 for ; Thu, 6 Sep 2012 15:52:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=P5sGI7GXxdIhyLZCkPVCpDivWEUho4VA7uAAzB2VcNLYNcjmt9560Xcpdn06X7vBCZvX5QcXUjfYBJLGg54/vNulzso8vXdkYY1LBPU8RFw3un8fXiDGKrG2ICzujMPjv1QH6OX/k5oukSwsiFT2bVCuD+nrj+NigoJHdqj5nFQ= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Thu, 06 Sep 2012 22:52:03 +0000 Message-ID: <50492912.2080400@Commerco.Com> Date: Thu, 06 Sep 2012 16:52:02 -0600 From: Alan Maitland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [weirds] Obsoleting conventional WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 22:52:06 -0000 Murray, Looking at things from a consumer of data, I think it would be unfortunate to loose the plain old WHOIS. I must agree with Andy Newton, it seems premature to make such a move. Alan On 9/6/2012 3:45 PM, Murray S. Kucherawy wrote: > I was just asked an interesting question: > > Are we planning to declare RFC 3912 (plain old WHOIS) obsolete and/or > historic as a result of this work? Should we? > > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > From superuser@gmail.com Thu Sep 6 16:05:10 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497C921E8041 for ; Thu, 6 Sep 2012 16:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TilyIsCqNz8N for ; Thu, 6 Sep 2012 16:05:09 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8096B21E803A for ; Thu, 6 Sep 2012 16:05:09 -0700 (PDT) Received: by lahm15 with SMTP id m15so1624533lah.31 for ; Thu, 06 Sep 2012 16:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OB2wfdRGSZBLy+rdkLpKWPmS7xpKpoSY2vd1/Gl9eSE=; b=pohnXmNvCYT1gIPgT48+WPDQxD+D1YTF0zUjLIMSYNf8MNmYavqIKU5SZa933WzUN/ F/DR7sShoOB4yEyD5uVPMFxtsNmXc2L0+at7L0GQ2HnwZQ3c48iJc05UxrGns8reEOs8 Y+Rc7jsXJmbMeFUiXxbP4U3Uogx2vh7IFcfSGFz2M2/h/3zptCIl+qOir+ExQUEE2OVD Og49Gwav8Qj8u2v0stVGSyy44Ug0dSy9DEqwFj1OvDn26sQ504sPTFyMojWTHH+U5vb/ CW5eMExIJO7W5SQaOzGFno73jS3NnhWAQsdpgRWzNzKJvY1N4GBWZG1F60gYCDgG9xIK 45Aw== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr1445961lbb.72.1346972708503; Thu, 06 Sep 2012 16:05:08 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Thu, 6 Sep 2012 16:05:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 16:05:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: text/plain; charset=ISO-8859-1 Cc: "weirds@ietf.org" Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 23:05:10 -0000 On Thu, Sep 6, 2012 at 3:40 PM, Andy Newton wrote: > 1) So long as the last paragraph of the charter remains, I have no > objection for seeking this change. I didn't suggest any change to the charter text, only the milestones. > 2) I see no reason why the first 4 drafts can't all be due Apr 2013, > unless the chairs are seeking implementation experience before moving the > documents to the IESG. I'm happy with sooner if we think we can hit them. I was building in some buffer time for upcoming holidays, etc. > 3) There is no mention of the requirements draft. Perhaps it should be > added with the same "(if needed)" qualifier. I'd do that one first if we think we need it. I'll post an update to it (still as an individual submission) soon and then we can decide whether to include it. -MSK From aservin@lacnic.net Thu Sep 6 16:27:38 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE6A21F8501 for ; Thu, 6 Sep 2012 16:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYnd+m8LOZOX for ; Thu, 6 Sep 2012 16:27:38 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0996E21F84F8 for ; Thu, 6 Sep 2012 16:27:37 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.90]) by mail.lacnic.net.uy (Postfix) with ESMTP id 1DB4D308436; Thu, 6 Sep 2012 20:27:30 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Fri, 7 Sep 2012 00:27:22 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1B2BBBA3-079B-438D-8E1D-A9D693581980@lacnic.net> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] Obsoleting conventional WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 23:27:38 -0000 I would prefer not to, at least not now. Do we have to take the decision now? Regards, as On 6 Sep 2012, at 22:45, Murray S. Kucherawy wrote: > I was just asked an interesting question: > > Are we planning to declare RFC 3912 (plain old WHOIS) obsolete and/or > historic as a result of this work? Should we? > > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From aservin@lacnic.net Thu Sep 6 16:33:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3622921F8552 for ; Thu, 6 Sep 2012 16:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiUo3StbqNfs for ; Thu, 6 Sep 2012 16:33:11 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0EA21F84DD for ; Thu, 6 Sep 2012 16:33:11 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.90]) by mail.lacnic.net.uy (Postfix) with ESMTP id 22338308436; Thu, 6 Sep 2012 20:33:00 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1119DA16-6823-4649-AB25-77523F696381" From: Arturo Servin In-Reply-To: Date: Fri, 7 Sep 2012 00:32:54 +0100 Message-Id: References: <007101cd8b50$a25f1fc0$e71d5f40$@cn> <008501cd8c07$2e909760$8bb1c620$@cn> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 23:33:12 -0000 --Apple-Mail=_1119DA16-6823-4649-AB25-77523F696381 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Seems reasonable to me. Regards. as On 6 Sep 2012, at 22:39, Murray S. Kucherawy wrote: > However, you are correct about the milestones; the charter text is > focused on providing a single solution, while the milestones show > clear division. This should have been caught sooner, and I apologize > if it has led to some confusion about our direction. I think given > the goal of unifying work as much as practical, we should petition to > change the milestones accordingly to focus on producing the common > stuff first and the divergent stuff later. Assuming the base proposed > set of documents, something like this could work: > > Feb 2013 draft-designteam-weirds-using-http to the IESG > Apr 2013 draft-hollenbeck-weirds-rdap-sec to the IESG > Jun 2013 draft-hollenbeck-weirds-unified-rdap-query to the IESG > Sep 2013 draft-newton-weirds-unified-json-response to the IESG > Dec 2013 extension drafts (if needed) to the IESG > > Does anyone think those are unreasonable? --Apple-Mail=_1119DA16-6823-4649-AB25-77523F696381 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Seems reasonable to = me.

Regards.
as

On = 6 Sep 2012, at 22:39, Murray S. Kucherawy wrote:

However, you = are correct about the milestones; the charter text is
focused on = providing a single solution, while the milestones show
clear = division.  This should have been caught sooner, and I = apologize
if it has led to some confusion about our direction. =  I think given
the goal of unifying work as much as practical, = we should petition to
change the milestones accordingly to focus on = producing the common
stuff first and the divergent stuff later. =  Assuming the base proposed
set of documents, something like = this could work:

Feb 2013 draft-designteam-weirds-using-http to = the IESG
Apr 2013 draft-hollenbeck-weirds-rdap-sec to the IESG
Jun = 2013 draft-hollenbeck-weirds-unified-rdap-query to the IESG
Sep 2013 = draft-newton-weirds-unified-json-response to the IESG
Dec 2013 = extension drafts (if needed) to the IESG

Does anyone think those = are unreasonable?

= --Apple-Mail=_1119DA16-6823-4649-AB25-77523F696381-- From bje@apnic.net Thu Sep 6 18:14:10 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6818C21F86BE for ; Thu, 6 Sep 2012 18:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpm5+2o0WoXP for ; Thu, 6 Sep 2012 18:14:10 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 810CE21F86BD for ; Thu, 6 Sep 2012 18:14:08 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:194f:999:27c9:7a9b] (unknown [IPv6:2001:dc0:a000:4:194f:999:27c9:7a9b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D72F8B69A5; Fri, 7 Sep 2012 11:14:06 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0FAFE673-C11A-4327-9B72-4839702E9EBF"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Fri, 7 Sep 2012 11:14:06 +1000 Message-Id: <13E80B30-28B6-4F70-89C4-0C8938C4B621@apnic.net> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1278) Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 01:14:10 -0000 --Apple-Mail=_0FAFE673-C11A-4327-9B72-4839702E9EBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Murray & WG, On 07/09/2012, at 9:05 AM, Murray S. Kucherawy wrote: >> 2) I see no reason why the first 4 drafts can't all be due Apr 2013, >> unless the chairs are seeking implementation experience before moving = the >> documents to the IESG. >=20 > I'm happy with sooner if we think we can hit them. I was building in > some buffer time for upcoming holidays, etc. Good move to change the milestones, and I prefer aiming for the stars = with an Apr 2013 deadline, too, but I'd like to hear from the group = working on the names elements survey about the timelines they think are = reasonable. Byron= --Apple-Mail=_0FAFE673-C11A-4327-9B72-4839702E9EBF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MDcwMTE0MDdaMCMGCSqGSIb3DQEJBDEWBBSV 8PvTyqc98mGxfhojzaRNTF7EjTCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQDOHEdCkQWyJvJG wSbDn2IlI+1nvj1At0bdTaCZgPx43JO1VHOVta/wq5v8mRWYWxvxs1vR7fWN4HRAWrrShnhrRcmE 1aL5p100vggp8jKmOWGGn1v61vH3LUUkTA0b8MChJuRXjeQ8fqYIx9uC2XASzN/Gc5+yXcJhxXrq si+iZspeLRxpZevs3jocD3QqOTXOHbOwaS94yyb0xa6YSxsOAyIWUj357l0gDRnhOY7V+h5HpiBX NMCOAB/FQ4at46MQwQ1ANu9Iz6Zqc+JGjcDJn6kRDzn3V44qCQHLcPMOwgjUPhSenKaQ1K1KkDl/ //3HXmI/ewXMtUnZRoD+8j47AAAAAAAA --Apple-Mail=_0FAFE673-C11A-4327-9B72-4839702E9EBF-- From superuser@gmail.com Thu Sep 6 22:14:20 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B55721F86BB for ; Thu, 6 Sep 2012 22:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSVwRQwyc-wv for ; Thu, 6 Sep 2012 22:14:20 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9257A21F86B8 for ; Thu, 6 Sep 2012 22:14:19 -0700 (PDT) Received: by lahm15 with SMTP id m15so1754904lah.31 for ; Thu, 06 Sep 2012 22:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JKWkznEN0M0Ozy+8ahktebGM53PdjbY+wf9eMjmzZxc=; b=kGi3phaev6VnMkCPZAxUOsaoM7eXWlK5w6Q31JkSvNuUAAoXKl0hFRB0wBDdN0+/Ir iiie8/SqXwIcLrXWR3AwQk9KSOf3FEzelkKCJ9Zr0bCoCU5D3cxh/0w90H8/TGr1dqa4 Sw0IeRwTkvRqdGwjGpfYzOBUeA1rx8B+yruTXyu5qsPsngN8EvmYIs/YuTLcRWg8pSoB 62h+Ele5K5Xu24U0CBIKifRg7d91DgNYE4AkhDBJS1eGRTiP4n0tyypoVF7Ej9g9WTKU yXLp2m9DsVxfKg/5fUWVVUD0XrmPKJeYxLGaqk85tqO7R4aQWLQj4NQherIat9GvzEy1 wzCg== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr1680447lbo.55.1346994858484; Thu, 06 Sep 2012 22:14:18 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Thu, 6 Sep 2012 22:14:18 -0700 (PDT) In-Reply-To: <1B2BBBA3-079B-438D-8E1D-A9D693581980@lacnic.net> References: <1B2BBBA3-079B-438D-8E1D-A9D693581980@lacnic.net> Date: Thu, 6 Sep 2012 22:14:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Cc: weirds@ietf.org Subject: Re: [weirds] Obsoleting conventional WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 05:14:20 -0000 On Thu, Sep 6, 2012 at 4:27 PM, Arturo Servin wrote: > I would prefer not to, at least not now. > > Do we have to take the decision now? Not at all. Just curious as to people's perspectives. We don't need to do anything, and in fact it's harder to do so if it's still in heavy use. -MSK From sanz@denic.de Thu Sep 6 23:55:33 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE2F21E808E for ; Thu, 6 Sep 2012 23:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDI1Vw4x+c2W for ; Thu, 6 Sep 2012 23:55:33 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 50CE621E8039 for ; Thu, 6 Sep 2012 23:55:33 -0700 (PDT) Received: from notes1.fra2.osl.denic.de (notes1.fra2.osl.denic.de [10.122.50.48]) by office.denic.de with esmtp id 1T9sTT-0002fB-PE; Fri, 07 Sep 2012 08:55:31 +0200 In-Reply-To: References: To: "Murray S. Kucherawy" MIME-Version: 1.0 X-KeepSent: C638A7E9:7729C7A8-C1257A72:0025ECF8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP1 Septem 15, 2011 From: Marcos Sanz Message-ID: Date: Fri, 7 Sep 2012 08:55:25 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 07.09.2012 08:55:31, Serialize complete at 07.09.2012 08:55:31 Content-Type: text/plain; charset="US-ASCII" Cc: weirds@ietf.org Subject: Re: [weirds] Obsoleting conventional WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 06:55:34 -0000 > Are we planning to declare RFC 3912 (plain old WHOIS) obsolete and/or > historic as a result of this work? Should we? No, we shouldn't. Marcos From shollenbeck@verisign.com Fri Sep 7 04:06:14 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402F821F876D for ; Fri, 7 Sep 2012 04:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJOiBZnuZ6dW for ; Fri, 7 Sep 2012 04:06:13 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 723EB21F87D8 for ; Fri, 7 Sep 2012 04:06:12 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUEnVJKZ8LVFAIziLmX2UaqFh9CIFc85m@postini.com; Fri, 07 Sep 2012 04:06:13 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q87B6BSN000379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 07:06:11 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Fri, 7 Sep 2012 07:06:11 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Obsoleting conventional WHOIS Thread-Index: AQHNjHj0EUCLAubCdU++8zU0kkN6YJd+uHHQ Date: Fri, 7 Sep 2012 11:06:10 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D679AD4@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 Subject: Re: [weirds] Obsoleting conventional WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 11:06:14 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Murray S. Kucherawy > Sent: Thursday, September 06, 2012 5:45 PM > To: weirds@ietf.org > Subject: [weirds] Obsoleting conventional WHOIS >=20 > I was just asked an interesting question: >=20 > Are we planning to declare RFC 3912 (plain old WHOIS) obsolete and/or > historic as a result of this work? Should we? Concurring with others: no and no. Scott From andy@arin.net Fri Sep 7 06:37:48 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1134121E8051 for ; Fri, 7 Sep 2012 06:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5pLga9dEx1J for ; Fri, 7 Sep 2012 06:37:47 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 917BD21E8050 for ; Fri, 7 Sep 2012 06:37:47 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id C509A213686; Fri, 7 Sep 2012 09:37:46 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 7B250213678; Fri, 7 Sep 2012 09:37:46 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 7 Sep 2012 09:37:18 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Fri, 7 Sep 2012 09:37:39 -0400 From: Andy Newton To: "Murray S. Kucherawy" , Linlin Zhou Thread-Topic: [weirds] New Unified DNR/RIR Internet-Drafts Thread-Index: AQHNi0HrzuLcqmYKTG2sVLh3JJzaWZd7zc2AgAA8SACAATDPgIAA4ckAgADItQA= Date: Fri, 7 Sep 2012 13:37:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <98437F7C12C1204E815EE6871CAFBF10@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 13:37:48 -0000 On 9/6/12 5:39 PM, "Murray S. Kucherawy" wrote: >Feb 2013 draft-designteam-weirds-using-http to the IESG >Apr 2013 draft-hollenbeck-weirds-rdap-sec to the IESG >Jun 2013 draft-hollenbeck-weirds-unified-rdap-query to the IESG >Sep 2013 draft-newton-weirds-unified-json-response to the IESG >Dec 2013 extension drafts (if needed) to the IESG In addition to the above, I think a milestone of delivering the object inventory as an informational RFC is needed as well. I believe this was mentioned at the meeting in Vancouver as well. -andy From nkong@cnnic.cn Fri Sep 7 08:08:47 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9C921F85B1 for ; Fri, 7 Sep 2012 08:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgubK9ZGRy6z for ; Fri, 7 Sep 2012 08:08:47 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6B05821F85AF for ; Fri, 7 Sep 2012 08:08:46 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 07 Sep 2012 23:08:35 +0800 From: "Ning Kong" To: "'Andy Newton'" , "'Murray S. Kucherawy'" , "'Linlin Zhou'" References: In-Reply-To: Date: Fri, 7 Sep 2012 23:08:07 +0800 Message-ID: <02e501cd8d0a$96e96540$c4bc2fc0$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIlZbJYRBR/On8RslGS7Were8aXg5bPQ6Lg Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 15:08:47 -0000 > In addition to the above, I think a milestone of delivering the object inventory > as an informational RFC is needed as well. I believe this was mentioned at the > meeting in Vancouver as well. I'd like to make a draft as an initial input based on my presentation (Whois Object Inventory Statistical Analysis) in Vancouver if the WG agree this work makes sense. Cheers, Ning From sm@resistor.net Fri Sep 7 14:07:42 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026B021E80D3 for ; Fri, 7 Sep 2012 14:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJJp4pq8U36c for ; Fri, 7 Sep 2012 14:07:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB64521E808F for ; Fri, 7 Sep 2012 14:07:40 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q87L7Vu2000229; Fri, 7 Sep 2012 14:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347052056; bh=Xbt524kQiPgknpnH+5B6dDM0D18jHZzQVSSF3qQTe5I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vZnac31vtO1Kq2cVPbmz/dSTD3BAh0YLIkXNFsOMEkL6zeXEZWf4rzf00LqihXadp WtsE1bAZmUal1py4UyG9h8YH3+xXfqgIIubpQRiw3g3bbKUDAWrNNRIWs4N53gLX86 uJJr94kJTtX16d1y744n9Z/CHPRxESNzpNawlZDc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347052056; i=@resistor.net; bh=Xbt524kQiPgknpnH+5B6dDM0D18jHZzQVSSF3qQTe5I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JBTEhCNCgezdNtA/8QelPedY9n0tiAMjkMchAX3Ev8AW8VvJlp13S+aXQdrMFXsnc gRbeFbkHu1z05maJs2L7/3IKBvdjOi4L36369inXwEtZM1abYOAEdHeE7sF6PU2fBY +9weAoMV1L7zyTvyXNdMoOEhhqqv/NpP7LURB8TU= Message-Id: <6.2.5.6.2.20120907135518.0abf66b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Sep 2012 14:05:54 -0700 To: Ning Kong From: SM In-Reply-To: <02e501cd8d0a$96e96540$c4bc2fc0$@cnnic.cn> References: <02e501cd8d0a$96e96540$c4bc2fc0$@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 21:07:42 -0000 Hi Ning, At 08:08 07-09-2012, Ning Kong wrote: >I'd like to make a draft as an initial input based on my presentation (Whois >Object Inventory Statistical Analysis) in Vancouver if the WG agree this >work makes sense. Anyone can submit a draft. Not all drafts have to end up as RFCs. That does not mean that the draft or the work is not useful. The question that might be asked is why is it important for the document to be part of the RFC archive. Regards, -sm From johnl@iecc.com Sun Sep 9 13:05:55 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF3A21F847F for ; Sun, 9 Sep 2012 13:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cuCRnkt8Hnt for ; Sun, 9 Sep 2012 13:05:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD8121F849B for ; Sun, 9 Sep 2012 13:05:54 -0700 (PDT) Received: (qmail 12310 invoked from network); 9 Sep 2012 20:05:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Sep 2012 20:05:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504cf69e.xn--9vv.k1208; i=johnl@user.iecc.com; bh=WxNFkrnvGRyMM+21xcMWI5xy0jNPJuZONYUXUx+igb0=; b=K7BAmh25oXy8Q8DZXZFHCzhXuc2scdbjBoq+yknYAb6LH0jltkZFNCpo3UbN15t0XRcgE8gxKS5FdAx6A/hHVYDN7I0x0uK9TCjwd4K2qo/SeWAWr+f3c+NnxXFIaUF7LatOLmfExUDrKjS8GgF+DQTKn4+RxEgWcJmYQgs+KP4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504cf69e.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=WxNFkrnvGRyMM+21xcMWI5xy0jNPJuZONYUXUx+igb0=; b=yoP9rwfdRlRitt13SJKXHjJUt31319TUo4CAGZ5dxH1ol1k5OUpOMSuvM+C+mcQK7Mnox1M7atOVFNya+TdVANt4FhDoNLd///18GFeBWbwAg748a2+jJchij896VTU3AOD6CNIBDn6Mggj/w+OKXpBXJY4jxK0e5FL6GJoX9lY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Sep 2012 20:05:28 -0000 Message-ID: <20120909200528.34986.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Obsoleting conventional WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 09 Sep 2012 20:05:56 -0000 >> Do we have to take the decision now? Untill all of the ICANN TLD agreements are amended to remove the requirement for port 43 WHOIS, it's not going away. We can worry about it later. Much, much, later. R's, John From johnl@iecc.com Sun Sep 9 13:07:15 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC03821F8566 for ; Sun, 9 Sep 2012 13:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEgoCzeg2gXP for ; Sun, 9 Sep 2012 13:07:15 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 231BF21F849B for ; Sun, 9 Sep 2012 13:07:15 -0700 (PDT) Received: (qmail 12518 invoked from network); 9 Sep 2012 20:07:14 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Sep 2012 20:07:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504cf6f2.xn--hew.k1208; i=johnl@user.iecc.com; bh=REFdjthRwV4sD2OfZR8pa1P3ON2Gx7eYAdpJEE94E9c=; b=NrmxwfzfdzvXx4wgmCZz7FkZTQqm1Pp4FrhbbgmeQw8Dm1aD8iv8F9AV8ZtG5fsBeKbdavJGe3DhfPe3cVd0C4vrxAZbnEdW3i+4SVwippF54au6I5UeanFXkmmNJMr/PzZYUZGsUttR2IndjLOVrFSqBvmWhWMT9YHK3zUx26Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504cf6f2.xn--hew.k1208; olt=johnl@user.iecc.com; bh=REFdjthRwV4sD2OfZR8pa1P3ON2Gx7eYAdpJEE94E9c=; b=r8duoIMRZ5/b6maL9sf0Li19QiTazUTCpA9jwgJKbT08QSINQd+bfOJ33iD+SMvBTjxhm427OZmfxLsPsXp4SailcHKJmeu3eOow/5C/QrtbG94ZQbKYDkBRUevbHaHLrLb6LIQCOQU5hehLXv27OPZoBSKp+dGC+Ir22VCK10g= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Sep 2012 20:06:52 -0000 Message-ID: <20120909200652.35051.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 09 Sep 2012 20:07:16 -0000 >In addition to the above, I think a milestone of delivering the object >inventory as an informational RFC is needed as well. I believe this was >mentioned at the meeting in Vancouver as well. It doesn't have to be a milestone. If the WG wants to make it an RFC, we can just do it. R's, John From Ed.Lewis@neustar.biz Sun Sep 9 16:03:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220FF21F8599 for ; Sun, 9 Sep 2012 16:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V43EpGEcHT1s for ; Sun, 9 Sep 2012 16:03:11 -0700 (PDT) Received: from smtp161.iad.emailsrvr.com (smtp161.iad.emailsrvr.com [207.97.245.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9E38521F858F for ; Sun, 9 Sep 2012 16:03:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp26.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id D50F1A81CE; Sun, 9 Sep 2012 19:03:10 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp26.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id B7AF4A81B0; Sun, 9 Sep 2012 19:03:09 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 9 Sep 2012 19:01:34 -0400 To: "Murray S. Kucherawy" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: weirds@ietf.org Subject: Re: [weirds] Obsoleting conventional WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 09 Sep 2012 23:03:12 -0000 At 14:45 -0700 9/6/12, Murray S. Kucherawy wrote: >I was just asked an interesting question: > >Are we planning to declare RFC 3912 (plain old WHOIS) obsolete and/or >historic as a result of this work? Should we? Way too premature to be thinking of this. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From Ed.Lewis@neustar.biz Sun Sep 9 16:33:18 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1193F21F849B for ; Sun, 9 Sep 2012 16:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.176 X-Spam-Level: X-Spam-Status: No, score=-101.176 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FGrmHlh5TEd for ; Sun, 9 Sep 2012 16:33:17 -0700 (PDT) Received: from smtp141.dfw.emailsrvr.com (smtp141.dfw.emailsrvr.com [67.192.241.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE6821F844B for ; Sun, 9 Sep 2012 16:33:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id DA54418022E; Sun, 9 Sep 2012 19:33:16 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 6740B180229; Sun, 9 Sep 2012 19:33:16 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Sun, 9 Sep 2012 19:25:15 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [weirds] Still a little disoriented X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 09 Sep 2012 23:33:18 -0000 I've been coming up to speed on the work in this WG. (I was unable to make it to Vancouver.) I've read the three latest documents on http://tools.ietf.org/id/weirds?maxhits=100&key=date&dir=desc, and I say it as that because there is no other designation that these are associated with the WG (yet - I get the process, but I'm just saying). I also appreciated the comments from Zhou Linlin (http://www.ietf.org/mail-archive/web/weirds/current/msg01497.html), "appreciated" in the sense that I haven't diven deep enough to say I agree or disagree. But the sentiment in there rang a bell in me. Registration breaks down into associating objects to entities. Whether it is domain name or IP numbers, there is that commonality. The more I think about it (having worked on both sides) there is much more in common than there is in difference. E.g., IPv4 addresses are assigned or allocated in a hierarchical fashion. The process to choose an appropriate range is an RIR topic, something not shared with a domain name registry. RIRs are used to "linked" objects, e.g., 192.0.2.0/24 is one object that is kind of a parent to 192.0.2.192/26. That relationship might appear to be unique to an RIR. But domain name registries also have "links" between objects thanks to IDN variants. For that reason (and point example) I would strive to eliminate the mental divide between names and numbers in the documents. This is in point 1 of Zhou's email. There really ought not be any sense of division in the approach to the software. But not all is that shiny. Beyond the basics of registration there are many policies unique to some registries. Off hand I don't have a list, I just know there are rocks under the water. There will be a need to make accommodations for this. BUT but...as is a big debate in EPP, we don't want to make "extensions" that common. (With a ;) to those who have ridden that issue for a few years now.) Point 2 in Zhou's message is also a concern of mine. It's not just the timeliness. The reason I subject'ed my message "Still a little disoriented" is that all of the documents I have seen seem to be more bent on presentation of the elements (queries and responses) than have any sense of data model or protocol architecture. When it comes to the "objects to entities" relationships managed by registries (and registrars where applicable), the various objects under consideration need to be defined. This might help reduce the number of strings used to identify a particular kind of object. E.g., a domain name might be owned by a organization. In some RIRs an address range might be allocated to a organization. In other RIRs the notion of a organization being in control of resource is not that direct. To a querier wanting to know who to contact about a name or number resource, the "admin contact" is more or less what is needed - but that is called by different names. Each registry should be free to retain their own legal model and internal representation. But a WEIRDS data model should allow that to be translated into a globally understood relationship label. And finally, I want to air once more the idea that registries have different policies placed on them and thus may have unique relationship labels to report. I just want to call this out as a concern of mine. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From andy@arin.net Mon Sep 10 07:32:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C4B21F86B8 for ; Mon, 10 Sep 2012 07:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH2sO6TVYyV7 for ; Mon, 10 Sep 2012 07:32:12 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id EEF5021F86AD for ; Mon, 10 Sep 2012 07:32:11 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 6C619213666; Mon, 10 Sep 2012 10:32:11 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 942862135A6; Mon, 10 Sep 2012 10:32:10 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 10 Sep 2012 10:31:53 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Mon, 10 Sep 2012 10:31:58 -0400 From: Andy Newton To: Edward Lewis , "weirds@ietf.org" Thread-Topic: [weirds] Still a little disoriented Thread-Index: AQHNjuN/zPTpvz2BiEKy3N41lMtZ7peDpEiA Date: Mon, 10 Sep 2012 14:31:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="Windows-1252" Content-ID: <99E1629353D32C49A881984E6358371F@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Still a little disoriented X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2012 14:32:13 -0000 Ed, I'm not sure if you are seeking clarifications to issues or simply stating overarching concerns, so in the interest of seeking rough consensus I'll assume it is the former and respond in-line. On 9/9/12 7:25 PM, "Edward Lewis" wrote: >I've read the three latest documents on >http://tools.ietf.org/id/weirds?maxhits=3D100&key=3Ddate&dir=3Ddesc, and I >say it as that because there is no other designation that these are >associated with the WG (yet - I get the process, but I'm just saying). I suggest you also read http://datatracker.ietf.org/doc/draft-designteam-weirds-using-http/ >[=8Astripped=8A] >For that reason (and point example) I would strive to eliminate the >mental divide between names and numbers in the documents. This is in >point 1 of Zhou's email. There really ought not be any sense of >division in the approach to the software. I agree. In the unified drafts there really is one approach as one is a complete subset of the other. The presentation was done to help show how the needs of each community were being addressed. This helpful for showing the overlap where there is overlap (keep in mind, that the RIR model has objects that simply don't exist in the DNR model, specifically IP networks and ASNs). However, I'm amenable to restructuring the draft into one model if people feel that it makes the draft easier to understand. >But not all is that shiny. Beyond the basics of registration there >are many policies unique to some registries. Off hand I don't have a >list, I just know there are rocks under the water. There will be a >need to make accommodations for this. BUT but...as is a big debate >in EPP, we don't want to make "extensions" that common. (With a ;) >to those who have ridden that issue for a few years now.) Admittedly there are policy differences, but the problem domain is very different from EPP. The EPP model is that client and server MUST agree on the nature and detail of every object class, and derivation is done by completely replacing an object of one namespace with an object from another. This is out of necessity because EPP is a read/write protocol where money exchanges hands. The approach defined in http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-6. 2 takes a different approach. Extensions can be placed in-line; clients that understand the extensions can make use of them and clients that do not should ignore them. This is easier to do with a WEIRDS protocol as the use is read-only. >Point 2 in Zhou's message is also a concern of mine. It's not just >the timeliness. The reason I subject'ed my message "Still a little >disoriented" is that all of the documents I have seen seem to be more >bent on presentation of the elements (queries and responses) than >have any sense of data model or protocol architecture. > >When it comes to the "objects to entities" relationships managed by >registries (and registrars where applicable), the various objects >under consideration need to be defined. This might help reduce the >number of strings used to identify a particular kind of object. Allow me to enumerate the object classes here: 1. Entity - organizations, people, groups, roles, etc=8A 2. Nameservers - sometimes called "hosts" 3. Domains - both forward and reverse 4. IP networks - both v4 and v6 5. ASNs - single and in block form If it would help, we can put this summary in the introduction. > >E.g., a domain name might be owned by a organization. In some RIRs >an address range might be allocated to a organization. In other RIRs >the notion of a organization being in control of resource is not that >direct. To a querier wanting to know who to contact about a name or >number resource, the "admin contact" is more or less what is needed - >but that is called by different names. > >Each registry should be free to retain their own legal model and >internal representation. But a WEIRDS data model should allow that >to be translated into a globally understood relationship label. > >And finally, I want to air once more the idea that registries have >different policies placed on them and thus may have unique >relationship labels to report. I just want to call this out as a >concern of mine. I think we have done this with the entity object class. See Appendix A.2 (http://tools.ietf.org/html/draft-newton-weirds-unified-json-response-00#ap pendix-A.2) and Appendix B (http://tools.ietf.org/html/draft-newton-weirds-unified-json-response-00#ap pendix-B) -andy From superuser@gmail.com Mon Sep 10 07:58:00 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7CC21F86F3 for ; Mon, 10 Sep 2012 07:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myFYFgkqkCd2 for ; Mon, 10 Sep 2012 07:58:00 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C202C21F86AB for ; Mon, 10 Sep 2012 07:57:59 -0700 (PDT) Received: by lbky2 with SMTP id y2so1375774lbk.31 for ; Mon, 10 Sep 2012 07:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=3Y4wdvj+WhkAn670fgBvxh4TyCjoYvWO/tNuZavq+os=; b=xhZKebC2Eqz/STkRG6903jdBtYohZ54ruBpT+c0JJYXaLb90fwsiPnSrof0rspt935 DkdJf+AeQ/asl6nbMMVo7AFja66LBRlKyIhrSkK8LCnn0I7TUrsOG+srm0PQXYSiR2C5 5lPDP8NppepM9o8MHeU5gBXfgM1yDgZ3dkOf1QV8EM+S8vdSYQVBgiKsdcJzW70VmvnF 3NgTLp8fbbOo+8Z+P04n7MwlsGzBt7OTo6g4+ECGjWK99oKbAstG9t+jEVzc8SkzCOmy rjAIS1RqMY6QVmp0kM4MxcQufmpWw8t1gfYLoBvbF0E50KtpKIkRTPfAd7pkeCv97PTR AIdg== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr12868843lab.41.1347289078784; Mon, 10 Sep 2012 07:57:58 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 10 Sep 2012 07:57:58 -0700 (PDT) Date: Mon, 10 Sep 2012 07:57:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: xiejiagui@cnnic.cn Content-Type: text/plain; charset=ISO-8859-1 Cc: weirds@ietf.org Subject: [weirds] Status update X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2012 14:58:00 -0000 On Wed, Sep 5, 2012 at 12:03 AM, Murray S. Kucherawy wrote: > A fairly complete set would appear to be something like: > > draft-designteam-weirds-using-http > draft-hollenbeck-weirds-rdap-sec > draft-hollenbeck-weirds-unified-rdap-query > draft-newton-weirds-unified-json-response > draft-kucherawy-weirds-requirements (but only if we want to keep a > requirements document going) >[...] There was some offline conversation about IETF process that allayed the concerns Linlin posted about this path forward (Linlin should feel free to confirm or correct me). As a result, I believe we have pretty good consensus to proceed with the top four, though it's only been five days and I haven't heard back from Olaf, so I won't pull the trigger on these just yet. Hopefully by the end of this week or early next week we can decide. I haven't heard any specific support for maintaining the fifth within the working group so we'll leave it out for now. I spoke to our Area Director about having a draft that publishes the research into name registry inventory. As this is not among our listed milestones nor is it required output, the recommendation is that this remain an individual submission for the time being. If we decide that we need it as a required reference to the unified JSON response draft, then we can import it as a working group document. If not, then we can avail ourselves of the other publication streams to get that done. However, we agree that the work can and should continue if the authors of that work wish to do so. -MSK, WEIRDS co-chair From superuser@gmail.com Mon Sep 10 11:39:23 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A45021F864D for ; Mon, 10 Sep 2012 11:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubMTzky5koJW for ; Mon, 10 Sep 2012 11:39:23 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A098921F8645 for ; Mon, 10 Sep 2012 11:39:22 -0700 (PDT) Received: by lbky2 with SMTP id y2so1547893lbk.31 for ; Mon, 10 Sep 2012 11:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=khrgOAIOPqBMju8uDN2KGbgWG0SsuD1+7AJ/pvLiYdA=; b=uVf8rdEaO3jFuKTaZk5g+8BPfwqK++2dtF1jDfxYq6v6LtEg6179/7UopHVI7iD2qN Xr7RRvDpxH6HuCeq8/63xK7K/6KUkcLl/pUXbShE/ZY78IcVr6qUSciRRfmlQGaP21+V WtvFFnNC5zG321jUdC9CgAEdTYkN/nomu77/BN6iOjtTYh9vtv9ZyITK3Ecwsz0wGs5b /QTgrgdMAHrNj/355ZdNNTl/b21+kjWIx0gSA30wj6p5IWRDfoCK3+PBEhHE69uU4uPN 4IFcZD5SOaBiIqbfLqmQTcTElAw9zZwelBztK12b2qnis0i/B5C56RNJ+zpQDXqCl6Bl RIPQ== MIME-Version: 1.0 Received: by 10.112.31.233 with SMTP id d9mr5296869lbi.116.1347302360806; Mon, 10 Sep 2012 11:39:20 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 10 Sep 2012 11:39:20 -0700 (PDT) Date: Mon, 10 Sep 2012 11:39:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: weirds@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [weirds] Atlanta meeting request X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2012 18:39:23 -0000 Colleagues, I imagine it's a good guess that we want to meet in Atlanta. I'd like some suggestions from the group as to what presentations we might want other than the usual document status updates. What specific issues do we feel need face time? How much time should we request? -MSK, WEIRDS co-chair From superuser@gmail.com Mon Sep 10 13:58:15 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F3F21F85AE for ; Mon, 10 Sep 2012 13:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MUd4LhypqpM for ; Mon, 10 Sep 2012 13:58:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92B3921F8593 for ; Mon, 10 Sep 2012 13:58:12 -0700 (PDT) Received: by lbky2 with SMTP id y2so1643704lbk.31 for ; Mon, 10 Sep 2012 13:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lBovgoGl4Of9OI9Py9bXqXGLtSFeJgLxaLQ7VuKelLw=; b=Iy/ZcQK3EqezSVrXBjplHq6AJO5C3KFRcz+br9x7legwp72A3nH6mWbMOddLkqhVTW 7R6Ddqe/cATDgBjvFSaOGCGiXoDBcsKpJ8UtY1clCyLBp6QJOFkIc2SsTRWV5o+2nb0q NgF8f78hzgoE2GYSNCvbNQcT2Glzt6b3hfxl8FLfWeHeQaT96Jj1CcuL/jB0AWTHEYCq s8F6dm4jQAX6g9MV7MCjjLcAvpAG1LrchYsxdgGtLfKsDsAFwRZZmfmcdyKpS9WpRnsK 4wB1qQWWuTiwFBUZYT8Eb/APSmd6c8dAoQbBhesHHc+Q4wdizde/LqcC9Owi1BIvq0xw FRdA== MIME-Version: 1.0 Received: by 10.112.24.101 with SMTP id t5mr5400345lbf.123.1347310691460; Mon, 10 Sep 2012 13:58:11 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 10 Sep 2012 13:58:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Sep 2012 13:58:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: weirds@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [weirds] Atlanta meeting request X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2012 20:58:15 -0000 On Mon, Sep 10, 2012 at 11:39 AM, Murray S. Kucherawy wrote: > I imagine it's a good guess that we want to meet in Atlanta. I'd like > some suggestions from the group as to what presentations we might want > other than the usual document status updates. What specific issues do > we feel need face time? How much time should we request? The meeting request deadline snuck up on me, and is in fact today. I've thus requested a two-hour meeting slot. We don't have to use all of it, but if we're sure we won't, I'll decrease the size of the request. We would still like to hear any suggested or requested agenda items. -MSK From shollenbeck@verisign.com Wed Sep 12 03:57:31 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F3C21F84A0 for ; Wed, 12 Sep 2012 03:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-5qEl+-gP2Q for ; Wed, 12 Sep 2012 03:57:31 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id BB50321F84C9 for ; Wed, 12 Sep 2012 03:57:29 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUFBqmViJuXfo2UgB/LqavUt4xOJ2g+at@postini.com; Wed, 12 Sep 2012 03:57:30 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q8CAvQeT021679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 06:57:26 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 06:57:05 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Atlanta meeting request Thread-Index: AQHNj4OSGd6z9DuKtkKbJ1n6/wyLo5eGi1Mw Date: Wed, 12 Sep 2012 10:57:24 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D687B12@BRN1WNEXMBX02.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 Subject: Re: [weirds] Atlanta meeting request X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2012 10:57:32 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Murray S. Kucherawy > Sent: Monday, September 10, 2012 2:39 PM > To: weirds@ietf.org > Subject: [weirds] Atlanta meeting request >=20 > Colleagues, >=20 > I imagine it's a good guess that we want to meet in Atlanta. I'd like > some suggestions from the group as to what presentations we might want > other than the usual document status updates. What specific issues do > we feel need face time? How much time should we request? I have some open questions about security services in my security draft. Fa= ce-to-face discussion would be helpful. Scott From andy@arin.net Wed Sep 12 13:34:47 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE73721F85B4 for ; Wed, 12 Sep 2012 13:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp9CK8ohUuon for ; Wed, 12 Sep 2012 13:34:47 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5DA21F85AC for ; Wed, 12 Sep 2012 13:34:47 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id A0EC8164F28; Wed, 12 Sep 2012 16:34:46 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 51C15164F25; Wed, 12 Sep 2012 16:34:46 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 12 Sep 2012 16:34:33 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 16:34:44 -0400 From: Andy Newton To: "Murray S. Kucherawy" , "xiejiagui@cnnic.cn" Thread-Topic: [weirds] Status update Thread-Index: AQHNj2SukMUE3OUtMUyt7VO4xdgZQJeHLUcA Date: Wed, 12 Sep 2012 20:34:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Status update X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2012 20:34:48 -0000 On 9/10/12 10:57 AM, "Murray S. Kucherawy" wrote: >A fairly complete set would appear to be something like: > >draft-designteam-weirds-using-http >draft-hollenbeck-weirds-rdap-sec >draft-hollenbeck-weirds-unified-rdap-query >draft-newton-weirds-unified-json-response >draft-kucherawy-weirds-requirements (but only if we want to keep a >requirements document going) >[...] The redirection draft written by Carlos is not here. At the very least I think we need an informational on this topic. -andy From johnl@iecc.com Wed Sep 12 14:58:22 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3093E21F8608 for ; Wed, 12 Sep 2012 14:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyv3Pf41KMww for ; Wed, 12 Sep 2012 14:58:21 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CF8A921F85EF for ; Wed, 12 Sep 2012 14:58:20 -0700 (PDT) Received: (qmail 9705 invoked from network); 12 Sep 2012 21:58:18 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Sep 2012 21:58:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5051057a.xn--i8sz2z.k1208; i=johnl@user.iecc.com; bh=MTI/hOFY2oEV9smVQt9nhr/ntBjWG67/erDUEuDbtTo=; b=dWiVlSEUP43hEKl7CmoSNfJ6TmQw+R4sPW0ir8dPJgPkdJRX66pkqv1iB/z8f/iMIZFtLT/zA7NiYUqaw8RBX/htppumILnQ7/FdsEW/XAz/+NFgZK7kXqGZjDXYZwCZaHQKWRsZfpvBQvCu1Rg+/3VSv9gvR/jBJO87DcBGi9s= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5051057a.xn--i8sz2z.k1208; olt=johnl@user.iecc.com; bh=MTI/hOFY2oEV9smVQt9nhr/ntBjWG67/erDUEuDbtTo=; b=CXpVKIUuCwGA6gwTon6mnmnTP2Xw07ofOUqPzUdOWPoGaF+DXxqZkrTWotpMWzUqAWO0sLLofeN3m7RHmzm1zP32dsVMRpGkfvIJrUQcjOda+fEbsQKo58uh4mvF48CX05m3qSNNXonFCZ896Q+h6aej+7LUoxw8Pftor63Jh6Q= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Sep 2012 21:57:56 -0000 Message-ID: <20120912215756.49313.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D676FCF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2012 21:58:22 -0000 I support adopting all three of these as -00 drafts, so we can use them as a starting point for future work. >> https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-unified-rdap-query I have some minor niggles, but it's fine as an initial draft. >> https://datatracker.ietf.org/doc/draft-newton-weirds-unified-json-response Slightly more niggles, e.g., what fields are free format vs. fixed syntax, but nothing that can't be fixed. >> https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-sec This one needs more work, although I still would be OK adopting it as a -00 with the understanding that we'll be addressing questions like these: * Does authentication work by sessions, i.e., you authenticate and get a cookie or something to return for the rest of the session, or is each query authenticated from scratch? * Is there some way to do single sign on, authenticate yourself once and reuse the credentials at other sites? This could be handy for name WHOIS if there's a hundred domains run by the same entity but with separate servers, or ICANN does shared WHOIS accounts like they're doing shared ZFA accounts. * Assuming there's more than one authentication mechanism, how do you figure how to authenticate yourself to what server? There are probably others, but these ought to be enough to keep us busy for a while. By the way, I wouldn't dismiss client certs. Take a look at https://www.startssl.com/ which provides surprisingly good free SSL certs. When you set up an account, they provide an S/MIME cert that's installed into your browser, and then works to authenticate you to come back. Somewhat to my surprise, it really works, with multiple browsers. Exporting the cert from one browser to another is a minor pain, but no worse than remembering site passwords. R's, John From mnot@mnot.net Wed Sep 12 20:53:52 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7390421F84F5 for ; Wed, 12 Sep 2012 20:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.339 X-Spam-Level: X-Spam-Status: No, score=-103.339 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxrpbGAkOXwc for ; Wed, 12 Sep 2012 20:53:51 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6B95921F848F for ; Wed, 12 Sep 2012 20:53:51 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BBBCF22E257; Wed, 12 Sep 2012 23:53:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: Date: Thu, 13 Sep 2012 13:53:40 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <129E1551-0EEB-414E-8453-3E2D60A60751@mnot.net> References: To: Byron Ellacott X-Mailer: Apple Mail (2.1486) X-Mailman-Approved-At: Thu, 13 Sep 2012 12:55:06 -0700 Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2012 03:53:52 -0000 Hi, This has been in my inbox for a while; sorry for the delay. Chipping in from a HTTP / Web perspective -- There are lots of ways to convey links to clients, with different = properties based upon the use cases at hand. I'm not sure of the use = case here, so I'll speak in generalities.=20 The most important things, however, are: 1) You don't overload the semantics of HTTP (e.g., "when the FooApp = gives a 404 status code, it means...") 2) You don't impinge on the server's control of its URI space (e.g., = the /query/foo URI will mean...") 3) you don't confuse the implementation with the interface exposed = (hopefully self-explanatory) Doing any of these is very likely to violate the Web architecture, and = bring down the wrath of various HTTP/Web/URI folk upon you late in your = review process, leading to all kinds of mess. Just from what I read below, it seems like you're at risk of #2 and = possibly #3. YMMV. If you'd like document / idea review, I and I'm sure lots of other folks = would be willing to help, as long as it isn't too time-consuming; i.e., = you figure out your problem domain, we'll help with how you use the Web. Overall, the advice that I (and many others) give people designing = HTTP-based APIs is to start by defining the formats (identified by media = types), and use links (identified by link relations) to tie them = together. Hope this helps, On 06/08/2012, at 5:56 PM, Byron Ellacott wrote: > Hi Murray-as-participant, >=20 > On 06/08/2012, at 12:40 PM, Murray S. Kucherawy wrote: >=20 >> Please say so if there are other points I've missed on either list. >=20 > d) It's twice the number of HTTP requests for a simple lookup. >=20 > e) Clients might just bypass it anyway; in the numbers space, whatever = URI structure ARIN uses has a high likelihood of being hard coded into = many clients so they can skip the never changing step of fetching a URI = template to do exactly the same transform every time. This might happen = for .com's URI structure, particularly if there's a reference server = that a number of common TLDs all operate. >=20 > f) They complicate redirection - if we use an HTTP redirection code, a = client would fetch the URI templates list, create the URI for the = resource they want, issue a query, and get back (after redirection) = another URI templates list. Or the redirecting server is forced to act = as a proxy, introducing a whole new class of error conditions and = apparent quality of service based on a third party operator. >=20 > I don't think I raised these at the mic, though. >=20 >> I can say that I implemented a first REPUTE system using URI = templates >> and the implementation wasn't terribly difficult. The C library I >> used is now open source, and numerous other implementations also = exist >> in a variety of languages. Much of that code could easily be = recycled >> into weirds clients, removing much of the implementation complexity. >=20 > It's not hard, by any stretch of the imagination, but it is double the = work for the client: >=20 > --- with URI templates, you start here --- > 1. Fetch the URI template resource > 2. Parse the URI template resource > 3. Select the appropriate template, and parse that > --- without URI templates, you start here --- > 4. Fetch the data resource > 5. Parse the data resource > 6. Do something useful with the data resource >=20 > While the parsing of the template is presumably to be done by a = library, this is still a lot of boilerplate to stitch container parsing, = template selection, and library call together, given how trivial the = rest of the client would be. >=20 > I spoke at the microphone about URI templates solving a problem we = don't really have. By that, I mean we don't have a mapping problem, or = a (client-server) configuration problem, and we don't have such a = complex discovery problem that we need this solution for it. I find the = arguments in favour of URI templates to be non-compelling: >=20 > 1) If names and numbers diverge, a client is going to need to know how = to handle two different responses. You cannot gloss over differences = with a template for the query string. >=20 > 2) A server's architectural change is bound to the same number of = moving parts in its URI space as before, to accommodate the standard's = description of what variables might be found in a template. What = changes do you think could meaningfully be made to the noise around = "example.com" that wouldn't just be deck chair rearrangements? Isn't = best current web software architecture practice to loosely couple URLs = to service modules? >=20 > 3) All other behaviour once inside the protocol URI space is dictated = by the standard. I could say "servers own response data formats, not = standards" but it would be equally meaningless. The protocol owns the = conversation between clients and servers, and both how to ask and how to = respond are part of the protocol. >=20 > 4) There are no existing implementations of this as yet unspecified = protocol. Existing port 80 rest-like registration data directory = services do not return results in a compliant format, and may not = provide query entry points for the same aggregate roots; the URL = structure is the least of the impacts on similar existing services. >=20 > I am not, I admit, a web architecture expert, but to my layperson's = eyes the listed benefits to servers seem nebulous and more about = technical purity than technical benefit, while the costs to clients are = real, and relatively large. >=20 > Byron >=20 -- Mark Nottingham http://www.mnot.net/ From johnl@iecc.com Thu Sep 13 17:30:33 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DA621F866C for ; Thu, 13 Sep 2012 17:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QQByGvrHjN2 for ; Thu, 13 Sep 2012 17:30:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4797C21F863C for ; Thu, 13 Sep 2012 17:30:32 -0700 (PDT) Received: (qmail 27105 invoked from network); 14 Sep 2012 00:30:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Sep 2012 00:30:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50527aa7.xn--hew.k1208; i=johnl@user.iecc.com; bh=MrBFO6O4rbOyB1IUuY+3FgDlo0IFgF8tbUtIHC1NZ7A=; b=AnQLq+AHr4twcT3NkFsQuuARA8UPECaxMU+q6LMikRTtAgITAHHe2BRCtjx+tXNcJTgyOluHz5Q3ryQ0VVBqfwgkofB+pxX7LlhhLmpUoiFikcOkE1IDvluMEMjWoaJMs1LRCzOQhIpVwqAUIVsA4S2dPcQ9xWhSPgkFCpCXbvQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50527aa7.xn--hew.k1208; olt=johnl@user.iecc.com; bh=MrBFO6O4rbOyB1IUuY+3FgDlo0IFgF8tbUtIHC1NZ7A=; b=Fkh/XXiPR0HGcPawUVZTnDjcl13sFimoLRext1qqmG+8hrYIhUME58R3Z1BYrJaSn6vkwAa9vX2A0Yhul4lNQt4IHsYv7t85LoE9m37T5iDJ63PZpn9Bj5NdIzOn/is8Riu8znHVeONx89N4DMmCJ9Uj8H2xmiJkavNbUKNrOA0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Sep 2012 00:30:09 -0000 Message-ID: <20120914003009.29941.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <129E1551-0EEB-414E-8453-3E2D60A60751@mnot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: mnot@mnot.net Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 00:30:33 -0000 > 2) You don't impinge on the server's control of its URI space (e.g., the /query/foo URI will mean...") Wait, stop right there. We're building a design from scratch here, with constrained syntax and semantics. If someone wants to build a WEIRDS server, he or she can implement the URLs and return values that WEIRDS defines. There is no installed base, there are no existing web services that we have to work around. What possible advantage is there for WEIRDS to encourage server operators to invent different syntax and demand that clients kludge around it with an extra level of lookup and templates? R's, John From keith@blacknight.com Fri Sep 14 02:24:27 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52DD21F8528 for ; Fri, 14 Sep 2012 02:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo0+F6boC9Ff for ; Fri, 14 Sep 2012 02:24:27 -0700 (PDT) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68021F84DC for ; Fri, 14 Sep 2012 02:24:26 -0700 (PDT) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id C4A2658231; Fri, 14 Sep 2012 10:24:24 +0100 (IST) Date: Fri, 14 Sep 2012 10:24:24 +0100 From: Keith Gaughan Cc: weirds@ietf.org Message-ID: <20120914092424.GE6800@nineve.blacknight.ie> References: <20120913195523.C974333C35C@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120913195523.C974333C35C@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 09:24:27 -0000 On Thu, Sep 13, 2012 at 01:53:40PM +1000, Mark Nottingham wrote: > This has been in my inbox for a while; sorry for the delay. > > Chipping in from a HTTP / Web perspective -- > Overall, the advice that I (and many others) give people designing HTTP-based > APIs is to start by defining the formats (identified by media types), and use > links (identified by link relations) to tie them together. Thanks Mark. I tried to make these very same points back last September--almost a year to this day, in fast--when I attempted to propose the use of URI templates rather than hardcoded URL patterns in the spec, but was rebuffed. One of the arguments against it, if I recall, was implementation difficultly. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From keith@blacknight.com Fri Sep 14 02:42:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9336721F85F0 for ; Fri, 14 Sep 2012 02:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.279 X-Spam-Level: X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRa0YSZ4QYJu for ; Fri, 14 Sep 2012 02:42:04 -0700 (PDT) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id BDEAB21F85AC for ; Fri, 14 Sep 2012 02:42:04 -0700 (PDT) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id 3321358231; Fri, 14 Sep 2012 10:42:02 +0100 (IST) Date: Fri, 14 Sep 2012 10:42:02 +0100 From: Keith Gaughan To: weirds@ietf.org Message-ID: <20120914094202.GF6800@nineve.blacknight.ie> References: <129E1551-0EEB-414E-8453-3E2D60A60751@mnot.net> <20120914003105.871B633C36D@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120914003105.871B633C36D@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 09:42:05 -0000 On Fri, Sep 14, 2012 at 12:30:09AM -0000, John Levine wrote: > > 2) You don't impinge on the server's control of its URI space (e.g., the > > /query/foo URI will mean...") > > Wait, stop right there. We're building a design from scratch here, with > constrained syntax and semantics. If someone wants to build a WEIRDS server, > he or she can implement the URLs and return values that WEIRDS defines. There > is no installed base, there are no existing web services that we have to work > around. Then how about dropping the 'RESTful' bit from the description of WEIRDS? The argument *against* using URI templates are frankly weak. The difference between using them and not using them is a difference of where the information is given: is a spec, or in the server responses. That's the *only* difference. Really, it is. The various counterarguments make *very* little sense within the larger picture. For instance, the request multiplication issue is a non-issue because... caching! And besides, if this efficiency issue was really all that much of a big deal, then WEIRDS shouldn't be built on HTTP in the first place as it's a ludicrously inefficient protocol. The implementation complexity issue is a non issue because (a) there are plenty of URI template libraries out there and (b) it's not really all that difficult to implement anyway. The argument that people will ignore URI templates and just hardwire the URLs is maybe the weakest of the lot: it could be made with just about any part of the spec, and if people write broken clients, that's their problem, not ours. This is the difference between WEIRDS being "of the web" rather than simply "on the web". > What possible advantage is there for WEIRDS to encourage server > operators to invent different syntax and demand that clients kludge > around it with an extra level of lookup and templates? What other syntax? We're talking RFC 6570 here. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From andy@arin.net Fri Sep 14 06:00:46 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B157F21F84D2 for ; Fri, 14 Sep 2012 06:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+c2VhU7kpjg for ; Fri, 14 Sep 2012 06:00:46 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADEA21F84EA for ; Fri, 14 Sep 2012 06:00:46 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 4E7FE16543B; Fri, 14 Sep 2012 09:00:45 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id A267116542F; Fri, 14 Sep 2012 09:00:44 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 14 Sep 2012 09:00:23 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 09:00:43 -0400 From: Andy Newton To: Keith Gaughan , "weirds@ietf.org" Thread-Topic: [weirds] URI templates and WEIRDS Thread-Index: AQHNkl0xeVjwvLFVOEGNSOTXei1gS5eJzSiA Date: Fri, 14 Sep 2012 13:00:43 +0000 Message-ID: In-Reply-To: <20120914094202.GF6800@nineve.blacknight.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 13:00:46 -0000 On 9/14/12 5:42 AM, "Keith Gaughan" wrote: >Then how about dropping the 'RESTful' bit from the description of WEIRDS? What do you think "RESTful" means? > >For instance, the request multiplication issue is a non-issue >because... caching! A lot of HTTP libraries do not do caching. So that would have to be another thing clients would need to implement. > >The argument that >people will ignore URI templates and just hardwire the URLs is maybe the >weakest >of the lot: it could be made with just about any part of the spec, and if >people >write broken clients, that's their problem, not ours. Well, we know people hardcode Whois server IP addresses. We've turned down nodes only to come back a year later to find that IP still getting port 43 queries. Happens with DNS servers too. And people writing broken clients is a concern server operators have. Just ask anybody dealing with those DNSSEC amplification issues. > >This is the difference between WEIRDS being "of the web" rather than >simply "on >the web". I'm not really sure what you mean by this. But it seems to me that if somebody wants to be "of the web" they could just put a URI template file on their server while still adhering to a non-URI templated spec. Does "of the web" offer new functionality? Because that would be interesting. But the idea that we need URI templates to avoid HTTP URL path collisions (#2 in the list offered by Mark) is incorrect. So long as the base path is not hardcoded, path collisions can be avoided. I think the question to be asked of URI templates is this: what new feature do we get? -andy From julian.reschke@gmx.de Fri Sep 14 06:43:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BAA21F84FD for ; Fri, 14 Sep 2012 06:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.958 X-Spam-Level: X-Spam-Status: No, score=-103.958 tagged_above=-999 required=5 tests=[AWL=-1.359, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AofH+czUpJP for ; Fri, 14 Sep 2012 06:43:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5F00621F84F2 for ; Fri, 14 Sep 2012 06:43:24 -0700 (PDT) Received: (qmail invoked by alias); 14 Sep 2012 13:43:22 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 14 Sep 2012 15:43:22 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/zC2NcIdrzK8YcVCDsMXxX7GsF/l+m+/rgUYKmvM +ZpBUhx9pmt5D7 Message-ID: <50533478.3040003@gmx.de> Date: Fri, 14 Sep 2012 15:43:20 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "weirds@ietf.org" Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 13:43:25 -0000 On 2012-09-14 15:00, Andy Newton wrote: > > > On 9/14/12 5:42 AM, "Keith Gaughan" wrote: > >> Then how about dropping the 'RESTful' bit from the description of WEIRDS? > > What do you think "RESTful" means? > ... My take: "adhering to REST principles". Sure, one can argue whether you need to adhere to *all* of them or not. But in this case I really have the impression that the label "restful" was used here just because it is en vogue. Best regards, Julian From andy@arin.net Fri Sep 14 07:32:36 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CED821F84DD for ; Fri, 14 Sep 2012 07:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT3dA0dgWGg3 for ; Fri, 14 Sep 2012 07:32:31 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id D89AE21F84D5 for ; Fri, 14 Sep 2012 07:32:30 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 43647213694; Fri, 14 Sep 2012 10:32:30 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 994F621368B; Fri, 14 Sep 2012 10:32:29 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 14 Sep 2012 10:32:08 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 10:32:29 -0400 From: Andy Newton To: Julian Reschke Thread-Topic: [weirds] URI templates and WEIRDS Thread-Index: AQHNkl0xeVjwvLFVOEGNSOTXei1gS5eJzSiAgABO+QD//8qpgA== Date: Fri, 14 Sep 2012 14:32:27 +0000 Message-ID: In-Reply-To: <50533478.3040003@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <5D52BA13F46A2841BED11DE2757E4D9B@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 14:32:36 -0000 On 9/14/12 9:43 AM, "Julian Reschke" wrote: >On 2012-09-14 15:00, Andy Newton wrote: >> >> >> On 9/14/12 5:42 AM, "Keith Gaughan" wrote: >> >>> Then how about dropping the 'RESTful' bit from the description of >>>WEIRDS? >> >> What do you think "RESTful" means? >> ... > >My take: "adhering to REST principles". > >Sure, one can argue whether you need to adhere to *all* of them or not. >But in this case I really have the impression that the label "restful" >was used here just because it is en vogue. So you think what we are describing in the drafts given looks closer to a SOAP web service or an HTTP API with service specific verbs than like REST? I believe you first showed us this great tool: http://isitrestful.com :) Back to my question about URI templates: what new feature does it bring to the table? Satisfying a purity argument about REST is not a protocol or usage feature. -andy From carlosm3011@gmail.com Fri Sep 14 07:58:20 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D3E21F84B2 for ; Fri, 14 Sep 2012 07:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwu00ebFPYqx for ; Fri, 14 Sep 2012 07:58:20 -0700 (PDT) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1212321F84AF for ; Fri, 14 Sep 2012 07:58:19 -0700 (PDT) Received: by vbmv11 with SMTP id v11so8376301vbm.27 for ; Fri, 14 Sep 2012 07:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/caY/UXIlBq40v5j7T5zvy6/rgITQ7yQdNXb4707IPM=; b=pa2GDjvnwLgwyAyJZ2Ha1YNQZ/m4TwCIhHMxor0hpclNhuxpB0F00RIXSRCcRomiIR UFhniVoX++JaxFcgm7aDlsjLM7XOQVHyK8S8LGfl26sy2baAsOs5380LfuO9685Iamqe v2Tstec0vYwvYnNHZv5JTW9e60j/be1D72kfcNFGptug9CzdYqz3uvbro/sZpBdJ+Sft W8Ul/J/Rtd6wTr/QdSzD5zk5XTGP2jjMf5+2kmPnmkdVlZOjrzE9r0Edi/QENuaGlgUL U3F05qJWXRUI+txgPrdwBT4XxGdzqw+WGcv3zE9ICveSgR0Px2gJN5GYJUZ/uScU08IH ru/g== Received: by 10.220.218.144 with SMTP id hq16mr2344545vcb.61.1347634699482; Fri, 14 Sep 2012 07:58:19 -0700 (PDT) Received: from europa.local ([200.7.87.205]) by mx.google.com with ESMTPS id b3sm393284vec.11.2012.09.14.07.58.17 (version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 07:58:18 -0700 (PDT) Message-ID: <5053460B.6030908@gmail.com> Date: Fri, 14 Sep 2012 11:58:19 -0300 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Keith Gaughan References: <129E1551-0EEB-414E-8453-3E2D60A60751@mnot.net> <20120914003105.871B633C36D@merlin.blacknight.ie> <20120914094202.GF6800@nineve.blacknight.ie> In-Reply-To: <20120914094202.GF6800@nineve.blacknight.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 14:58:20 -0000 Hello, My opinion on the matter has not changed during the past year: URI templates look like a nice solution to a problem this WG doesn't have. The efficiency point is still valid and relevant: as Andy noted, most WEIRDS clients won't be browsers but rather specially-crafted pieces of software unlikely to implement any form of caching of HTTP objects, which will be performing hundreds or thousands queries per hour in some cases. We (LACNIC) already have one customer of our prototype of this kind (a CSIRT in Spain). Each RTT is ~300 msec, so the extra query is, IMO, too large a tax. As others also put it, if the whole argument revolves around concerns about the 'correct' (by some definition**) usage of the term RESTful, I'd rather drop it. cheers! ~Carlos **: I'm 'holding in my hand' (metaphorically, as it is a PDF file) a copy of 'RESTful WebServices Cookbook' from O'Reilly, 2010 edition, and it doesn't even come close to saying that URI templates are mandatory for an interface to be qualified as 'RESTful', it even has a recipe (5.7) named 'When and How to use URI Templates' which is less than 2 pages long over a 314-page book. Recipe 4.3 even says 'Neither the architectural constraints of REST nor HTTP require that clients treat URIs as opaque. Doing so reduces coupling...'. So again, I'm not convinced we need URI templates in WEIRDS. On 9/14/12 6:42 AM, Keith Gaughan wrote: > On Fri, Sep 14, 2012 at 12:30:09AM -0000, John Levine wrote: > >>> 2) You don't impinge on the server's control of its URI space (e.g., the >>> /query/foo URI will mean...") >> >> Wait, stop right there. We're building a design from scratch here, with >> constrained syntax and semantics. If someone wants to build a WEIRDS server, >> he or she can implement the URLs and return values that WEIRDS defines. There >> is no installed base, there are no existing web services that we have to work >> around. > > Then how about dropping the 'RESTful' bit from the description of WEIRDS? > > The argument *against* using URI templates are frankly weak. The difference > between using them and not using them is a difference of where the information > is given: is a spec, or in the server responses. That's the *only* difference. > Really, it is. The various counterarguments make *very* little sense within the > larger picture. For instance, the request multiplication issue is a non-issue > because... caching! And besides, if this efficiency issue was really all that > much of a big deal, then WEIRDS shouldn't be built on HTTP in the first place as > it's a ludicrously inefficient protocol. The implementation complexity issue is > a non issue because (a) there are plenty of URI template libraries out there and > (b) it's not really all that difficult to implement anyway. The argument that > people will ignore URI templates and just hardwire the URLs is maybe the weakest > of the lot: it could be made with just about any part of the spec, and if people > write broken clients, that's their problem, not ours. > > This is the difference between WEIRDS being "of the web" rather than simply "on > the web". > >> What possible advantage is there for WEIRDS to encourage server >> operators to invent different syntax and demand that clients kludge >> around it with an extra level of lookup and templates? > > What other syntax? We're talking RFC 6570 here. > > K. > From johnl@iecc.com Fri Sep 14 08:22:42 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06DD21F84EB for ; Fri, 14 Sep 2012 08:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41mNr+44XSZA for ; Fri, 14 Sep 2012 08:22:42 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AB2E221F850D for ; Fri, 14 Sep 2012 08:22:41 -0700 (PDT) Received: (qmail 40317 invoked from network); 14 Sep 2012 15:22:41 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Sep 2012 15:22:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50534bc0.xn--btvx9d.k1208; i=johnl@user.iecc.com; bh=6NiEAkJQnDKY3GD/+hQmSfEyy/wcpKCTbFrxsDGiX/Q=; b=G8pDWgFVMVJbBiaV9Udp3sCPKxJUSGphMF7j2cvEQYDakezk8xM1QP56SdByQESOQCUD4yLcYziKN9Ce5a9nzGUAfrbUQQHXov0ekfm6l3TpUhF02ma30xsPWq3mRaegy0oD7IMmv0GCKGchiDt3p44kqIFABV2tmpKJr3Ca3cg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50534bc0.xn--btvx9d.k1208; olt=johnl@user.iecc.com; bh=6NiEAkJQnDKY3GD/+hQmSfEyy/wcpKCTbFrxsDGiX/Q=; b=cgEV9Tn0P6aFciz1J8Fq9+JjOBBgfU5ll3FqcFoC9VzsYH06iTkgOfQT6VJLN05xK43fjEQdknd77AqSvrrPhpimiY6dWA4jDv4zJBzKiqV48Eb6qesU0knY6km+P9Es0QrL26RVnAsSYKLEOv8COoNfIS9wxbP+KOGUTD+gvj0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Sep 2012 15:22:18 -0000 Message-ID: <20120914152218.31555.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <5053460B.6030908@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 15:22:43 -0000 >My opinion on the matter has not changed during the past year: URI >templates look like a nice solution to a problem this WG doesn't have. ... +1, and to the performance stuff I snipped >As others also put it, if the whole argument revolves around concerns >about the 'correct' (by some definition**) usage of the term RESTful, >I'd rather drop it. I would cheerfully change all of the mentions of "RESTful" to "fluffy bunny" in the charter if it would make this argument go away. R's, John From dblumenthal@pir.org Fri Sep 14 08:37:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E0321F851C for ; Fri, 14 Sep 2012 08:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.076 X-Spam-Level: X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlFDcf4H7iJS for ; Fri, 14 Sep 2012 08:37:07 -0700 (PDT) Received: from mail.pir.org (173-10-164-41-BusName-washingtonDC.hfc.comcastbusiness.net [173.10.164.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2AE21F850D for ; Fri, 14 Sep 2012 08:37:06 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Fri, 14 Sep 2012 11:37:05 -0400 From: Don Blumenthal To: "weirds@ietf.org" Date: Fri, 14 Sep 2012 11:37:02 -0400 Thread-Topic: ICANN Survey Thread-Index: Ac2SjsswH1LglyIaRRSsOy6ycPXpaw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] ICANN Survey X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 15:37:08 -0000 Semi OT, but ICANN posted a survey last night, asking for thoughts on possi= ble Whois technical (as opposed to policy) requirements. I am part of the W= orking Group that put it together, and figured that contributions from folk= s o this list would be particularly valuable. Here is the ICANN announcement: http://gnso.icann.org/en/announcements/anno= uncement-13sep12-en.htm Thanks. Don From fobispo@isc.org Fri Sep 14 09:16:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12E721F850D for ; Fri, 14 Sep 2012 09:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEl+YXGVm0iw for ; Fri, 14 Sep 2012 09:16:05 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3C66B21F8503 for ; Fri, 14 Sep 2012 09:16:05 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1AF32C9561; Fri, 14 Sep 2012 16:16:03 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:470:1f05:1326:e42d:dd02:c5ed:2d93] (unknown [IPv6:2001:470:1f05:1326:e42d:dd02:c5ed:2d93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B556E216C43; Fri, 14 Sep 2012 16:16:02 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: <5053460B.6030908@gmail.com> Date: Fri, 14 Sep 2012 09:16:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <129E1551-0EEB-414E-8453-3E2D60A60751@mnot.net> <20120914003105.871B633C36D@merlin.blacknight.ie> <20120914094202.GF6800@nineve.blacknight.ie> <5053460B.6030908@gmail.com> To: Carlos M. martinez X-Mailer: Apple Mail (2.1486) Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 16:16:05 -0000 I'm not sure about this. ICANN wants to have a reference implementation, that includes a Port 43 = whois to RDAP proxy, and it would be ideal for it to have some sort of = caching in front of it, however, if it can't make distinction between = objects it will be limited to caching query/response pairs, which is = very inefficient (better than no caching but still inefficient). I don't like making assumptions about third party software, but it would = be nice if we could provide the ability to provide various cacheable = objects in the response. One more reason for having an enclosure format + object definitions in = namespace like structures .. regards On Sep 14, 2012, at 7:58 AM, Carlos M. martinez = wrote: > software unlikely to implement any form of caching of HTTP objects, > which will be performing hundreds or thousands queries per hour in = some > cases. Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From andy@arin.net Fri Sep 14 09:39:15 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC27321F84B2 for ; Fri, 14 Sep 2012 09:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5PsctAQkN64 for ; Fri, 14 Sep 2012 09:39:15 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 207D321F8497 for ; Fri, 14 Sep 2012 09:39:15 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 87936165472; Fri, 14 Sep 2012 12:39:14 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id B735E16546C; Fri, 14 Sep 2012 12:39:13 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 14 Sep 2012 12:38:46 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 12:39:07 -0400 From: Andy Newton To: Francisco Obispo , Carlos M.martinez Thread-Topic: [weirds] URI templates and WEIRDS Thread-Index: AQHNkl0xeVjwvLFVOEGNSOTXei1gS5eKMRSAgAAVtoD//8NiAA== Date: Fri, 14 Sep 2012 16:39:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <917BD8C48FE21441A153AB9D00ED36B3@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 16:39:15 -0000 Having written such a beast, I can tell you that the performance improvement comes from caching the rendered result and preventing the requery. Caching the query/response pairs is not as inefficient as you make it out to be. In fact, MySQL does that to great effect at the database level. Also, that's exactly what an HTTP proxy or cache would be doing. And it is not an enclosure format that enables fine grained cache semantics, it is an object reference (see 'handle'). -andy On 9/14/12 12:16 PM, "Francisco Obispo" wrote: >I'm not sure about this. > >ICANN wants to have a reference implementation, that includes a Port 43 >whois to RDAP proxy, and it would be ideal for it to have some sort of >caching in front of it, however, if it can't make distinction between >objects it will be limited to caching query/response pairs, which is very >inefficient (better than no caching but still inefficient). > >I don't like making assumptions about third party software, but it would >be nice if we could provide the ability to provide various cacheable >objects in the response. > >One more reason for having an enclosure format + object definitions in >namespace like structures .. > >regards > > >On Sep 14, 2012, at 7:58 AM, Carlos M. martinez >wrote: > >> software unlikely to implement any form of caching of HTTP objects, >> which will be performing hundreds or thousands queries per hour in some >> cases. > >Francisco Obispo=20 >email: fobispo@isc.org >Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >PGP KeyID =3D B38DB1BE > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From superuser@gmail.com Fri Sep 14 11:16:41 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60C921F8546 for ; Fri, 14 Sep 2012 11:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lqwD5ZcsILn for ; Fri, 14 Sep 2012 11:16:41 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD5ED21F8543 for ; Fri, 14 Sep 2012 11:16:40 -0700 (PDT) Received: by lahm15 with SMTP id m15so3111809lah.31 for ; Fri, 14 Sep 2012 11:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YhMDzxs43enCxmgKyTEH/i4iOHJmOgGkHrxDTkUaA+Y=; b=YxUzSnNH/4IrmQsruFatN3m62PhAduF/XC4j+WdC1CoxSr0Zlm4EMCVfAA9PYIKtMw IM5Nz8C3r152TW7FP9B07svo6/2ZajpUaJpu7PRcfK5o6r4/besf1qZwR3GCJgKQbs3I ygWFfY9N33r5P4Av6/UaaKQSTpvxfQ/TRm9Hlig22YYWFg24buWZFKPN+hpqRXfb4ZuG Krd8tWm1qrKERSOZ5Z5t4j3koNdTH+XHapxe5jGoLC3tPZoKA02cddRJSlDRTFvo2aeV DchT+am9bMQwqbPy9tEvv1+Uhx1bzu12BynCYlBl39vQVoRLQkFlCia2qxpWQ/UWRges Ynwg== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr1383395lbh.85.1347646599814; Fri, 14 Sep 2012 11:16:39 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 14 Sep 2012 11:16:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Sep 2012 11:16:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Don Blumenthal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "weirds@ietf.org" Subject: Re: [weirds] ICANN Survey X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 18:16:41 -0000 On Fri, Sep 14, 2012 at 8:37 AM, Don Blumenthal wrote= : > Semi OT, but ICANN posted a survey last night, asking for thoughts on pos= sible Whois technical (as opposed to policy) requirements. I am part of the= Working Group that put it together, and figured that contributions from fo= lks o this list would be particularly valuable. > > Here is the ICANN announcement: http://gnso.icann.org/en/announcements/an= nouncement-13sep12-en.htm Thanks, Don. How fast will ICANN turn this into a summary after the period closes? As we're preparing to import documents and start working on them, it would be helpful to have this information available sooner rather than later, whether or not we actually use what's in it. -MSK From fobispo@isc.org Fri Sep 14 11:35:57 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BA621F8545 for ; Fri, 14 Sep 2012 11:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65PvZ3WRFmgt for ; Fri, 14 Sep 2012 11:35:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E0A1421F853E for ; Fri, 14 Sep 2012 11:35:56 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id E06D0C94B2; Fri, 14 Sep 2012 18:35:49 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:899a:fbb6:8055:7157] (unknown [IPv6:2001:4f8:3:64:899a:fbb6:8055:7157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D59AC216C43; Fri, 14 Sep 2012 18:35:49 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: Date: Fri, 14 Sep 2012 11:35:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <675879AF-7E1D-4028-AA39-07B95E7E3380@isc.org> References: To: Andy Newton X-Mailer: Apple Mail (2.1486) Cc: "weirds@ietf.org" Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 18:35:57 -0000 I would say that it depends on the architecture. I also have an implementation that uses Memcached in the P43 whois = proxy, and caches individual objects in memory. It is capable of only = fetching in the backend cache-missed objects, thus reducing the amount = of queries to the database and improving frontend performance. We can easily scale the system by adding more front end whois servers, = which are cheaper than high end database servers.. But that's an implementation issue..., and there is more than one way to = do it. If we have the need to map another use case, I'm worried that the = current model will not make that very easy. In the search for = simplicity, we will loose functionality (reusability). It's a balance = that the working group will have to leverage. Francisco On Sep 14, 2012, at 9:39 AM, Andy Newton wrote: > Having written such a beast, I can tell you that the performance > improvement comes from caching the rendered result and preventing the > requery. Caching the query/response pairs is not as inefficient as you > make it out to be. In fact, MySQL does that to great effect at the > database level. Also, that's exactly what an HTTP proxy or cache would = be > doing. >=20 > And it is not an enclosure format that enables fine grained cache > semantics, it is an object reference (see 'handle'). >=20 > -andy >=20 > On 9/14/12 12:16 PM, "Francisco Obispo" wrote: >=20 >=20 Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From johnl@iecc.com Fri Sep 14 12:31:29 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F7821F852C for ; Fri, 14 Sep 2012 12:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu4jlQe1nERs for ; Fri, 14 Sep 2012 12:31:29 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 13D0D21F8532 for ; Fri, 14 Sep 2012 12:31:28 -0700 (PDT) Received: (qmail 7612 invoked from network); 14 Sep 2012 19:31:28 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Sep 2012 19:31:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50538610.xn--3zv.k1208; i=johnl@user.iecc.com; bh=DdiQ827yKFy1ACufP1cJ16KWhvxgO5oktqDka+zQSDE=; b=IMyvwIV0EPwtA8aULSITpaMQSb/kse7sdCooGT1uk73OwaDQJz34nS2OZ771gMbTHcFLtkfrKcRj2RBaheCwfGZmvuBynipNJ/qCAn5TN1+SjTam0lgpyUDnpQucprCh20Q1tQpw0vBuk893kuvjJM9ZBSNZQbYIZitHGUQZGok= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50538610.xn--3zv.k1208; olt=johnl@user.iecc.com; bh=DdiQ827yKFy1ACufP1cJ16KWhvxgO5oktqDka+zQSDE=; b=lZ34vQh/gXb1SkRT+PAZ+5/DiggdfGgdZ0uWyG2XmUGu5dPpb2PC/7e8lE5QR1X4lU3CZ7hJwgzlB4Q87nWF2kDvd/pUXNp0jGYOSnw7thCVdwH1kziwZGCPHlAtNVBLDN2mgt73sFxrOnGPlK0WygYvpO917iOWbR+3pG0+Sc8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Sep 2012 19:31:06 -0000 Message-ID: <20120914193106.10146.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] ICANN Survey X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 19:31:29 -0000 >How fast will ICANN turn this into a summary after the period closes? In my experience, it takes quite a while for them to produce summaries, a month or more. I gather they're totally swamped by the new TLD applications, so it may be even longer now. So don't make any plans that depend on seeing the results of the survey. It may well be interesting, but I'd be amazed if it told us anything that would change in any important way what we're planning to do. R's, John From johnl@iecc.com Fri Sep 14 12:40:15 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BEB21F854F for ; Fri, 14 Sep 2012 12:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBEiy7jVKhdj for ; Fri, 14 Sep 2012 12:40:14 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 38E9A21F853E for ; Fri, 14 Sep 2012 12:40:14 -0700 (PDT) Received: (qmail 10024 invoked from network); 14 Sep 2012 19:40:12 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Sep 2012 19:40:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5053881c.xn--3zv.k1208; i=johnl@user.iecc.com; bh=q8YHpcl13UTBtqEWGFiIh08rEByV5f5EUYm2LyCaTGc=; b=BDyYps6ZFSRBAKHzY+ruUXYUgVNOtthWl8RS/uv3qH/QXOR/NPcamy7F9yzwa5xlhqphHfN8F03yPKSMmSexiXeWj1dnK1z+VB9bX734y9x4oY0TxgbvqQk7bzSvsDMbCxa11ba908++39k7yPavWFnqh0YKI9uewfLRajg+Uz0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5053881c.xn--3zv.k1208; olt=johnl@user.iecc.com; bh=q8YHpcl13UTBtqEWGFiIh08rEByV5f5EUYm2LyCaTGc=; b=aeyJBcjkN3mmDU0I4g/H7GIhCHnFANOEB3GAsueTpeEhQ2SzGHkvuLhu9OYGP81ArhTzoxxIy3QjA5wZgD8PDKTaDKJ2DfWlTx8+0/OJSOrEvYvcxkmureTT16p+d831KyD6wMRAln0+nfZ5h/kLxSclP7NWWTNnt/3fyJiQl44= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Sep 2012 19:39:50 -0000 Message-ID: <20120914193950.12540.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <675879AF-7E1D-4028-AA39-07B95E7E3380@isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 19:40:15 -0000 >If we have the need to map another use case, I'm worried that the current model will not make that >very easy. In the search for simplicity, we will loose functionality (reusability). It's a balance >that the working group will have to leverage. Seems to me that we've had domain and IP WHOIS for several decades, and the use cases are the same now as they were in the 1990s. I'm much more concerned about building something that is stable and scalable, and that is well enough specified that if there are 2000 or more registry WEIRDS servers and a thousand registrar servers, my client software can query them all the same way. R's, John From fobispo@isc.org Fri Sep 14 12:46:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A7721F8527 for ; Fri, 14 Sep 2012 12:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F3CfePCRNj8 for ; Fri, 14 Sep 2012 12:46:05 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 54A1021F84D3 for ; Fri, 14 Sep 2012 12:46:05 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id AF7635F98B1; Fri, 14 Sep 2012 19:45:55 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:899a:fbb6:8055:7157] (unknown [IPv6:2001:4f8:3:64:899a:fbb6:8055:7157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AE90B216C43; Fri, 14 Sep 2012 19:45:53 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: <20120914193950.12540.qmail@joyce.lan> Date: Fri, 14 Sep 2012 12:45:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120914193950.12540.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1486) Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 19:46:05 -0000 On Sep 14, 2012, at 12:39 PM, "John Levine" wrote: > Seems to me that we've had domain and IP WHOIS for several decades, > and the use cases are the same now as they were in the 1990s. =20 Yes, but how many other areas are now using the internet as the core of = their business (compared to the 1990s)?? I've already seen discussions = about registries that can serve more than just domain names, and IP = numbers, talking about Trademarks, etc..=20 > I'm > much more concerned about building something that is stable and > scalable, and that is well enough specified that if there are 2000 or > more registry WEIRDS servers and a thousand registrar servers, my > client software can query them all the same way. I don't have a problem with querying them all the same way, I have a = problem with returning the data in a _consistent_ way and not mixing up = data from one object type with another.. Consider the different models = and policies that exist today with ccTLDs, and you will notice that one = size does not fit all. Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From johnl@taugh.com Fri Sep 14 13:17:15 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F2A21F854A for ; Fri, 14 Sep 2012 13:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phPePx98QN42 for ; Fri, 14 Sep 2012 13:17:14 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 53DCB21F853E for ; Fri, 14 Sep 2012 13:17:14 -0700 (PDT) Received: (qmail 19676 invoked from network); 14 Sep 2012 20:17:11 -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:vbr-info:user-agent:cleverness; s=4cdb.505390c7.k1209; bh=9z7XS2FHbvo9pt8A4TJF7r+WLvJ/SmaTIhI9k22bMAo=; b=liYtgcqtUu/lesUJBtgkELiiwEX7e93uwvpqdCfhxsnM1V8EFheLScdDFiw3BP+1NwWmweoHNaKW5KE1wD+vVzI5RGhjPPKPYika6q6A4Kr8ys90o4aVhF0ZNNCA7aY1yi1W23D2cdzXbrjq2ogHO0JUNnRQQ12gvubFcwtKD5E= 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:vbr-info:user-agent:cleverness; s=4cdb.505390c7.k1209; bh=9z7XS2FHbvo9pt8A4TJF7r+WLvJ/SmaTIhI9k22bMAo=; b=nfYaUtB3TPEls2ADpJ5x/sUwj/+9v8rKiovi/eTzJc/EHpjbXnw236hzXTZW4ibxcWfwSW3NfdxtBrEmLbGxKJeyQEZZ2h5T28HWwKYczkI/lIy2Lyuad9/1JkWjhg2JATmToh0IjxxolMl2QE9sZdcPVDNG6qyq0X81F1eqQS8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 14 Sep 2012 20:16:49 -0000 Date: 14 Sep 2012 16:17:11 -0400 Message-ID: From: "John R Levine" To: "Francisco Obispo" In-Reply-To: References: <20120914193950.12540.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 20:17:15 -0000 >> Seems to me that we've had domain and IP WHOIS for several decades, >> and the use cases are the same now as they were in the 1990s. > > Yes, but how many other areas are now using the internet as the core of > their business (compared to the 1990s)?? I've already seen discussions > about registries that can serve more than just domain names, and IP > numbers, talking about Trademarks, etc.. If someone wants to set up a trademark registry, I suppose that's OK (actually, it's a dreadful idea, but for now we'll stick to the technical issues.) But the questions are going to be different from the ones about IPs or domain names, the answers will be different, and the back end database will be different. All that will really be the same is the http framework and the json software, both of which are generic. It's not our job to solve their problems, and even if we thought that it were, we'd have little to offer beyond what's already available off the shelf. >> scalable, and that is well enough specified that if there are 2000 or >> more registry WEIRDS servers and a thousand registrar servers, my >> client software can query them all the same way. > > I don't have a problem with querying them all the same way, I have a > problem with returning the data in a _consistent_ way and not mixing up > data from one object type with another. Consider the different models > and policies that exist today with ccTLDs, and you will notice that one > size does not fit all. No kidding. We're going to have enough trouble solving the problems we do have, without adding hypothetical extenstions for problems we don't have. Having seen the talk about the field inventory in Vancouver, I think we can come up with a design that can describe them all, but it'll take some hard work and experiments. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From fobispo@isc.org Fri Sep 14 13:28:01 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83C921F851C for ; Fri, 14 Sep 2012 13:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POm0zNs5gK1A for ; Fri, 14 Sep 2012 13:28:01 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0A32521F84EB for ; Fri, 14 Sep 2012 13:28:01 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id E032B5F98BF; Fri, 14 Sep 2012 20:27:49 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:899a:fbb6:8055:7157] (unknown [IPv6:2001:4f8:3:64:899a:fbb6:8055:7157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 33EF4216C3B; Fri, 14 Sep 2012 20:27:48 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: Date: Fri, 14 Sep 2012 13:27:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <86EE6824-0188-4EC4-90A0-5F47F157BEFC@isc.org> References: <20120914193950.12540.qmail@joyce.lan> To: "John R Levine" X-Mailer: Apple Mail (2.1486) Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 20:28:01 -0000 On Sep 14, 2012, at 1:17 PM, "John R Levine" wrote: >>=20 >> Yes, but how many other areas are now using the internet as the core = of their business (compared to the 1990s)?? I've already seen = discussions about registries that can serve more than just domain names, = and IP numbers, talking about Trademarks, etc.. >=20 > If someone wants to set up a trademark registry, I suppose that's OK = (actually, it's a dreadful idea, but for now we'll stick to the = technical issues.) But the questions are going to be different from the = ones about IPs or domain names, the answers will be different, and the = back end database will be different. All that will really be the same = is the http framework and the json software, both of which are generic. = It's not our job to solve their problems, and even if we thought that it = were, we'd have little to offer beyond what's already available off the = shelf. >=20 Which is why I believe the problem can be solved in two different parts, = 1) A standard enclosure format that is capable of transporting _any_ = type of object, and 2) the object definitions for both names and = numbers. >>>=20 >>=20 >> I don't have a problem with querying them all the same way, I have a = problem with returning the data in a _consistent_ way and not mixing up = data from one object type with another. Consider the different models = and policies that exist today with ccTLDs, and you will notice that one = size does not fit all. >=20 > No kidding. We're going to have enough trouble solving the problems = we do have, without adding hypothetical extenstions for problems we = don't have. Having seen the talk about the field inventory in Vancouver, = I think we can come up with a design that can describe them all, but = it'll take some hard work and experiments. >=20 That's my point, We _don't_ need to solve them all, rather provide some common object = templates that can be used across _all_, and an proper extension = mechanism that allows for the additional use cases. If someone wants to build a trademark registry (to follow up on the = example), they just need to define the new object types and that's it.. = guess what, they can do that with EPP already, so why not make it = explicit for RDAP ? I want to make sure we don't lock ourselves in a protocol that will = require a similar effort in 10-20 years, because it was not flexible = enough to evolve. Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From johnl@taugh.com Fri Sep 14 15:00:39 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BD421F8443 for ; Fri, 14 Sep 2012 15:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcibABgVvrjW for ; Fri, 14 Sep 2012 15:00:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 921E521F8460 for ; Fri, 14 Sep 2012 15:00:38 -0700 (PDT) Received: (qmail 45048 invoked from network); 14 Sep 2012 22:00:37 -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:vbr-info:user-agent:cleverness; s=aff7.5053a905.k1209; bh=pqkUojoTyn6GXy/bt7TX0tzTtDT4hLgvKwCsI9SJQ7E=; b=caSR0QGdTc0rYqPOWGB1JJoIdGQf3Fzo3BuAg6XFae3OpnTg+jKLNnGnFW9y3Zos5kqEyum+D6kz4sNH+aXKdNhAkEWL3s4juOA9liYrCowFycx953aLC9UtJZgrmrpefdbz9XadwHtatrOFfurRRT/wO1HA8+otqKF/0YFpd4c= 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:vbr-info:user-agent:cleverness; s=aff7.5053a905.k1209; bh=pqkUojoTyn6GXy/bt7TX0tzTtDT4hLgvKwCsI9SJQ7E=; b=Vhm6pmjbzNqGj/dPJPYKC7nlE2ntvSwIvlONjDKxO20U0hljvryRWcHLLhB0L6BPbWbozwad3GMQVooghcLltSBQr4zT/8wEF9rATGRoxq8FPsjdf8V4Yq+MmxU1Qir4j3UHzteC3kjIEpUBsmM85WEVlDDGqr53lECySBYG5lU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 14 Sep 2012 22:00:15 -0000 Date: 14 Sep 2012 18:00:36 -0400 Message-ID: From: "John R Levine" To: "Francisco Obispo" In-Reply-To: <86EE6824-0188-4EC4-90A0-5F47F157BEFC@isc.org> References: <20120914193950.12540.qmail@joyce.lan> <86EE6824-0188-4EC4-90A0-5F47F157BEFC@isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 22:00:39 -0000 > We _don't_ need to solve them all, rather provide some common object > templates that can be used across _all_, and an proper extension > mechanism that allows for the additional use cases. That would be complete failure. If a WEIRDS client can't query and parse the results mechanically, without having to add extra special extension cases for every registry and registrar, we'd be no better off than we are now. > I want to make sure we don't lock ourselves in a protocol that will > require a similar effort in 10-20 years, Since WHOIS hasn't changed materially in 20 years, I see no reason to add extra complication for purely hypothetical problems in the distant future, particularly if they mean that we won't solve the problems that we're here to solve. R's, John From fobispo@isc.org Fri Sep 14 15:41:34 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3799221F8526 for ; Fri, 14 Sep 2012 15:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SjfGOgAOAb5 for ; Fri, 14 Sep 2012 15:41:33 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 507D821F845B for ; Fri, 14 Sep 2012 15:41:33 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 587DAC94BF; Fri, 14 Sep 2012 22:41:27 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:899a:fbb6:8055:7157] (unknown [IPv6:2001:4f8:3:64:899a:fbb6:8055:7157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4CB40216C3B; Fri, 14 Sep 2012 22:41:27 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: Date: Fri, 14 Sep 2012 15:41:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <22424A8E-6D21-4981-8781-DCA6C3D3043C@isc.org> References: <20120914193950.12540.qmail@joyce.lan> <86EE6824-0188-4EC4-90A0-5F47F157BEFC@isc.org> To: John R Levine X-Mailer: Apple Mail (2.1486) Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 22:41:34 -0000 On Sep 14, 2012, at 3:00 PM, John R Levine wrote: > Since WHOIS hasn't changed materially in 20 years, I see no reason to = add extra complication for purely hypothetical problems in the distant = future, particularly if they mean that we won't solve the problems that = we're here to solve. I don't understand where/what the extra complication is, it is merely a = design choice. If we are not going to pay attention to what you call = hypothetical problems, then we don't need a discussion, merely a = braindump of what people are doing now and seek approval for it, = ignoring use cases is not going to make the problems go away. Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From johnl@iecc.com Fri Sep 14 17:05:32 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7832B21F8569 for ; Fri, 14 Sep 2012 17:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZHoofrm2RZa for ; Fri, 14 Sep 2012 17:05:31 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 98C4921F8568 for ; Fri, 14 Sep 2012 17:05:31 -0700 (PDT) Received: (qmail 70569 invoked from network); 15 Sep 2012 00:05:29 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Sep 2012 00:05:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5053c649.xn--btvx9d.k1208; i=johnl@user.iecc.com; bh=cyw8mBgaeIVQO/FKfEqToosFOE1uzhmQl9niJYxuew4=; b=uJIzEF6jv3uvjV5IxfBLIcWggkrvXu9Pa352YjMm9fQ1uCl43e5RP8irYoEvmR8ey6hVYz8okmD7HvZ6/6K5q/SJblNWcbNKxFnM4llsL88z0+9uIRUJS2KRqKrYuKUnRU1uC6vprbNTG6X6VyZxKOb9TDbRXayor3V/k8ujx+s= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5053c649.xn--btvx9d.k1208; olt=johnl@user.iecc.com; bh=cyw8mBgaeIVQO/FKfEqToosFOE1uzhmQl9niJYxuew4=; b=d3Mqkux1Zx++OiO+bXLK0KXw0KfeA6vLPCzOPUHIwHAj/uuFF5DeSHi7QGYbmpivZEgwFwEGESZC3ICL49WIXhsOnhge0hedyDlnipkG25XwaeQRuEsBmfDLmbJ8ewCNfB4q+a7n+YZDBsXgf56/8Sh3oQLxTuR5RAdIYgEprW0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 15 Sep 2012 00:05:07 -0000 Message-ID: <20120915000507.83159.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <22424A8E-6D21-4981-8781-DCA6C3D3043C@isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 15 Sep 2012 00:05:32 -0000 >> Since WHOIS hasn't changed materially in 20 years, I see no reason to add extra complication for >purely hypothetical problems in the distant future, particularly if they mean that we won't solve >the problems that we're here to solve. > >I don't understand where/what the extra complication is, it is merely a design choice. The templates are the extra complication. More network traffic, more client code, no useful added function for this application. > If we are not going to pay attention to what you call hypothetical > problems, then we don't need a discussion, merely a braindump of what > people are doing now and seek approval for it, ignoring use cases is > not going to make the problems go away. We definitely need to deal with real use cases, notably making sure that clients can decode and use all the results from domain WEIRDS servers. But we do not need to deal with hypothetical cases about what someone might want to do for a different application in 2022. This is getting repetitive. I'm done. R's, John From johnl@taugh.com Fri Sep 14 17:25:40 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844E221F855E for ; Fri, 14 Sep 2012 17:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLvr8BLpeisK for ; Fri, 14 Sep 2012 17:25:39 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D350A21F84B8 for ; Fri, 14 Sep 2012 17:25:38 -0700 (PDT) Received: (qmail 74011 invoked from network); 15 Sep 2012 00:25:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1211a.5053cb00.k1209; bh=VhFeEo52kGyQ5uIU4JyvCRWnJ8+Ox2hy83xbA9upNe4=; b=KfiFFBWDYB36FWTAIGZX7qX/x2q9fnrkzm/npUOuSCQ4mECpGiuXobjiQ0okkItrVPG9ku59D2uqP3CHtS8bLkKgNtMk1rmpK5KW7dxHGXjuQqzwlPQIpvT5ZDoe1zg3jkWImCH8a/VhyfXHFL/klTkS5+/YNQOgxG++t0xlato= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1211a.5053cb00.k1209; bh=VhFeEo52kGyQ5uIU4JyvCRWnJ8+Ox2hy83xbA9upNe4=; b=eKeuPoLYpC+MvyYnMpCAUI8yMplyzFZPBHCct/HI4D0sPozUOCscIm0Xv7PuM0s2Z5KFEGnoimglECijZ2FV6IUJQ7SEra54VqRvnNXjyO6BO1Ptq/Rz4oqS7RspvoiX1HKSb2CNBaWk2C1130sNJDgoAbb9PsonBX5y+bPHYgw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 15 Sep 2012 00:25:13 -0000 Date: 14 Sep 2012 20:25:35 -0400 Message-ID: From: "John R Levine" To: weirds@ietf.org In-Reply-To: References: <20120914003009.29941.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 15 Sep 2012 00:25:40 -0000 > HTTP URLs are owned and managed by the server; having standards usurp > that name space would fragment the Web. This seems to be some other argument that the one we were having. HTTP servers can implement any URLs they want, but if they also purport to be WEIRDS servers, it would be a good idea for some of the URLs they implement to be the ones that WEIRDS defines. If you want to look at documents, see the recent archives of this list. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From steve.sheng@icann.org Fri Sep 14 17:25:58 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B62B21F8569 for ; Fri, 14 Sep 2012 17:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eExtpDMS0Mys for ; Fri, 14 Sep 2012 17:25:57 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id CA46C21F84B8 for ; Fri, 14 Sep 2012 17:25:57 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Fri, 14 Sep 2012 17:25:57 -0700 From: Steve Sheng To: John Levine , "weirds@ietf.org" Date: Fri, 14 Sep 2012 17:25:55 -0700 Thread-Topic: [weirds] ICANN Survey Thread-Index: Ac2S2Kxm/qGobhSESWi0BxAOI2gXfw== Message-ID: In-Reply-To: <20120914193106.10146.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3430488356_55504838" MIME-Version: 1.0 Subject: Re: [weirds] ICANN Survey X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 15 Sep 2012 00:25:58 -0000 --B_3430488356_55504838 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello John, -----Original Message----- From: John Levine To: "weirds@ietf.org" Subject: Re: [weirds] ICANN Survey >>How fast will ICANN turn this into a summary after the period closes? > >In my experience, it takes quite a while for them to produce >summaries, a month or more. I gather they're totally swamped by the >new TLD applications, so it may be even longer now. I have checked my colleague who did this work. Currently, the survey is scheduled to close on 10/31, and a report summarizing the survey results will be ready by mid December 2012. We will make sure to forward a copy of the report to the weirds working group. Kind regards, Steve > >So don't make any plans that depend on seeing the results of the >survey. It may well be interesting, but I'd be amazed if it told us >anything that would change in any important way what we're planning to >do. > >R's, >John >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds --B_3430488356_55504838 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITmwYJKoZIhvcNAQcCoIITjDCCE4gCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EWcwggbiMIIFyqADAgECAhABZMwilD7GxArmntmcL5R/MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjA2MDcwMDAw MDBaFw0xNTA2MDcxMjAwMDBaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAk0LP2kd68QahDa0JHYITr25S nDBvdGo1ipsN1/W/XOD3D/TsHIwLW6fJGxggQe20WSP0z4C2bAwxm/86a7LgTSHFVHID6NCU wI3FjTukn1NKepT1qLFYJ+F+6Fr+PGXxAqkHjgtxvH6D6/i6CBVx23nhikAZZ9kohGXmrAeu q7WfAIKziZel8gESFvnlwl0ddgUB2onbPnytNSTkE7YadrP+seY5q8pH52M5m5BL5j6Ov6DS ix78Yx7rqRclE2MCTsRtlxy9MCQMf95/5Jhy+ZR6Hm+7kSXdosckMmqitzqw/sE6FNA+ChLQ PYA4KkmnRFZXjNLy0z3CqNOPj4hPAgMBAAGjggNkMIIDYDAfBgNVHSMEGDAWgBQVABIrE5iy mQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUz5w5ABV+GwM+WrkNqgAws9jssIwwIAYDVR0RBBkw F4EVc3RldmUuc2hlbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgw ggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5j b20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkA IAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUA IABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUA bAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgA IABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUA bgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj ZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEA zZA8H8eHQfdut5RjlHklXuWQYdnPAwmXRjcuqwhmvlsAghGxLyfQ6+glnd3TsSue+ighPszj 4i1ryRnBN4/SkywV+5gcP88BU94zAZJvSxmNeD5kR9HjZsL44PrpvgtDv0Q4Ap6PA3K9pals EPORzu1f+QcLFmSY/1E6nunOOjhAaSKwLKU8ThkwUmczI9Wm74SVNMjWJZlsHJsG4AoEUJe7 HG04zMo3/vadmoywbDHtmQjLZWNu/1OvBH0xaXnPW+meS8HaPALX6wDKPeUCxWq4/GLEqUWV L6IKJ3yRjbYrAjjGu1P4KTv9UsH0iEowiq+7ewjbD+dXexWsaXh8bTCCBsIwggWqoAMCAQIC EAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYI A6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkF l32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLO Bq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcK J1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0 MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCC AcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEE cTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+i vlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUF AAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTk c61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5Wwg V7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1b fDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDes z+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKf oAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMx MTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlx EqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gy NnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgv GP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgz bCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKm VrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgw FoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6 ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLY Z4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVt X4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83 fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKj JqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQAWTMIpQ+xsQK5p7ZnC+UfzAJ BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFNuZCwjfzObdwMnYPY1obHfbRG1YMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkxNTAwMjU1NVowDQYJ KoZIhvcNAQEBBQAEggEArNKKTOWnK8iI91ANHpuNY64NGLpp7RkCg4NOWsG0uCGVcrqGFjad 8T+AtsuzW7QBdlx+kGd6hXLoN5HpVC4SbbmAlbkBdFk0dUf6070IEDcMRVSPBTxUU8NveBhU Db4EDRN94OiaAz0zL5VTwppVWVGxt36Ddui9qLTdG5tpenRdLeRU1PRwOGv7KHMZFMMNfb37 8GiBPUdgRbW0EXK+Z73QgOZM1LPtzQ60sNM3tX3igC/bpClgOd1ZGDf0Oz+BljoxS5fCy/KN Z3KFLLBkywHEyWMFCk3DWcvSNmbUC+6HtplbdfhgIFY3EeQ1nECTVwpfLvEjPQsvdSbkhFEY qQ== --B_3430488356_55504838-- From dblumenthal@pir.org Fri Sep 14 19:07:24 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AF621E8037 for ; Fri, 14 Sep 2012 19:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.076 X-Spam-Level: X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwyvn7VO1+QL for ; Fri, 14 Sep 2012 19:07:23 -0700 (PDT) Received: from mail.pir.org (173-10-164-41-BusName-washingtonDC.hfc.comcastbusiness.net [173.10.164.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5F44921E8039 for ; Fri, 14 Sep 2012 19:07:23 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Fri, 14 Sep 2012 22:07:22 -0400 From: Don Blumenthal To: John Levine , "Murray S. Kucherawy" , "weirds@ietf.org" Date: Fri, 14 Sep 2012 22:07:16 -0400 Thread-Topic: [weirds] ICANN Survey Thread-Index: Ac2S5tWMa00cG2OIROGbmVdVxOejGQ== Message-ID: In-Reply-To: <20120914193106.10146.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] ICANN Survey X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 15 Sep 2012 02:07:24 -0000 I'll address both Murray and John at once. The survey closes on October 31, which I should have said in my first message. We hope to have preliminary results by mid-November and are aiming to release the final resort by mid-December. Given who from ICANN staff and the community are working on the project, the schedule shouldn't be affected by new gTLD tasks. We'll be happy to provide a pdf with the raw data after our survey system finishes processing the preliminary results and we have reviewed them, Don =20 On 9/14/12 3:31 PM, "John Levine" wrote: >>How fast will ICANN turn this into a summary after the period closes? > >In my experience, it takes quite a while for them to produce >summaries, a month or more. I gather they're totally swamped by the >new TLD applications, so it may be even longer now. > >So don't make any plans that depend on seeing the results of the >survey. It may well be interesting, but I'd be amazed if it told us >anything that would change in any important way what we're planning to >do. > >R's, >John >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From mnot@mnot.net Fri Sep 14 17:14:19 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756D221F857D for ; Fri, 14 Sep 2012 17:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.937 X-Spam-Level: X-Spam-Status: No, score=-103.937 tagged_above=-999 required=5 tests=[AWL=-1.338, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unqO0gszBP5Q for ; Fri, 14 Sep 2012 17:14:18 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id EA3C021F8557 for ; Fri, 14 Sep 2012 17:14:11 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CFBFB22E255; Fri, 14 Sep 2012 20:14:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <20120914003009.29941.qmail@joyce.lan> Date: Sat, 15 Sep 2012 10:14:01 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120914003009.29941.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1486) X-Mailman-Approved-At: Fri, 14 Sep 2012 21:44:30 -0700 Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 15 Sep 2012 00:14:19 -0000 On 14/09/2012, at 10:30 AM, John Levine wrote: >> 2) You don't impinge on the server's control of its URI space (e.g., = the /query/foo URI will mean...") >=20 > Wait, stop right there. We're building a design from scratch here, Not if you're using HTTP. > with constrained syntax and semantics. If someone wants to build a > WEIRDS server, he or she can implement the URLs and return values that > WEIRDS defines. There is no installed base, there are no existing web > services that we have to work around. You're not creating a new protocol; you're using one with defined = semantics.=20 HTTP URLs are owned and managed by the server; having standards usurp = that name space would fragment the Web. > What possible advantage is there for WEIRDS to encourage server > operators to invent different syntax and demand that clients kludge > around it with an extra level of lookup and templates? I didn't say that you have to use URI templates; I'm only pointing out = the sources of potential objections you'll receive once you request = wider review. There are plenty of ways to address different problems = within the constraints of the Web. If you have a document that's suitable for review, I'd be glad to give = you more specific feedback. Regards, -- Mark Nottingham http://www.mnot.net/ HTTPbis WG Chair IETF/W3C Liaison From sm@resistor.net Fri Sep 14 23:59:52 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909DE21F85A4 for ; Fri, 14 Sep 2012 23:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW09d3Aq4+Li for ; Fri, 14 Sep 2012 23:59:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C81FA21F8599 for ; Fri, 14 Sep 2012 23:59:51 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8F6xdd0007711; Fri, 14 Sep 2012 23:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347692387; bh=BDKuiNzGZY4buNjomJ9wgr2aPnp4qOfpKFvbpzCmlKY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mF3SNeYWM4+A2s4NTSOZhUNEWp9q/HgEd7pRkOVftBf/7ffhOz/pV4GAAEMq7xWsP CMcxsByQfG4Rrud8uhnZWjWXL41EyRPTRvlG8Tup4YwmOE6vhePAm3SrIXnnh5frgz bU9/7uyPH3NJwg3CuatKNAbSrIqCO2V2ee4yaDEU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347692387; i=@resistor.net; bh=BDKuiNzGZY4buNjomJ9wgr2aPnp4qOfpKFvbpzCmlKY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eGB8PCvBjonMpn4Y2NAddF3X+JKh0csYlTMAj5BEtIbI5VnFvAsLtbbrGE+HNIinD PC53gc4NDatFU34k5PkndQtv4hAIjeiAjc8VqIVohei+Is0w9Jnh6PRm7LBFoOzu// mv9Jqv3DZHtsG+EPsuJJ+SoJNznc049rZhkdWlNE= Message-Id: <6.2.5.6.2.20120914232908.0ab70eb8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Sep 2012 23:45:28 -0700 To: weirds@ietf.org From: SM In-Reply-To: <50533478.3040003@gmx.de> References: <50533478.3040003@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 15 Sep 2012 06:59:52 -0000 At 06:43 14-09-2012, Julian Reschke wrote: >My take: "adhering to REST principles". There are usually proposals to re-purpose a well-known architecture. The significance of whether that's a problem or not only become apparent after several years or more. My understanding is that if you are going to do it on port 80, you adhere to the principles. >Sure, one can argue whether you need to adhere to *all* of them or >not. But in this case I really have the impression that the label >"restful" was used here just because it is en vogue. :-) Regards, -sm From chris@ausregistry.com.au Sat Sep 15 19:09:56 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E4C21F848B for ; Sat, 15 Sep 2012 19:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g2XKJWN9LMg for ; Sat, 15 Sep 2012 19:09:55 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0629221F8464 for ; Sat, 15 Sep 2012 19:09:52 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 16 Sep 2012 12:09:51 +1000 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Sun, 16 Sep 2012 12:09:23 +1000 From: Chris Wright To: Julian Reschke , Andy Newton Date: Sun, 16 Sep 2012 12:09:52 +1000 Thread-Topic: [weirds] URI templates and WEIRDS Thread-Index: Ac2TsEnd4OfjGf2BRYiCVZgqXKWCzw== Message-ID: In-Reply-To: <50533478.3040003@gmx.de> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 16 Sep 2012 02:09:56 -0000 >> >>Then how about dropping the 'RESTful' bit from the description of WEIRDS? > >What do you think "RESTful" means? >... > My take: "adhering to REST principles". I think I bought up in the Vancouver meeting that what we are proposing to do here is not 'RESTful'. Frankly though I am ok with it, I think we need to do WEIRDS the way that we are doing it, so I agree with others that have said lets just pull the references to REST from the docs and move on. We use a term for this internally, when we are making an RPC style protocol over HTTP that some might confuse for REST, but it isn't really - we call it a HTTPful protocol, and I think that=B9s probably all that we need for WEIRDS, a well defined HTTPful protocol (that still needs to consider extensibility). For those further interested... If we wanted to I think we could make WEIRDS truly RESTful, its fits the paradigm well (if done properly), and certainly would be a more flexible WEIRDS to then be used for other 'objects'. I am just not sure its worth the effort - maybe it is, and maybe someone who thinks it is could convince me. Using URI templates, at least in my understanding, will make the protocol not RESTful, real REST is supposed to only require an entry point and then you 'discover' the rest from there. (I suppose if you use the URI templates to aid in that discoverability that would meet the model, but I think the discoverability is really supposed to be around following links). When people get into debates about what is and isn't REST I usually point them to the following articles, one of them written by Roy Fielding, the guy who coined the term - the 3rd article down does a good job of making things clear.=20 http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://martinfowler.com/articles/richardsonMaturityModel.html http://curtis.schlak.com/2012/01/23/hateoas-a-follow-up-to-rest-for-r33lz.h tml http://curtis.schlak.com/2012/01/19/fieldings-rest.html Thanks c. From fobispo@isc.org Sun Sep 16 11:57:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B137A21F8440 for ; Sun, 16 Sep 2012 11:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wertxfNpZGJE for ; Sun, 16 Sep 2012 11:57:42 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3F04921F8421 for ; Sun, 16 Sep 2012 11:57:42 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 9597FC94A2; Sun, 16 Sep 2012 18:57:35 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.105] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7D556216C3B; Sun, 16 Sep 2012 18:57:35 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: <20120915000507.83159.qmail@joyce.lan> Date: Sun, 16 Sep 2012 11:57:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120915000507.83159.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1486) Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 16 Sep 2012 18:57:43 -0000 On Sep 14, 2012, at 5:05 PM, John Levine wrote: >=20 >>> Since WHOIS hasn't changed materially in 20 years, I see no reason = to add extra complication for >> purely hypothetical problems in the distant future, particularly if = they mean that we won't solve >> the problems that we're here to solve. >>=20 >> I don't understand where/what the extra complication is, it is merely = a design choice. >=20 > The templates are the extra complication. More network traffic, more > client code, no useful added function for this application. So the solution to not using templates is to have a chaotic list of = attributes smushed together in one single document, and implementors are = supposed to figure out how each must be formatted? Apologies, but I don't think this is a "simple" approach, it seems to me = that this is the "shortcut" instead. >=20 >> If we are not going to pay attention to what you call hypothetical >> problems, then we don't need a discussion, merely a braindump of what >> people are doing now and seek approval for it, ignoring use cases is >> not going to make the problems go away. >=20 > We definitely need to deal with real use cases, notably making sure > that clients can decode and use all the results from domain WEIRDS > servers. But we do not need to deal with hypothetical cases about > what someone might want to do for a different application in 2022. So you don't think that this protocol can't be used for any other thing = except names and numbers? Why did we implemented EPP then? we could've just written a plan = exchange tab separated values with the fields required to register = domain names and that should've been enough to solve the problem. I know this sounds a bit rude, but I think we are not being coherent by = having a provisioning protocol that can be extended, that supports very = well any type of object, who is transport agnostic, and then a protocol = to query the data that is limited to names and numbers and with a = chaotic format. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From carlosm3011@gmail.com Sun Sep 16 12:32:51 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF32B21F845E for ; Sun, 16 Sep 2012 12:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kgZLMuHe2lA for ; Sun, 16 Sep 2012 12:32:50 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7921F844F for ; Sun, 16 Sep 2012 12:32:50 -0700 (PDT) Received: by yenl13 with SMTP id l13so6809yen.31 for ; Sun, 16 Sep 2012 12:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RR2i1RskdHXRafXZbcGD2RJ4L9IcqSAnPwUzCNheG2Q=; b=DcJY0PsO54Lk4lk8dc1MPARI5BEzgUehCIq5X2b4HKRsxROZHdpojqowd2iVW9SP3W lLSuj5DMFYwfb63vH1gU7aGpOJ7Ija9+RrH5N3pzOhOkpFd6mXcAKZfjFjpdHPWtWFKx qJX4uAKAUH6f/As71qG0y+KTwjrE3dwO8p1A/LvQ4PL3sZ0wPcsOF/JymBEqaRrigEKL q0rigZ+TSWshno5z2PUxAM32qsjxsDdHxx/luxpFXRUG9uR6lgJMLpJ4QCgbC0/3rS/4 WU1mwbT4NBFVPk7erI63XViAhnI90j3IKz55cYx96VkKQWeXdAtSTiglDx6oxyTF3xPK +iLg== Received: by 10.236.124.44 with SMTP id w32mr9458488yhh.76.1347823970303; Sun, 16 Sep 2012 12:32:50 -0700 (PDT) Received: from erebus.local (r186-53-81-150.dialup.adsl.anteldata.net.uy. [186.53.81.150]) by mx.google.com with ESMTPS id p70sm4290665yhl.18.2012.09.16.12.32.47 (version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 12:32:48 -0700 (PDT) Message-ID: <5056295D.9070706@gmail.com> Date: Sun, 16 Sep 2012 16:32:45 -0300 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Francisco Obispo References: <20120915000507.83159.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John Levine , weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 16 Sep 2012 19:32:51 -0000 Francisco, >From the work carried by the WG so far I don't see that we have a problem with the URIs. Most of the hard discussion has been around responses and not requests, so, really, I still fail to see what benefit URI templates will bring to the table, and I see many drawbacks. Redefining WHOIS has failed before, and IMO it failed due to added unnecessary complexity. I'm sure the added complexity seemed a good idea at the time of writing the documents, but then harsh reality set in and the community made a choice for us. Personally, I believe that the watermark of complexity this particular user community is willing to accept is that of clients that can be implemented in bash+wget or in python+urllib2 in less than 20 lines. They will implement no caching and they will probably hardcode URIs anyway. After 15-20 years of RIRs, ARIN's WHOIS is still the entry point for many queries due to a hardcoded string. They decided that before implementing BEEP they rather stay on a protocol that looks it was designed when the sabre-toothed tiger roamed the Earth. I believe we need to avoid a repetition of that scenario at all costs, even if it means creating something that is not 'that perfect' (again, by some definition of 'perfect') cheers! ~Carlos On 9/16/12 3:57 PM, Francisco Obispo wrote: > > On Sep 14, 2012, at 5:05 PM, John Levine wrote: > >> >>>> Since WHOIS hasn't changed materially in 20 years, I see no reason to add extra complication for >>> purely hypothetical problems in the distant future, particularly if they mean that we won't solve >>> the problems that we're here to solve. >>> >>> I don't understand where/what the extra complication is, it is merely a design choice. >> >> The templates are the extra complication. More network traffic, more >> client code, no useful added function for this application. > > So the solution to not using templates is to have a chaotic list of attributes smushed together in one single document, and implementors are supposed to figure out how each must be formatted? > > Apologies, but I don't think this is a "simple" approach, it seems to me that this is the "shortcut" instead. > > >> >>> If we are not going to pay attention to what you call hypothetical >>> problems, then we don't need a discussion, merely a braindump of what >>> people are doing now and seek approval for it, ignoring use cases is >>> not going to make the problems go away. >> >> We definitely need to deal with real use cases, notably making sure >> that clients can decode and use all the results from domain WEIRDS >> servers. But we do not need to deal with hypothetical cases about >> what someone might want to do for a different application in 2022. > > > So you don't think that this protocol can't be used for any other thing except names and numbers? > > Why did we implemented EPP then? we could've just written a plan exchange tab separated values with the fields required to register domain names and that should've been enough to solve the problem. > > I know this sounds a bit rude, but I think we are not being coherent by having a provisioning protocol that can be extended, that supports very well any type of object, who is transport agnostic, and then a protocol to query the data that is limited to names and numbers and with a chaotic format. > > > Francisco Obispo > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID = B38DB1BE > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From johnl@taugh.com Sun Sep 16 12:41:46 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AA621F8501 for ; Sun, 16 Sep 2012 12:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMLqOpMcTyCt for ; Sun, 16 Sep 2012 12:41:46 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0841D21F84F6 for ; Sun, 16 Sep 2012 12:41:45 -0700 (PDT) Received: (qmail 23063 invoked from network); 16 Sep 2012 19:41:45 -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:vbr-info:user-agent:cleverness; s=5a15.50562b79.k1209; bh=o35VFGtBy+f7znK/XM9PxSI+B+P0JMjt5ROZqaErtzE=; b=Y04hfYm6/ltFNwKUsEvaLRzqn9BF5WlIMBIVl4S5WCApQlfFuwtU8+K4+fRgocOOoA4gIKQCTlIjK9JYn4noBK4AamDYBjMhZBrSVWG57qHu90A1gQax6SBYh8+mIzCd6rVD8FtmE6DGyRo+RSNuFu71a6KP2biDYEzYU8VRa7E= 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:vbr-info:user-agent:cleverness; s=5a15.50562b79.k1209; bh=o35VFGtBy+f7znK/XM9PxSI+B+P0JMjt5ROZqaErtzE=; b=QqFEVwW0wmo7D9xad0412ii4/S0eT/A7O2b03ppMb09rRp8E83MvbWZvVDnSoZQEr9A+n+ebeIQlvo7FGJRI21eDv/LZbMQ5DXZT3jXAHHLsLtdoDrjlbqvM7MzNEF747eDtJ8XH/TRWZWWn6rtA3lUtEcT+Qj/JmOkeIa4GocM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 16 Sep 2012 19:41:22 -0000 Date: 16 Sep 2012 15:41:44 -0400 Message-ID: From: "John R Levine" To: "Francisco Obispo" In-Reply-To: References: <20120915000507.83159.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] the problem we're here to solve is WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 16 Sep 2012 19:41:46 -0000 [ snip ] > So you don't think that this protocol can't be used for any other thing except names and numbers? Actually, the goal is to design one protocol to ask for information about IP addresses, and a probably somewhat different protocol to ask about domain names. If you don't believe me, read the charter. > I know this sounds a bit rude, but I think we are not being coherent by > having a provisioning protocol that can be extended, that supports very > well any type of object, who is transport agnostic, and then a protocol > to query the data that is limited to names and numbers and with a > chaotic format. That would be a dandy plan for a research group. But not for a WHOIS replacement, unless you want to drive the work into the weeds just like the last N attempts to replace WHOIS. R's, John From fobispo@isc.org Sun Sep 16 14:09:58 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969EA21F84EC for ; Sun, 16 Sep 2012 14:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_66=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py0T2pWZ37rg for ; Sun, 16 Sep 2012 14:09:57 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7991F21F84B6 for ; Sun, 16 Sep 2012 14:09:53 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1020C5F9932; Sun, 16 Sep 2012 21:09:42 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [10.197.172.151] (mobile-198-228-208-094.mycingular.net [198.228.208.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3EF03216C3D; Sun, 16 Sep 2012 21:09:40 +0000 (UTC) (envelope-from fobispo@isc.org) References: <20120915000507.83159.qmail@joyce.lan> <5056295D.9070706@gmail.com> In-Reply-To: <5056295D.9070706@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Francisco Obispo Date: Sun, 16 Sep 2012 14:09:35 -0700 To: "Carlos M. martinez" Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 16 Sep 2012 21:09:58 -0000 Sent from my iPhone On Sep 16, 2012, at 12:32 PM, "Carlos M. martinez" w= rote: > Francisco, >=20 >> =46rom the work carried by the WG so far I don't see that we have a > problem with the URIs. Most of the hard discussion has been around > responses and not requests, so, really, I still fail to see what benefit > URI templates will bring to the table, and I see many drawbacks. >=20 * extensibility * reusability * coherence * simplicity ... > Redefining WHOIS has failed before, and IMO it failed due to added > unnecessary complexity. I'm sure the added complexity seemed a good idea > at the time of writing the documents, but then harsh reality set in and > the community made a choice for us. Agree but an enclosure format+object definitions does not bring this to the= table. >=20 > Personally, I believe that the watermark of complexity this particular > user community is willing to accept is that of clients that can be > implemented in bash+wget or in python+urllib2 in less than 20 lines. > They will implement no caching and they will probably hardcode URIs > anyway. After 15-20 years of RIRs, ARIN's WHOIS is still the entry point > for many queries due to a hardcoded string. >=20 I can implement it in less than 20 lines of code, but even more important th= an that; you re going to need to use a JSON library to parse the results any= way, and having a way to obtain the result objects would be no different Exc= ept that you would know how to treat the data and will reduce guess work.. I= n example, if my app only needs ip information it doesn't need to understan= d or deal with domain or contact.. In the current model everything is mixed u= p in the same data structure. > They decided that before implementing BEEP they rather stay on a > protocol that looks it was designed when the sabre-toothed tiger roamed > the Earth. >=20 > I believe we need to avoid a repetition of that scenario at all costs, > even if it means creating something that is not 'that perfect' (again, > by some definition of 'perfect') >=20 What does all cost mean in this context? Designing a protocol that is not go= ing to meet registry needs in the future? Or am I bringing hypothetical case= s again? At the minimum the protocol should be able to represent all registr= ation data, not just names and mumbers, and if the charter is excluding ever= ything else, then it's wrong and must be corrected Regards > cheers! >=20 > ~Carlos >=20 > On 9/16/12 3:57 PM, Francisco Obispo wrote: >>=20 >> On Sep 14, 2012, at 5:05 PM, John Levine wrote: >>=20 >>>=20 >>>>> Since WHOIS hasn't changed materially in 20 years, I see no reason to a= dd extra complication for >>>> purely hypothetical problems in the distant future, particularly if the= y mean that we won't solve >>>> the problems that we're here to solve. >>>>=20 >>>> I don't understand where/what the extra complication is, it is merely a= design choice. >>>=20 >>> The templates are the extra complication. More network traffic, more >>> client code, no useful added function for this application. >>=20 >> So the solution to not using templates is to have a chaotic list of attri= butes smushed together in one single document, and implementors are supposed= to figure out how each must be formatted? >>=20 >> Apologies, but I don't think this is a "simple" approach, it seems to me t= hat this is the "shortcut" instead. >>=20 >>=20 >>>=20 >>>> If we are not going to pay attention to what you call hypothetical >>>> problems, then we don't need a discussion, merely a braindump of what >>>> people are doing now and seek approval for it, ignoring use cases is >>>> not going to make the problems go away. >>>=20 >>> We definitely need to deal with real use cases, notably making sure >>> that clients can decode and use all the results from domain WEIRDS >>> servers. But we do not need to deal with hypothetical cases about >>> what someone might want to do for a different application in 2022. >>=20 >>=20 >> So you don't think that this protocol can't be used for any other thing e= xcept names and numbers? >>=20 >> Why did we implemented EPP then? we could've just written a plan exchange= tab separated values with the fields required to register domain names and t= hat should've been enough to solve the problem. >>=20 >> I know this sounds a bit rude, but I think we are not being coherent by h= aving a provisioning protocol that can be extended, that supports very well a= ny type of object, who is transport agnostic, and then a protocol to query t= he data that is limited to names and numbers and with a chaotic format. >>=20 >>=20 >> Francisco Obispo=20 >> Director of Applications and Services - ISC >> email: fobispo@isc.org >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >> PGP KeyID =3D B38DB1BE >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >>=20 From bill.smith@paypal-inc.com Sun Sep 16 18:12:00 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5E21F852B for ; Sun, 16 Sep 2012 18:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDaFpeAHpfYj for ; Sun, 16 Sep 2012 18:11:59 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 7E94121F8505 for ; Sun, 16 Sep 2012 18:11:59 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:11:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:X-CFilter; b=RKHKQ5B8KYQcX8r1UAWs7kAFn6WRSg2e1doQoSIRnUw15On4gKgTVt/9 lBJF0cpj+CAU2Qq9YTo9h6mncFcxv1FWo3ZWckcvtJPkTlw3Sxq9sXHu/ tR/ixDnbv1pthG4; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bill.smith@paypal-inc.com; q=dns/txt; s=ppinc; t=1347844319; x=1379380319; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=w9ARB4bv6343XBSSYQuI+9Ol8UmwwlmoCga2568gYVI=; b=kR7HLsSOb6lr4RvmTRrpUddBryzenVLe1lxfFdFN1oE9sycMTpuDYPwI C3T/lFLBFANXYXAFKJmZA8IPNXgXpKmmHzbu7ZtL4RYxKg1u2RRRXhy3T Gv+nkZRNG0JrWo3; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,432,1344236400"; d="scan'208";a="9787806" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-006.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 16 Sep 2012 18:11:58 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-006.corp.ebay.com ([fe80::5c45:283f:1e47:5cdf%17]) with mapi id 14.02.0318.001; Sun, 16 Sep 2012 19:11:58 -0600 From: "Smith, Bill" To: John R Levine Thread-Topic: [weirds] the problem we're here to solve is WHOIS Thread-Index: AQHNlEc8CmilwKMJbUKcGAVbzjpct5eOHuIA Date: Mon, 17 Sep 2012 01:11:57 +0000 Message-ID: <80B2A58AFE381140A62C0512215B4F682AFDB4@DEN-EXDDA-S12.corp.ebay.com> References: <20120915000507.83159.qmail@joyce.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.25.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <083905F5EFDFA74EBF00F516F6F3C59E@corp.ebay.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "weirds@ietf.org" Subject: Re: [weirds] the problem we're here to solve is WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 01:12:00 -0000 On Sep 16, 2012, at 12:41 PM, John R Levine wrote: >=20 > Actually, the goal is to design one protocol to ask for information about= IP addresses, and a probably somewhat different protocol to ask about doma= in names. If you don't believe me, read the charter. Sorry to bring up an old subject, but from the charter "but with the explic= it additional goals of producing a simple, easy-to-implement protocol". Not= e the use of the singular. Of course the charter concludes with "Should the Working Group reach a poin= t where it determines that the problem of producing a grand unified specifi= cation for both numbers and names appears to be intractable, it will be per= mitted to divide the problem into separate tasks and amend its milestones a= ccordingly." Perhaps I missed the decision on intractability. If so, apologies to all. From bill.smith@paypal-inc.com Sun Sep 16 18:16:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E0C21F84EF for ; Sun, 16 Sep 2012 18:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU1JpZWkHnzP for ; Sun, 16 Sep 2012 18:16:12 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 05DDB21F84B2 for ; Sun, 16 Sep 2012 18:16:11 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received: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-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:X-CFilter; b=gfJaRbdHPBg/uGj4GLCrqNkk3eq5+o3NLEHFb2Tok5D6YBq1DOzNLaiJ i58Wx7sDkW5xRiYttsRD/+LmeqpIInl7dqcGHWpqGqJ5U0mGy4Or9KEWQ lO9HJwzaOPuDULS; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bill.smith@paypal-inc.com; q=dns/txt; s=ppinc; t=1347844572; x=1379380572; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=M3NjMw1Q1IJk12WDODq3/mR7kU3N+AUhHkrYDtmxzEs=; b=N1+c5SdNCO2HTOn3x1vWZCQ17tf1q63jd0iu0xmCzlgxZiPcBXY0Dywt ywvw+P7bdh9fca7p4jhECDMOITPwjzz7/E6v6TMi8LJVk6cvimE3zTgPN oxaOwE1tDuxBMG5; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,432,1344236400"; d="scan'208";a="10277378" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 16 Sep 2012 18:16:11 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-002.corp.ebay.com ([fe80::cbe:ffa5:17f0:a24a%14]) with mapi id 14.02.0318.001; Sun, 16 Sep 2012 19:16:11 -0600 From: "Smith, Bill" To: John Levine Thread-Topic: [weirds] URI templates and WEIRDS Thread-Index: AQHNkl0xSLawiqJ/lEqrOjBMPOzBHZeKUpuAgAAGtACAA8qUAA== Date: Mon, 17 Sep 2012 01:16:10 +0000 Message-ID: <80B2A58AFE381140A62C0512215B4F682AFE1D@DEN-EXDDA-S12.corp.ebay.com> References: <20120914152218.31555.qmail@joyce.lan> In-Reply-To: <20120914152218.31555.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.25.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <64BB61861F1ED24CB8803B5CB68EFC67@corp.ebay.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "" Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 01:16:12 -0000 On Sep 14, 2012, at 8:22 AM, John Levine wrote: >=20 > I would cheerfully change all of the mentions of "RESTful" to "fluffy > bunny" in the charter if it would make this argument go away. >=20 I again point to the charter that states "The framework shall be for data t= o be delivered via a RESTful data service using HTTP (optionally using TLS)= ". IMO, that's a strong statement and says this group *will* produce a RESTful= service. Of course we could open up a charter discussion, again, but would that be p= roductive?= From johnl@iecc.com Sun Sep 16 18:19:06 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DA721F845A for ; Sun, 16 Sep 2012 18:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvDGBudiiqlc for ; Sun, 16 Sep 2012 18:19:06 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 081CD21F8453 for ; Sun, 16 Sep 2012 18:19:05 -0700 (PDT) Received: (qmail 77988 invoked from network); 17 Sep 2012 01:19:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Sep 2012 01:19:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50567a88.xn--9vv.k1208; i=johnl@user.iecc.com; bh=kZb3/x7PwB/trk/IpYneq18jwh6p8QLbPBGIp8fjdNo=; b=CAKU8fVDAICSdj4vE1Dxoxi8P1wK/QMnOFd8axJGAtqHYGFfrbT+zdlhTIt+yZoEBysxKOBpIwIHJL7pUfdWzODWDwN8pvtc3Tz7w+5nWjTxzgTkxiHcKrUPxUUyh/VisJqbocWgZ5qa64btOmn9HXZ8dZ2lPW5YQy31HuUGIJ8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50567a88.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=kZb3/x7PwB/trk/IpYneq18jwh6p8QLbPBGIp8fjdNo=; b=c8sdkVX1Dkn1tMnJx3JBy7HrfGIoOXZ3R+3e5gW9c9mIm03I/T1fGXrApGAQhLGbg414b8UBjCGvEcZSVC8mhnu51FbJ115uJ3byyngepb1r1Rnkzrj3jgPlNOiwTNq65r/SgjkYkKWf1fQGgHZKkgI0zaXay19fANdMRQRSxC0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Sep 2012 01:18:42 -0000 Message-ID: <20120917011842.67025.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <80B2A58AFE381140A62C0512215B4F682AFDB4@DEN-EXDDA-S12.corp.ebay.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] the problem we're here to solve is WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 01:19:07 -0000 >Sorry to bring up an old subject, but from the charter "but with the explicit additional >goals of producing a simple, easy-to-implement protocol". Note the use of the singular. Sure, but since both the questions and answers for numbers and names are different, even under the most optimistic assumptions there won't be much to share beyond generic json libraries, http redirect codes, and maybe authorization schemes. R's, John From bje@apnic.net Sun Sep 16 18:51:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBFB21F84FC for ; Sun, 16 Sep 2012 18:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jP-brCxDA22 for ; Sun, 16 Sep 2012 18:51:08 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id AA42B21F84F8 for ; Sun, 16 Sep 2012 18:51:07 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:f46b:f269:98b0:2467] (unknown [IPv6:2001:dc0:a000:4:f46b:f269:98b0:2467]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 7AC7FB69BB; Mon, 17 Sep 2012 11:51:06 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0DE1B6C3-43A6-434F-AA3A-31F8B4D75D05"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: <20120917011842.67025.qmail@joyce.lan> Date: Mon, 17 Sep 2012 11:51:06 +1000 Message-Id: <4E807633-F242-46D5-8D74-DB0FD3C8F409@apnic.net> References: <20120917011842.67025.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1278) Cc: weirds@ietf.org Subject: Re: [weirds] the problem we're here to solve is WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 01:51:08 -0000 --Apple-Mail=_0DE1B6C3-43A6-434F-AA3A-31F8B4D75D05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi John, On 17/09/2012, at 11:18 AM, John Levine wrote: >> Sorry to bring up an old subject, but from the charter "but with the = explicit additional >> goals of producing a simple, easy-to-implement protocol". Note the = use of the singular. >=20 > Sure, but since both the questions and answers for numbers and names > are different, even under the most optimistic assumptions there won't > be much to share beyond generic json libraries, http redirect codes, = and > maybe authorization schemes. Does this mean you think = http://tools.ietf.org/html/draft-newton-weirds-unified-json-response is = a dead end? Byron --Apple-Mail=_0DE1B6C3-43A6-434F-AA3A-31F8B4D75D05 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MTcwMTUxMDZaMCMGCSqGSIb3DQEJBDEWBBRt jnPuo+506bbi3dAEKkVd/vplmDCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQAUOBG6xPFihkSz KKW4fnp4UqrhVPGDt89D5frxmg2pTKvsG38gW6dPcVS8cB2ea3raofwE6UKpVUgEeLmj6edYq6Xz x/XunL6/lrfK/IbgnC9UltPW7EJHdYl0zNbd0EbwSI1VSoDlHVTRp6kA0quRFvDlH/I3LMJh24VH Qm+s2T3s1k0ab1WkDOg7aoLZXuSx5CLI0HTcRdlL5mtgwkDL3XmnIMSmou34/IiEJA+g/wT93ZWZ +rsL/QPPXVWmJ+jxehofmOFdeBOHNyZLjhtGH5z+zhsy0dW8gvtzY79avb37oGCt4d9NiKilS3jM 51yJE9mf7eMsstv4wjZ4NjM4AAAAAAAA --Apple-Mail=_0DE1B6C3-43A6-434F-AA3A-31F8B4D75D05-- From bje@apnic.net Sun Sep 16 18:51:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9332C21F8510 for ; Sun, 16 Sep 2012 18:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQyQMVin3+eW for ; Sun, 16 Sep 2012 18:51:08 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id A9B2021F84EB for ; Sun, 16 Sep 2012 18:51:06 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:f46b:f269:98b0:2467] (unknown [IPv6:2001:dc0:a000:4:f46b:f269:98b0:2467]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DA956B69B8; Mon, 17 Sep 2012 11:51:04 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_F54C826E-1E57-4654-A081-74360A2E3529"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Mon, 17 Sep 2012 11:51:04 +1000 Message-Id: References: <20120915000507.83159.qmail@joyce.lan> <5056295D.9070706@gmail.com> To: Francisco Obispo X-Mailer: Apple Mail (2.1278) Cc: weirds@ietf.org Subject: Re: [weirds] Object container X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 01:51:08 -0000 --Apple-Mail=_F54C826E-1E57-4654-A081-74360A2E3529 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Francisco, On 17/09/2012, at 7:09 AM, Francisco Obispo wrote: >>> =46rom the work carried by the WG so far I don't see that we have a >> problem with the URIs. Most of the hard discussion has been around >> responses and not requests, so, really, I still fail to see what = benefit >> URI templates will bring to the table, and I see many drawbacks. >=20 > * extensibility > * reusability > * coherence > * simplicity > ... If I understand the basis of your thinking here, it's that the response = should look notionally like this: { "object-1": { "some": "data", "reference": [ "object-2", = "object-3" ] }, "object-2": { "some": "data", "reference": [ "object-4" ] }, "object-3": { "more": "data" }, "object-4": { "this": "data"} } whereas now, it looks notionally like this: { "object-1": { "some": "data", "object-2": { "some": "data", "object-4": { "this": "data" } }, "object-3": { "more": "data" } } } With your justification being that the former can contain more kinds of = objects, down the line, more easily than the latter, and that the former = is more susceptible to the caching of parts of a given response than the = latter? Does this approach also depend on URI templates, or a similar mechanism, = where the first query to any given server looks kind of like: { "object-type-1": "a-uri-template-for-that-object", =85 } Do you see that mechanism as primarily required to support the = names+numbers work, or to support extensibility for querying entirely = separate object types, other than the { ip, domain, entity, autnum, = nameserver } set of objects so far identified? Essentially, I'd like to understand if this is a discussion about the = scope of the working group's output, or about the best way to approach = the more constrained problem of providing an alternative mechanism for = querying WHOIS data, that supports i18n, redirection, consistency, and = authen/authz, or something in between. Byron --Apple-Mail=_F54C826E-1E57-4654-A081-74360A2E3529 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MTcwMTUxMDVaMCMGCSqGSIb3DQEJBDEWBBSB a+QXATXJsURKO0e1Xc0cEcEGczCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQC5DP3nmp2Re63S y1Nom2VtfoMpC7d+jJ9mFdAV+CIOp6JZxvnnufOSCpTypDpoGgLSmLvn177PiDXK1hhUWZJpcqiW OprTyfMkMCT0t7FRs7ic35ao7xH/gtA7RXzbFT7LJKU3wu8A6jcV5eOMKAWs0xqX1PWuJ6MgBwDx TP9W9pZ1gcM6Nk5+Td0WfJ07w67jlLvB7EDYzmYejJ2VdSIdgYSxHCAuQWiqP80ZQIVSW16qmAPw MSlHQp89FsLbjih6+R6URP1IGd50VYpgvQEcZWxaz7SXC4s+1dRb74tPVnWeEup2gY4psmCqs5yb M522VpTazDgpPMcVLfaQmLRZAAAAAAAA --Apple-Mail=_F54C826E-1E57-4654-A081-74360A2E3529-- From andy@arin.net Sun Sep 16 19:23:57 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF32F21F843F for ; Sun, 16 Sep 2012 19:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGDaK6aT8BKc for ; Sun, 16 Sep 2012 19:23:57 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 04D7E21F843E for ; Sun, 16 Sep 2012 19:23:57 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 09FED213643; Sun, 16 Sep 2012 22:23:51 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 4738821361C; Sun, 16 Sep 2012 22:23:50 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sun, 16 Sep 2012 22:23:29 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Sun, 16 Sep 2012 22:23:31 -0400 From: Andy Newton To: "Smith, Bill" , John Levine Thread-Topic: [weirds] URI templates and WEIRDS Thread-Index: AQHNkl0xeVjwvLFVOEGNSOTXei1gS5eKMRSAgAAGtACAA8qWAP//z8GA Date: Mon, 17 Sep 2012 02:23:30 +0000 Message-ID: In-Reply-To: <80B2A58AFE381140A62C0512215B4F682AFE1D@DEN-EXDDA-S12.corp.ebay.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 02:23:57 -0000 On 9/16/12 9:16 PM, "Smith, Bill" wrote: > >On Sep 14, 2012, at 8:22 AM, John Levine wrote: > >>=20 >> I would cheerfully change all of the mentions of "RESTful" to "fluffy >> bunny" in the charter if it would make this argument go away. >>=20 > >I again point to the charter that states "The framework shall be for data >to be delivered via a RESTful data service using HTTP (optionally using >TLS)". > >IMO, that's a strong statement and says this group *will* produce a >RESTful service. > >Of course we could open up a charter discussion, again, but would that be >productive? It's good that we are having these conversations, otherwise real work might get accomplished. :) Though English is a horribly imprecise language, this isn't that hard. The meaning of the suffix "ful" is "to be characterized by". If somebody is forgetful, that means they forget a lot of things but it does not mean they forget everything. If a tool is useful, that means it can be used for many purposes but does not mean it can be used for every task. If we had wanted to create a REST service, the charter would say "REST" and not "RESTful". The purpose of using the term "RESTful web service" is to differentiate from other types of web services, notably the SOAP based services. It's a "useful" distinction in that it gives the reader of this interoperable specification a starting point in understanding the protocol description. And after all, an interoperable specification is what we are to produce. If the greater universe of Internet programmers recognizes what is being described here as a "RESTful web service", then the term has done its job regardless of how uncomfortable that might make some protocol purist wonk. All that being said, if there is some feature or utility that can be acquired by more closely adhering to a pure REST architecture, I'm willing to discuss it. So far nothing has been offered. -andy From johnl@taugh.com Sun Sep 16 19:24:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1EB21F846D for ; Sun, 16 Sep 2012 19:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbQS7z6LTdA8 for ; Sun, 16 Sep 2012 19:24:05 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96121F8467 for ; Sun, 16 Sep 2012 19:24:04 -0700 (PDT) Received: (qmail 89818 invoked from network); 17 Sep 2012 02:24:03 -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:vbr-info:user-agent:cleverness; s=15ed9.505689c3.k1209; bh=OBAX5P4nC/jPbiFQze1MTqb3q2s/SBzVrzsd8boAEzQ=; b=u1cjpWcNu2g2f6LgYLyrac943POpJJXwsgWt6GVWjkmkSccDEAeZ6WWiYsOBK3FSC6S0w6Ve2nVHtKAeFEhizBK/mg5lsSx3rtBAK8lteLSixXG6EH1BdpPyH6qRVCIE1yzpwwHPpjP+MGcir52zZ6ji2aSZtsu2c4HMWH3Mxi0= 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:vbr-info:user-agent:cleverness; s=15ed9.505689c3.k1209; bh=OBAX5P4nC/jPbiFQze1MTqb3q2s/SBzVrzsd8boAEzQ=; b=P+ZPW5Rf+zSiMJf7cpyRb7/++X1Y8Xd+8lgNhtBzQ++Y3wrQy5JEQLl26M28+ibWG/HXz/uX2W86emeEZAe+GFrwBzgv1P4kivs2E3IlGjtr0ZYLar8hXyoc9IexQuNw1GeSZND/Fu0zrE6I26QBEn8i1FpJdUVaX5ZGUZ/L59s= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 17 Sep 2012 02:23:41 -0000 Date: 16 Sep 2012 22:24:03 -0400 Message-ID: From: "John R Levine" To: "Byron Ellacott" In-Reply-To: <4E807633-F242-46D5-8D74-DB0FD3C8F409@apnic.net> References: <20120917011842.67025.qmail@joyce.lan> <4E807633-F242-46D5-8D74-DB0FD3C8F409@apnic.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] the problem we're here to solve is WHOIS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 02:24:05 -0000 >> Sure, but since both the questions and answers for numbers and names >> are different, even under the most optimistic assumptions there won't >> be much to share beyond generic json libraries, http redirect codes, and >> maybe authorization schemes. > > Does this mean you think http://tools.ietf.org/html/draft-newton-weirds-unified-json-response is a dead end? With luck it'll let the two applications share some library code, but that doesn't that the fact that the questions and answrs are basically different. R's, John From chris@ausregistry.com.au Sun Sep 16 21:30:03 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6631221F84C9 for ; Sun, 16 Sep 2012 21:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhNR47HTruyP for ; Sun, 16 Sep 2012 21:30:01 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id E91F121F84CF for ; Sun, 16 Sep 2012 21:29:57 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 17 Sep 2012 14:29:55 +1000 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Mon, 17 Sep 2012 14:29:27 +1000 From: Chris Wright To: Andy Newton , "Smith, Bill" , John Levine Date: Mon, 17 Sep 2012 14:29:51 +1000 Thread-Topic: [weirds] URI templates and WEIRDS Thread-Index: AQHNkl0xeVjwvLFVOEGNSOTXei1gS5eKMRSAgAAGtACAA8qWAP//z8GAgAAY5nA= Message-ID: <8CEF048B9EC83748B1517DC64EA130FB72D1CFCB53@off-win2003-01.ausregistrygroup.local> References: <80B2A58AFE381140A62C0512215B4F682AFE1D@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 04:30:03 -0000 QW5keSBldCBhbC4NCg0KPiBUaG91Z2ggRW5nbGlzaCBpcyBhIGhvcnJpYmx5IGltcHJlY2lzZSBs YW5ndWFnZSwgdGhpcyBpc24ndCB0aGF0IGhhcmQuIFRoZSBtZWFuaW5nIG9mIHRoZSBzdWZmaXgg ImZ1bCIgaXMgInRvIGJlIGNoYXJhY3Rlcml6ZWQgYnkiLiBJZiBzb21lYm9keSBpcyBmb3JnZXRm dWwsID4gdGhhdCBtZWFucyB0aGV5IGZvcmdldCBhIGxvdCBvZiB0aGluZ3MgYnV0IGl0IGRvZXMg bm90IG1lYW4gdGhleSBmb3JnZXQgZXZlcnl0aGluZy4gSWYgYSB0b29sIGlzIHVzZWZ1bCwgdGhh dCBtZWFucyBpdCBjYW4gYmUgdXNlZCBmb3IgbWFueSBwdXJwb3NlcyBidXQgPiBkb2VzIG5vdCBt ZWFuIGl0IGNhbiBiZSB1c2VkIGZvciBldmVyeSB0YXNrLiBJZiB3ZSBoYWQgd2FudGVkIHRvIGNy ZWF0ZSBhIFJFU1Qgc2VydmljZSwgdGhlIGNoYXJ0ZXIgd291bGQgc2F5ICJSRVNUIiBhbmQgbm90 ICJSRVNUZnVsIi4NCg0KSSBsaWtlIHlvdXIgZGVmaW5pdGlvbi9jbGFyaWZpY2F0aW9uIGFib3V0 IHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHNheWluZyBiZWluZyBSRVNUIGNvbXBsaWFudCBhcyBv cHBvc2VkIHRvIGJlaW5nICdSRVNUZnVsJywgSW0gbm90IDEwMCUgc3VyZSBJIGFtIG9uIGJvYXJk IHdpdGggaXQgaW4gYSBicm9hZGVyIHNlbnNlLCBidXQgZm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlz IHdvcmtpbmcgZ3JvdXAgbGV0cyBydW4gd2l0aCBpdCwgaXQgbWFrZXMgc2Vuc2UuDQoNCj4gQWxs IHRoYXQgYmVpbmcgc2FpZCwgaWYgdGhlcmUgaXMgc29tZSBmZWF0dXJlIG9yIHV0aWxpdHkgdGhh dCBjYW4gYmUgYWNxdWlyZWQgYnkgbW9yZSBjbG9zZWx5IGFkaGVyaW5nIHRvIGEgcHVyZSBSRVNU IGFyY2hpdGVjdHVyZSwgSSdtIHdpbGxpbmcgdG8gZGlzY3VzcyBpdC4gU28gZmFyIG5vdGhpbmcg aGFzIGJlZW4gb2ZmZXJlZC4NCg0KQSBwdXJlbHkgUkVTVCBzZXJ2aWNlIGZvciBXRUlSRFMgbWln aHQgbG9vayBzb21ldGhpbmcgbGlrZSB0aGlzIChJbSB1c2luZyB0aGUgZG9tYWluIHNlcnZpY2Ug YXMgYW4gZXhhbXBsZSwgYnV0IHNpbWlsYXIgY291bGQgYmUgZG9uZSBmb3IgQVMgbnVtYmVycywg SVAgQWRkcmVzc2VzIGFuZCB0aGUgbGlrZSkgLSBhbmQgbm90ZSB0aGF0IHRoaXMgaXMganVzdCBv bmUgcG9zc2libGUgc2VydmljZSB0aGF0IHdvdWxkIHF1YWxpZnkgYXMgUkVTVC4uLiAoYWxzbyBu b3RlIHRoYXQgbXkgZXhhbXBsZXMgYXJlbid0IGV4YWN0bHkgIHN5bnRhY3RpY2FsbHkgY29ycmVj dCkNCg0KU2F5IEkgaGFkIGEgY2xpZW50IHRoYXQgd2FzIHRyeWluZyB0byBmaW5kIHRoZSBpbmZv cm1hdGlvbiBhYm91dCBleGFtcGxlLmNvbSAtIHRoZSBmbG93IGluIGEgUkVTVCB3b3JsZCB3b3Vs ZCBnbyBzb21ldGhpbmcgbGlrZSB0aGlzLi4uIA0KDQpUaGUgZW50cnkgcG9pbnQgd291bGQgYmUg YSB3ZWxsIGtub3cgVVJMIGxldCdzIGNhbGwgaXQgaHR0cDovL3dlaXJkcy5pYW5hLm9yZyB3aGlj aCB3b3VsZCByZXR1cm4gYSBkb2N1bWVudCAocHJvYmFibHkgZW5jb2RlZCBpbiBKU09OKSB0aGF0 IGdhdmUgeW91IGEgbGlzdCBvZiB0aGUgVExEcyBpbiB0aGUgcm9vdCB6b25lLCBhbmQgbGluayB0 byBhIHJlc291cmNlIHRoYXQgY29udGFpbnMgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgVExE cy4uIGZvciBlZyBpdCBtaWdodCByZXR1cm4NCg0KDQp7DQoJZG9tYWluIDogeyBuYW1lOiBjb20s IGxpbms6IHsgcmVsYXRpb246IGl0ZW0sIHVybDogaHR0cDovL3dlaXJkcy5pYW5hLm9yZy9kb21h aW4/ZG9tYWluPWNvbSB9IH0NCglkb21haW46IHsgbmFtZTogbmV0LCBsaW5rOiAgeyByZWxhdGlv bjogaXRlbSwgdXJsOiBodHRwOi8vd2VpcmRzLmlhbmEub3JnL2RvbWFpbj9kb21haW49bmV3IH0g fQ0KCWV0Yy4uLg0KfQ0KDQoqbm90ZSB0aGF0IHRoZSByZWxhdGlvbnMgdGhhdCBhcmUgcmVwcmVz ZW50ZWQgYnkgbGlua3MgYXJlIGFjdHVhbGx5IGRlZmluZWQgaW4gYW4gSUFOQSByZWdpc3RyeSBo ZXJlICh3ZSBjYW4gYWRkIG1vcmUgdG8gdGhpcyB3aXRoIG91ciBwcm90b2NvbCBpZiB3ZSBkZXNp cmUpIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvbGluay1yZWxhdGlvbnMvbGluay1y ZWxhdGlvbnMueG1sIE1vc3Qgb2YgdGhpcyBzdHVmZiwgc3RhcnRlZCBmcm9tIHRoZSBBVE9NIHBy b3RvY29sIEkgYmVsaWV2ZSwgd2hpY2ggaXMgYSB3ZWxsLWtub3duIFJFU1QgcHJvdG9jb2wgLSBt YXliZSB3ZSBzaG91bGQgYXNrIHRoZSBBVE9NIHBlb3BsZSBmb3IgYXNzaXN0YW5jZS4NCg0KQW55 d2F5IG1vdmluZyBvbiwgdGhlbiBhIGNsaWVudCB3b3VsZCBmb2xsb3cgdGhlIGxpbmsgdG8gZ2V0 IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbSAnaXRlbScgaW4gdGhlIGxpc3Qgd2hpY2gg bWlnaHQgcmV0dXJuIHRoZSBmb2xsb3dpbmc6DQoNCnsNCglkb21haW5OYW1lOiBjb20sDQoJcmVn aXN0cnlNYW5hZ2VyOiB7IG5hbWU6IHZlcmlzaWduLCBsaW5rOiB7IHJlbGF0aW9uOiByZWdpc3Ry eSB1cmw6IGh0dHA6Ly93ZWlyZHMudmVyc2lnbi5jb20vYmFzZT9yZWdpc3RyeT12ZXJzaWduIH0g fSwNCglyZWdpc3RlcmVkRG9tYWluczogeyBsaW5rOiB7IHJlbGF0aW9uOmNvbGxlY3Rpb24gdXJs OiBodHRwOi8vd2VpcmRzLnZlcmlzaWduLmNvbS9kb21haW5zIH19LA0KCWxhc3RVcGRhdGVkOiAi MS8zLzIwMTAgIg0KCWV0Yw0KfQ0KDQpUaGVuIHRoZSBjbGllbnQgd291bGQgcXVlcnkgdGhlIGh0 dHA6Ly93ZWlyZHMudmVyc2lnbi5jb20vZG9tYWlucyB1cmwgKG5vdGUgdGhhdCB0aGF0IHVybCBj b3VsZCBoYXZlIGp1c3QgYXMgZWFzaWx5IGJlZW4gZnRwOi8vd2VpcmRzLnZlcmlzaWduLmNvbS9k b21haW4uanNvbi5saXN0ICkgYW5kIHByb2JhYmx5IGdldCBhIHJlc3BvbnNlIHNvbWV0aGluZyBs aWtlIHRoZSBhYm92ZSBzYXk6DQoNCg0Kew0KCWRvbWFpbiA6IHsgbmFtZTogZ29vZ2xlLmNvbSwg bGluazogeyByZWxhdGlvbjogaXRlbSwgdXJsOiBodHRwOi8vd2VpcmRzLnZlcmlzaWduLmNvbS9k b21haW4/ZG9tYWluPWdvb2dsZS5jb20gfSB9DQoJZG9tYWluOiB7IG5hbWU6IGJsYWguY29tLCBs aW5rOiAgeyByZWxhdGlvbjogaXRlbSwgdXJsOiBodHRwOi8vd2VpcmRzLnZlcmlzaWduLmNvbS9u ZXdEb21haW4vZ2V0RG9tYWluSW5mbz9kb21haW49YmxhaC5jb20gfSB9DQoJZG9tYWluIDogeyBu YW1lOiBleGFtcGxlLmNvbSwgbGluazogeyByZWxhdGlvbjogaXRlbSwgdXJsOiBodHRwOi8vd2Vp cmRzLnZlcmlzaWduLmNvbS9yZXNlcnZlZERvbWFpbnM/ZG9tYWluPWV4YW1wbGUuY29tIH0gfQ0K CWV0Yy4uLg0KfQ0KDQpOb3RlIHRoZSBkaWZmZXJlbnQgVVJMcywgdGhpcyBpcyBhY3R1YWxseSBu b3QgYSBwcm9ibGVtIGFuZCBleGFjdGx5IHdoYXQgUkVTVCBpcyBhbGwgYWJvdXQsIHRoZSBVUkxz IGFyZSAnbGVhcm5lZCcgYW5kIHRoZW4gZm9sbG93ZWQsIGVhY2ggc2VydmVyIGNhbiBtYWtlIHVw IHRoZWlyIG93biBzY2hlbWVzIGFuZCBzbyBmb3J0aC4NCg0KU28gdGhlIGFkdmFudGFnZXMgb2Yg dGhpcyBhcmUgbWFueSwgd2Ugb25seSBuZWVkIGRlZmluZSBlbmNvZGluZ3MsIGFuZCBsaW5rIHJl bGF0aW9ucywgYW5kIGhvdyB3ZSBhcmUgZ29pbmcgdG8gcmVwcmVzZW50IHRob3NlIGxpbmsgcmVs YXRpb25zIGluIG91ciBvYmplY3RzIGJ1dCB0aGF0cyBhYm91dCBpdC4uLiB0aGUgYWN0dWFsbCB0 cmFuc3BvcnQgaXMgaXJyZWxldmFudCB0byB0aGUgcHJvdG9jb2wgZXRjICh3ZSBjb3VsZCBsb2Nr IGl0IGRvd24gdG8ganVzdCBIVFRQKSB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBpcyBzbWFs bGVyLCBjbGVhbmVyIGVhc2llciB0byB1bmRlcnN0YW5kIGFuZCBtdWNoIG1vcmUgZmxleGlibGUs IHRoZSBkaXNhZHZhbnRhZ2UgaXMgKGF0IGxlYXN0IGluIHRoaXMgZXhhbXBsZSBvZiBhIFJFU1Qg bW9kZWwpIGl0IHJlcXVpcmVzIGEgY2VudHJhbCBzdGFydGluZyBwb2ludC4gV2UgY291bGQgd29y ayBhcm91bmQgdGhhdCBieSBoYXZpbmcgYSB3YXkgaW4gdGhlIFdFSVJEUyBwcm90b2NvbCB0aGF0 IHlvdSAnaW5mZXInIGEgc3RhcnRpbmcgcG9pbnQgYmFzZWQgb24gd2hhdCB5b3VyIHRyeWluZyB0 byBsb29rIHVwLCAodGhlIGJvb3Qgc3RyYXBwaW5nIHdlIGhhZCBiZWVuIHRhbGtpbmcgYWJvdXQg ZWFsaWVyKSwgc28gZXNzZW50aWFsbHkgZWFjaCByZWdpc3RyeSB3b3VsZCBzdGlsbCBwcm92aWRl IGEgcHVyZWx5IFJFU1Qgc2VydmljZSwgYnV0IHRoZSBzaW5nbGUgZW50cnkgcG9pbnQgaXMgcGVy IHJlZ2lzdHJ5IGFuZCBsb29rZWQgdXAgZXh0ZXJuYWwgdG8gdGhlIFJFU1QgcGFydCBvZiB0aGUg b3ZlcmFsbCBwcm90b2NvbC4gQW5vdGhlciBwb3RlbnRpYWwgcHJvYmxlbSB3aXRoIHRoaXMgYXBw cm9hY2ggaXMgdGhhdCBieSB2ZXJ5IGRlZmluaXRpb24gSSBuZWVkIHRvIGJlIGFibGUgdG8gZ2V0 IGEgbGlzdCBvZiBkb21haW5zIHRvIGZpbmQgdGhlIFVSTHMgdG8gdGhlIHNwZWNpZmljIGl0ZW0g LSBzb21lIGNjVExEcyB3b3VsZCBub3QgbGlrZSB0aGlzLiBBbHNvIGFzIHRoZSBudW1iZXIgb2Yg ZG9tYWlucyBnZXRzIGJpZ2dlciAodGhpbmsgdmVyaXNpZ24gd2l0aCB0aGUgfjEwMCBtaWxsaW9u IC5jb21zLCB0aGUgbGlzdHMgd291bGQgYmUgbGFyZ2UgYW5kIHdvdWxkIG5lZWQgdG8gYmUgYWJs ZSB0byBiZSBmaWx0ZXJlZCAtIHNvIGluIHRoZSBlbmQsIEkgZG9u4oCZdCB0aGluayB0aGF0IHdo YXQgd2UgYXJlIHRyeWluZyB0byBkbyB3aXRoIFdFUklEUyBhY3R1YWxseSBmaXRzIG5pY2VseSBp bnRvICAodGhpcyBpbnRlcnByZXRhdGlvbiBvZikgUkVTVC4gUGVyaGFwcyB0aGVyZSBpcyBhIHdh eSB0byBhZGRyZXNzIHRoZXNlIGNvbmNlcm5zIGluIGEgcHVyZSBSRVNUIGltcGxlbWVudGF0aW9u IGJ1dCBJIGhhdmUgcHV0IGFib3V0IDEwIG1pbnMgb2YgdGhvdWdodCBpbnRvIHRoZSBSRVNUIGV4 YW1wbGUgaW4gdGhpcyBlbWFpbCBhbmQgdGhleSB3ZXJlbid0IGltbWVkaWF0ZWx5IG9idmlvdXMu DQoNClNvIEkgdGhpbmsgbXkgdm90ZSBpcyBzdGlsbCBzb21ldGhpbmcga2luZGEgbGlrZSBSRVNU LCBidXQgdGhhdCBpcyBub3QgYWN0dWFsbHkgUkVTVCwgYW5kIHRoYXQgd2Ugc3RvcCBjYWxsaW5n IGl0IFJFU1QgYW5kIGJlIGRvbmUgd2l0aCBpdCwgY2FuIHdlIGdldCBldmVyeW9uZSB0byBhZ3Jl ZSB0byB0aGF0PyAoQWx0aG91Z2ggaWYgb3RoZXJzIGZlbHQgc3Ryb25nbHkgdGhhdCB0aGV5IHdh bnRlZCB0byBjb250aW51ZSBjcmVhdGluZyBhIHB1cmUgUkVTVCBzZXJ2aWNlIHRoZW4gSSBhbSBm aW5lIHdpdGggdGhhdCB0bywgYnV0IGxldCdzIG1ha2UgYSBjYWxsIG9uZSB3YXkgb3IgdGhlIG90 aGVyIGFuZCB0aGVuIG1vdmUgb24pLg0KDQpUaGFua3MNCg0KYy4NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogd2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp3ZWly ZHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkgTmV3dG9uDQpTZW50OiBNb25k YXksIDE3IFNlcHRlbWJlciAyMDEyIDEyOjI0IFBNDQpUbzogU21pdGgsIEJpbGw7IEpvaG4gTGV2 aW5lDQpDYzogPHdlaXJkc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbd2VpcmRzXSBVUkkgdGVt cGxhdGVzIGFuZCBXRUlSRFMNCg0KDQoNCk9uIDkvMTYvMTIgOToxNiBQTSwgIlNtaXRoLCBCaWxs IiA8YmlsbC5zbWl0aEBwYXlwYWwtaW5jLmNvbT4gd3JvdGU6DQoNCj4NCj5PbiBTZXAgMTQsIDIw MTIsIGF0IDg6MjIgQU0sIEpvaG4gTGV2aW5lIDxqb2hubEB0YXVnaC5jb20+IHdyb3RlOg0KPg0K Pj4gDQo+PiBJIHdvdWxkIGNoZWVyZnVsbHkgY2hhbmdlIGFsbCBvZiB0aGUgbWVudGlvbnMgb2Yg IlJFU1RmdWwiIHRvICJmbHVmZnkgDQo+PiBidW5ueSIgaW4gdGhlIGNoYXJ0ZXIgaWYgaXQgd291 bGQgbWFrZSB0aGlzIGFyZ3VtZW50IGdvIGF3YXkuDQo+PiANCj4NCj5JIGFnYWluIHBvaW50IHRv IHRoZSBjaGFydGVyIHRoYXQgc3RhdGVzICJUaGUgZnJhbWV3b3JrIHNoYWxsIGJlIGZvciANCj5k YXRhIHRvIGJlIGRlbGl2ZXJlZCB2aWEgYSBSRVNUZnVsIGRhdGEgc2VydmljZSB1c2luZyBIVFRQ IChvcHRpb25hbGx5IA0KPnVzaW5nIFRMUykiLg0KPg0KPklNTywgdGhhdCdzIGEgc3Ryb25nIHN0 YXRlbWVudCBhbmQgc2F5cyB0aGlzIGdyb3VwICp3aWxsKiBwcm9kdWNlIGEgDQo+UkVTVGZ1bCBz ZXJ2aWNlLg0KPg0KPk9mIGNvdXJzZSB3ZSBjb3VsZCBvcGVuIHVwIGEgY2hhcnRlciBkaXNjdXNz aW9uLCBhZ2FpbiwgYnV0IHdvdWxkIHRoYXQgDQo+YmUgcHJvZHVjdGl2ZT8NCg0KDQpJdCdzIGdv b2QgdGhhdCB3ZSBhcmUgaGF2aW5nIHRoZXNlIGNvbnZlcnNhdGlvbnMsIG90aGVyd2lzZSByZWFs IHdvcmsgbWlnaHQgZ2V0IGFjY29tcGxpc2hlZC4gOikNCg0KVGhvdWdoIEVuZ2xpc2ggaXMgYSBo b3JyaWJseSBpbXByZWNpc2UgbGFuZ3VhZ2UsIHRoaXMgaXNuJ3QgdGhhdCBoYXJkLiBUaGUgbWVh bmluZyBvZiB0aGUgc3VmZml4ICJmdWwiIGlzICJ0byBiZSBjaGFyYWN0ZXJpemVkIGJ5Ii4gSWYg c29tZWJvZHkgaXMgZm9yZ2V0ZnVsLCB0aGF0IG1lYW5zIHRoZXkgZm9yZ2V0IGEgbG90IG9mIHRo aW5ncyBidXQgaXQgZG9lcyBub3QgbWVhbiB0aGV5IGZvcmdldCBldmVyeXRoaW5nLiBJZiBhIHRv b2wgaXMgdXNlZnVsLCB0aGF0IG1lYW5zIGl0IGNhbiBiZSB1c2VkIGZvciBtYW55IHB1cnBvc2Vz IGJ1dCBkb2VzIG5vdCBtZWFuIGl0IGNhbiBiZSB1c2VkIGZvciBldmVyeSB0YXNrLiBJZiB3ZSBo YWQgd2FudGVkIHRvIGNyZWF0ZSBhIFJFU1Qgc2VydmljZSwgdGhlIGNoYXJ0ZXIgd291bGQgc2F5 ICJSRVNUIiBhbmQgbm90ICJSRVNUZnVsIi4NCg0KVGhlIHB1cnBvc2Ugb2YgdXNpbmcgdGhlIHRl cm0gIlJFU1RmdWwgd2ViIHNlcnZpY2UiIGlzIHRvIGRpZmZlcmVudGlhdGUgZnJvbSBvdGhlciB0 eXBlcyBvZiB3ZWIgc2VydmljZXMsIG5vdGFibHkgdGhlIFNPQVAgYmFzZWQgc2VydmljZXMuIEl0 J3MgYSAidXNlZnVsIiBkaXN0aW5jdGlvbiBpbiB0aGF0IGl0IGdpdmVzIHRoZSByZWFkZXIgb2Yg dGhpcyBpbnRlcm9wZXJhYmxlIHNwZWNpZmljYXRpb24gYSBzdGFydGluZyBwb2ludCBpbiB1bmRl cnN0YW5kaW5nIHRoZSBwcm90b2NvbCBkZXNjcmlwdGlvbi4NCkFuZCBhZnRlciBhbGwsIGFuIGlu dGVyb3BlcmFibGUgc3BlY2lmaWNhdGlvbiBpcyB3aGF0IHdlIGFyZSB0byBwcm9kdWNlLg0KSWYg dGhlIGdyZWF0ZXIgdW5pdmVyc2Ugb2YgSW50ZXJuZXQgcHJvZ3JhbW1lcnMgcmVjb2duaXplcyB3 aGF0IGlzIGJlaW5nIGRlc2NyaWJlZCBoZXJlIGFzIGEgIlJFU1RmdWwgd2ViIHNlcnZpY2UiLCB0 aGVuIHRoZSB0ZXJtIGhhcyBkb25lIGl0cyBqb2IgcmVnYXJkbGVzcyBvZiBob3cgdW5jb21mb3J0 YWJsZSB0aGF0IG1pZ2h0IG1ha2Ugc29tZSBwcm90b2NvbCBwdXJpc3Qgd29uay4NCg0KQWxsIHRo YXQgYmVpbmcgc2FpZCwgaWYgdGhlcmUgaXMgc29tZSBmZWF0dXJlIG9yIHV0aWxpdHkgdGhhdCBj YW4gYmUgYWNxdWlyZWQgYnkgbW9yZSBjbG9zZWx5IGFkaGVyaW5nIHRvIGEgcHVyZSBSRVNUIGFy Y2hpdGVjdHVyZSwgSSdtIHdpbGxpbmcgdG8gZGlzY3VzcyBpdC4gU28gZmFyIG5vdGhpbmcgaGFz IGJlZW4gb2ZmZXJlZC4NCg0KLWFuZHkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCndlaXJkcyBtYWlsaW5nIGxpc3QNCndlaXJkc0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWlyZHMNCg== From fobispo@isc.org Sun Sep 16 22:49:35 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67B721E803C for ; Sun, 16 Sep 2012 22:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+AxuFql9vfV for ; Sun, 16 Sep 2012 22:49:34 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 45C6221E8034 for ; Sun, 16 Sep 2012 22:49:34 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id C280B5F9921; Mon, 17 Sep 2012 05:49:21 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.105] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8B0B2216C3D; Mon, 17 Sep 2012 05:49:19 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB72D1CFCB53@off-win2003-01.ausregistrygroup.local> Date: Sun, 16 Sep 2012 22:49:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8A4AAE91-9222-4694-B519-38CBFC7E1B46@isc.org> References: <80B2A58AFE381140A62C0512215B4F682AFE1D@DEN-EXDDA-S12.corp.ebay.com> <8CEF048B9EC83748B1517DC64EA130FB72D1CFCB53@off-win2003-01.ausregistrygroup.local> To: Byron Ellacott , Chris Wright X-Mailer: Apple Mail (2.1486) Cc: weirds@ietf.org Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 05:49:35 -0000 here a more complete response/set of thoughts for those interested: On Sep 16, 2012, at 9:29 PM, Chris Wright = wrote: > Also as the number of domains gets bigger (think verisign with the = ~100 million .coms, the lists would be large and would need to be able = to be filtered - so in the end, I don=92t think that what we are trying = to do with WERIDS actually fits nicely into (this interpretation of) = REST. Perhaps there is a way to address these concerns in a pure REST = implementation but I have put about 10 mins of thought into the REST = example in this email and they weren't immediately obvious. >=20 Most people favored JSON as the default transport for the response, I = was originally suggesting XML, and one of the advantages, is that I can = use an event-driven parser (SAX), and extract only the parts of the XML = that I need from a stream (filehandle, network stream, etc.) without = having to load all the document in memory. Most JSON parsers that I've used load the whole document in memory, so = you would have to have a lot of memory available to process a COM = response. :-S > So I think my vote is still something kinda like REST, but that is not = actually REST, and that we stop calling it REST and be done with it, can = we get everyone to agree to that? (Although if others felt strongly that = they wanted to continue creating a pure REST service then I am fine with = that to, but let's make a call one way or the other and then move on). I have to confess that I have not reviewed the query document as much as = I've wanted to, but here are my thoughts on the whole process:=20 We only need an anchor point for the TLD or IP delgation to do a = successful discovery. But when I think of RESTful I think of having a = table with: Root: https://weirds.nic.TLD/ Method: HEAD GET PUT POST DELETE URL /domain/example.com 1 1 0 0 0 /contact/sh8013 1 1 0 0 0 /host/ns1.example.com 1 1 0 0 0 /registrar/foo-registrar 1 1 0 0 0 /search/query-string 1 1 0 0 0=09 In this case, since this would be a read-only protocol, we would not = implement PUT POST or DELETE, except for creating/ending a session, but = that's another issue. When using the HEAD method, we would check for object existence, the GET = method will return the data associated with it. /search/ would be a special URI to perform whois-equivalent queries = where all the supported namespaces would be searched for an exact match, = or a partial match based on some rules/permissions. The response document should contain the object description, and if = provided an optional flag, return the information associated to = contained objects. For a domain query: { "version":"1.0", "object":{ "namespace":"domain-1.0", "name":"example.com:", "registrant":"sh8013", "contacts":{ "tec":["fo1234","abd4321"], "adm":["foo412","bar543"] }, "hosts":["ns1.example.com","ns2.example.net"], "registrar":"foo-registrar", "updatedDate":"2012-04-01T12:00:12.0Z", "createdDate":"2010-01-03T14:10:14.0Z" }, "uri":"https://weirds.nic.TLD/domain/example.com", "responseDate": "2012-09-16T21:54:12.0Z" } For a domain query with the "returnAll" flag (or whatever we want to = call it): { "version":"1.0", "object":{ "namespace":"domain-1.0", "name":"example.com:", "registrant":"sh8013", "contacts":{ "tec":["fo1234"], "adm":["foo412"] }, "hosts":["ns1.example.com","ns2.example.net"], "registrar":"foo-registrar", "updatedDate":"2012-04-01T12:00:12.0Z", "createdDate":"2010-01-03T14:10:14.0Z" }, "additional":{ "contacts":{ "sh8013":{ "namespace":"contact-1.0", "id":"sh8013", "name":"Foo Bar", "email":"foobar@example.com", "addresses":[=20 {=20 "address":["950 = Charter St.","Redwood City"], "state":"CA", "country:"US" } ], = "createdDate":"2001-04-05T12:00:00.0Z", }, "fo1234":{ "namespace":"contact-1.0", "id":"fo1234", "name":"Foo Bar", "email":"foobar@example.com", "addresses":[=20 {=20 "address":["950 = Charter St.","Redwood City"], "state":"CA", "country:"US" } ], = "createdDate":"2001-04-05T12:00:00.0Z", }, "foo412":{ "namespace":"contact-1.0", "id":"foo412", "name":"Foo Bar", "email":"foobar@example.com", "addresses":[=20 {=20 "address":["950 = Charter St.","Redwood City"], "state":"CA", "country:"US" } ], = "createdDate":"2001-04-05T12:00:00.0Z", } }, "hosts":{ "ns1.example.com":{ "namespace":"host-1.0", "name":"ns1.example.com", = "addresses":["2001:4f8:a:b:c::1","149.20.200.1"], = "createdDate":"2010-10-10T12:00:00.0Z", }, "ns2.example.net":{ "namespace":"host-1.0", "name":"ns2.example.net", = "addresses":["2001:4f8:a:b:c::1","149.20.200.1"], = "createdDate":"2010-10-10T12:00:00.0Z", }, "registrars":{ "namespace":"registrar-1.0", "name":"foo-registrar", "url":"http://foo-registrar.com" } } "uri":"https://weirds.nic.TLD/domain/example.com", "responseDate": "2012-09-16T21:54:12.0Z" } This is my idea on how we should be representing the responses.. Notice = the enclosure format, there is a version, a response section, an = additional section, a response date, and a URI that was used to retrieve = the query. There are several advantages of this: 1) If someone stores the file, it can easily identify it; 2) Objects have a "namespace" associated with it, which allows clients = to quickly identify the type of object thus be able to process it = accordingly (knowing exactly which fields to fetch and how to present = them). 3) If the "returnAll" flag is turned "on", (which should be definable by = registry policy), the response will also contain an "additional" section = with the additional "objects" identifying the query. 4) If I am a system performing thousands of queries, I could cache the = individual object responses (with a lifetime), and prevent additional = queries to the servers. (whois to RDAP) 5) There is coherence with EPP with the ability to support registry = objects in general, so a group of people could work on the various = objects for their own types of registries: names, and numbers working = independently but agreeing on common object types: contacts, hosts 6) An additional "extension" section could be implemented either at the = object level or at the response level to provide additional information = not supported natively by the protocol, (AGP, TMCH, DNSSEC, IDN, etc.) To demonstrate how easy it would be to process this.. If I was a mail = administrator trying to contact the technical contact to report a = problem, all I needed to do was: 1) query: https://weirds.nic.TLD/domain/example.com?returnAll=3D1 2) parse the response with a JSON parser and call (perl pseudo code): # obtain the first technical contact from the contacts list $tech_ref=3D$response_json->{object}->{contacts}->{tec}->[0]; # use the contact from the additional section = $tech_contact=3D$response_json->{additional}->{contacts}->{$tech_ref}; &send_email( to=3D>$tech_contact->{email}, name=3D>$tech_contact->{name} ); If the returnAll option was disabled the main difference would be: 1) query: https://weirds.nic.TLD/domain/example.com?returnAll=3D0 2) parse the response with a JSON parser and call (perl pseudo code): # obtain the first technical contact from the contacts list $tech_ref=3D$response_json->{object}->{contacts}->{tec}->[0]; # &fetch_contact() would perform a GET request to=20 # https://weirds.nic.TLD/contact/fo1234 and=20 $query2=3D&fetch_contact($tech_ref); # use the returned object as the tech contact $tech_contact=3D$query2->{object}; # send email &send_email( to=3D>$tech_contact->{email}, name=3D>$tech_contact->{name} ); This should help clear some of the doubts about introducing additional = complexity. The idea of separating the response into different sections = is very similar, and it uses the same rationale as EPP, with this we now = have a more robust protocol that can adapt to more object types and also = be extensible for those cases where the standard set of responses don't = fit the current schema. Hopefully there will be some reconsideration going forward, I think I've = explained myself enough to get some opinions. Best regards, Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From bje@apnic.net Mon Sep 17 00:10:13 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29A121F84B2 for ; Mon, 17 Sep 2012 00:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCPLFsjhEgij for ; Mon, 17 Sep 2012 00:10:13 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 73FA321E8034 for ; Mon, 17 Sep 2012 00:10:11 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:f46b:f269:98b0:2467] (unknown [IPv6:2001:dc0:a000:4:f46b:f269:98b0:2467]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 70DA9B68A0; Mon, 17 Sep 2012 17:10:09 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_71236F21-CB01-4919-9038-9E5109A801A9"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: <8A4AAE91-9222-4694-B519-38CBFC7E1B46@isc.org> Date: Mon, 17 Sep 2012 17:10:08 +1000 Message-Id: References: <80B2A58AFE381140A62C0512215B4F682AFE1D@DEN-EXDDA-S12.corp.ebay.com> <8CEF048B9EC83748B1517DC64EA130FB72D1CFCB53@off-win2003-01.ausregistrygroup.local> <8A4AAE91-9222-4694-B519-38CBFC7E1B46@isc.org> To: Francisco Obispo X-Mailer: Apple Mail (2.1278) Cc: weirds@ietf.org Subject: Re: [weirds] Response container structure X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 07:10:14 -0000 --Apple-Mail=_71236F21-CB01-4919-9038-9E5109A801A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Francisco, On 17/09/2012, at 3:49 PM, Francisco Obispo wrote: > Most JSON parsers that I've used load the whole document in memory, so = you would have to have a lot of memory available to process a COM = response. :-S I would hope that looking up the entire list of registrations = underneath .COM. is NOT a necessary step in looking up the registration = data for EXAMPLE.COM. :-) > For a domain query with the "returnAll" flag (or whatever we want to = call it): >=20 > { > "version":"1.0", [full example cut for brevity] > } >=20 > This is my idea on how we should be representing the responses.. = Notice the enclosure format, there is a version, a response section, an = additional section, a response date, and a URI that was used to retrieve = the query. How is this objectively superior to: { "version":"1.0", "object": { "namespace":"domain-1.0", "name":"example.com:", "registrant": { "namespace":"contact-1.0", "id":"sh8013", "name":"Foo Bar", "email":"foobar@example.com", "addresses":[ {=20 "address":["950 Charter St.","Redwood = City"], "state":"CA", "country:"US" } ], "createdDate":"2001-04-05T12:00:00.0Z", } "contacts":{ "tec": { "namespace":"contact-1.0", "id":"fo1234", "name":"Foo Bar", "email":"foobar@example.com", "addresses": [ {=20 "address":["950 Charter = St.","Redwood City"], "state":"CA", "country:"US" } ], "createdDate":"2001-04-05T12:00:00.0Z", } "adm": { "namespace":"contact-1.0", "id":"foo412", "name":"Foo Bar", "email":"foobar@example.com", "addresses": [ {=20 "address":["950 Charter = St.","Redwood City"], "state":"CA", "country:"US" } ], "createdDate":"2001-04-05T12:00:00.0Z", }, } "hosts":[ { "namespace":"host-1.0", "name":"ns1.example.com", = "addresses":["2001:4f8:a:b:c::1","149.20.200.1"], "createdDate":"2010-10-10T12:00:00.0Z", }, { "namespace":"host-1.0", "name":"ns2.example.com", = "addresses":["2001:4f8:a:b:c::1","149.20.200.1"], "createdDate":"2010-10-10T12:00:00.0Z", }, ], "registrar": { "namespace":"registrar-1.0", "name":"foo-registrar", "url":"http://foo-registrar.com" }, "updatedDate":"2012-04-01T12:00:12.0Z", "createdDate":"2010-01-03T14:10:14.0Z" }, "uri":"https://weirds.nic.TLD/domain/example.com", "responseDate": "2012-09-16T21:54:12.0Z" } > There are several advantages of this: >=20 > 1) If someone stores the file, it can easily identify it; Still true; > 2) Objects have a "namespace" associated with it, which allows clients = to quickly identify the type of object thus be able to process it = accordingly (knowing exactly which fields to fetch and how to present = them). Still true; the current unified response draft doesn't include the type = of the top level response object, which I think is a weakness we can = correct, but the type of subsequent objects can be easily inferred by = its position in the response document. I note your example assumes that = something contained in $response_json->{additional}->{contacts} is, in = fact, a contact, too. :-) > 3) If the "returnAll" flag is turned "on", (which should be definable = by registry policy), the response will also contain an "additional" = section with the additional "objects" identifying the query. Expand or do not expand the sub-objects; interesting potential = discussion over a "returnAll" flag to have, I don't feel strongly either = way, though it would be perhaps polite to make the reference a URI = instead of an opaque string, if you're not going to include the actual = data. > 4) If I am a system performing thousands of queries, I could cache the = individual object responses (with a lifetime), and prevent additional = queries to the servers. (whois to RDAP) Since your front-end is building the final answer each time, it makes no = (apparent) difference whether the individual object responses are = structurally placed at point A or point B in the output. > 5) There is coherence with EPP with the ability to support registry = objects in general, so a group of people could work on the various = objects for their own types of registries: names, and numbers working = independently but agreeing on common object types: contacts, hosts Still true; > 6) An additional "extension" section could be implemented either at = the object level or at the response level to provide additional = information not supported natively by the protocol, (AGP, TMCH, DNSSEC, = IDN, etc.) Still true; you just put the additional information right where you'd = otherwise have needed to put a dangling link to the additional = information anyway. (And, just for the record, I would be disappointed = with the WG outcome if DNSSEC and IDN data were not supported natively = in the drafts we produce in this first chartered set of milestones. :-) > To demonstrate how easy it would be to process this.. If I was a mail = administrator trying to contact the technical contact to report a = problem, all I needed to do was: Agreed, your example is neither harder nor easier to process than my = example. If you're using a SAX parser for an XML document, you'd enter = an element with a particular namespace and shoot off to the right = handler for that element and its children, regardless of where it = appeared in the document. I think you've answered my original question, which was whether URI = templates are a critical part of your preferred representation - I don't = think they are, so we are having a discussion around the structure of = the container. I will freely admit that I prefer nested for no particular technical = reason. It "feels" like a flat model exposes an implementation specific = abstraction of data, while a nested model "feels" like it talks about = the registration information as a cohesive whole as seen from that = perspective, but these are clearly not technical justifications, they = are aesthetic. Are there technical justifications either way that I'm missing? Byron --Apple-Mail=_71236F21-CB01-4919-9038-9E5109A801A9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MTcwNzEwMDlaMCMGCSqGSIb3DQEJBDEWBBSQ +QNbuIKtpJUlhCuRO8t4Lc+gwjCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQBbY8oAC2gLHPxl GAWzL/sN9LY3EkIZIFDdLj3uBD1929f59rxIrbuiQTrT4St6lnEsTmNS8Q1as2MkdYTA2oGOPQuF qAmHXUt1lo44MEF/YGg9B/jbQZcmSUjOc6WIpJ1z8yAvd3ce5fI4YVpulYPZUFkcKb5XMZ8bkV0a BRVI8joSkiAZqJXYdWTPE4Mc/YLlQXRdmQR8OKti6ZFlsvrO+FpWTiFdiMzmPq+gFGAtivP0UNZ6 WA0bU6uvRyYH0oPhoxNVCetrqENz6nfd9B9n0JYdO9TFEXb5bzvDKcrh10MOZdQS4rhAh7a/vLxB wY8gRnPwfbYst2oyMyRU2FswAAAAAAAA --Apple-Mail=_71236F21-CB01-4919-9038-9E5109A801A9-- From andy@arin.net Mon Sep 17 07:02:51 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE0F21F844B for ; Mon, 17 Sep 2012 07:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc-FnU6sSr+6 for ; Mon, 17 Sep 2012 07:02:28 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 6275621F842F for ; Mon, 17 Sep 2012 07:02:28 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 8DBCB165159; Mon, 17 Sep 2012 10:02:20 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id BDCD816512F; Mon, 17 Sep 2012 10:02:19 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 17 Sep 2012 10:02:08 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 10:02:12 -0400 From: Andy Newton To: Chris Wright , "Smith, Bill" , John Levine Thread-Topic: [weirds] URI templates and WEIRDS Thread-Index: AQHNkl0xeVjwvLFVOEGNSOTXei1gS5eKMRSAgAAGtACAA8qWAP//z8GAgAAY5nCAAKpPAA== Date: Mon, 17 Sep 2012 14:02:11 +0000 Message-ID: In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB72D1CFCB53@off-win2003-01.ausregistrygroup.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <7DE4024629CB2844A76E73F001B29BAD@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [weirds] URI templates and WEIRDS X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 14:02:51 -0000 On 9/17/12 12:29 AM, "Chris Wright" wrote: >So I think my vote is still something kinda like REST, but that is not >actually REST, and that we stop calling it REST and be done with it, can >we get everyone to agree to that? (Although if others felt strongly that >they wanted to continue creating a pure REST service then I am fine with >that to, but let's make a call one way or the other and then move on). Chris, Many thanks for the description. I agree, we don't want a pure REST system. There are serious issue with it in our use cases, and we've even discussed the gaps in our bootstrapping threads and just didn't know it. And I agree we shouldn't call our work REST. But "RESTful" is a perfectly adequate description for the reasons I've given. And one last thing (not aimed at you Chris :) ): If we want to start playing these architectural purity games then I suggest the REST purists pay closer attention to BCP 56. -andy From andy@arin.net Mon Sep 17 07:30:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65A421F867A for ; Mon, 17 Sep 2012 07:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0hqC7tEnbhk for ; Mon, 17 Sep 2012 07:30:43 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBB121F8678 for ; Mon, 17 Sep 2012 07:30:42 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 0E389213675; Mon, 17 Sep 2012 10:30:42 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 0EBD321361C; Mon, 17 Sep 2012 10:30:41 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 17 Sep 2012 10:30:35 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 10:30:40 -0400 From: Andy Newton To: Byron Ellacott , Francisco Obispo Thread-Topic: [weirds] Response container structure Thread-Index: AQHNlKOEMgx/JUEDdU6jax6CGftCgZeOmLwA Date: Mon, 17 Sep 2012 14:30:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="Windows-1252" Content-ID: <66023E4887534D4EA580C12D2A68C5E2@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Response container structure X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 14:30:43 -0000 On 9/17/12 3:10 AM, "Byron Ellacott" wrote: >Hi Francisco, > >On 17/09/2012, at 3:49 PM, Francisco Obispo wrote: > >> Most JSON parsers that I've used load the whole document in memory, so >>you would have to have a lot of memory available to process a COM >>response. :-S > >I would hope that looking up the entire list of registrations underneath >.COM. is NOT a necessary step in looking up the registration data for >EXAMPLE.COM. :-) Well, there are stream parsers available for JSON. The idea that you can only do this with XML is bunk. And there is so much more wrong with that pattern than the need for a stream/event parser. > >> There are several advantages of this: >>=20 >> 1) If someone stores the file, it can easily identify it; > >Still true; Indeed. This argument keeps getting made as if Section 9 of Using-HTTP didn't exist.=20 (http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-9 ). > >> 2) Objects have a "namespace" associated with it, which allows clients >>to quickly identify the type of object thus be able to process it >>accordingly (knowing exactly which fields to fetch and how to present >>them). > >Still true; the current unified response draft doesn't include the type >of the top level response object, which I think is a weakness we can >correct, but the type of subsequent objects can be easily inferred by its >position in the response document. I note your example assumes that >something contained in $response_json->{additional}->{contacts} is, in >fact, a contact, too. :-) Adding an "objectClass" member to the top level object is superfluous. Certainly if the top level object has the members "startAddress" and "endAddress", software confusing it for a name server object is poorly written. But I'm willing to add this if we can finally quit arguing this topic. > >> 3) If the "returnAll" flag is turned "on", (which should be definable >>by registry policy), the response will also contain an "additional" >>section with the additional "objects" identifying the query. > >Expand or do not expand the sub-objects; interesting potential discussion >over a "returnAll" flag to have, I don't feel strongly either way, though >it would be perhaps polite to make the reference a URI instead of an >opaque string, if you're not going to include the actual data. It is unnecessary complexity. We do this in the ARIN RESTful Whois service and people get confused by it and generally hate it. Once they figure it out, the set returnAll to true for everything. > >> 5) There is coherence with EPP with the ability to support registry >>objects in general, so a group of people could work on the various >>objects for their own types of registries: names, and numbers working >>independently but agreeing on common object types: contacts, hosts > >Still true; Agreed, and to expand further on this point: The EPP model is actually different than the one being described here. In the EPP model, every difference of a contact, name server, domain, etc=8A is a new object class (that is if LunarNIC wants to add custom data to the contact class, they override completely the standard contact class). In the EPP world, making sure the client and server have a perfect understanding is essential because money is changing hands, it is a read/write protocol, there is a contractual relationship between the actors, and set of actors is limited to a smaller community. None of that is true for WEIRDS. Requiring a generic WEIRDS client to know a specialized object class for any registry that simply wants to add one bit of custom data is to high a bar for the purposes we need. >I will freely admit that I prefer nested for no particular technical >reason. It "feels" like a flat model exposes an implementation specific >abstraction of data, while a nested model "feels" like it talks about the >registration information as a cohesive whole as seen from that >perspective, but these are clearly not technical justifications, they are >aesthetic. > >Are there technical justifications either way that I'm missing? Actually, yes there is a very good technical reason. Not all registries wish to model all data as first class objects. This is the cause of the issue of name servers being attributes on domains vs being first class objects. See section 4 of Unified Response (http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-9 ). I also see that we will have this issue with entities. -andy From fobispo@isc.org Mon Sep 17 08:52:21 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073EB21F8703 for ; Mon, 17 Sep 2012 08:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VfsCFm-rBNd for ; Mon, 17 Sep 2012 08:52:20 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id C0E8421F8702 for ; Mon, 17 Sep 2012 08:52:19 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 407725F995C; Mon, 17 Sep 2012 15:52:09 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:470:1f05:1326:8d6:bf7c:83b2:524e] (unknown [IPv6:2001:470:1f05:1326:8d6:bf7c:83b2:524e]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 46516216C47; Mon, 17 Sep 2012 15:52:08 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: Date: Mon, 17 Sep 2012 08:52:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3CE05095-269F-48B9-A309-2F1006A1DDE8@isc.org> References: <80B2A58AFE381140A62C0512215B4F682AFE1D@DEN-EXDDA-S12.corp.ebay.com> <8CEF048B9EC83748B1517DC64EA130FB72D1CFCB53@off-win2003-01.ausregistrygroup.local> <8A4AAE91-9222-4694-B519-38CBFC7E1B46@isc.org> To: Byron Ellacott X-Mailer: Apple Mail (2.1486) Cc: weirds@ietf.org Subject: Re: [weirds] Response container structure X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 15:52:21 -0000 Byron: Thanks for taking the time to go over my concerns, Here are some comments: On Sep 17, 2012, at 12:10 AM, Byron Ellacott wrote: > Hi Francisco, >=20 > On 17/09/2012, at 3:49 PM, Francisco Obispo wrote: >=20 >> Most JSON parsers that I've used load the whole document in memory, = so you would have to have a lot of memory available to process a COM = response. :-S >=20 > I would hope that looking up the entire list of registrations = underneath .COM. is NOT a necessary step in looking up the registration = data for EXAMPLE.COM. :-) >=20 Yes that was what I meant, not the EXAMPLE.COM data ;-) >> For a domain query with the "returnAll" flag (or whatever we want to = call it): >>=20 >> { >> "version":"1.0", > [full example cut for brevity] >> } >>=20 >> This is my idea on how we should be representing the responses.. = Notice the enclosure format, there is a version, a response section, an = additional section, a response date, and a URI that was used to retrieve = the query. >=20 > How is this objectively superior to: >=20 Well what worries me is being too repetitive, I'm afraid that if an = object is referenced in more than one location, that we would be adding = more data than it is actually needed. >=20 >> There are several advantages of this: >>=20 >> 1) If someone stores the file, it can easily identify it; >=20 > Still true; >=20 >> 2) Objects have a "namespace" associated with it, which allows = clients to quickly identify the type of object thus be able to process = it accordingly (knowing exactly which fields to fetch and how to present = them). >=20 > Still true; the current unified response draft doesn't include the = type of the top level response object, which I think is a weakness we = can correct, but the type of subsequent objects can be easily inferred = by its position in the response document. I note your example assumes = that something contained in $response_json->{additional}->{contacts} is, = in fact, a contact, too. :-) >=20 Well we can either assume it, or provide a full URI as you described it, = I'm happy with any of the two, but I believe that the URI might not be = needed because objects tend to live only in one registry, so it would be = redundant to say "https://weirds.nic.TLD/contact/sh8013" than just = "sh8013" since to fetch the data the client would have to go to the same = URI anyway. >> 3) If the "returnAll" flag is turned "on", (which should be definable = by registry policy), the response will also contain an "additional" = section with the additional "objects" identifying the query. >=20 > Expand or do not expand the sub-objects; interesting potential = discussion over a "returnAll" flag to have, I don't feel strongly either = way, though it would be perhaps polite to make the reference a URI = instead of an opaque string, if you're not going to include the actual = data. >=20 I think this is useful, we could set a reasonable default, and let = registries define it via policy. >> 4) If I am a system performing thousands of queries, I could cache = the individual object responses (with a lifetime), and prevent = additional queries to the servers. (whois to RDAP) >=20 > Since your front-end is building the final answer each time, it makes = no (apparent) difference whether the individual object responses are = structurally placed at point A or point B in the output. That is if things are delimited as objects, if that's the case I'm ok = with it, but we need some 'namespace' or 'type' attribute to = differentiate. >=20 >> 6) An additional "extension" section could be implemented either at = the object level or at the response level to provide additional = information not supported natively by the protocol, (AGP, TMCH, DNSSEC, = IDN, etc.) >=20 > Still true; you just put the additional information right where you'd = otherwise have needed to put a dangling link to the additional = information anyway. (And, just for the record, I would be disappointed = with the WG outcome if DNSSEC and IDN data were not supported natively = in the drafts we produce in this first chartered set of milestones. :-) I agree as well, but the way we support them can't be by just adding the = attributes to existing object, I would like to see a mechanism to do so, = preventing the original objects from being polluted with attributes that = are not directly related to them, thus we need a framework to extend = them. >=20 >> To demonstrate how easy it would be to process this.. If I was a mail = administrator trying to contact the technical contact to report a = problem, all I needed to do was: >=20 > Agreed, your example is neither harder nor easier to process than my = example. If you're using a SAX parser for an XML document, you'd enter = an element with a particular namespace and shoot off to the right = handler for that element and its children, regardless of where it = appeared in the document. >=20 > I think you've answered my original question, which was whether URI = templates are a critical part of your preferred representation - I don't = think they are, so we are having a discussion around the structure of = the container. Good to know, so we should keep moving forward with the minor changes. >=20 > I will freely admit that I prefer nested for no particular technical = reason. It "feels" like a flat model exposes an implementation specific = abstraction of data, while a nested model "feels" like it talks about = the registration information as a cohesive whole as seen from that = perspective, but these are clearly not technical justifications, they = are aesthetic. > Are there technical justifications either way that I'm missing? I'm a bit paranoid by not being too redundant, and keeping the payload = small as well, so, I do think there is an advantage of only providing = references (whatever those may be) in the response, and then figuring = out how to list those unique elements (with content or not) in another = section of the response. Thanks again Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From fobispo@isc.org Mon Sep 17 09:04:31 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0E521F84FD for ; Mon, 17 Sep 2012 09:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i6rJBhysH6m for ; Mon, 17 Sep 2012 09:04:30 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3521F84F8 for ; Mon, 17 Sep 2012 09:04:30 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 32B3AC953E; Mon, 17 Sep 2012 16:04:20 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:470:1f05:1326:8d6:bf7c:83b2:524e] (unknown [IPv6:2001:470:1f05:1326:8d6:bf7c:83b2:524e]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D356A216C3D; Mon, 17 Sep 2012 16:04:19 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: Date: Mon, 17 Sep 2012 09:04:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Newton X-Mailer: Apple Mail (2.1486) Cc: "weirds@ietf.org" Subject: Re: [weirds] Response container structure X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 16:04:31 -0000 Hi Andy, Thanks for taking the time to go over my concerns again, here are more comments: On Sep 17, 2012, at 7:30 AM, Andy Newton wrote: >=20 >=20 > On 9/17/12 3:10 AM, "Byron Ellacott" wrote: >=20 >> Hi Francisco, >>=20 >> On 17/09/2012, at 3:49 PM, Francisco Obispo wrote: >>=20 >>> Most JSON parsers that I've used load the whole document in memory, = so >>> you would have to have a lot of memory available to process a COM >>> response. :-S >>=20 >> I would hope that looking up the entire list of registrations = underneath >> .COM. is NOT a necessary step in looking up the registration data for >> EXAMPLE.COM. :-) >=20 >=20 > Well, there are stream parsers available for JSON. The idea that you = can > only do this with XML is bunk. And there is so much more wrong with = that > pattern than the need for a stream/event parser. I have not use such parsers in JSON, I don't doubt they exist, but the = ones that I've used and are common to both Perl, Python and C++ are not = event-based. >=20 >>=20 >>> There are several advantages of this: >>>=20 >>> 1) If someone stores the file, it can easily identify it; >>=20 >> Still true; >=20 >=20 > Indeed. This argument keeps getting made as if Section 9 of Using-HTTP > didn't exist.=20 > = (http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-= 9 > ). yes I've seen that, and perhaps it's the fact that the elements are = intermixed with the object attributes what generates me the additional = noise. >=20 >>=20 >>> 2) Objects have a "namespace" associated with it, which allows = clients >>> to quickly identify the type of object thus be able to process it >>> accordingly (knowing exactly which fields to fetch and how to = present >>> them). >>=20 >> Still true; the current unified response draft doesn't include the = type >> of the top level response object, which I think is a weakness we can >> correct, but the type of subsequent objects can be easily inferred by = its >> position in the response document. I note your example assumes that >> something contained in $response_json->{additional}->{contacts} is, = in >> fact, a contact, too. :-) >=20 >=20 > Adding an "objectClass" member to the top level object is superfluous. > Certainly if the top level object has the members "startAddress" and > "endAddress", software confusing it for a name server object is poorly > written. But I'm willing to add this if we can finally quit arguing = this > topic. >=20 In sync with my previous comment, so please do!. >>=20 >>> 3) If the "returnAll" flag is turned "on", (which should be = definable >>> by registry policy), the response will also contain an "additional" >>> section with the additional "objects" identifying the query. >>=20 >> Expand or do not expand the sub-objects; interesting potential = discussion >> over a "returnAll" flag to have, I don't feel strongly either way, = though >> it would be perhaps polite to make the reference a URI instead of an >> opaque string, if you're not going to include the actual data. >=20 > It is unnecessary complexity. We do this in the ARIN RESTful Whois = service > and people get confused by it and generally hate it. Once they figure = it > out, the set returnAll to true for everything. I wouldn't call it complexity, it's a feature, users don't have to know = about it unless a registry supports it, you can provide some reasonable = default for your setup, but let others decide on their experience. >=20 >>=20 >>> 5) There is coherence with EPP with the ability to support registry >>> objects in general, so a group of people could work on the various >>> objects for their own types of registries: names, and numbers = working >>> independently but agreeing on common object types: contacts, hosts >>=20 >> Still true; >=20 >=20 > Agreed, and to expand further on this point: The EPP model is actually > different than the one being described here. In the EPP model, every > difference of a contact, name server, domain, etc=8A is a new object = class > (that is if LunarNIC wants to add custom data to the contact class, = they > override completely the standard contact class). In the EPP world, = making > sure the client and server have a perfect understanding is essential > because money is changing hands, it is a read/write protocol, there is = a > contractual relationship between the actors, and set of actors is = limited > to a smaller community. None of that is true for WEIRDS. Requiring a > generic WEIRDS client to know a specialized object class for any = registry > that simply wants to add one bit of custom data is to high a bar for = the > purposes we need. Yes and no, EPP is not _always_ about exchanging money, secondly, EPP is considered = a standard for Registry-Registrar interaction, so having a protocol to = represent registry data should at least make sure that it is capable of covering = the object types and extensions used by registries with EPP. I'm not saying that the same information will be made available, that's = registry policy, but at the minimum they should be bundled. Imaging building a car that can go 100 mph, but only using tires that = cannot=20 go over 40 mph.. We will start hitting serious limitations as more registries try to = adopt it, and will fall back to P43 whois where they can publish exactly what they = need in free form format. >=20 >=20 >> I will freely admit that I prefer nested for no particular technical >> reason. It "feels" like a flat model exposes an implementation = specific >> abstraction of data, while a nested model "feels" like it talks about = the >> registration information as a cohesive whole as seen from that >> perspective, but these are clearly not technical justifications, they = are >> aesthetic. >>=20 >> Are there technical justifications either way that I'm missing? >=20 >=20 > Actually, yes there is a very good technical reason. Not all = registries > wish to model all data as first class objects. This is the cause of = the > issue of name servers being attributes on domains vs being first class > objects. See section 4 of Unified Response > = (http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-= 9 > ). I also see that we will have this issue with entities. >=20 Registry policy should be outside of this specification, the policy = cannot be whether they want to support an object or not, the policy is whether = they make the information public or not, and if they do, then the way of = making it public is by representing them in objects just like everyone else. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From andy@arin.net Mon Sep 17 11:09:09 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58D921F86DF for ; Mon, 17 Sep 2012 11:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHUEuhRCePyk for ; Mon, 17 Sep 2012 11:09:09 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 128FC21F86A7 for ; Mon, 17 Sep 2012 11:09:09 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 43E5116518C; Mon, 17 Sep 2012 14:09:03 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 7868716517B; Mon, 17 Sep 2012 14:09:02 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 17 Sep 2012 14:08:56 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 14:09:02 -0400 From: Andy Newton To: Francisco Obispo Thread-Topic: [weirds] Response container structure Thread-Index: AQHNlKOEMgx/JUEDdU6jax6CGftCgZeOmLwAgABdOQD//9/KAA== Date: Mon, 17 Sep 2012 18:09:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Response container structure X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 18:09:10 -0000 On 9/17/12 12:04 PM, "Francisco Obispo" wrote: >>>>There are several advantages of this: >>>>=20 >>>> 1) If someone stores the file, it can easily identify it; >>>=20 >>> Still true; >>=20 >>=20 >> Indeed. This argument keeps getting made as if Section 9 of Using-HTTP >> didn't exist.=20 >>=20 >>(http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section >>-9 >> ). > >yes I've seen that, and perhaps it's the fact that the elements are >intermixed with the object attributes what generates me the additional >noise. I'd be happy to clarify the section and add clarifying text if you can tell us what you suggest isn't clear. >EPP is not _always_ about exchanging money, secondly, EPP is considered a >standard for Registry-Registrar interaction, so having a protocol to >represent >registry data should at least make sure that it is capable of covering the >object types and extensions used by registries with EPP. Please provide your gap analysis if you have it. >We will start hitting serious limitations as more registries try to adopt >it, >and will fall back to P43 whois where they can publish exactly what they >need >in free form format. Again, if you can provide your actual analysis that would be helpful. Real examples beat theoretical discussions. > >>=20 >>=20 >>> I will freely admit that I prefer nested for no particular technical >>> reason. It "feels" like a flat model exposes an implementation >>>specific >>> abstraction of data, while a nested model "feels" like it talks about >>>the >>> registration information as a cohesive whole as seen from that >>> perspective, but these are clearly not technical justifications, they >>>are >>> aesthetic. >>>=20 >>> Are there technical justifications either way that I'm missing? >>=20 >>=20 >> Actually, yes there is a very good technical reason. Not all registries >> wish to model all data as first class objects. This is the cause of the >> issue of name servers being attributes on domains vs being first class >> objects. See section 4 of Unified Response >>=20 >>(http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section >>-9 >> ). I also see that we will have this issue with entities. >>=20 > >Registry policy should be outside of this specification, the policy cannot >be whether they want to support an object or not, the policy is whether >they >make the information public or not, and if they do, then the way of making >it public is by representing them in objects just like everyone else. Did you read the reference above? It's not about policy. It's about object representation. -andy From Ed.Lewis@neustar.biz Mon Sep 17 11:31:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC8221E803C for ; Mon, 17 Sep 2012 11:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.743 X-Spam-Level: X-Spam-Status: No, score=-102.743 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN9+WkNJxlXG for ; Mon, 17 Sep 2012 11:31:07 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by ietfa.amsl.com (Postfix) with ESMTP id 961FF21E8037 for ; Mon, 17 Sep 2012 11:31:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp31.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 1CA9350194; Mon, 17 Sep 2012 14:31:07 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp31.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id B121D5016F; Mon, 17 Sep 2012 14:31:06 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 17 Sep 2012 14:31:03 -0400 To: "weirds@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [weirds] Comparisons to EPP was Re: Response container structure X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 18:31:08 -0000 At 9:04 -0700 9/17/12, Francisco Obispo wrote: >EPP is not _always_ about exchanging money, secondly, EPP is considered a >standard for Registry-Registrar interaction, so having a protocol to represent >registry data should at least make sure that it is capable of covering the >object types and extensions used by registries with EPP. This is an off-shoot thread, with a different subject. It's tempting to drag up EPP into the WEIRDS WG discussions, I've done it. But EPP is solving a much different problem and is in use by a different set of clients. Outside of the two protocols dealing with registries and the low-level format (addresses and dates), there isn't much more in common between them. One of my working assumptions, because I haven't seen a WG requirements document (still weaving my way through what's out there) is that the protocol to be developed by the WEIRDS WG is to allow inspection of a registry's object->entity relationships. This isn't the same as having access to the registry's database, meaning not all data is necessarily accessible. I.e., I don't expect that all EPP carried information is to be exposed in the WEIRDS WG protocol. I don't expect to see the protocol be "capable of covering the object types and extensions" used in EPP exchanges. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From chris@ausregistry.com.au Mon Sep 17 16:41:23 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C430421E809C for ; Mon, 17 Sep 2012 16:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cusKePz4mfZk for ; Mon, 17 Sep 2012 16:41:23 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8775021E808C for ; Mon, 17 Sep 2012 16:41:20 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 18 Sep 2012 09:41:18 +1000 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Tue, 18 Sep 2012 09:40:51 +1000 From: Chris Wright To: "" Date: Tue, 18 Sep 2012 09:41:16 +1000 Thread-Topic: Text media type Thread-Index: Ac2VLYlTPixYftLBQvOex54pZGOZwg== Message-ID: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_8CEF048B9EC83748B1517DC64EA130FB72DB514C98offwin200301a_" MIME-Version: 1.0 Subject: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 23:41:23 -0000 --_000_8CEF048B9EC83748B1517DC64EA130FB72DB514C98offwin200301a_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V291bGQgcGVvcGxlIGJlIGFnYWluc3QgaW5jbHVkaW5nIGEgcGxhaW4gdGV4dCBtZWRpYSB0eXBl IGluIFdFSVJEUz8NCg0KSSB3b3VsZCBsaWtlIHRvIGRvIHRoaXMsIHNvIHRoYXQgaWYgYSBjbGll bnQgd2FudHMgdGhleSBjYW4gc3BlY2lmeSBhIHBsYWluIHRleHQgbWVkaWEgdHlwZSBhbmQgSSBj b3VsZCBzZW5kIHRoZW0gYSBVVEY4IGVuY29kZWQgdGV4dCBzdHJlYW0gdGhhdCBpcyBlc3NlbnRp YWxseSBteSBjdXJyZW50IFdob0lzIHJlc3BvbnNlIChzbyB0aGUgZmllbGRzIGFyZSBwcmVmaXhl ZCB3aXRoIGEgZGVzY3JpcHRpdmUgbGFiZWwpLg0KDQpUaGlzIHdvdWxkIG1ha2UgdHJhbnNpdGlv biBlYXNpZXIsIGFuZCBhIHJlYWxseSBzaW1wbGUgV0VSSURTIGNsaWVudCAoZWcgYSBjb21tYW5k IGxpbmUgd2dldCBvciBjdXJsKSBjb3VsZCBqdXN0IGdldCB0aGUgcGxhaW4gdGV4dCB2ZXJzaW9u IGFuZCBzZW5kIGl0IHRvIGNvbnNvbGUuDQoNCk9mIGNvdXJzZSB0aGUgV0VSSURTIHNlcnZlciB3 b3VsZCBhbHNvIGhhdmUgdG8gc3VwcG9ydCB0aGUgSlNPTiBtZWRpYSB0eXBlIGFzIHdlbGwgdG8g YWxsb3cgdGhlIOKAmG1hY2hpbmUgdG8gbWFjaGluZeKAmSBzdHlsZSBpbnRlcmFjdGlvbiB3ZSBh cmUgaW50ZW5kaW5nLg0KDQpBbnkgb25lIHNlZSBhbnkgaXNzdWVzIHdpdGggdGhpcz8NCg0KVGhh bmtzDQoNCmMuDQoNCg== --_000_8CEF048B9EC83748B1517DC64EA130FB72DB514C98offwin200301a_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+V291bGQgcGVvcGxl IGJlIGFnYWluc3QgaW5jbHVkaW5nIGEgcGxhaW4gdGV4dCBtZWRpYSB0eXBlIGluIFdFSVJEUz88 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPkkgd291bGQgbGlrZSB0byBkbyB0aGlzLCBzbyB0aGF0IGlmIGEgY2xp ZW50IHdhbnRzIHRoZXkgY2FuIHNwZWNpZnkgYSBwbGFpbiB0ZXh0IG1lZGlhIHR5cGUgYW5kIEkg Y291bGQgc2VuZCB0aGVtIGEgVVRGOCBlbmNvZGVkIHRleHQgc3RyZWFtIHRoYXQgaXMgZXNzZW50 aWFsbHkgbXkgY3VycmVudCBXaG9JcyByZXNwb25zZSAoc28gdGhlIGZpZWxkcyBhcmUgcHJlZml4 ZWQgd2l0aCBhIGRlc2NyaXB0aXZlIGxhYmVsKS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlRoaXMgd291bGQg bWFrZSB0cmFuc2l0aW9uIGVhc2llciwgYW5kIGEgcmVhbGx5IHNpbXBsZSBXRVJJRFMgY2xpZW50 IChlZyBhIGNvbW1hbmQgbGluZSB3Z2V0IG9yIGN1cmwpIGNvdWxkIGp1c3QgZ2V0IHRoZSBwbGFp biB0ZXh0IHZlcnNpb24gYW5kIHNlbmQgaXQgdG8gY29uc29sZS48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPk9m IGNvdXJzZSB0aGUgV0VSSURTIHNlcnZlciB3b3VsZCBhbHNvIGhhdmUgdG8gc3VwcG9ydCB0aGUg SlNPTiBtZWRpYSB0eXBlIGFzIHdlbGwgdG8gYWxsb3cgdGhlIOKAmG1hY2hpbmUgdG8gbWFjaGlu ZeKAmSBzdHlsZSBpbnRlcmFjdGlvbiB3ZSBhcmUgaW50ZW5kaW5nLjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ QW55IG9uZSBzZWUgYW55IGlzc3VlcyB3aXRoIHRoaXM/PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tQVUnPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLUFVJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1BVSc+Yy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvYm9k eT48L2h0bWw+ --_000_8CEF048B9EC83748B1517DC64EA130FB72DB514C98offwin200301a_-- From fobispo@isc.org Mon Sep 17 16:52:57 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC51B21E809E for ; Mon, 17 Sep 2012 16:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tELU0AjS6yj1 for ; Mon, 17 Sep 2012 16:52:56 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 54A1821E804A for ; Mon, 17 Sep 2012 16:52:56 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id CB142C9595; Mon, 17 Sep 2012 23:52:47 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:e0c4:3569:103f:aecb] (unknown [IPv6:2001:4f8:3:64:e0c4:3569:103f:aecb]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B316D216C40; Mon, 17 Sep 2012 23:52:47 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> Date: Mon, 17 Sep 2012 16:52:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5743F8D2-FB2A-468F-8C5E-AF3C0D5C5F3E@isc.org> References: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> To: Chris Wright X-Mailer: Apple Mail (2.1486) Cc: "" Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 23:52:57 -0000 I guess the plan is to have a p43 whois to RDAP proxy for those cases = where legacy support is needed. On Sep 17, 2012, at 4:41 PM, Chris Wright = wrote: > Would people be against including a plain text media type in WEIRDS? > =20 > I would like to do this, so that if a client wants they can specify a = plain text media type and I could send them a UTF8 encoded text stream = that is essentially my current WhoIs response (so the fields are = prefixed with a descriptive label). > =20 > This would make transition easier, and a really simple WERIDS client = (eg a command line wget or curl) could just get the plain text version = and send it to console. > =20 > Of course the WERIDS server would also have to support the JSON media = type as well to allow the =91machine to machine=92 style interaction we = are intending. > =20 > Any one see any issues with this? > =20 > Thanks > =20 > c. > =20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From carlosm3011@gmail.com Mon Sep 17 16:55:03 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17B721E809E for ; Mon, 17 Sep 2012 16:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXVrlbUOvY8H for ; Mon, 17 Sep 2012 16:55:02 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB47121E804A for ; Mon, 17 Sep 2012 16:55:02 -0700 (PDT) Received: by yhq56 with SMTP id 56so475336yhq.31 for ; Mon, 17 Sep 2012 16:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=yX+RA4GToEKgA9yVR3sOkJVDJB9tzMvsizvDXcJnsqM=; b=HAouYPua4QjjBfCrD78nlx25ySrcJ+i/PRZCn51+HWkTLmOPmC4Llez5qYcvHEDZu/ CvcW4T3GrMEncNr2IK7am1BeJ/1R5hJy1dPXUOYi22iSm0StJu7GrfwaAeaztZJ7rY7Z PJZZMVbZED+Lym0SlvV7I6bN39Pi+IBL/yEhpSB6QBsHJGhjSiK6ot3wBKMVJ9cNaQJn 0oNfyPGHOy3u8pVkRra6z+xdUYVv8xdnW86KdJ0CuRlTl6r3NTAN3+ugLfHnXZcCF+eW n18sabE8NXvf2kPLBUYrH2F1jH0rUzQxUgraPKKtz+LG7vEXwkRunn1V3YB1WopEEjb2 hrHg== Received: by 10.236.180.42 with SMTP id i30mr13367302yhm.89.1347926102267; Mon, 17 Sep 2012 16:55:02 -0700 (PDT) Received: from [192.168.1.239] (r186-53-94-149.dialup.adsl.anteldata.net.uy. [186.53.94.149]) by mx.google.com with ESMTPS id o11sm10824216anp.4.2012.09.17.16.54.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 16:55:01 -0700 (PDT) References: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1CE259E6-C511-484C-8872-B6A24E2EA890 Message-Id: <7AFE9480-E28F-4D3A-81EF-BCDB1C625170@gmail.com> X-Mailer: iPhone Mail (9B206) From: Carlos Martinez Date: Mon, 17 Sep 2012 20:56:27 -0300 To: Chris Wright Cc: "" Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 23:55:03 -0000 --Apple-Mail-1CE259E6-C511-484C-8872-B6A24E2EA890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We are for it. In fact we were planing to add it to our prototype.=20 Regards Carlos Sent from a mobile device On Sep 17, 2012, at 8:41 PM, Chris Wright wrote: > Would people be against including a plain text media type in WEIRDS? > =20 > I would like to do this, so that if a client wants they can specify a plai= n text media type and I could send them a UTF8 encoded text stream that is e= ssentially my current WhoIs response (so the fields are prefixed with a desc= riptive label). > =20 > This would make transition easier, and a really simple WERIDS client (eg a= command line wget or curl) could just get the plain text version and send i= t to console. > =20 > Of course the WERIDS server would also have to support the JSON media type= as well to allow the =E2=80=98machine to machine=E2=80=99 style interaction= we are intending. > =20 > Any one see any issues with this? > =20 > Thanks > =20 > c. > =20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail-1CE259E6-C511-484C-8872-B6A24E2EA890 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
We are for it. In fact we w= ere planing to add it to our prototype. 

Regar= ds

Carlos

Sent from a mobile device

On Sep 17, 2012, at 8:41 PM, Chris Wright <chris@ausregistry.com.au> wrote:

Would people be against including a plain text media type in WEIRDS= ?

 

I would like to do this, so that if a client wants they can specify a= plain text media type and I could send them a UTF8 encoded text stream that= is essentially my current WhoIs response (so the fields are prefixed with a= descriptive label).

 <= /p>

This would make transition easier, and a really si= mple WERIDS client (eg a command line wget or curl) could just get the plain= text version and send it to console.

<= o:p> 

Of course the WERIDS server would= also have to support the JSON media type as well to allow the =E2=80=98mach= ine to machine=E2=80=99 style interaction we are intending.

 

Any one see= any issues with this?

 

Thank= s

 

c.

=  

_______________________________________________
weird= s mailing list
weirds@iet= f.org
https://www.ietf.org/mailman/listinfo/weirds
= --Apple-Mail-1CE259E6-C511-484C-8872-B6A24E2EA890-- From andy@arin.net Mon Sep 17 17:09:39 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1021021F8616 for ; Mon, 17 Sep 2012 17:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qu+X+9dHCG+9 for ; Mon, 17 Sep 2012 17:09:38 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 6838121F8628 for ; Mon, 17 Sep 2012 17:09:38 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id B863A213664; Mon, 17 Sep 2012 20:09:37 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 56630213600; Mon, 17 Sep 2012 20:09:37 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 17 Sep 2012 20:09:24 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 20:09:30 -0400 From: Andy Newton To: Chris Wright , "" Thread-Topic: [weirds] Text media type Thread-Index: Ac2VLYlTPixYftLBQvOex54pZGOZwgABFWeA Date: Tue, 18 Sep 2012 00:09:30 +0000 Message-ID: In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 00:09:39 -0000 > >Would people be against including a plain text media type in WEIRDS? >=20 >I would like to do this, so that if a client wants they can specify a >plain text media type and I could send them a UTF8 encoded text stream >that is essentially my current WhoIs response (so the fields are prefixed >with a descriptive label). >=20 >This would make transition easier, and a really simple WERIDS client (eg >a command line wget or curl) could just get the plain text version and >send it to console. >=20 >Of course the WERIDS server would also have to support the JSON media >type as well to allow the =8Cmachine to machine=B9 style interaction we ar= e >intending. >=20 >Any one see any issues with this? >=20 >Thanks >=20 >c. We support plain text and xhtml depending on the Accept header, and plan to do so going forward. Perhaps this type of behavior ought to be explicitly called out in the Using HTTP draft even if there will be no specification for those formats. -andy From bje@apnic.net Mon Sep 17 19:08:49 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DDF21F84EC for ; Mon, 17 Sep 2012 19:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhi2FjLvqKAe for ; Mon, 17 Sep 2012 19:08:48 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 205BC21F84EA for ; Mon, 17 Sep 2012 19:08:46 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:4d5d:3a70:7cf9:28da] (unknown [IPv6:2001:dc0:a000:4:4d5d:3a70:7cf9:28da]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 7073EB684F; Tue, 18 Sep 2012 12:08:45 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_8480C3F0-46E8-4A3B-B5A6-315746A7DD45"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Tue, 18 Sep 2012 12:08:44 +1000 Message-Id: <1A26DD8D-DAB9-42C7-A42A-960FD528D11B@apnic.net> References: To: Andy Newton , Francisco Obispo X-Mailer: Apple Mail (2.1278) Cc: weirds@ietf.org Subject: Re: [weirds] Response container structure X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 02:08:49 -0000 --Apple-Mail=_8480C3F0-46E8-4A3B-B5A6-315746A7DD45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Andy, On 18/09/2012, at 12:30 AM, Andy Newton wrote: >>> 3) If the "returnAll" flag is turned "on", (which should be = definable >>> by registry policy), the response will also contain an "additional" >>> section with the additional "objects" identifying the query. >>=20 >> Expand or do not expand the sub-objects; interesting potential = discussion >> over a "returnAll" flag to have, I don't feel strongly either way, = though >> it would be perhaps polite to make the reference a URI instead of an >> opaque string, if you're not going to include the actual data. >=20 > It is unnecessary complexity. We do this in the ARIN RESTful Whois = service > and people get confused by it and generally hate it. Once they figure = it > out, the set returnAll to true for everything. If someone is willing to demonstrate that their weirds server would = require such a flag to meet actual or reasonably likely policy = conditions, I'd be OK with including it. Otherwise, it's just one more = thing client software will need to consider, and the protocol will need = to include. I have no such need of a flag, as a server I'd rather have fewer code = paths and fewer clients coming back for additional data and just shove = everything I know out the door in one go, and as a client I'd rather = have fewer code paths and fewer round trips and just get everything I = can learn in one go. > Actually, yes there is a very good technical reason. Not all = registries > wish to model all data as first class objects. This is the cause of = the > issue of name servers being attributes on domains vs being first class > objects. See section 4 of Unified Response > = (http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-= 9 > ). I also see that we will have this issue with entities. = (http://tools.ietf.org/html/draft-newton-weirds-unified-json-response-00#s= ection-4) I was thinking that you could just take the data you'd put inline in = that section and move it down to an additional, but you're right in that = where there's no handle or other identifier you'd be making up a UUID or = something just to link the two items together, and it might be quite = misleading to clients to have a handle that cannot be queried for = separately. Regarding duplicated data objects, the unified response draft only has = one entity object per entity handle. There's no difference, that I can = see. It might be fractionally harder to find the particular type of = entity you want, but one of the things we quickly see with the domain = survey data is that the types of entities recorded is one of the most = widely variant facets of registration data - I don't know that it's = feasible to specify an enumeration of entity roles, and it might be hard = to even specify a minimum set. Byron --Apple-Mail=_8480C3F0-46E8-4A3B-B5A6-315746A7DD45 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MTgwMjA4NDVaMCMGCSqGSIb3DQEJBDEWBBTw EUprivNtLB3Uk2cMnvNW22NnCzCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQB6EFiCmJhmlReZ u2AVMcDPN9Oa/g+K2ZdnSIhXZBAYjkln83tROVFH+8cjfQeerD5A96XVDJhHPECSYfPdNzneVexO YfTEUPDkrUmCBumslfLGnB6MnHQBgCpCJc9cP1NWeFHlGVQXPM9HoEFYOlSr7aMFyIwZEM5KRgPp 5/lpDZ/WZ+SgrEWpnExJzcTCnde6LHCpyWJjR/dCmWMYvAUgxaHnyOmLg8ng22MH6pfkp5Y7kPMn jKF9/cEqjdlFfN+41Sf2EsbCw12Yggz1TuiQsN28SUXy1op9Jj1q97sZ9eJ131Wiu/PL1kT1FQe2 buk0c43cFr1NNm2SPHxSyDHjAAAAAAAA --Apple-Mail=_8480C3F0-46E8-4A3B-B5A6-315746A7DD45-- From andy@arin.net Mon Sep 17 19:37:36 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC3621F8435 for ; Mon, 17 Sep 2012 19:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXq73+1Ge6hy for ; Mon, 17 Sep 2012 19:37:35 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 49CFB21F8419 for ; Mon, 17 Sep 2012 19:37:35 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id A49D616520D; Mon, 17 Sep 2012 22:37:34 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id D786B165201; Mon, 17 Sep 2012 22:37:33 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 17 Sep 2012 22:37:26 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 22:37:32 -0400 From: Andy Newton To: Byron Ellacott , Francisco Obispo Thread-Topic: [weirds] Response container structure Thread-Index: AQHNlKOEMgx/JUEDdU6jax6CGftCgZeOmLwAgAEGGgD//8T7AA== Date: Tue, 18 Sep 2012 02:37:31 +0000 Message-ID: In-Reply-To: <1A26DD8D-DAB9-42C7-A42A-960FD528D11B@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="Windows-1252" Content-ID: <80E13F66ADE2E94A87890EC5DF17866D@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Response container structure X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 02:37:36 -0000 On 9/17/12 10:08 PM, "Byron Ellacott" wrote: >If someone is willing to demonstrate that their weirds server would >require such a flag to meet actual or reasonably likely policy >conditions, I'd be OK with including it. Otherwise, it's just one more >thing client software will need to consider, and the protocol will need >to include. That's an interesting take. I'll posit that even if such a flag were needed for some policy reason, another policy will pop up needing another flag, etc=8A But like you said, if somebody can demonstrate the need... >>Actually, yes there is a very good technical reason. Not all registries >> wish to model all data as first class objects. This is the cause of the >> issue of name servers being attributes on domains vs being first class >> objects. See section 4 of Unified Response >>=20 >>(http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section >>-9 >> ). I also see that we will have this issue with entities. > >(http://tools.ietf.org/html/draft-newton-weirds-unified-json-response-00#s >ection-4) DOH! >I was thinking that you could just take the data you'd put inline in that >section and move it down to an additional, but you're right in that where >there's no handle or other identifier you'd be making up a UUID or >something just to link the two items together, and it might be quite >misleading to clients to have a handle that cannot be queried for >separately. Exactly! >Regarding duplicated data objects, the unified response draft only has >one entity object per entity handle. There's no difference, that I can >see. It might be fractionally harder to find the particular type of >entity you want, but one of the things we quickly see with the domain >survey data is that the types of entities recorded is one of the most >widely variant facets of registration data - I don't know that it's >feasible to specify an enumeration of entity roles, and it might be hard >to even specify a minimum set. Agreed. -andy From fobispo@isc.org Mon Sep 17 20:33:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3222321E80A0 for ; Mon, 17 Sep 2012 20:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bofJl+Mlxj9f for ; Mon, 17 Sep 2012 20:33:07 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 53A7E21F8442 for ; Mon, 17 Sep 2012 20:33:07 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 42F0F5F984C; Tue, 18 Sep 2012 03:32:54 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:470:1f05:1326:7588:5c36:89fb:d108] (unknown [IPv6:2001:470:1f05:1326:7588:5c36:89fb:d108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 896B7216C3B; Tue, 18 Sep 2012 03:32:52 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: Date: Mon, 17 Sep 2012 20:31:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44F35C0B-B121-4E7F-BDC7-AB69A34D6474@isc.org> References: To: Andy Newton X-Mailer: Apple Mail (2.1486) Cc: "weirds@ietf.org" Subject: Re: [weirds] Response container structure X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 03:33:08 -0000 On Sep 17, 2012, at 7:37 PM, Andy Newton wrote: > On 9/17/12 10:08 PM, "Byron Ellacott" wrote: >=20 >> If someone is willing to demonstrate that their weirds server would >> require such a flag to meet actual or reasonably likely policy >> conditions, I'd be OK with including it. Otherwise, it's just one = more >> thing client software will need to consider, and the protocol will = need >> to include. >=20 > That's an interesting take. I'll posit that even if such a flag were > needed for some policy reason, another policy will pop up needing = another > flag, etc=8A But like you said, if somebody can demonstrate the = need... I think Byron was very clear with his use case, which is exactly the = same that I have. If you provide an answer that does not have all the components, the = client might generate additional requests asking for the missing pieces. But I also don't want to make that behavior mandatory, in some other = occasions,=20 I want exactly the opposite, to prevent hitting the backend with = unnecessary requests if the client does not want them. >=20 >>> Actually, yes there is a very good technical reason. Not all = registries >>> wish to model all data as first class objects. This is the cause of = the >>> issue of name servers being attributes on domains vs being first = class >>> objects. See section 4 of Unified Response >>>=20 >>> = (http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section >>> -9 >>> ). I also see that we will have this issue with entities. >>=20 >> = (http://tools.ietf.org/html/draft-newton-weirds-unified-json-response-00#s= >> ection-4) >=20 >=20 > DOH! >=20 >> I was thinking that you could just take the data you'd put inline in = that >> section and move it down to an additional, but you're right in that = where >> there's no handle or other identifier you'd be making up a UUID or >> something just to link the two items together, and it might be quite >> misleading to clients to have a handle that cannot be queried for >> separately. >=20 >=20 > Exactly! >=20 Can't speak for number registries, but it is very common for name = registries to have unique identifiers for the internet objects they manage: = contacts (contact_id), hosts (host_name), and domains (domain_names). The ID doesn't need to be universal, it just needs to be unique to that = repository. In my opinion the handle should be used to retrieve the specific object = via another restful request, why not do it? or am I missing something >> Regarding duplicated data objects, the unified response draft only = has >> one entity object per entity handle. There's no difference, that I = can >> see. It might be fractionally harder to find the particular type of >> entity you want, but one of the things we quickly see with the domain >> survey data is that the types of entities recorded is one of the most >> widely variant facets of registration data - I don't know that it's >> feasible to specify an enumeration of entity roles, and it might be = hard >> to even specify a minimum set. >=20 We can start with the general set that EPP has, and the rest will need=20= to be done using an extension mechanism, which is nothing more than placing the additional information in 'extension' field that has a = namespace identifier associated to it. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From johnl@iecc.com Mon Sep 17 20:40:24 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B9521E80A6 for ; Mon, 17 Sep 2012 20:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMn7IMxPC9JO for ; Mon, 17 Sep 2012 20:40:23 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9B521E80A0 for ; Mon, 17 Sep 2012 20:40:22 -0700 (PDT) Received: (qmail 72865 invoked from network); 18 Sep 2012 03:40:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Sep 2012 03:40:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5057ed24.xn--9vv.k1208; i=johnl@user.iecc.com; bh=3brEE6eT400OI407wGxR1bh1WeL+UGndBCbTTnhadKQ=; b=PJHZm3CHjhwrY8TqiF0FBVjPzvToL8Z4MDrmphORZ3fC4N1fi0Cyxj2zmhGVGYh2SgjvQijIEOWaTmZCANEwiWCnQAWGw8REFuIk0faSDo/E3ghpKM8FtgupIDhh0hD62FQUMDvPx7+gm5JS7I9vaXCEZBazqDlEWpgejvXEhrk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5057ed24.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=3brEE6eT400OI407wGxR1bh1WeL+UGndBCbTTnhadKQ=; b=sqCmx0gBbTDhECfVIWvqU/PRv3xWsfoPPGWagooyaE7eeaG1Wdv+6zwT1Vxtne3ENH2MI3KNRZz7RQzM5dn9jYL0DQMGmUCkuUXyjVPJj8/WUyuA0Me0T4D6pKCttISFjMGcZx3PaRXvA/MEdTi1k3tvVYpOTPtD0mV5TTdHf00= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Sep 2012 03:39:58 -0000 Message-ID: <20120918033958.36596.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 03:40:24 -0000 >Would people be against including a plain text media type in WEIRDS? It's a perfectly reasonable thing to do, but I would have reservations about putting it into WEIRDS, because history tells us that once something is in the spec, it'll never, ever go away. Would you want it to say that the text/plain response is an entirely implementation dependent stream of UTF-8 text, or more than that? As soon as there is any sort of spec for what's in that stream, we've effectively doubled our work, since now we have to define the text version as well as the JSON version for everything. Remember that a standard describes what you have to do in order to interoperate. You're always allowed to have your software do things beyond what the standard says, so long as it doesn't interfere with the standard compliant operation. It'd be fine to leave text/plain out of the standard, but implement it anyway as a non-standard transition hack. R's, John From fobispo@isc.org Mon Sep 17 20:47:40 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E38A21F8432 for ; Mon, 17 Sep 2012 20:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTYqDOgD7Y1Z for ; Mon, 17 Sep 2012 20:47:39 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 877CE21F841E for ; Mon, 17 Sep 2012 20:47:39 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 3C083C9476; Tue, 18 Sep 2012 03:47:30 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.105] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 23416216C3D; Tue, 18 Sep 2012 03:47:30 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: <20120918033958.36596.qmail@joyce.lan> Date: Mon, 17 Sep 2012 20:47:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <74FD21A0-7D32-46CD-9B7F-1BD437904966@isc.org> References: <20120918033958.36596.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1486) Cc: weirds@ietf.org Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 03:47:40 -0000 John, I have to say that perhaps for the first time in the last week, I deeply = agree with you ;-) On Sep 17, 2012, at 8:39 PM, "John Levine" wrote: >> Would people be against including a plain text media type in WEIRDS? >=20 > It's a perfectly reasonable thing to do, but I would have reservations > about putting it into WEIRDS, because history tells us that once > something is in the spec, it'll never, ever go away. >=20 > Would you want it to say that the text/plain response is an entirely > implementation dependent stream of UTF-8 text, or more than that? As > soon as there is any sort of spec for what's in that stream, we've > effectively doubled our work, since now we have to define the text > version as well as the JSON version for everything. >=20 > Remember that a standard describes what you have to do in order to > interoperate. You're always allowed to have your software do things > beyond what the standard says, so long as it doesn't interfere with > the standard compliant operation. It'd be fine to leave text/plain > out of the standard, but implement it anyway as a non-standard > transition hack. >=20 > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From AMaitland@Commerco.Com Mon Sep 17 23:19:06 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E87121F842F for ; Mon, 17 Sep 2012 23:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVxqOr9U+Ekn for ; Mon, 17 Sep 2012 23:19:05 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9058A21F841E for ; Mon, 17 Sep 2012 23:19:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=QulqzrLDsgBNK8N7QdLUc7puiYkxa0aflAQIWLJ+gPRWJNMeu2ppysqS+s+Y4hpqJ0Up/s/2QldsQBG+tLHTJjqnBOjL6rZX04aDY5UuaekKv09tMNV53tNRzJS5YhqgI4kFlrBSaZZDvRSo9EyL8eh6ghOV1fQ9I4Uaw0ndCm4= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Tue, 18 Sep 2012 06:19:04 +0000 Message-ID: <50581252.2050005@Commerco.Com> Date: Tue, 18 Sep 2012 00:18:58 -0600 From: Alan Maitland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 06:19:06 -0000 On 9/17/2012 5:41 PM, Chris Wright wrote: > Would people be against including a plain text media type in WEIRDS? > This approach could be expressed as transitional gateway for operators and consumers of their data to ease over to WIERDS from WHOIS. > I would like to do this, so that if a client wants they can specify a > plain text media type and I could send them a UTF8 encoded text stream > that is essentially my current WhoIs response (so the fields are > prefixed with a descriptive label). While that seems to make sense, does it really encourage good behavior? In other words, will it make the task of transitioning or migrating to a full implementation of a more RESTful environment less desirable for consumers of data and the registries? > > This would make transition easier, and a really simple WERIDS client (eg > a command line wget or curl) could just get the plain text version and > send it to console. Agreed. Another question to ask... would such a solution be able to as easily implement the same kinds of security measures as has been proposed by some on this list? > > Of course the WERIDS server would also have to support the JSON media > type as well to allow the ‘machine to machine’ style interaction we are > intending. > > Any one see any issues with this? While there might be some questions to think about, offering a plain text media type seems a valid idea in approaching transitional migration from WHOIS to WIERDS. Perhaps the approach in describing this could be expressed in a "MAY choose to implement a plain text option to assist in transition or encourage early adoption" approach. > > Thanks > > c. > Best, Alan M. From dave.piscitello@icann.org Mon Sep 17 23:48:21 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD7011E8091 for ; Mon, 17 Sep 2012 23:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEKAUFJI41qc for ; Mon, 17 Sep 2012 23:48:20 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 76E9911E808E for ; Mon, 17 Sep 2012 23:48:20 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 17 Sep 2012 23:48:19 -0700 From: Dave Piscitello To: Alan Maitland Date: Mon, 17 Sep 2012 23:48:15 -0700 Thread-Topic: [weirds] Text media type Thread-Index: Ac2VaZaqAgm9FmoCQoSdgdFxxO8hyQ== Message-ID: <6E6B02A0-3901-4569-8507-1B43F2EF1FBC@icann.org> References: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> <50581252.2050005@Commerco.Com> In-Reply-To: <50581252.2050005@Commerco.Com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 06:48:21 -0000 U28geW91IGFyZSBzdWdnZXN0aW5nIGEgcGxhaW4gdGV4dCByZXNwb25zZSB0byBhIHN0cnVjdHVy ZWQgcXVlcnkgdGhhdCBwcmVzdW1hYmx5IHJldHVybnMgdGhlIGN1cnJlbnQgYmxvYiBvZiB3aGF0 ZXZlciBkYXRhIHRoZSBwcm92aWRlciBzZXJ2ZXMgdXAuIERvZXNuJ3QgdGhpcyBsZWF2ZSBhbGwg dGhlIGJ1cmRlbiBvbiB0aGUgY2xpZW50IGFuZCBjb25zdW1lciBvZiBkYXRhIChJLmUsIGFsbCB0 aGUgdmFyaWFiaWxpdHkgYWNyb3NzIHdob2lzIHJlc3BvbnNlcyBtdXN0IGJlIG5vcm1hbGl6ZWQg c3RpbGwpPw0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIFNlcCAxOCwgMjAxMiwgYXQgNzox OSBBTSwgIkFsYW4gTWFpdGxhbmQiIDxBTWFpdGxhbmRAQ29tbWVyY28uQ29tPiB3cm90ZToNCg0K PiBPbiA5LzE3LzIwMTIgNTo0MSBQTSwgQ2hyaXMgV3JpZ2h0IHdyb3RlOg0KPj4gV291bGQgcGVv cGxlIGJlIGFnYWluc3QgaW5jbHVkaW5nIGEgcGxhaW4gdGV4dCBtZWRpYSB0eXBlIGluIFdFSVJE Uz8NCj4+IA0KPiANCj4gVGhpcyBhcHByb2FjaCBjb3VsZCBiZSBleHByZXNzZWQgYXMgdHJhbnNp dGlvbmFsIGdhdGV3YXkgZm9yIG9wZXJhdG9ycyANCj4gYW5kIGNvbnN1bWVycyBvZiB0aGVpciBk YXRhIHRvIGVhc2Ugb3ZlciB0byBXSUVSRFMgZnJvbSBXSE9JUy4NCj4gDQo+PiBJIHdvdWxkIGxp a2UgdG8gZG8gdGhpcywgc28gdGhhdCBpZiBhIGNsaWVudCB3YW50cyB0aGV5IGNhbiBzcGVjaWZ5 IGENCj4+IHBsYWluIHRleHQgbWVkaWEgdHlwZSBhbmQgSSBjb3VsZCBzZW5kIHRoZW0gYSBVVEY4 IGVuY29kZWQgdGV4dCBzdHJlYW0NCj4+IHRoYXQgaXMgZXNzZW50aWFsbHkgbXkgY3VycmVudCBX aG9JcyByZXNwb25zZSAoc28gdGhlIGZpZWxkcyBhcmUNCj4+IHByZWZpeGVkIHdpdGggYSBkZXNj cmlwdGl2ZSBsYWJlbCkuDQo+IA0KPiBXaGlsZSB0aGF0IHNlZW1zIHRvIG1ha2Ugc2Vuc2UsIGRv ZXMgaXQgcmVhbGx5IGVuY291cmFnZSBnb29kIGJlaGF2aW9yPyANCj4gIEluIG90aGVyIHdvcmRz LCB3aWxsIGl0IG1ha2UgdGhlIHRhc2sgb2YgdHJhbnNpdGlvbmluZyBvciBtaWdyYXRpbmcgdG8g DQo+IGEgZnVsbCBpbXBsZW1lbnRhdGlvbiBvZiBhIG1vcmUgUkVTVGZ1bCBlbnZpcm9ubWVudCBs ZXNzIGRlc2lyYWJsZSBmb3IgDQo+IGNvbnN1bWVycyBvZiBkYXRhIGFuZCB0aGUgcmVnaXN0cmll cz8NCj4gDQo+PiANCj4+IFRoaXMgd291bGQgbWFrZSB0cmFuc2l0aW9uIGVhc2llciwgYW5kIGEg cmVhbGx5IHNpbXBsZSBXRVJJRFMgY2xpZW50IChlZw0KPj4gYSBjb21tYW5kIGxpbmUgd2dldCBv ciBjdXJsKSBjb3VsZCBqdXN0IGdldCB0aGUgcGxhaW4gdGV4dCB2ZXJzaW9uIGFuZA0KPj4gc2Vu ZCBpdCB0byBjb25zb2xlLg0KPiANCj4gQWdyZWVkLiAgQW5vdGhlciBxdWVzdGlvbiB0byBhc2su Li4gd291bGQgc3VjaCBhIHNvbHV0aW9uIGJlIGFibGUgdG8gYXMgDQo+IGVhc2lseSBpbXBsZW1l bnQgdGhlIHNhbWUga2luZHMgb2Ygc2VjdXJpdHkgbWVhc3VyZXMgYXMgaGFzIGJlZW4gDQo+IHBy b3Bvc2VkIGJ5IHNvbWUgb24gdGhpcyBsaXN0Pw0KPiANCj4+IA0KPj4gT2YgY291cnNlIHRoZSBX RVJJRFMgc2VydmVyIHdvdWxkIGFsc28gaGF2ZSB0byBzdXBwb3J0IHRoZSBKU09OIG1lZGlhDQo+ PiB0eXBlIGFzIHdlbGwgdG8gYWxsb3cgdGhlIOKAmG1hY2hpbmUgdG8gbWFjaGluZeKAmSBzdHls ZSBpbnRlcmFjdGlvbiB3ZSBhcmUNCj4+IGludGVuZGluZy4NCj4+IA0KPj4gQW55IG9uZSBzZWUg YW55IGlzc3VlcyB3aXRoIHRoaXM/DQo+IA0KPiBXaGlsZSB0aGVyZSBtaWdodCBiZSBzb21lIHF1 ZXN0aW9ucyB0byB0aGluayBhYm91dCwgb2ZmZXJpbmcgYSBwbGFpbiANCj4gdGV4dCBtZWRpYSB0 eXBlIHNlZW1zIGEgdmFsaWQgaWRlYSBpbiBhcHByb2FjaGluZyB0cmFuc2l0aW9uYWwgbWlncmF0 aW9uIA0KPiBmcm9tIFdIT0lTIHRvIFdJRVJEUy4NCj4gDQo+IFBlcmhhcHMgdGhlIGFwcHJvYWNo IGluIGRlc2NyaWJpbmcgdGhpcyBjb3VsZCBiZSBleHByZXNzZWQgaW4gYSAiTUFZIA0KPiBjaG9v c2UgdG8gaW1wbGVtZW50IGEgcGxhaW4gdGV4dCBvcHRpb24gdG8gYXNzaXN0IGluIHRyYW5zaXRp b24gb3IgDQo+IGVuY291cmFnZSBlYXJseSBhZG9wdGlvbiIgYXBwcm9hY2guDQo+IA0KPj4gDQo+ PiBUaGFua3MNCj4+IA0KPj4gYy4NCj4+IA0KPiANCj4gQmVzdCwNCj4gDQo+IEFsYW4gTS4NCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiB3ZWlyZHMgbWFpbGluZyBsaXN0DQo+IHdlaXJkc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlaXJkcw0K From AMaitland@Commerco.Com Tue Sep 18 00:26:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0195721F8589 for ; Tue, 18 Sep 2012 00:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxmvvlCTtH9U for ; Tue, 18 Sep 2012 00:26:24 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 22E5F21F8557 for ; Tue, 18 Sep 2012 00:26:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=X3j+Md8+H+GPrKNxbkyKJHFkmneL3MS5nvDYUtBTp243ZEmdj3O2tlxoqAHSU5cMwNiLO9HIsabA7MfcDpOk7P+M8d7Dsq8boYJlsnm8AwT49dsNLU6Rs5AZKyPjFseQzpvEwUpNHVaNZxggZ0BeoMm5rDV17dDjwZcRq8TNcdk= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Tue, 18 Sep 2012 07:26:17 +0000 Message-ID: <50582212.8050406@Commerco.Com> Date: Tue, 18 Sep 2012 01:26:10 -0600 From: Alan Maitland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dave Piscitello References: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> <50581252.2050005@Commerco.Com> <6E6B02A0-3901-4569-8507-1B43F2EF1FBC@icann.org> In-Reply-To: <6E6B02A0-3901-4569-8507-1B43F2EF1FBC@icann.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: weirds@ietf.org Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 07:26:25 -0000 Hi Dave, On 9/18/2012 12:48 AM, Dave Piscitello wrote: > So you are suggesting a plain text response to a structured query that presumably returns the current blob of whatever data the provider serves up. Doesn't this leave all the burden on the client and consumer of data (I.e, all the variability across whois responses must be normalized still)? > > Sent from my iPhone > Actually, I was responding to Chris Wright at ausregistry.com.au who started the thread. From a transitional perspective, his idea might at least offer a common request point and mechanism for both the plain text and the new response formats. As the issues with having to work in plain text already exist today, one might expect that dealing with the plain text from a consumer/client basis will really not be that much different then is the case for current WHOIS responses. Of course, the alternate view might well be to simply say if you wish to support the WHOIS responses as they exist today, why not just do that? But then if there are client consumers who would prefer to have the WHOIS style responses live on and those registries who would opt to continue to provide such responses and WHOIS gets retired, there might be some WEIRDS "buyers" (implementers?) remorse. Then again, that view might presume the WEIRDS text response would be a long term solution, which may not be the choice of the majority of those sculpting and implementing the WEIRDS protocol. Best, Alan M. > On Sep 18, 2012, at 7:19 AM, "Alan Maitland" wrote: > >> On 9/17/2012 5:41 PM, Chris Wright wrote: >>> Would people be against including a plain text media type in WEIRDS? >>> >> >> This approach could be expressed as transitional gateway for operators >> and consumers of their data to ease over to WIERDS from WHOIS. >> >>> I would like to do this, so that if a client wants they can specify a >>> plain text media type and I could send them a UTF8 encoded text stream >>> that is essentially my current WhoIs response (so the fields are >>> prefixed with a descriptive label). >> >> While that seems to make sense, does it really encourage good behavior? >> In other words, will it make the task of transitioning or migrating to >> a full implementation of a more RESTful environment less desirable for >> consumers of data and the registries? >> >>> >>> This would make transition easier, and a really simple WERIDS client (eg >>> a command line wget or curl) could just get the plain text version and >>> send it to console. >> >> Agreed. Another question to ask... would such a solution be able to as >> easily implement the same kinds of security measures as has been >> proposed by some on this list? >> >>> >>> Of course the WERIDS server would also have to support the JSON media >>> type as well to allow the ‘machine to machine’ style interaction we are >>> intending. >>> >>> Any one see any issues with this? >> >> While there might be some questions to think about, offering a plain >> text media type seems a valid idea in approaching transitional migration >> from WHOIS to WIERDS. >> >> Perhaps the approach in describing this could be expressed in a "MAY >> choose to implement a plain text option to assist in transition or >> encourage early adoption" approach. >> >>> >>> Thanks >>> >>> c. >>> >> >> Best, >> >> Alan M. >> From wolfgang.nagele@ausregistry.com.au Tue Sep 18 00:57:55 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D005A21F8658 for ; Tue, 18 Sep 2012 00:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjWg8CQJ3bDc for ; Tue, 18 Sep 2012 00:57:55 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id EF3AE21F8484 for ; Tue, 18 Sep 2012 00:57:54 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 18 Sep 2012 17:57:53 +1000 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Tue, 18 Sep 2012 17:57:25 +1000 From: Wolfgang Nagele To: Dave Piscitello Date: Tue, 18 Sep 2012 17:57:51 +1000 Thread-Topic: [weirds] Text media type Thread-Index: Ac2Vcz0xi75IVengQjyqoKQffQfH1g== Message-ID: References: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> <50581252.2050005@Commerco.Com> <6E6B02A0-3901-4569-8507-1B43F2EF1FBC@icann.org> In-Reply-To: <6E6B02A0-3901-4569-8507-1B43F2EF1FBC@icann.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 07:57:55 -0000 Hi, If we were to use a text/plain content-type I would suggest not to infer an= y sort of structure of that data. For that response the client would have t= o serve the answer "as-is". Given that, I would rather define a content-type for RPSL - application/rps= l for instance so it is clear which format is being returned/requested. Regards, -- Wolfgang Nagele Senior Systems and Network Administrator AusRegistry Pty Ltd Level 8, 10 Queens Road Melbourne, Victoria, Australia, 3004 Phone +61 3 9090 1756 Email: wolfgang.nagele@ausregistry.com.au Web: www.ausregistry.com.au The information contained in this communication is intended for the named r= ecipients only. It is subject to copyright and may contain legally privileg= ed and confidential information and if you are not an intended recipient yo= u must not use, copy, distribute or take any action in reliance on it. If y= ou have received this communication in error, please delete all copies from= your system and notify us immediately. On Sep 18, 2012, at 4:48 PM, Dave Piscitello wr= ote: > So you are suggesting a plain text response to a structured query that pr= esumably returns the current blob of whatever data the provider serves up. = Doesn't this leave all the burden on the client and consumer of data (I.e, = all the variability across whois responses must be normalized still)? >=20 > Sent from my iPhone >=20 > On Sep 18, 2012, at 7:19 AM, "Alan Maitland" wro= te: >=20 >> On 9/17/2012 5:41 PM, Chris Wright wrote: >>> Would people be against including a plain text media type in WEIRDS? >>>=20 >>=20 >> This approach could be expressed as transitional gateway for operators=20 >> and consumers of their data to ease over to WIERDS from WHOIS. >>=20 >>> I would like to do this, so that if a client wants they can specify a >>> plain text media type and I could send them a UTF8 encoded text stream >>> that is essentially my current WhoIs response (so the fields are >>> prefixed with a descriptive label). >>=20 >> While that seems to make sense, does it really encourage good behavior?= =20 >> In other words, will it make the task of transitioning or migrating to=20 >> a full implementation of a more RESTful environment less desirable for=20 >> consumers of data and the registries? >>=20 >>>=20 >>> This would make transition easier, and a really simple WERIDS client (e= g >>> a command line wget or curl) could just get the plain text version and >>> send it to console. >>=20 >> Agreed. Another question to ask... would such a solution be able to as= =20 >> easily implement the same kinds of security measures as has been=20 >> proposed by some on this list? >>=20 >>>=20 >>> Of course the WERIDS server would also have to support the JSON media >>> type as well to allow the =91machine to machine=92 style interaction we= are >>> intending. >>>=20 >>> Any one see any issues with this? >>=20 >> While there might be some questions to think about, offering a plain=20 >> text media type seems a valid idea in approaching transitional migration= =20 >> from WHOIS to WIERDS. >>=20 >> Perhaps the approach in describing this could be expressed in a "MAY=20 >> choose to implement a plain text option to assist in transition or=20 >> encourage early adoption" approach. >>=20 >>>=20 >>> Thanks >>>=20 >>> c. >>>=20 >>=20 >> Best, >>=20 >> Alan M. >>=20 >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From dave.piscitello@icann.org Tue Sep 18 04:04:31 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17BC21F8685 for ; Tue, 18 Sep 2012 04:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc5ir1QUY+1T for ; Tue, 18 Sep 2012 04:04:30 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id B31D721F8687 for ; Tue, 18 Sep 2012 04:04:23 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 18 Sep 2012 04:04:23 -0700 From: Dave Piscitello To: Alan Maitland Date: Tue, 18 Sep 2012 04:04:17 -0700 Thread-Topic: [weirds] Text media type Thread-Index: Ac2VjVv38Qu96k3qRxig1PqV4XlKKA== Message-ID: References: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> <50581252.2050005@Commerco.Com> <6E6B02A0-3901-4569-8507-1B43F2EF1FBC@icann.org> <50582212.8050406@Commerco.Com> In-Reply-To: <50582212.8050406@Commerco.Com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 11:04:31 -0000 VHggZm9yIHRoZSBjbGFyaWZpY2F0aW9uLg0KDQpJIHNoYXJlIEpvaG4gTGV2aW5lJ3MgY29uZmVy IHRoYXQgdGhpcyB3b3VsZCBOZXZlciBnbyBhd2F5IGFuZCB0aHVzIG1hbnkgb2YgdGhlIGJlbmVm aXRzIHdvdWxkIG5vdCBiZSByZWFsaXplZC4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiBT ZXAgMTgsIDIwMTIsIGF0IDg6NDcgQU0sICJBbGFuIE1haXRsYW5kIiA8QU1haXRsYW5kQENvbW1l cmNvLkNvbT4gd3JvdGU6DQoNCj4gSGkgRGF2ZSwNCj4gDQo+IE9uIDkvMTgvMjAxMiAxMjo0OCBB TSwgRGF2ZSBQaXNjaXRlbGxvIHdyb3RlOg0KPj4gU28geW91IGFyZSBzdWdnZXN0aW5nIGEgcGxh aW4gdGV4dCByZXNwb25zZSB0byBhIHN0cnVjdHVyZWQgcXVlcnkgdGhhdCBwcmVzdW1hYmx5IHJl dHVybnMgdGhlIGN1cnJlbnQgYmxvYiBvZiB3aGF0ZXZlciBkYXRhIHRoZSBwcm92aWRlciBzZXJ2 ZXMgdXAuIERvZXNuJ3QgdGhpcyBsZWF2ZSBhbGwgdGhlIGJ1cmRlbiBvbiB0aGUgY2xpZW50IGFu ZCBjb25zdW1lciBvZiBkYXRhIChJLmUsIGFsbCB0aGUgdmFyaWFiaWxpdHkgYWNyb3NzIHdob2lz IHJlc3BvbnNlcyBtdXN0IGJlIG5vcm1hbGl6ZWQgc3RpbGwpPw0KPj4gDQo+PiBTZW50IGZyb20g bXkgaVBob25lDQo+PiANCj4gDQo+IEFjdHVhbGx5LCBJIHdhcyByZXNwb25kaW5nIHRvIENocmlz IFdyaWdodCBhdCBhdXNyZWdpc3RyeS5jb20uYXUgd2hvIA0KPiBzdGFydGVkIHRoZSB0aHJlYWQu DQo+IA0KPiBGcm9tIGEgdHJhbnNpdGlvbmFsIHBlcnNwZWN0aXZlLCBoaXMgaWRlYSBtaWdodCBh dCBsZWFzdCBvZmZlciBhIGNvbW1vbiANCj4gcmVxdWVzdCBwb2ludCBhbmQgbWVjaGFuaXNtIGZv ciBib3RoIHRoZSBwbGFpbiB0ZXh0IGFuZCB0aGUgbmV3IHJlc3BvbnNlIA0KPiBmb3JtYXRzLg0K PiANCj4gQXMgdGhlIGlzc3VlcyB3aXRoIGhhdmluZyB0byB3b3JrIGluIHBsYWluIHRleHQgYWxy ZWFkeSBleGlzdCB0b2RheSwgb25lIA0KPiBtaWdodCBleHBlY3QgdGhhdCBkZWFsaW5nIHdpdGgg dGhlIHBsYWluIHRleHQgZnJvbSBhIGNvbnN1bWVyL2NsaWVudCANCj4gYmFzaXMgd2lsbCByZWFs bHkgbm90IGJlIHRoYXQgbXVjaCBkaWZmZXJlbnQgdGhlbiBpcyB0aGUgY2FzZSBmb3IgDQo+IGN1 cnJlbnQgV0hPSVMgcmVzcG9uc2VzLg0KPiANCj4gT2YgY291cnNlLCB0aGUgYWx0ZXJuYXRlIHZp ZXcgbWlnaHQgd2VsbCBiZSB0byBzaW1wbHkgc2F5IGlmIHlvdSB3aXNoIHRvIA0KPiBzdXBwb3J0 IHRoZSBXSE9JUyByZXNwb25zZXMgYXMgdGhleSBleGlzdCB0b2RheSwgd2h5IG5vdCBqdXN0IGRv IHRoYXQ/DQo+IA0KPiBCdXQgdGhlbiBpZiB0aGVyZSBhcmUgY2xpZW50IGNvbnN1bWVycyB3aG8g d291bGQgcHJlZmVyIHRvIGhhdmUgdGhlIA0KPiBXSE9JUyBzdHlsZSByZXNwb25zZXMgbGl2ZSBv biBhbmQgdGhvc2UgcmVnaXN0cmllcyB3aG8gd291bGQgb3B0IHRvIA0KPiBjb250aW51ZSB0byBw cm92aWRlIHN1Y2ggcmVzcG9uc2VzIGFuZCBXSE9JUyBnZXRzIHJldGlyZWQsIHRoZXJlIG1pZ2h0 IA0KPiBiZSBzb21lIFdFSVJEUyAiYnV5ZXJzIiAoaW1wbGVtZW50ZXJzPykgcmVtb3JzZS4NCj4g DQo+IFRoZW4gYWdhaW4sIHRoYXQgdmlldyBtaWdodCBwcmVzdW1lIHRoZSBXRUlSRFMgdGV4dCBy ZXNwb25zZSB3b3VsZCBiZSBhIA0KPiBsb25nIHRlcm0gc29sdXRpb24sIHdoaWNoIG1heSBub3Qg YmUgdGhlIGNob2ljZSBvZiB0aGUgbWFqb3JpdHkgb2YgdGhvc2UgDQo+IHNjdWxwdGluZyBhbmQg aW1wbGVtZW50aW5nIHRoZSBXRUlSRFMgcHJvdG9jb2wuDQo+IA0KPiBCZXN0LA0KPiANCj4gQWxh biBNLg0KPiANCj4+IE9uIFNlcCAxOCwgMjAxMiwgYXQgNzoxOSBBTSwgIkFsYW4gTWFpdGxhbmQi PEFNYWl0bGFuZEBDb21tZXJjby5Db20+ICB3cm90ZToNCj4+IA0KPj4+IE9uIDkvMTcvMjAxMiA1 OjQxIFBNLCBDaHJpcyBXcmlnaHQgd3JvdGU6DQo+Pj4+IFdvdWxkIHBlb3BsZSBiZSBhZ2FpbnN0 IGluY2x1ZGluZyBhIHBsYWluIHRleHQgbWVkaWEgdHlwZSBpbiBXRUlSRFM/DQo+Pj4+IA0KPj4+ IA0KPj4+IFRoaXMgYXBwcm9hY2ggY291bGQgYmUgZXhwcmVzc2VkIGFzIHRyYW5zaXRpb25hbCBn YXRld2F5IGZvciBvcGVyYXRvcnMNCj4+PiBhbmQgY29uc3VtZXJzIG9mIHRoZWlyIGRhdGEgdG8g ZWFzZSBvdmVyIHRvIFdJRVJEUyBmcm9tIFdIT0lTLg0KPj4+IA0KPj4+PiBJIHdvdWxkIGxpa2Ug dG8gZG8gdGhpcywgc28gdGhhdCBpZiBhIGNsaWVudCB3YW50cyB0aGV5IGNhbiBzcGVjaWZ5IGEN Cj4+Pj4gcGxhaW4gdGV4dCBtZWRpYSB0eXBlIGFuZCBJIGNvdWxkIHNlbmQgdGhlbSBhIFVURjgg ZW5jb2RlZCB0ZXh0IHN0cmVhbQ0KPj4+PiB0aGF0IGlzIGVzc2VudGlhbGx5IG15IGN1cnJlbnQg V2hvSXMgcmVzcG9uc2UgKHNvIHRoZSBmaWVsZHMgYXJlDQo+Pj4+IHByZWZpeGVkIHdpdGggYSBk ZXNjcmlwdGl2ZSBsYWJlbCkuDQo+Pj4gDQo+Pj4gV2hpbGUgdGhhdCBzZWVtcyB0byBtYWtlIHNl bnNlLCBkb2VzIGl0IHJlYWxseSBlbmNvdXJhZ2UgZ29vZCBiZWhhdmlvcj8NCj4+PiAgSW4gb3Ro ZXIgd29yZHMsIHdpbGwgaXQgbWFrZSB0aGUgdGFzayBvZiB0cmFuc2l0aW9uaW5nIG9yIG1pZ3Jh dGluZyB0bw0KPj4+IGEgZnVsbCBpbXBsZW1lbnRhdGlvbiBvZiBhIG1vcmUgUkVTVGZ1bCBlbnZp cm9ubWVudCBsZXNzIGRlc2lyYWJsZSBmb3INCj4+PiBjb25zdW1lcnMgb2YgZGF0YSBhbmQgdGhl IHJlZ2lzdHJpZXM/DQo+Pj4gDQo+Pj4+IA0KPj4+PiBUaGlzIHdvdWxkIG1ha2UgdHJhbnNpdGlv biBlYXNpZXIsIGFuZCBhIHJlYWxseSBzaW1wbGUgV0VSSURTIGNsaWVudCAoZWcNCj4+Pj4gYSBj b21tYW5kIGxpbmUgd2dldCBvciBjdXJsKSBjb3VsZCBqdXN0IGdldCB0aGUgcGxhaW4gdGV4dCB2 ZXJzaW9uIGFuZA0KPj4+PiBzZW5kIGl0IHRvIGNvbnNvbGUuDQo+Pj4gDQo+Pj4gQWdyZWVkLiAg QW5vdGhlciBxdWVzdGlvbiB0byBhc2suLi4gd291bGQgc3VjaCBhIHNvbHV0aW9uIGJlIGFibGUg dG8gYXMNCj4+PiBlYXNpbHkgaW1wbGVtZW50IHRoZSBzYW1lIGtpbmRzIG9mIHNlY3VyaXR5IG1l YXN1cmVzIGFzIGhhcyBiZWVuDQo+Pj4gcHJvcG9zZWQgYnkgc29tZSBvbiB0aGlzIGxpc3Q/DQo+ Pj4gDQo+Pj4+IA0KPj4+PiBPZiBjb3Vyc2UgdGhlIFdFUklEUyBzZXJ2ZXIgd291bGQgYWxzbyBo YXZlIHRvIHN1cHBvcnQgdGhlIEpTT04gbWVkaWENCj4+Pj4gdHlwZSBhcyB3ZWxsIHRvIGFsbG93 IHRoZSDigJhtYWNoaW5lIHRvIG1hY2hpbmXigJkgc3R5bGUgaW50ZXJhY3Rpb24gd2UgYXJlDQo+ Pj4+IGludGVuZGluZy4NCj4+Pj4gDQo+Pj4+IEFueSBvbmUgc2VlIGFueSBpc3N1ZXMgd2l0aCB0 aGlzPw0KPj4+IA0KPj4+IFdoaWxlIHRoZXJlIG1pZ2h0IGJlIHNvbWUgcXVlc3Rpb25zIHRvIHRo aW5rIGFib3V0LCBvZmZlcmluZyBhIHBsYWluDQo+Pj4gdGV4dCBtZWRpYSB0eXBlIHNlZW1zIGEg dmFsaWQgaWRlYSBpbiBhcHByb2FjaGluZyB0cmFuc2l0aW9uYWwgbWlncmF0aW9uDQo+Pj4gZnJv bSBXSE9JUyB0byBXSUVSRFMuDQo+Pj4gDQo+Pj4gUGVyaGFwcyB0aGUgYXBwcm9hY2ggaW4gZGVz Y3JpYmluZyB0aGlzIGNvdWxkIGJlIGV4cHJlc3NlZCBpbiBhICJNQVkNCj4+PiBjaG9vc2UgdG8g aW1wbGVtZW50IGEgcGxhaW4gdGV4dCBvcHRpb24gdG8gYXNzaXN0IGluIHRyYW5zaXRpb24gb3IN Cj4+PiBlbmNvdXJhZ2UgZWFybHkgYWRvcHRpb24iIGFwcHJvYWNoLg0KPj4+IA0KPj4+PiANCj4+ Pj4gVGhhbmtzDQo+Pj4+IA0KPj4+PiBjLg0KPj4+PiANCj4+PiANCj4+PiBCZXN0LA0KPj4+IA0K Pj4+IEFsYW4gTS4NCj4+PiANCj4gDQo= From shollenbeck@verisign.com Tue Sep 18 04:04:37 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7F421F869A for ; Tue, 18 Sep 2012 04:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEbRmAkqtqnr for ; Tue, 18 Sep 2012 04:04:36 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id B055221F869E for ; Tue, 18 Sep 2012 04:04:34 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUFhVQosm2zGUCZwbMD2ip5B03OzsZhnw@postini.com; Tue, 18 Sep 2012 04:04:36 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q8IB4Vwb013396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 07:04:31 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Tue, 18 Sep 2012 07:04:03 -0400 From: "Hollenbeck, Scott" To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Text media type Thread-Index: Ac2VLYlTPixYftLBQvOex54pZGOZwgAQ0QoAAAcOJTA= Date: Tue, 18 Sep 2012 11:04:30 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D689A3A@BRN1WNEXMBX02.vcorp.ad.vrsn.com> References: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> <20120918033958.36596.qmail@joyce.lan> In-Reply-To: <20120918033958.36596.qmail@joyce.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 11:04:37 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of John Levine > Sent: Monday, September 17, 2012 11:40 PM > To: weirds@ietf.org > Subject: Re: [weirds] Text media type >=20 > >Would people be against including a plain text media type in WEIRDS? >=20 > It's a perfectly reasonable thing to do, but I would have reservations > about putting it into WEIRDS, because history tells us that once > something is in the spec, it'll never, ever go away. >=20 > Would you want it to say that the text/plain response is an entirely > implementation dependent stream of UTF-8 text, or more than that? As > soon as there is any sort of spec for what's in that stream, we've > effectively doubled our work, since now we have to define the text > version as well as the JSON version for everything. >=20 > Remember that a standard describes what you have to do in order to > interoperate. You're always allowed to have your software do things > beyond what the standard says, so long as it doesn't interfere with the > standard compliant operation. It'd be fine to leave text/plain out of > the standard, but implement it anyway as a non-standard transition > hack. I concur. We already have some text in the unified query draft that sort-of= describes this scenario: "It is envisioned that each registry will continue to maintain NICNAME/WHOI= S and/or RESTful web services specific to their needs and those of their co= nstituencies, and the information retrieved through the patterns described = here may reference such services." I also agree that it doesn't need to be described in the specs. Scott From aservin@lacnic.net Tue Sep 18 05:50:04 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A3221F8768 for ; Tue, 18 Sep 2012 05:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hba14MzCvkLI for ; Tue, 18 Sep 2012 05:50:03 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1F40021F8767 for ; Tue, 18 Sep 2012 05:50:03 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy (unknown [200.7.87.78]) by mail.lacnic.net.uy (Postfix) with ESMTP id 15941308424 for ; Tue, 18 Sep 2012 09:49:59 -0300 (UYT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1278) From: Arturo Servin In-Reply-To: Date: Tue, 18 Sep 2012 09:49:57 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> <50581252.2050005@Commerco.Com> <6E6B02A0-3901-4569-8507-1B43F2EF1FBC@icann.org> <50582212.8050406@Commerco.Com> To: "" X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 12:50:04 -0000 Same as many I prefer not to standardise this, otherwise it will = never go away. Regards, as On 18 Sep 2012, at 08:04, Dave Piscitello wrote: > Tx for the clarification. >=20 > I share John Levine's confer that this would Never go away and thus = many of the benefits would not be realized. >=20 > Sent from my iPhone >=20 > On Sep 18, 2012, at 8:47 AM, "Alan Maitland" = wrote: >=20 >> Hi Dave, >>=20 >> On 9/18/2012 12:48 AM, Dave Piscitello wrote: >>> So you are suggesting a plain text response to a structured query = that presumably returns the current blob of whatever data the provider = serves up. Doesn't this leave all the burden on the client and consumer = of data (I.e, all the variability across whois responses must be = normalized still)? >>>=20 >>> Sent from my iPhone >>>=20 >>=20 >> Actually, I was responding to Chris Wright at ausregistry.com.au who=20= >> started the thread. >>=20 >> =46rom a transitional perspective, his idea might at least offer a = common=20 >> request point and mechanism for both the plain text and the new = response=20 >> formats. >>=20 >> As the issues with having to work in plain text already exist today, = one=20 >> might expect that dealing with the plain text from a consumer/client=20= >> basis will really not be that much different then is the case for=20 >> current WHOIS responses. >>=20 >> Of course, the alternate view might well be to simply say if you wish = to=20 >> support the WHOIS responses as they exist today, why not just do = that? >>=20 >> But then if there are client consumers who would prefer to have the=20= >> WHOIS style responses live on and those registries who would opt to=20= >> continue to provide such responses and WHOIS gets retired, there = might=20 >> be some WEIRDS "buyers" (implementers?) remorse. >>=20 >> Then again, that view might presume the WEIRDS text response would be = a=20 >> long term solution, which may not be the choice of the majority of = those=20 >> sculpting and implementing the WEIRDS protocol. >>=20 >> Best, >>=20 >> Alan M. >>=20 >>> On Sep 18, 2012, at 7:19 AM, "Alan Maitland" = wrote: >>>=20 >>>> On 9/17/2012 5:41 PM, Chris Wright wrote: >>>>> Would people be against including a plain text media type in = WEIRDS? >>>>>=20 >>>>=20 >>>> This approach could be expressed as transitional gateway for = operators >>>> and consumers of their data to ease over to WIERDS from WHOIS. >>>>=20 >>>>> I would like to do this, so that if a client wants they can = specify a >>>>> plain text media type and I could send them a UTF8 encoded text = stream >>>>> that is essentially my current WhoIs response (so the fields are >>>>> prefixed with a descriptive label). >>>>=20 >>>> While that seems to make sense, does it really encourage good = behavior? >>>> In other words, will it make the task of transitioning or migrating = to >>>> a full implementation of a more RESTful environment less desirable = for >>>> consumers of data and the registries? >>>>=20 >>>>>=20 >>>>> This would make transition easier, and a really simple WERIDS = client (eg >>>>> a command line wget or curl) could just get the plain text version = and >>>>> send it to console. >>>>=20 >>>> Agreed. Another question to ask... would such a solution be able = to as >>>> easily implement the same kinds of security measures as has been >>>> proposed by some on this list? >>>>=20 >>>>>=20 >>>>> Of course the WERIDS server would also have to support the JSON = media >>>>> type as well to allow the =91machine to machine=92 style = interaction we are >>>>> intending. >>>>>=20 >>>>> Any one see any issues with this? >>>>=20 >>>> While there might be some questions to think about, offering a = plain >>>> text media type seems a valid idea in approaching transitional = migration >>>> from WHOIS to WIERDS. >>>>=20 >>>> Perhaps the approach in describing this could be expressed in a = "MAY >>>> choose to implement a plain text option to assist in transition or >>>> encourage early adoption" approach. >>>>=20 >>>>>=20 >>>>> Thanks >>>>>=20 >>>>> c. >>>>>=20 >>>>=20 >>>> Best, >>>>=20 >>>> Alan M. >>>>=20 >>=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From carlosm3011@gmail.com Tue Sep 18 05:53:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5820921F8691 for ; Tue, 18 Sep 2012 05:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soN7yZ6mRgg4 for ; Tue, 18 Sep 2012 05:53:04 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6865421F8687 for ; Tue, 18 Sep 2012 05:53:04 -0700 (PDT) Received: by ggnh4 with SMTP id h4so1746012ggn.31 for ; Tue, 18 Sep 2012 05:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=ntBMfJPtRujdaig1oIf8OGRRUJ4bGXg4Zn2MzxKpnvg=; b=taHU6wWwCuQqoaAeqihDvFyrQFngYI0eKphOvhDxJ81A7bs+C/49+p6eUCvRF2UelR HOGuase6eJoC+hhDUvG1K/ERn06Anyh3xYXm9R2N0WaP0wzz3cMEP+bvXmQs7juwaEpl pHwE2f51q62n/QgBkHh9CkfS8KFQwSLNVYbrUcn5WBCUWvA9BYvfaHVnQoEXXys+4ibJ N5UHpUCjT5W1nEYqlrlszIq2glDsaZYQYPqdxHnHEc4Wkb0zcBs6ciefO7OmvGgV4T5N d3n2i4kq2nGr/smQTI9vtKlI93hPHbDgzAfzHYQSwzWO9WomLzpATRsKETssrlAkQbb/ qjGA== Received: by 10.236.190.4 with SMTP id d4mr48657yhn.65.1347972783917; Tue, 18 Sep 2012 05:53:03 -0700 (PDT) Received: from [190.132.235.210] (r190-132-235-210.dialup.mobile.ancel.net.uy. [190.132.235.210]) by mx.google.com with ESMTPS id o11sm12151481anp.4.2012.09.18.05.52.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 05:53:02 -0700 (PDT) References: <8CEF048B9EC83748B1517DC64EA130FB72DB514C98@off-win2003-01.ausregistrygroup.local> <20120918033958.36596.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F0D689A3A@BRN1WNEXMBX02.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D689A3A@BRN1WNEXMBX02.vcorp.ad.vrsn.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <04DC10FB-7EB7-46FD-9AC0-71139FD4537F@gmail.com> X-Mailer: iPhone Mail (9B206) From: Carlos Martinez Date: Tue, 18 Sep 2012 09:54:24 -0300 To: "Hollenbeck, Scott" Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] Text media type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 12:53:05 -0000 Agreed. What is currently written should suffice.=20 Sent from a mobile device On Sep 18, 2012, at 8:04 AM, "Hollenbeck, Scott" w= rote: >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of John Levine >> Sent: Monday, September 17, 2012 11:40 PM >> To: weirds@ietf.org >> Subject: Re: [weirds] Text media type >>=20 >>> Would people be against including a plain text media type in WEIRDS? >>=20 >> It's a perfectly reasonable thing to do, but I would have reservations >> about putting it into WEIRDS, because history tells us that once >> something is in the spec, it'll never, ever go away. >>=20 >> Would you want it to say that the text/plain response is an entirely >> implementation dependent stream of UTF-8 text, or more than that? As >> soon as there is any sort of spec for what's in that stream, we've >> effectively doubled our work, since now we have to define the text >> version as well as the JSON version for everything. >>=20 >> Remember that a standard describes what you have to do in order to >> interoperate. You're always allowed to have your software do things >> beyond what the standard says, so long as it doesn't interfere with the >> standard compliant operation. It'd be fine to leave text/plain out of >> the standard, but implement it anyway as a non-standard transition >> hack. >=20 > I concur. We already have some text in the unified query draft that sort-o= f describes this scenario: >=20 > "It is envisioned that each registry will continue to maintain NICNAME/WHO= IS and/or RESTful web services specific to their needs and those of their co= nstituencies, and the information retrieved through the patterns described h= ere may reference such services." >=20 > I also agree that it doesn't need to be described in the specs. >=20 > Scott > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From superuser@gmail.com Tue Sep 18 11:55:30 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53D221E80C1 for ; Tue, 18 Sep 2012 11:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7BB0T0B-Ggl for ; Tue, 18 Sep 2012 11:55:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E185E21E8034 for ; Tue, 18 Sep 2012 11:55:29 -0700 (PDT) Received: by lahm15 with SMTP id m15so128852lah.31 for ; Tue, 18 Sep 2012 11:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8GhDIPQHyhyg91wdaYcbqYUvAP2ZkxFb1sp7C9s039E=; b=W3waAstWEuAgUSvkLGDIO8ETV/Rd53z1UwOkKoL+/kfZ/o43BkC/jEoQ35knkZzOQc GirjIGxumjrxy7LdI32gx8lKdd3Y7lkYgX3JCLLpRzBew0za8Jt0N2dJUjR+7GQUW4P+ o+3Wl+HNz7Jx9KRrehHoif0D8xdSb4STAXUSMG4zyFpr1D0gq41UDGPH27SLcqG5cUyV mHOyXgKPZlUSEWcqDBWjHM5my+vTB/dysV1GJLQ5PNkfTn05W5F5zogI4a6EQH/NEw/x gaaEzXVNgpsSggQOXgpLTQpX0RSqPtcAcrsnckAV5SJkKiMOOFcYMnoHmXNIgm+u3dba RSDQ== MIME-Version: 1.0 Received: by 10.112.84.101 with SMTP id x5mr252351lby.28.1347994528894; Tue, 18 Sep 2012 11:55:28 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 18 Sep 2012 11:55:28 -0700 (PDT) Date: Tue, 18 Sep 2012 11:55:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: weirds@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [weirds] Submitting documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 18:55:30 -0000 Thanks to those of you who worked behind the scenes on getting document proposals together. Document authors/editors are invited to submit new working group documents as follows: 1) draft-designteam-weirds-using-http becomes draft-ietf-weirds-using-http (Byron, Ning, Andy) 2) draft-hollenbeck-weirds-rdap-sec becomes draft-ietf-weirds-rdap-sec (Scott, [see below]) 3) draft-hollenbeck-weirds-unified-rdap-query becomes draft-ietf-weirds-rdap-query (Scott, Andy) 4) draft-newton-weirds-unified-json-response becomes draft-ietf-weirds-json-response (Scott, Andy) 5) draft-lacnic-weirds-restwhois-redirects becomes draft-ietf-weirds-rdap-redirects ([see below]) For (2), Ning has volunteered to assist Scott. Ning, please email Scott and confirm your interest and availability to do that work, and then one of you can submit the document. I am also talking to the Security Area ADs to see about getting some independent security help on that topic. For (5), I'd like to see a names person in the author list, and preferably a shorter list. If you folks can work that out, you're welcome to submit as well. Thank you again. Let's get busy! -MSK From aservin@lacnic.net Tue Sep 18 12:08:54 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC6B21F861D for ; Tue, 18 Sep 2012 12:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.993 X-Spam-Level: X-Spam-Status: No, score=-0.993 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfxlSgOk5o9N for ; Tue, 18 Sep 2012 12:08:54 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id DD94D21F85C7 for ; Tue, 18 Sep 2012 12:08:53 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy (unknown [200.7.87.78]) by mail.lacnic.net.uy (Postfix) with ESMTP id A0FD5308432; Tue, 18 Sep 2012 16:08:49 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_0B048EEC-1E9E-4E75-BD16-1B8AA338A223" From: Arturo Servin In-Reply-To: Date: Tue, 18 Sep 2012 16:08:49 -0300 Message-Id: <0BBC7FE6-C193-4948-A853-0E8722F1BF50@lacnic.net> References: To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] Submitting documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 19:08:54 -0000 --Apple-Mail=_0B048EEC-1E9E-4E75-BD16-1B8AA338A223 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii If somebody wants to help, it is welcome. Just let us know. Regards, as On 18 Sep 2012, at 15:55, Murray S. Kucherawy wrote: > For (5), I'd like to see a names person in the author list, and > preferably a shorter list. If you folks can work that out, you're > welcome to submit as well. --Apple-Mail=_0B048EEC-1E9E-4E75-BD16-1B8AA338A223 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii If somebody wants to help, it is = welcome. Just let us know.

=

Regards,
as

= On 18 Sep 2012, at 15:55, Murray S. Kucherawy wrote:

For (5), I'd = like to see a names person in the author list, and
preferably a = shorter list.  If you folks can work that out, you're
welcome to = submit as well.

= --Apple-Mail=_0B048EEC-1E9E-4E75-BD16-1B8AA338A223-- From wil@cloudregistry.net Tue Sep 18 21:06:53 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFF821E8096 for ; Tue, 18 Sep 2012 21:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us0Oq+gesKpI for ; Tue, 18 Sep 2012 21:06:53 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8D021E8095 for ; Tue, 18 Sep 2012 21:06:52 -0700 (PDT) Received: by qcac10 with SMTP id c10so534244qca.31 for ; Tue, 18 Sep 2012 21:06:52 -0700 (PDT) X-Google-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:x-gm-message-state; bh=2YHhNQomj80e2APPCmMZtAO8YUR2ysDam5TRDufoJ70=; b=S74Es7Us3QPHz2hoTmSp4OvNf+Nsrsnu20VMMzOEmJi74/xVxEEw6I+IaELUAMUeO0 u0CS3W8rkWgcztz0tcsw5l/jp9WH9lhFD7ygfCRx5YM8U8HuE+nEaD8HIEmY00gRnepz WL7/z9jn2mrKgv8TTpk6vFyV/iG468IwDeOtC+BOGh4QdH5Rr7iUogXfmUgGK1GW8LHP JCo0oF89bm9pwP3inPIVAjDQYNTe7lUlnrjg4z4KbsMiRPWd8t/nkJvWDxLG3RyVO+Gu e3m7M7GvT2hxtxEvt4ftGB4OdmB5knvA6ZS52osyypeTi/VHvMFBpA3oS5aBKVjeQ0ZN 8Ybg== Received: by 10.224.222.209 with SMTP id ih17mr4361242qab.82.1348027612313; Tue, 18 Sep 2012 21:06:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.112 with HTTP; Tue, 18 Sep 2012 21:06:06 -0700 (PDT) In-Reply-To: <0BBC7FE6-C193-4948-A853-0E8722F1BF50@lacnic.net> References: <0BBC7FE6-C193-4948-A853-0E8722F1BF50@lacnic.net> From: Wil Tan Date: Wed, 19 Sep 2012 14:06:06 +1000 Message-ID: To: Arturo Servin Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl568ETqGN4SBZeY5sHEVzRr+8x+QkK8Dboygsf1ewc/QyRpI9861nhUNgiIouVhVeWdffp Cc: weirds@ietf.org Subject: Re: [weirds] Submitting documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 04:06:54 -0000 On Wed, Sep 19, 2012 at 5:08 AM, Arturo Servin wrote: > > If somebody wants to help, it is welcome. Just let us know. > I'm happy to contribute to the draft, which IMO is already in pretty good shape. I do have concerns that the loop detection mechanism of modifying the URI breaks caching. Will send a separate comment on it. .wil > > Regards, > as > > On 18 Sep 2012, at 15:55, Murray S. Kucherawy wrote: > > For (5), I'd like to see a names person in the author list, and > preferably a shorter list. If you folks can work that out, you're > welcome to submit as well. > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From wil@cloudregistry.net Tue Sep 18 21:37:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2E321E8090 for ; Tue, 18 Sep 2012 21:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm8mC1dQG19x for ; Tue, 18 Sep 2012 21:37:43 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B030B21F841C for ; Tue, 18 Sep 2012 21:37:42 -0700 (PDT) Received: by qcac10 with SMTP id c10so549405qca.31 for ; Tue, 18 Sep 2012 21:37:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=h4eUZbnAPDs03Cm5m6P6AfFyC6jb6Fnwzltx55myxa4=; b=B8LPf7v6I5lfesd23FOy8q9rrKW01T8JZI1x9iINpZ1eUFt1gCITt9jjfSn8izfnPP Bkv4q/kfeSFAjxB6we62P+CHFK84hyRFu4ToQt+QgkCDiji0HZXNFy534K40xCgT0B5S od65q+BexdbOXwHRQS7zUzlxLsmK+z1b9jNOo8vCQrDfy1xgFhnA9WpuWEpyNIjTY4ik NfffV2CqDhiEq0Vm+FfNncamtJhC6Zcrd/cWmR/ndirHVF/p6tB7BnOCXlSewnPTH/ia +imd9MbvtHmJMXDFJYpVYRxazApg1rKpRstwrpB5abse/o2P2ijpRuvW7bKNHk7JH28L GqGA== Received: by 10.229.135.76 with SMTP id m12mr1312237qct.68.1348029462173; Tue, 18 Sep 2012 21:37:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.112 with HTTP; Tue, 18 Sep 2012 21:37:01 -0700 (PDT) From: Wil Tan Date: Wed, 19 Sep 2012 14:37:01 +1000 Message-ID: To: weirds@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQldMePWg3Oti4f05iCEedrNI5QeXla2BCgRtCGSERJs6vYZom2xiAkJxOfBcA+mxqxcv9mh Subject: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 04:37:43 -0000 In section 2.4 of draft-lacnic-weirds-restwhois-redirects-00: When redirection is used there is always the risk that bogus user- agents and applications or malicious user can create loops that in turn may become Denial of Service attacks. In our use cases where the registries (e.g. the RIRs) are federated, how could a malicious user create loops? I would imagine that loops are most likely caused by administrative errors, e.g. wrong entries in a registry's database. Am I missing something? The document suggests that the server modify the URI prior to redirecting, but it's less than ideal since it breaks caching. I realize that there's no ideal solution here, but feel that this is perhaps something that's best solved using a combination of: - knowing the other weirds servers that would redirect to you; and - if the request needs to be redirected, and the Referer header indicates that the UA came from another weirds server, refuse to redirect; and - we should mandate that UA's send the Referer headers Also, in 3.1.1. Operators that support the redirect URI MUST never process redirects that contain a step value greater that their locally set threshold. If the query can be satisfied locally without responding with a redirect, shouldn't the operator just process it even if the step value exceeds threshold? .wil From carlosm3011@gmail.com Tue Sep 18 22:06:57 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A79E21F869D for ; Tue, 18 Sep 2012 22:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yin1M6RE0jTN for ; Tue, 18 Sep 2012 22:06:56 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC021F868A for ; Tue, 18 Sep 2012 22:06:56 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so729388vcb.31 for ; Tue, 18 Sep 2012 22:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nDfeKmkym6gFmjCLI04kvkOrhaqLBKHeo83xrEBdx6w=; b=qXjX6mlbqphXiwCw88l6jpQkfZAqBwJSb9NMHO1i83OI7wTcNJsByHljwcqFIGyDBT hrEgma6jCo+eBwtQJKYQqA5Lr58WKxe44X0qKM0pPAKOHYAYy7oBNpIjyaowN3I6uGzW wT641SEXvOOEM/8O/5GzE5AcsVupzWvRNB1W8kgLIkCZJ45P1sUkrFEZjZzK2BoMHyds VVL2kF3WutEtx/6P1QHyKYFKrBXuilBUoO1LZDXN2g6gAYta/8iHzoJyZBkZydd9SRJo Lu891uz5VXvILI3YHYPjTTFqUEIZIsnu8gybs1wDR4kKVrJQ2OikBM8/vYqD/8tQZKFH Y80A== Received: by 10.52.72.164 with SMTP id e4mr1034543vdv.103.1348031216057; Tue, 18 Sep 2012 22:06:56 -0700 (PDT) Received: from erebus.local ([2001:470:d815:fe0:8d03:4dac:af41:f561]) by mx.google.com with ESMTPS id g19sm464301vdh.17.2012.09.18.22.06.53 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 22:06:55 -0700 (PDT) Message-ID: <505952EF.40906@gmail.com> Date: Wed, 19 Sep 2012 02:06:55 -0300 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Wil Tan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 05:06:57 -0000 Thanks Wil ! Will review. On 9/19/12 1:37 AM, Wil Tan wrote: > In section 2.4 of draft-lacnic-weirds-restwhois-redirects-00: > > When redirection is used there is always the risk that bogus user- > agents and applications or malicious user can create loops that in > turn may become Denial of Service attacks. > > In our use cases where the registries (e.g. the RIRs) are federated, > how could a malicious user create loops? I would imagine that loops > are most likely caused by administrative errors, e.g. wrong entries in > a registry's database. Am I missing something? > > The document suggests that the server modify the URI prior to > redirecting, but it's less than ideal since it breaks caching. I > realize that there's no ideal solution here, but feel that this is > perhaps something that's best solved using a combination of: > > - knowing the other weirds servers that would redirect to you; and > - if the request needs to be redirected, and the Referer header > indicates that the UA came from another weirds server, refuse to > redirect; and > - we should mandate that UA's send the Referer headers > > Also, in 3.1.1. > > Operators that support the redirect URI MUST never process redirects > that contain a step value greater that their locally set threshold. > > If the query can be satisfied locally without responding with a > redirect, shouldn't the operator just process it even if the step > value exceeds threshold? > > .wil > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From aservin@lacnic.net Wed Sep 19 04:04:53 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA6521F8754 for ; Wed, 19 Sep 2012 04:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RJmaVq75cxD for ; Wed, 19 Sep 2012 04:04:53 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id E8E8421F8753 for ; Wed, 19 Sep 2012 04:04:52 -0700 (PDT) Received: from [IPv6:2800:af:ba30:ea95:4887:817a:e369:268b] (unknown [IPv6:2800:af:ba30:ea95:4887:817a:e369:268b]) by mail.lacnic.net.uy (Postfix) with ESMTP id 548F730846B; Wed, 19 Sep 2012 08:04:46 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Wed, 19 Sep 2012 08:04:43 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wil Tan X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 11:04:53 -0000 Wil=20 Thanks for the comments. On 19 Sep 2012, at 01:37, Wil Tan wrote: > In section 2.4 of draft-lacnic-weirds-restwhois-redirects-00: >=20 > When redirection is used there is always the risk that bogus user- > agents and applications or malicious user can create loops that in > turn may become Denial of Service attacks. >=20 > In our use cases where the registries (e.g. the RIRs) are federated, > how could a malicious user create loops? I would imagine that loops > are most likely caused by administrative errors, e.g. wrong entries in > a registry's database. Am I missing something? >=20 Yes, basically it is because administrative errors pointing to = wrong information. In name spaces there could be some bad cases, imagine that = registrar X says that example.com is register in Y, then Y said that is = W, and then W says that is X. Because is coming from W now, X has no = idea that it was the original query > The document suggests that the server modify the URI prior to > redirecting, but it's less than ideal since it breaks caching. I > realize that there's no ideal solution here, but feel that this is > perhaps something that's best solved using a combination of: >=20 > - knowing the other weirds servers that would redirect to you; and That is very complicated, there could be tons. For RIRs could be = easy but for names I do not think it is possible. > - if the request needs to be redirected, and the Referer header > indicates that the UA came from another weirds server, refuse to > redirect; and Well, then that is basically forbid redirection, isn't it? > - we should mandate that UA's send the Referer headers That is ok, it help to identify simple redirection from A to B, = but it does not help with the above case of multiple redirection.=20 >=20 > Also, in 3.1.1. >=20 > Operators that support the redirect URI MUST never process redirects > that contain a step value greater that their locally set threshold. >=20 > If the query can be satisfied locally without responding with a > redirect, shouldn't the operator just process it even if the step > value exceeds threshold? Well, perhaps it is language there. We meant to generate another = redirection. What about: "Operators that support the redirect URI MUST never create a new = redirect that contain a step value greater that their locally set threshold. = However=20 if the Operator has an authoritative response to the agent it MUST = respond regardless to the threshold value." Regards, as >=20 > .wil > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From wil@cloudregistry.net Wed Sep 19 04:43:36 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD76921F860E for ; Wed, 19 Sep 2012 04:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g850+8JU7Ev8 for ; Wed, 19 Sep 2012 04:43:34 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABA8321F84D6 for ; Wed, 19 Sep 2012 04:43:34 -0700 (PDT) Received: by qcac10 with SMTP id c10so818345qca.31 for ; Wed, 19 Sep 2012 04:43:28 -0700 (PDT) X-Google-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:x-gm-message-state; bh=pQHE6XtQ1s4i8CKiROY+0E5R18YgymB7iZ+CZPFThcM=; b=QJcbjJBfxRlfVnmUS3p0EgrlWjuPIC0/BrfmB7cKxrhGHDuLleFFgs83uMX73nr/a0 J8bZzM7b5XLyb+pyP2agqaSqb+YhugtZTyDyh1STUxK6EIDxejvXg87wLJZ6zhy2/vCf FgFD7E9D7FSO+85DtVq5gXvx4g+stmHtS1w6Ft+Ne18gHxEE3wTKQCf9a0NQPiuJ47G+ BkKOvOYspDurojGRxLHsEmsi3KhioEQQXZeflHTsVi1flPW7WDxiCgFk9bj/iNyYkV/L Ftj8BvBkHyLgJKDi8SerZUB1t1mK54MHi8+7R51shUPzqI2AuDxT/Njba3gVFIvImbhU YAOg== Received: by 10.224.181.205 with SMTP id bz13mr5324089qab.76.1348055008686; Wed, 19 Sep 2012 04:43:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.112 with HTTP; Wed, 19 Sep 2012 04:42:48 -0700 (PDT) In-Reply-To: References: From: Wil Tan Date: Wed, 19 Sep 2012 21:42:48 +1000 Message-ID: To: Arturo Servin Content-Type: multipart/alternative; boundary=20cf303b40f3ee332d04ca0c8361 X-Gm-Message-State: ALoCoQk3cV0LSZcXX4aKcEPYjMLLGMJhscyPIxBBTtsplChRHDA9OQqye+wsHXX0upjY4OqYmx3C Cc: weirds@ietf.org Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 11:43:36 -0000 --20cf303b40f3ee332d04ca0c8361 Content-Type: text/plain; charset=UTF-8 Hi Arturo, On Wed, Sep 19, 2012 at 9:04 PM, Arturo Servin wrote: > On 19 Sep 2012, at 01:37, Wil Tan wrote: > > > In section 2.4 of draft-lacnic-weirds-restwhois-redirects-00: > > > > When redirection is used there is always the risk that bogus user- > > agents and applications or malicious user can create loops that in > > turn may become Denial of Service attacks. > > > > In our use cases where the registries (e.g. the RIRs) are federated, > > how could a malicious user create loops? I would imagine that loops > > are most likely caused by administrative errors, e.g. wrong entries in > > a registry's database. Am I missing something? > > > > Yes, basically it is because administrative errors pointing to > wrong information. > > In name spaces there could be some bad cases, imagine that > registrar X says that example.com is register in Y, then Y said that is > W, and then W says that is X. Because is coming from W now, X has no idea > that it was the original query > > I can't really see the name registries doing redirects the way that the RIRs do. There are too many TLDs to begin with, and more coming. The only two use cases I can think of in the name registries are: 1. thin registries like COM/NET who refer to the authoritative server (operated by a registrar). In that case, though, the registry is still authoritative for part of the data (like who the registrar of record is, creation/expiry dates, etc. - all except contacts) so it would still return a full response, including a referral URL to another server. That is, it won't be doing a 301 redirect. 2. in a TLD with multiple second level domains that are administratively separated from the top level, e.g. ZA, and if there isn't a way for clients to bootstrap the WEIRDS server for the second level namespaces, perhaps a query for xyz.co.za to the top level .za WEIRDS server could result in a redirect to the .co.za WEIRDS server. In this case, though, it'd be terribly inefficient if every single query results in a redirect. > > The document suggests that the server modify the URI prior to > > redirecting, but it's less than ideal since it breaks caching. I > > realize that there's no ideal solution here, but feel that this is > > perhaps something that's best solved using a combination of: > > > > - knowing the other weirds servers that would redirect to you; and > > That is very complicated, there could be tons. For RIRs could be > easy but for names I do not think it is possible. > > Right, but as I said above, I doubt it'd be very useful for names, unless I'm missing something. > - if the request needs to be redirected, and the Referer header > > indicates that the UA came from another weirds server, refuse to > > redirect; and > > Well, then that is basically forbid redirection, isn't it? > > One level of redirect is allowed in this case. If the query had no Referer header, or one that isn't identified as a WEIRDS server, a redirection would occur. In other words, the premise is that, if a query was redirected to me, but I'm not authoritative for the object, then the previous server that you asked either got it wrong, or wasn't specific enough. > > - we should mandate that UA's send the Referer headers > > That is ok, it help to identify simple redirection from A to B, > but it does not help with the above case of multiple redirection. > > > > > Also, in 3.1.1. > > > > Operators that support the redirect URI MUST never process redirects > > that contain a step value greater that their locally set threshold. > > > > If the query can be satisfied locally without responding with a > > redirect, shouldn't the operator just process it even if the step > > value exceeds threshold? > > Well, perhaps it is language there. We meant to generate another > redirection. What about: > > "Operators that support the redirect URI MUST never create a new redirect > that contain a step value greater that their locally set threshold. > However > if the Operator has an authoritative response to the agent it MUST > respond > regardless to the threshold value." > > Works for me :) .wil --20cf303b40f3ee332d04ca0c8361 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Arturo,

On Wed, Sep 19, 2012 at 9:04 P= M, Arturo Servin <aservin@lacnic.net> wrote:
On 19 Sep 2012, at 01:37, Wil Tan wrote:

> In section 2.4 of draft-lacnic-weirds-restwhois-redirects-00:
>
> =C2=A0 When redirection is used there is always the risk that bogus us= er-
> =C2=A0 agents and applications or malicious user can create loops that= in
> =C2=A0 turn may become Denial of Service attacks.
>
> In our use cases where the registries (e.g. the RIRs) are federated, > how could a malicious user create loops? I would imagine that loops > are most likely caused by administrative errors, e.g. wrong entries in=
> a registry's database. Am I missing something?
>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes, basically it is because administrati= ve errors pointing to wrong information.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In name spaces there could be some bad cases, i= magine that registrar X says that example.com is register in Y, then Y said that is W, and then W= says that is X. Because is coming from W now, X has no idea that it was th= e original query


I can't re= ally see the name registries doing redirects the way that the RIRs do. Ther= e are too many TLDs to begin with, and more coming. The only two use cases = I can think of in the name registries are:

1. thin registries like COM/NET who refer to the author= itative server (operated by a registrar). In that case, though, the registr= y is still authoritative for part of the data (like who the registrar of re= cord is, creation/expiry dates, etc. - all except contacts) so it would sti= ll return a full response, including a referral URL to another server. That= is, it won't be doing a 301 redirect.

2. in a TLD with multiple second level domains that are= administratively separated from the top level, e.g. ZA, and if there isn&#= 39;t a way for clients to bootstrap the WEIRDS server for the second level = namespaces, perhaps a query for xyz.co.za = to the top level .za WEIRDS server could result in a redirect to the .co.za WEIRDS server. In this case, though, it'd= be terribly inefficient if every single query results in a redirect.

=C2=A0
> The document suggests that the server modify the URI prior to
> redirecting, but it's less than ideal since it breaks caching. I > realize that there's no ideal solution here, but feel that this is=
> perhaps something that's best solved using a combination of:
>
> - knowing the other weirds servers that would redirect to you; and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 That is very complicated, there could be = tons. For RIRs could be easy but for names I do not think it is possible.


Right, but as = I said above, I doubt it'd be very useful for names, unless I'm mis= sing something.


> - if the request needs to be redirected, and the Referer header
> indicates that the UA came from another weirds server, refuse to
> redirect; and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Well, then that is basically forbid redir= ection, isn't it?


One level of r= edirect is allowed in this case. If the query had no Referer header, or one= that isn't identified as a WEIRDS server, a redirection would occur. I= n other words, the premise is that, if a query was redirected to me, but I&= #39;m not authoritative for the object, then the previous server that you a= sked either got it wrong, or wasn't specific enough.

=C2=A0
> - we should mandate that UA's send the Referer headers

=C2=A0 =C2=A0 =C2=A0 =C2=A0 That is ok, it help to identify simple re= direction from A to B, but it does not help with the above case of multiple= redirection.

>
> Also, in 3.1.1.
>
> =C2=A0 Operators that support the redirect URI MUST never process redi= rects
> =C2=A0 that contain a step value greater that their locally set thresh= old.
>
> If the query can be satisfied locally without responding with a
> redirect, shouldn't the operator just process it even if the step<= br> > value exceeds threshold?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Well, perhaps it is language there. We me= ant to generate another redirection. What about:

"Operators that support the redirect URI MUST never create a new redir= ect
=C2=A0 that contain a step value greater that their locally set threshold. = However
=C2=A0 if the Operator has an authoritative response to the agent it MUST r= espond
=C2=A0regardless to the threshold value."


Works for me :)

.wil --20cf303b40f3ee332d04ca0c8361-- From aservin@lacnic.net Wed Sep 19 04:52:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F36B21F86E1 for ; Wed, 19 Sep 2012 04:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y31gcsZO4CF2 for ; Wed, 19 Sep 2012 04:52:07 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id B742421F8665 for ; Wed, 19 Sep 2012 04:52:06 -0700 (PDT) Received: from [IPv6:2800:af:ba30:d156:3506:1e4f:2ed3:54dc] (unknown [IPv6:2800:af:ba30:d156:3506:1e4f:2ed3:54dc]) by mail.lacnic.net.uy (Postfix) with ESMTP id CA11C308427; Wed, 19 Sep 2012 08:52:01 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_C0644848-2CB0-4162-BB28-C71CF37D2B01" From: Arturo Servin In-Reply-To: Date: Wed, 19 Sep 2012 08:52:01 -0300 Message-Id: <60F2382A-2B95-4E9C-895F-12145D9468D8@lacnic.net> References: To: Wil Tan X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 11:52:08 -0000 --Apple-Mail=_C0644848-2CB0-4162-BB28-C71CF37D2B01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Wil, If I understand well your proposal is to only allow just one = redirect by using Referer headers, right? Regards, as On 19 Sep 2012, at 08:42, Wil Tan wrote: > Hi Arturo, >=20 > On Wed, Sep 19, 2012 at 9:04 PM, Arturo Servin = wrote: > On 19 Sep 2012, at 01:37, Wil Tan wrote: >=20 > > In section 2.4 of draft-lacnic-weirds-restwhois-redirects-00: > > > > When redirection is used there is always the risk that bogus user- > > agents and applications or malicious user can create loops that in > > turn may become Denial of Service attacks. > > > > In our use cases where the registries (e.g. the RIRs) are federated, > > how could a malicious user create loops? I would imagine that loops > > are most likely caused by administrative errors, e.g. wrong entries = in > > a registry's database. Am I missing something? > > >=20 > Yes, basically it is because administrative errors pointing to = wrong information. >=20 > In name spaces there could be some bad cases, imagine that = registrar X says that example.com is register in Y, then Y said that is = W, and then W says that is X. Because is coming from W now, X has no = idea that it was the original query >=20 >=20 > I can't really see the name registries doing redirects the way that = the RIRs do. There are too many TLDs to begin with, and more coming. The = only two use cases I can think of in the name registries are: >=20 > 1. thin registries like COM/NET who refer to the authoritative server = (operated by a registrar). In that case, though, the registry is still = authoritative for part of the data (like who the registrar of record is, = creation/expiry dates, etc. - all except contacts) so it would still = return a full response, including a referral URL to another server. That = is, it won't be doing a 301 redirect. >=20 > 2. in a TLD with multiple second level domains that are = administratively separated from the top level, e.g. ZA, and if there = isn't a way for clients to bootstrap the WEIRDS server for the second = level namespaces, perhaps a query for xyz.co.za to the top level .za = WEIRDS server could result in a redirect to the .co.za WEIRDS server. In = this case, though, it'd be terribly inefficient if every single query = results in a redirect. >=20 > =20 > > The document suggests that the server modify the URI prior to > > redirecting, but it's less than ideal since it breaks caching. I > > realize that there's no ideal solution here, but feel that this is > > perhaps something that's best solved using a combination of: > > > > - knowing the other weirds servers that would redirect to you; and >=20 > That is very complicated, there could be tons. For RIRs could = be easy but for names I do not think it is possible. >=20 >=20 > Right, but as I said above, I doubt it'd be very useful for names, = unless I'm missing something. >=20 >=20 > > - if the request needs to be redirected, and the Referer header > > indicates that the UA came from another weirds server, refuse to > > redirect; and >=20 > Well, then that is basically forbid redirection, isn't it? >=20 >=20 > One level of redirect is allowed in this case. If the query had no = Referer header, or one that isn't identified as a WEIRDS server, a = redirection would occur. In other words, the premise is that, if a query = was redirected to me, but I'm not authoritative for the object, then the = previous server that you asked either got it wrong, or wasn't specific = enough. >=20 > =20 > > - we should mandate that UA's send the Referer headers >=20 > That is ok, it help to identify simple redirection from A to = B, but it does not help with the above case of multiple redirection. >=20 > > > > Also, in 3.1.1. > > > > Operators that support the redirect URI MUST never process = redirects > > that contain a step value greater that their locally set = threshold. > > > > If the query can be satisfied locally without responding with a > > redirect, shouldn't the operator just process it even if the step > > value exceeds threshold? >=20 > Well, perhaps it is language there. We meant to generate = another redirection. What about: >=20 > "Operators that support the redirect URI MUST never create a new = redirect > that contain a step value greater that their locally set threshold. = However > if the Operator has an authoritative response to the agent it MUST = respond > regardless to the threshold value." >=20 >=20 > Works for me :) >=20 > .wil --Apple-Mail=_C0644848-2CB0-4162-BB28-C71CF37D2B01 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Wil,

If I understand well your proposal is to only allow just one redirect by using Referer headers, right?


Regards,
as

On 19 Sep 2012, at 08:42, Wil Tan wrote:

Hi Arturo,

On Wed, Sep 19, 2012 at 9:04 PM, Arturo Servin <aservin@lacnic.net> wrote:
On 19 Sep 2012, at 01:37, Wil Tan wrote:

> In section 2.4 of draft-lacnic-weirds-restwhois-redirects-00:
>
>   When redirection is used there is always the risk that bogus user-
>   agents and applications or malicious user can create loops that in
>   turn may become Denial of Service attacks.
>
> In our use cases where the registries (e.g. the RIRs) are federated,
> how could a malicious user create loops? I would imagine that loops
> are most likely caused by administrative errors, e.g. wrong entries in
> a registry's database. Am I missing something?
>

        Yes, basically it is because administrative errors pointing to wrong information.

        In name spaces there could be some bad cases, imagine that registrar X says that example.com is register in Y, then Y said that is W, and then W says that is X. Because is coming from W now, X has no idea that it was the original query


I can't really see the name registries doing redirects the way that the RIRs do. There are too many TLDs to begin with, and more coming. The only two use cases I can think of in the name registries are:

1. thin registries like COM/NET who refer to the authoritative server (operated by a registrar). In that case, though, the registry is still authoritative for part of the data (like who the registrar of record is, creation/expiry dates, etc. - all except contacts) so it would still return a full response, including a referral URL to another server. That is, it won't be doing a 301 redirect.

2. in a TLD with multiple second level domains that are administratively separated from the top level, e.g. ZA, and if there isn't a way for clients to bootstrap the WEIRDS server for the second level namespaces, perhaps a query for xyz.co.za to the top level .za WEIRDS server could result in a redirect to the .co.za WEIRDS server. In this case, though, it'd be terribly inefficient if every single query results in a redirect.

 
> The document suggests that the server modify the URI prior to
> redirecting, but it's less than ideal since it breaks caching. I
> realize that there's no ideal solution here, but feel that this is
> perhaps something that's best solved using a combination of:
>
> - knowing the other weirds servers that would redirect to you; and

        That is very complicated, there could be tons. For RIRs could be easy but for names I do not think it is possible.


Right, but as I said above, I doubt it'd be very useful for names, unless I'm missing something.


> - if the request needs to be redirected, and the Referer header
> indicates that the UA came from another weirds server, refuse to
> redirect; and

        Well, then that is basically forbid redirection, isn't it?


One level of redirect is allowed in this case. If the query had no Referer header, or one that isn't identified as a WEIRDS server, a redirection would occur. In other words, the premise is that, if a query was redirected to me, but I'm not authoritative for the object, then the previous server that you asked either got it wrong, or wasn't specific enough.

 
> - we should mandate that UA's send the Referer headers

        That is ok, it help to identify simple redirection from A to B, but it does not help with the above case of multiple redirection.

>
> Also, in 3.1.1.
>
>   Operators that support the redirect URI MUST never process redirects
>   that contain a step value greater that their locally set threshold.
>
> If the query can be satisfied locally without responding with a
> redirect, shouldn't the operator just process it even if the step
> value exceeds threshold?

        Well, perhaps it is language there. We meant to generate another redirection. What about:

"Operators that support the redirect URI MUST never create a new redirect
  that contain a step value greater that their locally set threshold. However
  if the Operator has an authoritative response to the agent it MUST respond
 regardless to the threshold value."


Works for me :)

.wil

--Apple-Mail=_C0644848-2CB0-4162-BB28-C71CF37D2B01-- From wil@cloudregistry.net Wed Sep 19 05:53:27 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0A621F86E1 for ; Wed, 19 Sep 2012 05:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ufkm3UpqyNI5 for ; Wed, 19 Sep 2012 05:53:26 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C75421F85F7 for ; Wed, 19 Sep 2012 05:53:26 -0700 (PDT) Received: by qafi29 with SMTP id i29so3541586qaf.10 for ; Wed, 19 Sep 2012 05:53:26 -0700 (PDT) X-Google-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:x-gm-message-state; bh=G+xNnASUGWSk7+Yb72LPefBxz1g0h9kTJrUxx8fxEcw=; b=WzH/UXBAlCejH/B5k3OSGQNjxX3jwKkiigwl/g2YOQvCfaX6JGQrCQWmEhzntEqeI5 63ERYvdFWztV/QsVLtV+MwgbqKfKAlDOeJ7V4GX7GSKMIj0pqHDxwUKZ1m3M7f4FKxlz xKrH452OWJqAsR2x5ROqIfEsOHn7/7RmDA/v5C2TNaGa+MGgPWbSo9frYOfobCX8Dq2j e0juyZULQMufcCGzNdhAD/8gTNkuyylMSa2CcSy2bFIb5fkmzF6UopE12uPPEKjPvvZe vrONQoHv+leV2El5GRTvA+wWbZdWveCst6Rez/QaouqUp0mo6VBLxa3TqAbBu9Ri2fuC L8zQ== Received: by 10.229.137.139 with SMTP id w11mr1908390qct.113.1348059205778; Wed, 19 Sep 2012 05:53:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.112 with HTTP; Wed, 19 Sep 2012 05:52:45 -0700 (PDT) In-Reply-To: <60F2382A-2B95-4E9C-895F-12145D9468D8@lacnic.net> References: <60F2382A-2B95-4E9C-895F-12145D9468D8@lacnic.net> From: Wil Tan Date: Wed, 19 Sep 2012 22:52:45 +1000 Message-ID: To: Arturo Servin Content-Type: multipart/alternative; boundary=00235452feb418bc0d04ca0d7e47 X-Gm-Message-State: ALoCoQk4O8wo3otjXVRFRoRVdr316JlIT3CidtDNFzqfezO6uzDY9H4hnFZr5qhhwEpifEnDEfWA Cc: weirds@ietf.org Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 12:53:27 -0000 --00235452feb418bc0d04ca0d7e47 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 19, 2012 at 9:52 PM, Arturo Servin wrote: > Wil, > > If I understand well your proposal is to only allow just one redirect by > using Referer headers, right? > > Yes. The drawback I could see is that I suspect most HTTP libraries don't send Referer when following redirects. I just checked Python's urllib and it doesn't. .wil --00235452feb418bc0d04ca0d7e47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 19, 2012 at 9:52 PM, Arturo = Servin <aservin@lacnic.net> wrote:
Wil,

If I understand well your proposal is to only= allow just one redirect by using Referer headers, right?


Yes. The drawback I could see is tha= t I suspect most HTTP libraries don't send Referer when following redir= ects. I just checked Python's urllib and it doesn't.

.wil
--00235452feb418bc0d04ca0d7e47-- From aservin@lacnic.net Wed Sep 19 06:07:24 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E9A21F873E for ; Wed, 19 Sep 2012 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0ZBPKVAxZdy for ; Wed, 19 Sep 2012 06:07:24 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0A621F871A for ; Wed, 19 Sep 2012 06:07:21 -0700 (PDT) Received: from [IPv6:2800:af:ba30:d156:3506:1e4f:2ed3:54dc] (unknown [IPv6:2800:af:ba30:d156:3506:1e4f:2ed3:54dc]) by mail.lacnic.net.uy (Postfix) with ESMTP id 1367230844D; Wed, 19 Sep 2012 10:07:17 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_7C439520-472A-4F1A-BC4E-C9A874DE82A0" From: Arturo Servin In-Reply-To: Date: Wed, 19 Sep 2012 10:07:15 -0300 Message-Id: <3812081F-B276-4294-AED1-96D36FE9B078@lacnic.net> References: <60F2382A-2B95-4E9C-895F-12145D9468D8@lacnic.net> To: Wil Tan X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 13:07:24 -0000 --Apple-Mail=_7C439520-472A-4F1A-BC4E-C9A874DE82A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In fact, the drawback is that one redirect is not enough for = RIRs and perhaps for some corner cases in names. Example RIR: User queries IANA for space X, IANA redirects to ARIN but it = does not have the space because it was issued to APNIC because a = transfer.=20 Example names: User queries .example for example.com. .Example does not about = .com and it redirects to IANA. IANA does not have .com and shouldt = redirect to Verisign. One solution could be instead of doing a second redirect (or = even a first one) to return a "redirect object" which in turns would = have the information to query the next WEIRDS server: { "redirect-server": "weirds.example.com", "redirected-by": "weirds.example", "redirect-times": 2 } =09 Or something like that. Regards, as On 19 Sep 2012, at 09:52, Wil Tan wrote: >=20 >=20 > On Wed, Sep 19, 2012 at 9:52 PM, Arturo Servin = wrote: > Wil, >=20 > If I understand well your proposal is to only allow just one = redirect by using Referer headers, right? >=20 >=20 > Yes. The drawback I could see is that I suspect most HTTP libraries = don't send Referer when following redirects. I just checked Python's = urllib and it doesn't. >=20 > .wil --Apple-Mail=_7C439520-472A-4F1A-BC4E-C9A874DE82A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In fact, the drawback is that one = redirect is not enough for RIRs and perhaps for some corner cases in = names.

Example = RIR:

User queries IANA for space X, = IANA redirects to ARIN but it does not have the space because it was = issued to APNIC because a transfer. 

Example = names:

User queries .example for example.com. .Example does not about = .com and it redirects to IANA. IANA does not have .com and shouldt = redirect to Verisign.

One = solution could be instead of doing a second redirect (or even a first = one) to return a "redirect object" which in turns would have the = information to query the next WEIRDS = server:

{
= "redirect-server": "weirds.example.com",
= "redirected-by": "weirds.example",
= "redirect-times": 2
}
=
Or something like = that.

Regards,
as

On= 19 Sep 2012, at 09:52, Wil Tan wrote:



On Wed, Sep 19, 2012 at 9:52 PM, Arturo Servin = <aservin@lacnic.net> = wrote:
Wil,

If I understand well your = proposal is to only allow just one redirect by using Referer headers, = right?


Yes. The drawback I could see is = that I suspect most HTTP libraries don't send Referer when following = redirects. I just checked Python's urllib and it doesn't.

.wil

= --Apple-Mail=_7C439520-472A-4F1A-BC4E-C9A874DE82A0-- From internet-drafts@ietf.org Wed Sep 19 06:44:29 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DC621F86F6; Wed, 19 Sep 2012 06:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv4iitW1b-UC; Wed, 19 Sep 2012 06:44:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BE621F86F0; Wed, 19 Sep 2012 06:44:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919134429.6184.5496.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 06:44:29 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 13:44:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : JSON Responses for the Registy Data Access Protocol (RDA= P) Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-json-response-00.txt Pages : 37 Date : 2012-09-19 Abstract: This document describes responses in the JSON format to the Registry Data Access Protocol (RDAP) queries described in draft-ietf-weirds-rdap-query. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-json-response There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-json-response-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Sep 19 06:50:57 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F304221F86F0; Wed, 19 Sep 2012 06:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjVwtskF-lcn; Wed, 19 Sep 2012 06:50:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E70321F8618; Wed, 19 Sep 2012 06:50:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919135050.6188.3833.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 06:50:50 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 13:50:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Unified Registration Data Access Protocol Query Format Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-00.txt Pages : 10 Date : 2012-09-19 Abstract: This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shollenbeck@verisign.com Wed Sep 19 06:59:36 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D151B21F846E for ; Wed, 19 Sep 2012 06:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.364 X-Spam-Level: X-Spam-Status: No, score=-6.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUl3WRB0hVH7 for ; Wed, 19 Sep 2012 06:59:36 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 15DF321F8467 for ; Wed, 19 Sep 2012 06:59:35 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUFnPxq7zYE5aQbkcMJ5hEp00CzMRsect@postini.com; Wed, 19 Sep 2012 06:59:36 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q8JDxX7J001344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 09:59:34 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Wed, 19 Sep 2012 09:59:04 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Submitting documents Thread-Index: AQHNlc8vHJE5rN1R20KYBgIPryWafpeRshfg Date: Wed, 19 Sep 2012 13:59:32 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D68A623@BRN1WNEXMBX02.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 Subject: Re: [weirds] Submitting documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 13:59:36 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Murray S. Kucherawy > Sent: Tuesday, September 18, 2012 2:55 PM > To: weirds@ietf.org > Subject: [weirds] Submitting documents >=20 > Thanks to those of you who worked behind the scenes on getting document > proposals together. >=20 > Document authors/editors are invited to submit new working group > documents as follows: >=20 > 1) draft-designteam-weirds-using-http becomes draft-ietf-weirds-using- > http (Byron, Ning, Andy) >=20 > 2) draft-hollenbeck-weirds-rdap-sec becomes draft-ietf-weirds-rdap-sec > (Scott, [see below]) >=20 > 3) draft-hollenbeck-weirds-unified-rdap-query becomes draft-ietf- > weirds-rdap-query (Scott, Andy) >=20 > 4) draft-newton-weirds-unified-json-response becomes draft-ietf-weirds- > json-response (Scott, Andy) >=20 > 5) draft-lacnic-weirds-restwhois-redirects becomes draft-ietf-weirds- > rdap-redirects ([see below]) >=20 > For (2), Ning has volunteered to assist Scott. Ning, please email > Scott and confirm your interest and availability to do that work, and > then one of you can submit the document. I am also talking to the > Security Area ADs to see about getting some independent security help > on that topic. >=20 > For (5), I'd like to see a names person in the author list, and > preferably a shorter list. If you folks can work that out, you're > welcome to submit as well. >=20 > Thank you again. Let's get busy! (3) and (4) have been submitted. I'll work with Ning on (2). Scott From superuser@gmail.com Wed Sep 19 07:00:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B809821F872D for ; Wed, 19 Sep 2012 07:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ+yz8r0gVmJ for ; Wed, 19 Sep 2012 07:00:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E94B521F8723 for ; Wed, 19 Sep 2012 07:00:42 -0700 (PDT) Received: by lboj14 with SMTP id j14so550805lbo.31 for ; Wed, 19 Sep 2012 07:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Yk1KmVTK9Piu8DS9xm/0OONhWs63A9FBk2KEAfmDoyY=; b=J7mHRjfEiE2y8oiKJPSd6gP35280k0rIg+Kz1amLtgFj4pRSwOAGX61p0qIBoniNKp uNiuWzmmsBLFiwx4ak6kJC9UAwbul/fR60+L/HBn5aTPj9JqkelG/dZJ8SqX1qfuw1aQ r4UDQ9XuwOXrrikqEh6kp5rVA3ifichQ9syokx/jS1wW+4vaut9OZR922Eg8BDExVbJo DSP88cxYf9F5xAeX7oBJsckTFy7LVkLa2IklMMD1Ao5vosq7y/EXm7AkX84u2l4KnlM4 PpjF00khSx/qmjnE+PpHSlGRvU2iKiMGeT+tee5KSKkpIZkfZq8aiEqHBCsiCAn0kXlO 3VdA== MIME-Version: 1.0 Received: by 10.112.84.101 with SMTP id x5mr1073135lby.28.1348063241865; Wed, 19 Sep 2012 07:00:41 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 19 Sep 2012 07:00:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 07:00:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: weirds@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [weirds] Submitting documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 14:00:43 -0000 On Tue, Sep 18, 2012 at 11:55 AM, Murray S. Kucherawy wrote: > Thanks to those of you who worked behind the scenes on getting > document proposals together. > > Document authors/editors are invited to submit new working group > documents as follows: >[...] As you can see, these are beginning to appear, and the WG can now begin to develop them. A quick reminder: October 15 is the cutoff for submitting -00 drafts before the Atlanta meeting, and October 22 is the cutoff date for all draft submissions prior to the meeting. We then enter a quiet period regarding document updates until after the meeting has started. -MSK From wil@cloudregistry.net Wed Sep 19 07:04:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2D921F870B for ; Wed, 19 Sep 2012 07:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXcHm9G1zNdo for ; Wed, 19 Sep 2012 07:04:04 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2B321F85C0 for ; Wed, 19 Sep 2012 07:04:04 -0700 (PDT) Received: by qcac10 with SMTP id c10so950021qca.31 for ; Wed, 19 Sep 2012 07:04:03 -0700 (PDT) X-Google-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:x-gm-message-state; bh=bXVI3dTDLakMT4U+XwDfBLZMMBfbhSGIxxAiFSk/fjQ=; b=XazeklwtOIijnsvOvnUe/JHh3rCSuazi/MOHsPVDKTxEpyOHHQHW/BfrOwqF7pzFiK 5x9klbz6zP6NIWs9zqU7exnUa+izqvWJysu+S2xCpCYaN8zEWOmQoCECt65Ht82Rxl6h fR5Vc3uW1sw6rKgiuWnTrYo4Nh1T0se+scHYIazcSZFhof9rDIszvkEbt45MnffCqV27 Em4lDnMij9hpFoDAEX+iftUj/YBtPUUhv1eNe0jDft+vvIwDJclDixxEUgwfq7EADWhr l2s+L3jKGwCI3WSBdpKvYoAITvNpJ8H/1wxSXLNm7y8ilRylFC/i2pEP5iC9Y/HT2TQD wGow== Received: by 10.224.222.209 with SMTP id ih17mr7282137qab.82.1348063443553; Wed, 19 Sep 2012 07:04:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.112 with HTTP; Wed, 19 Sep 2012 07:03:23 -0700 (PDT) In-Reply-To: <3812081F-B276-4294-AED1-96D36FE9B078@lacnic.net> References: <60F2382A-2B95-4E9C-895F-12145D9468D8@lacnic.net> <3812081F-B276-4294-AED1-96D36FE9B078@lacnic.net> From: Wil Tan Date: Thu, 20 Sep 2012 00:03:23 +1000 Message-ID: To: Arturo Servin Content-Type: multipart/alternative; boundary=20cf3074b4e0b00c2604ca0e7ab7 X-Gm-Message-State: ALoCoQlSGxY+eSuuke1zd2gc3AjURRPgWyIXvZTPgt3HOxwxKOVbuI85P4tEB2eAuaHOr052Yd2d Cc: weirds@ietf.org Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 14:04:05 -0000 --20cf3074b4e0b00c2604ca0e7ab7 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 19, 2012 at 11:07 PM, Arturo Servin wrote: > > In fact, the drawback is that one redirect is not enough for RIRs and > perhaps for some corner cases in names. > > Example RIR: > > User queries IANA for space X, IANA redirects to ARIN but it does not have > the space because it was issued to APNIC because a transfer. > > Would there be any circumstances where ARIN would want to return more information about a transferred block, such as the size of the block, or date transferred? If it does, then perhaps we'll need to return a "redirect object" as you proposed below anyway, because in a 301 you can't convey anything much other than the target URL. > Example names: > > User queries .example for example.com. .Example does not about .com and > it redirects to IANA. IANA does not have .com and shouldt redirect to > Verisign. > > I think in the case of names, this sort of redirection wouldn't be supported by registries because it's *should* be quite straightforward for a client to know that it's querying the wrong server (by comparing the TLD). Also, I doubt IANA would run a generic redirector service. That's just my view, and it'd be great if others can weigh in. > One solution could be instead of doing a second redirect (or even a first > one) to return a "redirect object" which in turns would have the > information to query the next WEIRDS server: > > { > "redirect-server": "weirds.example.com", > "redirected-by": "weirds.example", > "redirect-times": 2 > } > Or something like that. > > I suppose that could work, at the expense of more complexity for clients to support redirects. What we gain is cacheability. .wil --20cf3074b4e0b00c2604ca0e7ab7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 19, 2012 at 11:07 PM, Arturo Ser= vin <aservin@lacnic.net> wrote:

In fact, the drawback is that one redirect is not= enough for RIRs and perhaps for some corner cases in names.

Example RIR:
<= div>
User querie= s IANA for space X, IANA redirects to ARIN but it does not have the space b= ecause it was issued to APNIC because a transfer.=C2=A0


Would there be any ci= rcumstances where ARIN would want to return more information about a transf= erred block, such as the size of the block, or date transferred? If it does= , then perhaps we'll need to return a "redirect object" as yo= u proposed below anyway, because in a 301 you can't convey anything muc= h other than the target URL.


=C2=A0
Example names:

User queri= es .example for example.co= m. .Example does not about .com and it redirects to IANA. IANA does not= have .com and shouldt redirect to Verisign.


I think in the case o= f names, this sort of redirection wouldn't be supported by registries b= ecause it's *should* be quite straightforward for a client to know that= it's querying the wrong server (by comparing the TLD). Also, I doubt I= ANA would run a generic redirector service. That's just my view, and it= 'd be great if others can weigh in.

=C2=A0
One solution could be instead of doing a second redirect (or ev= en a first one) to return a "redirect object" which in turns woul= d have the information to query the next WEIRDS server:

{
"redirect-server": "weirds.example.com",
"redirected-by": "weirds.example= ",
"redirect-times"= ;: 2
}
Or something like that= .


I suppose that could = work, at the expense of more complexity for clients to support redirects. W= hat we gain is cacheability.

.wil=C2=A0
--20cf3074b4e0b00c2604ca0e7ab7-- From superuser@gmail.com Wed Sep 19 07:09:20 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC85321F861D for ; Wed, 19 Sep 2012 07:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MGVhqrEvEZ7 for ; Wed, 19 Sep 2012 07:09:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C383121F8610 for ; Wed, 19 Sep 2012 07:09:19 -0700 (PDT) Received: by lboj14 with SMTP id j14so566624lbo.31 for ; Wed, 19 Sep 2012 07:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5SKFLwvkP1bVLVid8YKQ5IcuDNUYJ8LQ7sWF9YG9V6g=; b=rVz/iZtp/c9pZ8Y7M205b1tCmr7lTAyZfJH2dsCEmGdXB+1yJRJdC5PUqlrNPRelcU kljq+wGtJvyZzs8bsvAlhXrvc8hSTo8HnqsBrU8D6J9p3yiFHfCKyQ/fps15XKq2R7Ci gPXW1jv3vyGfdRv++e+aA5ufbhIwiQ3qV0zijDry0fau9DacRo4QBwQZ4bbETBzWrced qDe6JHPUVthNaJcZDnL4+CrWV79KEN3E5NZfMC7YoVv49tl7iKMXPqw/Q+XP06SVkiBW xeZAez9B4VNRFXU1KMtGgBTzmkEvhkuSmv34gka1OwGaKfZOstvTQxBJlRq7jWnI8BDP bAfw== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr1084238lbo.55.1348063758805; Wed, 19 Sep 2012 07:09:18 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 19 Sep 2012 07:09:18 -0700 (PDT) Date: Wed, 19 Sep 2012 07:09:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: weirds@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [weirds] Requirements document X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 14:09:20 -0000 I haven't heard much in the way of support or demand for a requirements document to be developed/maintained, even if we decide up front that we don't plan to publish it in the end, so I'm going to let draft-kucherawy-weirds-requirements expire. If the WG feels we should keep this up, please say so and we can hopefully identify a different editor. -MSK From andy@arin.net Wed Sep 19 07:17:53 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCE521F8522 for ; Wed, 19 Sep 2012 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNTIRc-cYRHY for ; Wed, 19 Sep 2012 07:17:53 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 21E2221F851E for ; Wed, 19 Sep 2012 07:17:53 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 71A1921368B; Wed, 19 Sep 2012 10:17:52 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 0BAD1213649; Wed, 19 Sep 2012 10:17:52 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 19 Sep 2012 10:17:39 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 10:17:51 -0400 From: Andy Newton To: Wil Tan , Arturo Servin Thread-Topic: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 Thread-Index: AQHNlnGNrn/iOLT7d0iDU/L7VPzHdg== Date: Wed, 19 Sep 2012 14:17:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <38894552DD845247AC1EA60565506FE6@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 14:17:53 -0000 > >User queries IANA for space X, IANA redirects to ARIN but it does not >have the space because it was issued to APNIC because a transfer. I believe at that point ARIN would redirect to APNIC, right? What am I missing? >Would there be any circumstances where ARIN would want to return more >information about a transferred block, such as the size of the block, or >date transferred? If it does, then perhaps we'll need to return a >"redirect object" as you proposed below anyway, > because in a 301 you can't convey anything much other than the target >URL. Not that I like this idea, but I thought HTTP allowed a entity body even for redirects. But I could be wrong. >Also, I doubt IANA would run a generic > redirector service. That's just my view, and it'd be great if others can >weigh in. I believe ICANN could be easily convinced to run such a service. -andy From aservin@lacnic.net Wed Sep 19 07:28:45 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9108821F8639 for ; Wed, 19 Sep 2012 07:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=-1.755, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMJfFMsnPELb for ; Wed, 19 Sep 2012 07:28:44 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF6421F8514 for ; Wed, 19 Sep 2012 07:28:44 -0700 (PDT) Received: from [192.168.1.133] (r186-48-209-86.dialup.adsl.anteldata.net.uy [186.48.209.86]) by mail.lacnic.net.uy (Postfix) with ESMTP id 58920308432; Wed, 19 Sep 2012 11:28:34 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_376A36E3-B279-49A4-A5C7-BA45FA73E9E8" From: Arturo Servin In-Reply-To: Date: Wed, 19 Sep 2012 11:28:33 -0300 Message-Id: References: To: Andy Newton X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 14:28:45 -0000 --Apple-Mail=_376A36E3-B279-49A4-A5C7-BA45FA73E9E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Andy, On 19 Sep 2012, at 11:17, Andy Newton wrote: >>=20 >> User queries IANA for space X, IANA redirects to ARIN but it does not >> have the space because it was issued to APNIC because a transfer. >=20 >=20 > I believe at that point ARIN would redirect to APNIC, right? What am I > missing? Wil is suggesting to do just one redirect. If that were the = case, in the IANA-ARIN-APNIC example you would need 2 redirects. One for = IANA to ARIN and another from ARIN to APNIC. A similar case happens when = you have ReferralServers (I think just ARIN has them at least for now). Regards, as= --Apple-Mail=_376A36E3-B279-49A4-A5C7-BA45FA73E9E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

User queries IANA for space X, IANA = redirects to ARIN but it does not
have the space because it was issued to APNIC because a = transfer.


I believe at that point ARIN would = redirect to APNIC, right? What am = I
missing?

Wil is = suggesting to do just one redirect. If that were the case, in the = IANA-ARIN-APNIC example you would need 2 redirects. One for IANA to ARIN = and another from ARIN to APNIC. A similar case happens when you have = ReferralServers (I think just ARIN has them at least for = now).

Regards,
as
= --Apple-Mail=_376A36E3-B279-49A4-A5C7-BA45FA73E9E8-- From andy@arin.net Wed Sep 19 07:50:40 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF721F86F0 for ; Wed, 19 Sep 2012 07:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+RVdlEP1EA2 for ; Wed, 19 Sep 2012 07:50:40 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 4C97821F8653 for ; Wed, 19 Sep 2012 07:50:40 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id B2F97213692; Wed, 19 Sep 2012 10:50:39 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 6638721366F; Wed, 19 Sep 2012 10:50:39 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 19 Sep 2012 10:50:19 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 10:50:32 -0400 From: Andy Newton To: Arturo Servin Thread-Topic: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 Thread-Index: AQHNlnGNrn/iOLT7d0iDU/L7VPzHdpeR/EKA///DE4A= Date: Wed, 19 Sep 2012 14:50:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <6AFF3976BB767741A6C280483888CFFD@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 14:50:40 -0000 > >Wil is suggesting to do just one redirect. If that were the case, in the >IANA-ARIN-APNIC example you would need 2 redirects. One for IANA to ARIN >and another from ARIN to APNIC. A similar case > happens when you have ReferralServers (I think just ARIN has them at >least for now). So one redirect is ok, but two redirects is not? I do not understand the concern. -andy From shollenbeck@verisign.com Wed Sep 19 08:10:29 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24B921F8723 for ; Wed, 19 Sep 2012 08:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG079-DTnPxI for ; Wed, 19 Sep 2012 08:10:29 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id E3A9021F86AF for ; Wed, 19 Sep 2012 08:10:27 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUFngYy/Z7YYEgSahr6vM12h1L39cu5UD@postini.com; Wed, 19 Sep 2012 08:10:28 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q8JFANY5003944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 11:10:23 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Wed, 19 Sep 2012 11:09:54 -0400 From: "Hollenbeck, Scott" To: Wil Tan Thread-Topic: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 Thread-Index: AQHNlm+kl1QwvSIc7UCyHpbMLSW3oZeRxLmA Date: Wed, 19 Sep 2012 15:10:22 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D68A77B@BRN1WNEXMBX02.vcorp.ad.vrsn.com> References: <60F2382A-2B95-4E9C-895F-12145D9468D8@lacnic.net> <3812081F-B276-4294-AED1-96D36FE9B078@lacnic.net> 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_831693C2CDA2E849A7D7A712B24E257F0D68A77BBRN1WNEXMBX02vc_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 15:10:29 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F0D68A77BBRN1WNEXMBX02vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogd2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp3ZWlyZHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFdpbCBUYW4NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDE5 LCAyMDEyIDEwOjAzIEFNDQpUbzogQXJ0dXJvIFNlcnZpbg0KQ2M6IHdlaXJkc0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFt3ZWlyZHNdIFJlZGlyZWN0IExvb3AgRGV0ZWN0aW9uIC0gY29tbWVudHMg b24gZHJhZnQtbGFjbmljLXdlaXJkcy1yZXN0d2hvaXMtcmVkaXJlY3RzLTAwDQoNCg0KT24gV2Vk LCBTZXAgMTksIDIwMTIgYXQgMTE6MDcgUE0sIEFydHVybyBTZXJ2aW4gPGFzZXJ2aW5AbGFjbmlj Lm5ldDxtYWlsdG86YXNlcnZpbkBsYWNuaWMubmV0Pj4gd3JvdGU6DQoNCkluIGZhY3QsIHRoZSBk cmF3YmFjayBpcyB0aGF0IG9uZSByZWRpcmVjdCBpcyBub3QgZW5vdWdoIGZvciBSSVJzIGFuZCBw ZXJoYXBzIGZvciBzb21lIGNvcm5lciBjYXNlcyBpbiBuYW1lcy4NCg0KRXhhbXBsZSBSSVI6DQoN ClVzZXIgcXVlcmllcyBJQU5BIGZvciBzcGFjZSBYLCBJQU5BIHJlZGlyZWN0cyB0byBBUklOIGJ1 dCBpdCBkb2VzIG5vdCBoYXZlIHRoZSBzcGFjZSBiZWNhdXNlIGl0IHdhcyBpc3N1ZWQgdG8gQVBO SUMgYmVjYXVzZSBhIHRyYW5zZmVyLg0KDQoNCldvdWxkIHRoZXJlIGJlIGFueSBjaXJjdW1zdGFu Y2VzIHdoZXJlIEFSSU4gd291bGQgd2FudCB0byByZXR1cm4gbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCBhIHRyYW5zZmVycmVkIGJsb2NrLCBzdWNoIGFzIHRoZSBzaXplIG9mIHRoZSBibG9jaywgb3Ig ZGF0ZSB0cmFuc2ZlcnJlZD8gSWYgaXQgZG9lcywgdGhlbiBwZXJoYXBzIHdlJ2xsIG5lZWQgdG8g cmV0dXJuIGEgInJlZGlyZWN0IG9iamVjdCIgYXMgeW91IHByb3Bvc2VkIGJlbG93IGFueXdheSwg YmVjYXVzZSBpbiBhIDMwMSB5b3UgY2FuJ3QgY29udmV5IGFueXRoaW5nIG11Y2ggb3RoZXIgdGhh biB0aGUgdGFyZ2V0IFVSTC4NCg0KDQoNCkV4YW1wbGUgbmFtZXM6DQoNClVzZXIgcXVlcmllcyAu ZXhhbXBsZSBmb3IgZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29tPi4gLkV4YW1wbGUgZG9l cyBub3QgYWJvdXQgLmNvbSBhbmQgaXQgcmVkaXJlY3RzIHRvIElBTkEuIElBTkEgZG9lcyBub3Qg aGF2ZSAuY29tIGFuZCBzaG91bGR0IHJlZGlyZWN0IHRvIFZlcmlzaWduLg0KDQoNCkkgdGhpbmsg aW4gdGhlIGNhc2Ugb2YgbmFtZXMsIHRoaXMgc29ydCBvZiByZWRpcmVjdGlvbiB3b3VsZG4ndCBi ZSBzdXBwb3J0ZWQgYnkgcmVnaXN0cmllcyBiZWNhdXNlIGl0J3MgKnNob3VsZCogYmUgcXVpdGUg c3RyYWlnaHRmb3J3YXJkIGZvciBhIGNsaWVudCB0byBrbm93IHRoYXQgaXQncyBxdWVyeWluZyB0 aGUgd3Jvbmcgc2VydmVyIChieSBjb21wYXJpbmcgdGhlIFRMRCkuIEFsc28sIEkgZG91YnQgSUFO QSB3b3VsZCBydW4gYSBnZW5lcmljIHJlZGlyZWN0b3Igc2VydmljZS4gVGhhdCdzIGp1c3QgbXkg dmlldywgYW5kIGl0J2QgYmUgZ3JlYXQgaWYgb3RoZXJzIGNhbiB3ZWlnaCBpbi4NCg0KSUFOQSBt aWdodCBub3QsIGJ1dCBvdGhlcnMgbWlnaHQgKGFuZCBwcm9iYWJseSB3aWxsKS4NCg0KU2NvdHQN Cg== --_000_831693C2CDA2E849A7D7A712B24E257F0D68A77BBRN1WNEXMBX02vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IHdlaXJkcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86d2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPldpbCBUYW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBTZXB0ZW1iZXIgMTksIDIwMTIgMTA6MDMgQU08YnI+DQo8Yj5Ubzo8L2I+IEFydHVybyBTZXJ2 aW48YnI+DQo8Yj5DYzo8L2I+IHdlaXJkc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3dlaXJkc10gUmVkaXJlY3QgTG9vcCBEZXRlY3Rpb24gLSBjb21tZW50cyBvbiBkcmFmdC1s YWNuaWMtd2VpcmRzLXJlc3R3aG9pcy1yZWRpcmVjdHMtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIFNlcCAxOSwgMjAxMiBhdCAxMTowNyBQTSwgQXJ0 dXJvIFNlcnZpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFzZXJ2aW5AbGFjbmljLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmFzZXJ2aW5AbGFjbmljLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGZhY3QsIHRoZSBkcmF3 YmFjayBpcyB0aGF0IG9uZSByZWRpcmVjdCBpcyBub3QgZW5vdWdoIGZvciBSSVJzIGFuZCBwZXJo YXBzIGZvciBzb21lIGNvcm5lciBjYXNlcyBpbiBuYW1lcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXhhbXBsZSBSSVI6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVzZXIgcXVlcmllcyBJ QU5BIGZvciBzcGFjZSBYLCBJQU5BIHJlZGlyZWN0cyB0byBBUklOIGJ1dCBpdCBkb2VzIG5vdCBo YXZlIHRoZSBzcGFjZSBiZWNhdXNlIGl0IHdhcyBpc3N1ZWQgdG8gQVBOSUMgYmVjYXVzZSBhIHRy YW5zZmVyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgdGhlcmUgYmUgYW55IGNpcmN1bXN0YW5jZXMgd2hl cmUgQVJJTiB3b3VsZCB3YW50IHRvIHJldHVybiBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGEgdHJh bnNmZXJyZWQgYmxvY2ssIHN1Y2ggYXMgdGhlIHNpemUgb2YgdGhlIGJsb2NrLCBvciBkYXRlIHRy YW5zZmVycmVkPyBJZiBpdCBkb2VzLCB0aGVuIHBlcmhhcHMgd2UnbGwgbmVlZCB0byByZXR1cm4g YSAmcXVvdDtyZWRpcmVjdCBvYmplY3QmcXVvdDsgYXMgeW91IHByb3Bvc2VkDQogYmVsb3cgYW55 d2F5LCBiZWNhdXNlIGluIGEgMzAxIHlvdSBjYW4ndCBjb252ZXkgYW55dGhpbmcgbXVjaCBvdGhl ciB0aGFuIHRoZSB0YXJnZXQgVVJMLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FeGFtcGxlIG5hbWVz OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5V c2VyIHF1ZXJpZXMgLmV4YW1wbGUgZm9yIDxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPg0KZXhhbXBsZS5jb208L2E+LiAuRXhhbXBsZSBkb2VzIG5vdCBhYm91dCAu Y29tIGFuZCBpdCByZWRpcmVjdHMgdG8gSUFOQS4gSUFOQSBkb2VzIG5vdCBoYXZlIC5jb20gYW5k IHNob3VsZHQgcmVkaXJlY3QgdG8gVmVyaXNpZ24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRo aW5rIGluIHRoZSBjYXNlIG9mIG5hbWVzLCB0aGlzIHNvcnQgb2YgcmVkaXJlY3Rpb24gd291bGRu J3QgYmUgc3VwcG9ydGVkIGJ5IHJlZ2lzdHJpZXMgYmVjYXVzZSBpdCdzICpzaG91bGQqIGJlIHF1 aXRlIHN0cmFpZ2h0Zm9yd2FyZCBmb3IgYSBjbGllbnQgdG8ga25vdyB0aGF0IGl0J3MgcXVlcnlp bmcgdGhlIHdyb25nIHNlcnZlciAoYnkgY29tcGFyaW5nIHRoZSBUTEQpLiBBbHNvLCBJIGRvdWJ0 IElBTkENCiB3b3VsZCBydW4gYSBnZW5lcmljIHJlZGlyZWN0b3Igc2VydmljZS4gVGhhdCdzIGp1 c3QgbXkgdmlldywgYW5kIGl0J2QgYmUgZ3JlYXQgaWYgb3RoZXJzIGNhbiB3ZWlnaCBpbi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SUFOQSBtaWdodCBub3QsIGJ1dCBvdGhlcnMgbWlnaHQgKGFuZCBwcm9iYWJseSB3aWxsKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlNjb3R0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_831693C2CDA2E849A7D7A712B24E257F0D68A77BBRN1WNEXMBX02vc_-- From wil@cloudregistry.net Wed Sep 19 08:10:47 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1484421F870A for ; Wed, 19 Sep 2012 08:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12-drCgnMUVs for ; Wed, 19 Sep 2012 08:10:42 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB53821F869A for ; Wed, 19 Sep 2012 08:10:41 -0700 (PDT) Received: by qcac10 with SMTP id c10so1019554qca.31 for ; Wed, 19 Sep 2012 08:10:40 -0700 (PDT) X-Google-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:x-gm-message-state; bh=mrLTB5kLCcp/pKz2Nw7HeB8qT7kmluZC9CId4ruc5AA=; b=ozutrHaIL0eT7xX7Vjg7DnikS6+g5s4RqHPUEW7ZcoKvNsoT+Fhk80cJbbz+dkit55 6DmB6J6HJMK2XcEdePlaqHCPSy24jvguamuZnCK6bCojlotfYviWLpxyKp36C5eYL10t hbWCehVxEvWX5BDGZQ1GO8yoClKpe5hiAJOcZX0qT/RBlvODdSgqboIosQLw67Nz2qiB VpNgaMC9VYUZi6bQI4nlOWKeWBjwpqzZyTrA7f8R4Tw+4778jJgwACzyxEM0t2m8Gy2q 1y87Jiemw1RB1mY65KVLOOwU7G88Cj5+G7ezvflY/ybdHZXx7LPtHV2T59R98YIo3K6Y v6lg== Received: by 10.224.39.195 with SMTP id h3mr7855634qae.39.1348067440053; Wed, 19 Sep 2012 08:10:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.112 with HTTP; Wed, 19 Sep 2012 08:09:59 -0700 (PDT) In-Reply-To: References: From: Wil Tan Date: Thu, 20 Sep 2012 01:09:59 +1000 Message-ID: To: Andy Newton Content-Type: multipart/alternative; boundary=20cf306f7d14e5ce0804ca0f6848 X-Gm-Message-State: ALoCoQnf8t04vnd6gqKhuwi3ef9HMzDnJu0SuKoGJZdHYo72unHK6xlHtELn/94aOsRyawXQM/HV Cc: "weirds@ietf.org" Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 15:10:47 -0000 --20cf306f7d14e5ce0804ca0f6848 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 20, 2012 at 12:50 AM, Andy Newton wrote: > > > >Wil is suggesting to do just one redirect. If that were the case, in the > >IANA-ARIN-APNIC example you would need 2 redirects. One for IANA to ARIN > >and another from ARIN to APNIC. A similar case > > happens when you have ReferralServers (I think just ARIN has them at > >least for now). > > > So one redirect is ok, but two redirects is not? I do not understand the > concern. > > My concern is that modifying the URI just to curb redirect loops is not cache-friendly. In trying to come up with an alternative, I thought that if there were no real use cases for supporting multiple redirects, then we could stop redirect loops by allowing only a single redirect by checking the Referer header, assuming clients send them. The proposal was: upon receiving a request, if the server is not authoritative for the object requested, it would check to see if the Referer header value, if present, is one of the other weirds servers that would redirect to it (IANA and the other RIRs), and if so, it will refuse to redirect the client. In any case, I think Arturo had just debunked my wrong assumption of not needing multiple redirects. .wil --20cf306f7d14e5ce0804ca0f6848 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 20, 2012 at 12:50 AM, Andy N= ewton <andy@arin.net> wrote:
>
>Wil is suggesting to do just one redirect. If that were the case, in th= e
>IANA-ARIN-APNIC example you would need 2 redirects. One for IANA to ARI= N
>and another from ARIN to APNIC. A similar case
> happens when you have ReferralServers (I think just ARIN has them at >least for now).


So one redirect is ok, but two redirects is not? I do not understand = the
concern.


My concern is that modifying the URI just to curb re= direct loops is not cache-friendly. In trying to come up with an alternativ= e, I thought that if there were no real use cases for supporting multiple r= edirects, then we could stop redirect loops by allowing only a single redir= ect by checking the Referer header, assuming clients send them.

The proposal was: upon receiving a request, if the serv= er is not authoritative for the object requested, it would check to see if = the Referer header value, if present, is one of the other weirds servers th= at would redirect to it (IANA and the other RIRs), and if so, it will refus= e to redirect the client.

In any case, I think Arturo had just debunked my wrong = assumption of not needing multiple redirects.

.wil=
--20cf306f7d14e5ce0804ca0f6848-- From aservin@lacnic.net Wed Sep 19 08:23:03 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B926321F8665 for ; Wed, 19 Sep 2012 08:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amcOsWjKmesp for ; Wed, 19 Sep 2012 08:23:02 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3A64721F8653 for ; Wed, 19 Sep 2012 08:23:01 -0700 (PDT) Received: from [192.168.1.133] (r186-48-209-86.dialup.adsl.anteldata.net.uy [186.48.209.86]) by mail.lacnic.net.uy (Postfix) with ESMTP id 9EEAB308444; Wed, 19 Sep 2012 12:22:59 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_D3150509-32DA-435B-9BA7-20D79A3697D2" From: Arturo Servin In-Reply-To: Date: Wed, 19 Sep 2012 12:22:58 -0300 Message-Id: <58C91A17-F913-4FC3-B4EE-16D0F34DED67@lacnic.net> References: To: Wil Tan X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 15:23:03 -0000 --Apple-Mail=_D3150509-32DA-435B-9BA7-20D79A3697D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think that we could conclude: - More that one redirect is required - Currently approach to detect loops is not cache-friendly - We need to decide: - If we require to detect the loop, if so - a cache-friendly approach - or just live with the current one So, my first question to the group is: Do we need to detect in the server that a loop has occurred or = we just leave it to the user agent to deal with it? Regards, as On 19 Sep 2012, at 12:09, Wil Tan wrote: >=20 >=20 > On Thu, Sep 20, 2012 at 12:50 AM, Andy Newton wrote: > > > >Wil is suggesting to do just one redirect. If that were the case, in = the > >IANA-ARIN-APNIC example you would need 2 redirects. One for IANA to = ARIN > >and another from ARIN to APNIC. A similar case > > happens when you have ReferralServers (I think just ARIN has them at > >least for now). >=20 >=20 > So one redirect is ok, but two redirects is not? I do not understand = the > concern. >=20 >=20 > My concern is that modifying the URI just to curb redirect loops is = not cache-friendly. In trying to come up with an alternative, I thought = that if there were no real use cases for supporting multiple redirects, = then we could stop redirect loops by allowing only a single redirect by = checking the Referer header, assuming clients send them. >=20 > The proposal was: upon receiving a request, if the server is not = authoritative for the object requested, it would check to see if the = Referer header value, if present, is one of the other weirds servers = that would redirect to it (IANA and the other RIRs), and if so, it will = refuse to redirect the client. >=20 > In any case, I think Arturo had just debunked my wrong assumption of = not needing multiple redirects. >=20 > .wil --Apple-Mail=_D3150509-32DA-435B-9BA7-20D79A3697D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think that we could = conclude:

- More that one redirect is = required
- Currently approach to detect = loops is not cache-friendly
- We need to = decide:
- If we require to detect = the loop, if so
- a = cache-friendly approach
- or just live = with the current one

So, my = first question to the group is:

Do we = need to detect in the server that a loop has occurred or we just leave = it to the user agent to deal with = it?

Regards,
as

On = 19 Sep 2012, at 12:09, Wil Tan wrote:



On Thu, Sep 20, 2012 at 12:50 AM, Andy Newton = <andy@arin.net> wrote:
>
>Wil is suggesting to do just one redirect. If that were the case, in = the
>IANA-ARIN-APNIC example you would need 2 redirects. One for IANA to = ARIN
>and another from ARIN to APNIC. A similar case
> happens when you have ReferralServers (I think just ARIN has them = at
>least for now).


So one redirect is ok, but two redirects is not? I do not = understand the
concern.


My = concern is that modifying the URI just to curb redirect loops is not = cache-friendly. In trying to come up with an alternative, I thought that = if there were no real use cases for supporting multiple redirects, then = we could stop redirect loops by allowing only a single redirect by = checking the Referer header, assuming clients send them.

The proposal was: upon receiving a request, if the = server is not authoritative for the object requested, it would check to = see if the Referer header value, if present, is one of the other weirds = servers that would redirect to it (IANA and the other RIRs), and if so, = it will refuse to redirect the client.

In any case, I think Arturo had just debunked my = wrong assumption of not needing multiple = redirects.

.wil

= --Apple-Mail=_D3150509-32DA-435B-9BA7-20D79A3697D2-- From shollenbeck@verisign.com Wed Sep 19 08:26:59 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD03721F8701 for ; Wed, 19 Sep 2012 08:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGILC+Usvq93 for ; Wed, 19 Sep 2012 08:26:59 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4213C21F8665 for ; Wed, 19 Sep 2012 08:26:55 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUFnkPsF0vbd01ahOlVqigsmUF4H5O06i@postini.com; Wed, 19 Sep 2012 08:26:58 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q8JFQs8Z019244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 11:26:54 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Wed, 19 Sep 2012 11:26:53 -0400 From: "Hollenbeck, Scott" To: Arturo Servin , Wil Tan Thread-Topic: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 Thread-Index: AQHNlnqv0xTxmX0ATESa6RVYj5pAQpeRyTgw Date: Wed, 19 Sep 2012 15:26:53 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D68A8E8@BRN1WNEXMBX02.vcorp.ad.vrsn.com> References: <58C91A17-F913-4FC3-B4EE-16D0F34DED67@lacnic.net> In-Reply-To: <58C91A17-F913-4FC3-B4EE-16D0F34DED67@lacnic.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: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F0D68A8E8BRN1WNEXMBX02vc_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 15:26:59 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F0D68A8E8BRN1WNEXMBX02vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Arturo Servin Sent: Wednesday, September 19, 2012 11:23 AM To: Wil Tan Cc: weirds@ietf.org Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-we= irds-restwhois-redirects-00 I think that we could conclude: - More that one redirect is required - Currently approach to detect loops is not cache-friendly - We need to decide: - If we require to detect the loop, if so - a cache-friendly approach - or just live with the current one So, my first question to the group is: Do we need to detect in the server that a loop has occurred or we= just leave it to the user agent to deal with it? As a server operator I like the idea of being able to detect and abort a lo= op. Scott --_000_831693C2CDA2E849A7D7A712B24E257F0D68A8E8BRN1WNEXMBX02vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Arturo Servin
Sent: Wednesday, September 19, 2012 11:23 AM
To: Wil Tan
Cc: weirds@ietf.org
Subject: Re: [weirds] Redirect Loop Detection - comments on draft-la= cnic-weirds-restwhois-redirects-00

 

 

   &nb= sp;      I think that we could conclude:

 

   &nb= sp;      - More that one redirect is requir= ed

   &nb= sp;      - Currently approach to detect loo= ps is not cache-friendly

   &nb= sp;      - We need to decide:

   &nb= sp;            =       - If we require to detect the loop, i= f so

   &nb= sp;            =             &nb= sp;     - a cache-friendly approach

   &nb= sp;            =             &nb= sp;     - or just live with the current one

 

   &nb= sp;      So, my first question to the group= is:

 

   &nb= sp;      Do we need to detect in the server= that a loop has occurred or we just leave it to the user agent to deal wit= h it?

 <= /p>

As a server operator I li= ke the idea of being able to detect and abort a loop.

 <= /p>

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F0D68A8E8BRN1WNEXMBX02vc_-- From carlosm3011@gmail.com Wed Sep 19 08:36:45 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D4A21F86FE for ; Wed, 19 Sep 2012 08:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt5q4Blsw0+Y for ; Wed, 19 Sep 2012 08:36:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCF1121F86F7 for ; Wed, 19 Sep 2012 08:36:44 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so1462392vbb.31 for ; Wed, 19 Sep 2012 08:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0++SRPp+4mNt9iP2/N6JmAIvKf1Y/Gpg35lcwGqsbtY=; b=W3TQ694qjkEwsu2nKnv+9JCUFY7Ju+YUL7NvPCWwqSl+X0t0FsETxVN21Tqi1a91ii QUFi5B+qbWgjf2MIczmv29khaLlvhk9IevaO/CTF1WtcxG/hlr7aeDENA0C+GrnZB9Ex nkVYATfL5PRxVZ4kkK1qZErzOwP6sVL2Q4yulcoMh1l+848Fhj+vldA3iIntnMYRyKvi 0tkHka0omAUQTILN4NKlcJSDm8P0bmUkuC22Z1YJLAyQuMEwPApoSIs34edn8kyPhPQq ABPPPZ5jTp/YoWB9VyAi0t4v9rJ12qIegZ8vnBNjImi+P/tA1kVKSUwr+VuVINbJl+7U Qfgw== Received: by 10.52.240.171 with SMTP id wb11mr1709459vdc.86.1348069002569; Wed, 19 Sep 2012 08:36:42 -0700 (PDT) Received: from europa.local ([2001:470:d815:fe0:346b:4056:b9a:2af3]) by mx.google.com with ESMTPS id q19sm703366vdt.4.2012.09.19.08.36.39 (version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 08:36:41 -0700 (PDT) Message-ID: <5059E684.3080508@gmail.com> Date: Wed, 19 Sep 2012 12:36:36 -0300 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Arturo Servin References: <58C91A17-F913-4FC3-B4EE-16D0F34DED67@lacnic.net> In-Reply-To: <58C91A17-F913-4FC3-B4EE-16D0F34DED67@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 15:36:45 -0000 I agree with Arturo, and definitely I see use cases for more than one redirect. The caching concern is a valid one though, so it is back to the drawing board for that part :-) ~Carlos On 9/19/12 12:22 PM, Arturo Servin wrote: > > I think that we could conclude: > > - More that one redirect is required > - Currently approach to detect loops is not cache-friendly > - We need to decide: > - If we require to detect the loop, if so > - a cache-friendly approach > - or just live with the current one > > So, my first question to the group is: > > Do we need to detect in the server that a loop has occurred or we just > leave it to the user agent to deal with it? > > Regards, > as > > On 19 Sep 2012, at 12:09, Wil Tan wrote: > >> >> >> On Thu, Sep 20, 2012 at 12:50 AM, Andy Newton > > wrote: >> >> > >> >Wil is suggesting to do just one redirect. If that were the case, >> in the >> >IANA-ARIN-APNIC example you would need 2 redirects. One for IANA >> to ARIN >> >and another from ARIN to APNIC. A similar case >> > happens when you have ReferralServers (I think just ARIN has them at >> >least for now). >> >> >> So one redirect is ok, but two redirects is not? I do not >> understand the >> concern. >> >> >> My concern is that modifying the URI just to curb redirect loops is >> not cache-friendly. In trying to come up with an alternative, I >> thought that if there were no real use cases for supporting multiple >> redirects, then we could stop redirect loops by allowing only a single >> redirect by checking the Referer header, assuming clients send them. >> >> The proposal was: upon receiving a request, if the server is not >> authoritative for the object requested, it would check to see if the >> Referer header value, if present, is one of the other weirds servers >> that would redirect to it (IANA and the other RIRs), and if so, it >> will refuse to redirect the client. >> >> In any case, I think Arturo had just debunked my wrong assumption of >> not needing multiple redirects. >> >> .wil > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Wed Sep 19 09:03:15 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEEC21F8748 for ; Wed, 19 Sep 2012 09:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPVdJ9y3x9Tx for ; Wed, 19 Sep 2012 09:03:13 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 7214221F86DE for ; Wed, 19 Sep 2012 09:03:13 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 9ADCC165285; Wed, 19 Sep 2012 12:03:12 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 18283165259; Wed, 19 Sep 2012 12:03:12 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 19 Sep 2012 12:02:47 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 12:02:59 -0400 From: Andy Newton To: Wil Tan Thread-Topic: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 Thread-Index: AQHNlnGNrn/iOLT7d0iDU/L7VPzHdpeR/EKA///DE4CAAEiBgP//y7yA Date: Wed, 19 Sep 2012 16:02:58 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: multipart/alternative; boundary="_000_CC7F627FD294andyarinnet_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 16:03:15 -0000 --_000_CC7F627FD294andyarinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The proposal was: upon receiving a request, if the server is not authoritat= ive for the object requested, it would check to see if the Referer header v= alue, if present, is one of the other weirds servers that would redirect to= it (IANA and the other RIRs), and if so, it will refuse to redirect the cl= ient. Thanks. Now I understand. In any case, I think Arturo had just debunked my wrong assumption of not ne= eding multiple redirects. As far as I can tell, there are two use cases: 1. Client asks for IP or ASN at ARIN. ARIN was never authoritative for i= t but knows that RIPE is, so ARIN redirects to RIPE. RIPE has transferred t= he IP or ASN to APNIC, so RIPE redirects to APNIC. And from there it stops.= There will only ever be three levels deep at most because all subsequent p= arceling out of that space has to be done by RIPE. 2. Client asks for example.biz at VeriSign. VeriSign is not authoritativ= e for .biz, so it redirects to Neustar. It might end here or Nuestar may re= direct to the registrar (though I doubt it). In both cases, a loop is a condition that is an error and is caused by a mi= sbehaving client because the servers never would have redirected them into = a loop. Therefore we should treat this condition like any other of a misbeh= aving client. Even if we standardized loop detection parameters, there's no= thing to say the client will still do the right thing. -andy --_000_CC7F627FD294andyarinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: <9ABC37A6737EC24D82DBC5D42C31C0AF@corp.arin.net> Content-Transfer-Encoding: quoted-printable

The proposal was: upon receiving a request, if the server is not authoritat= ive for the object requested, it would check to see if the Referer header v= alue, if present, is one of the other weirds servers that would redirect to= it (IANA and the other RIRs), and if so, it will refuse to redirect the client.


Thanks. Now I understand.


In any case, I think Arturo had just debunked my wrong assumption of n= ot needing multiple redirects.



As far as I can tell, there are two use cases:

  1. Client asks for IP or ASN at ARIN. ARIN was never authoritative for it = but knows that RIPE is, so ARIN redirects to RIPE. RIPE has transferred the= IP or ASN to APNIC, so RIPE redirects to APNIC. And from there it stops. T= here will only ever be three levels deep at most because all subsequent parceling out of that space has to be = done by RIPE.
  2. Client asks for example.biz at VeriSign. VeriSign is = not authoritative for .biz, so it redirects to Neustar. It might end here o= r Nuestar may redirect to the registrar (though I doubt it).
In both cases, a loop is a condition that is an error and is caused by= a misbehaving client because the servers never would have redirected them = into a loop. Therefore we should treat this condition like any other of a m= isbehaving client. Even if we standardized loop detection parameters, there's nothing to say the client will still do= the right thing.

-andy

--_000_CC7F627FD294andyarinnet_-- From johnl@iecc.com Wed Sep 19 13:28:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79A921F8514 for ; Wed, 19 Sep 2012 13:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZLNSjXkA3K0 for ; Wed, 19 Sep 2012 13:28:05 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78D21F8510 for ; Wed, 19 Sep 2012 13:28:00 -0700 (PDT) Received: (qmail 4286 invoked from network); 19 Sep 2012 20:27:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Sep 2012 20:27:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=505a2ac8.xn--3zv.k1208; i=johnl@user.iecc.com; bh=+2F0q0/6bH+W1qdgi5EEi2fcNcHSkbcUG6XMJ2T8qMQ=; b=rcaIL9Tc2/Z+Q2M3lwqEAX7LtdpPSK7mw1Hqd5rMwVQW1mPF6fvaM54FYTyZzLdeOTxVBM0EwpUT3b1bQwHxohU0Dg3MiOZdS5vSZFDG+IYqXq+JOzGdfAm3m4J5cAZP1aQL8o6f2oelvBAQVuXHNf7R+RRsihoA5qdfkjdwRNQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=505a2ac8.xn--3zv.k1208; olt=johnl@user.iecc.com; bh=+2F0q0/6bH+W1qdgi5EEi2fcNcHSkbcUG6XMJ2T8qMQ=; b=axVpx74t4xmPrguZG+QWiO5V2iepOSEreipewd+BDu0iP4pjPvEDRVNysi2wCNJixxgjdjbtEINS3JHGyknvuKU5Krea4+GdqounA9Ya88LiPQqaAPQlEM7NtUuffD0ZOvmdv6DLocmRPmzU/KaO6rk75g2P1bhtkoUzRVxL2Oo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 19 Sep 2012 20:27:30 -0000 Message-ID: <20120919202730.75197.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 20:28:05 -0000 >In both cases, a loop is a condition that is an error and is caused by a >misbehaving client because the servers never would have redirected them into a >loop. I don't think we can assume that. No matter what we do, there's no way that we can predict every possible server misconfiguration that could lead to a redirect loop, particularly a loop that goes through multiple servers. Example: client queries ARIN, ARIN redirects to RIPE, RIPE redirects to an LIR, LIR redirects to a hosting company that provides SWIP-like info for its clients, company hasn't yet configured the range and helpfully provides a default redirect back to ARIN. Oops. Yeah, they shouldn't do that, but they will. People are going to do their WEIRDS lookups using existing http clients, or new clients will use existing http libraries, all of which use counters to break redirect loops. (They've been a problem for over 15 years, after all.) If there's a loop, it's much, much more likely to be due to multiple servers disagreeing about who's responsible for something than client bugs. Even if someone does manage to write a client that loops, the only way you're going to know that it's looping is that it's hammering on your server at a high rate. So as you suggest, the defenses you already have against unreasonable clients will deal with this rather unlikely scenario. R's, John From andy@arin.net Wed Sep 19 13:33:58 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749AA21E8049 for ; Wed, 19 Sep 2012 13:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWHU5VvZi+aZ for ; Wed, 19 Sep 2012 13:33:58 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id E6AFB21E8034 for ; Wed, 19 Sep 2012 13:33:57 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 4F98C213690; Wed, 19 Sep 2012 16:33:57 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id C6B892135F5; Wed, 19 Sep 2012 16:33:56 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 19 Sep 2012 16:33:25 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 16:33:37 -0400 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 Thread-Index: AQHNlnGNrn/iOLT7d0iDU/L7VPzHdpeR/EKA///DE4CAAEiBgP//y7yAgACM+wD//76igA== Date: Wed, 19 Sep 2012 20:33:35 +0000 Message-ID: In-Reply-To: <20120919202730.75197.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <57368AA6AD8C8D4D9C5056C336CAD94E@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 20:33:58 -0000 On 9/19/12 4:27 PM, "John Levine" wrote: >Even if someone does manage to write a client that loops, the only way >you're going to know that it's looping is that it's hammering on your >server at a high rate. So as you suggest, the defenses you already >have against unreasonable clients will deal with this rather unlikely >scenario. So we've come to the same conclusion from a different starting point. Excellent! :) -andy From internet-drafts@ietf.org Thu Sep 20 08:22:51 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B2A21F86E1; Thu, 20 Sep 2012 08:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbrgyobWx5Cx; Thu, 20 Sep 2012 08:22:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0932E21F8555; Thu, 20 Sep 2012 08:22:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120920152221.12357.83840.idtracker@ietfa.amsl.com> Date: Thu, 20 Sep 2012 08:22:21 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2012 15:22:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Security Services for the Registration Data Access Proto= col Author(s) : Scott Hollenbeck Ning Kong Filename : draft-ietf-weirds-rdap-sec-00.txt Pages : 7 Date : 2012-09-20 Abstract: The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services and their application to RDAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ed.Lewis@neustar.biz Thu Sep 20 09:36:13 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B46521F8783 for ; Thu, 20 Sep 2012 09:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcdiIPOGwgvT for ; Thu, 20 Sep 2012 09:36:12 -0700 (PDT) Received: from smtp171.dfw.emailsrvr.com (smtp171.dfw.emailsrvr.com [67.192.241.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5A92E21F870B for ; Thu, 20 Sep 2012 09:36:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 2C73518813B; Thu, 20 Sep 2012 12:36:11 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp17.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 96AFF18818C; Thu, 20 Sep 2012 12:36:10 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 20 Sep 2012 12:35:21 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2012 16:36:13 -0000 Commenting on this thread in general... I'd drop any assumptions about why a query arrives at a server. Intended or not, a protocol should define what happens when it accepts a query that it has no data to match (and may know a better source). This is just basic protocol engineering. The DNS has a similar problem and there are a few lessons to be taken from there. (I'm not going to say DNS's model is the way to go, it's just a working example.) 1. In DNS there is a record called a CNAME which causes a query to "restart" with a new (arbitrary) name, hence there is no guarantee that a loop is avoided. The solution used in DNS is to have the querier keep a count and cut off searching at 5. Yes, "5" because, well, why not, it's a cool number. We don't want a scared number like 6, who is afraid of 7 because "7 8 9". (Those teaching children English numbers get that joke.) What is architecturally significant here is that the burden is placed on the querier to "police" this. The assumption is that answering with a CNAME is not a burden to the server. 2. The DNS has coined the term "lame" for any server that is asked a question about data not in its knowledge base. (I.e., a "lame server".) Transferring that term here, we are concerned about WEIRDS protocol servers that are lame for queries and how do they react - regardless of why the query was sent. "Lameness" and the CNAME loop are unrelated topics in DNS, they both have lessons learned to apply here. FWIW, even if from DNSSEC alone, we have seen that operational miscues are far more damaging than a security incident. Although the latter might be a bigger problem for the victim, the former is "across the board" pain. 3. In the DNS there was no original indication of lameness. Over time the convention was to "go ask upwards" (the root - or IANA was the target of the redirection). After decades of this as accepted practice this got turned into a DDoS abuse point because the referral was larger than the query. Emphasizing this is DNS specific, the DNS protocol is highly susceptible to abuse when the answer is more bytes than the question. Today servers return a response code indicating there's no response and it is up to the client to figure out where to go. (Plus - in the 90's a particular buggy OS implementation, in the sense what it gullibly accepted the upwards referral, caused a material problem that led to at least one ARIN policy to look for lame servers.) When it comes to this topic, there is a difference between names and numbers. With names, it is "obvious" who the appropriate server (provider) should be, given the TLD and the sublabels from there. For numbers, the RIR federation has apportioned the address space in a non-obvious way. The use case of ARIN responding with a redirect to LACNIC is far more anticipated than Verisign redirecting to Neustar. Although this is a difference I don't think it is significant as queriers still have to know how to navigate and servers still have to know how to respond. Servers for names as well as numbers might get a query for "257.12.34.82" and they will all have to tell the client to go somewhere else. Are loops possible - yes. Should a querier be smart about them - yes. Does a server need to worry about them - it shouldn't. Does a server have to indicate it doesn't have the answer - yes. Does the server need to tell the client where to ask next - for queries for names it shouldn't, for queries for numbers a solution is needed. If generating a redirect is easy, then placing the burden to avoid them on the client will diffuse the problem. If knowing where to tell the client to go is hard, redirecting isn't easy. Even a names server needs to know what is the right numbers server. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From zhoulinlin@cnnic.cn Thu Sep 20 20:31:11 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B9821E809E for ; Thu, 20 Sep 2012 20:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLext6PfES2k for ; Thu, 20 Sep 2012 20:31:10 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id F386221E8051 for ; Thu, 20 Sep 2012 20:31:08 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 21 Sep 2012 11:30:59 +0800 From: "Linlin Zhou" To: "'Edward Lewis'" , References: In-Reply-To: Date: Fri, 21 Sep 2012 11:30:58 +0800 Message-ID: <008901cd97a9$848c0b10$8da42130$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2XThDgpdAXkRg+SXqScJwhMuaDFAAWdipw Content-Language: zh-cn Subject: Re: [weirds] Redirect Loop Detection - comments on draft-lacnic-weirds-restwhois-redirects-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 03:31:11 -0000 > > 1. In DNS there is a record called a CNAME which causes a query to "restart" with > a new (arbitrary) name, hence there is no guarantee that a loop is avoided. The > solution used in DNS is to have the querier keep a count and cut off searching at 5. > Yes, "5" because, well, why not, it's a cool number. We don't want a scared > number like 6, who is afraid of 7 because "7 8 9". (Those teaching children > English numbers get that joke.) I found that RFC2616 10.3 also recommend maximum of five redirections. Do we need to put this recommend in this section to avoid the threshold is set too big or too small? If the redirection times greater than the threshold, I suggest have a response error code defined here, such as 40x or 50x. >What is architecturally significant here is that > the burden is placed on the querier to "police" this. > The assumption is that answering with a CNAME is not a burden to the server. > Linlin From shollenbeck@verisign.com Fri Sep 21 05:36:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928D321F8770 for ; Fri, 21 Sep 2012 05:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNqfpWJq8tQ0 for ; Fri, 21 Sep 2012 05:36:24 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 01E1121F8760 for ; Fri, 21 Sep 2012 05:36:22 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUFxfRjdp5nQdLYyrwLRURWNRkVEe9Ral@postini.com; Fri, 21 Sep 2012 05:36:23 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q8LCaLV1002960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Sep 2012 08:36:22 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Fri, 21 Sep 2012 08:36:21 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: SAC055: SSAC Comment on the WHOIS Review Team Final Report Thread-Index: Ac2X9bOoYzgs5ITERnCcuvl99v4j/A== Date: Fri, 21 Sep 2012 12:36:20 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D68B686@BRN1WNEXMBX02.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 Subject: [weirds] SAC055: SSAC Comment on the WHOIS Review Team Final Report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 12:36:25 -0000 Recently announced (sorry if this is a re-post): http://www.icann.org/en/groups/ssac/documents/sac-055-en.pdf Scott From internet-drafts@ietf.org Fri Sep 21 05:45:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9521F8778; Fri, 21 Sep 2012 05:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyftbrl1f+Qu; Fri, 21 Sep 2012 05:45:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F23A21F8764; Fri, 21 Sep 2012 05:45:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921124542.17167.42026.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 05:45:42 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 12:45:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Using the Registration Data Access Protocol (RDAP) with = HTTP Author(s) : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-00.txt Pages : 25 Date : 2012-09-21 Abstract: This document describes the usage of the Registration Data Access Protocol (RDAP) using HTTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From andy@arin.net Fri Sep 21 06:25:56 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8322921F8797 for ; Fri, 21 Sep 2012 06:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koQXTXrg5IRw for ; Fri, 21 Sep 2012 06:25:54 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 96A5D21F86F3 for ; Fri, 21 Sep 2012 06:25:54 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id C9E8C213694; Fri, 21 Sep 2012 09:25:53 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 7DE702135A6; Fri, 21 Sep 2012 09:25:51 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 21 Sep 2012 09:25:29 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 09:25:50 -0400 From: Andy Newton To: "Hollenbeck, Scott" , "weirds@ietf.org" Thread-Topic: [weirds] SAC055: SSAC Comment on the WHOIS Review Team Final Report Thread-Index: Ac2X9bOoYzgs5ITERnCcuvl99v4j/AABukIA Date: Fri, 21 Sep 2012 13:25:49 +0000 Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D68B686@BRN1WNEXMBX02.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="Windows-1252" Content-ID: <668B9D1CE8484D4F9503EF3ECB1D6190@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] SAC055: SSAC Comment on the WHOIS Review Team Final Report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 13:25:56 -0000 On 9/21/12 8:36 AM, "Hollenbeck, Scott" wrote: >Recently announced (sorry if this is a re-post): > >http://www.icann.org/en/groups/ssac/documents/sac-055-en.pdf First I've seen of it. Thanks. Having skimmed it, I have two general comments: 1. The premise of this SSAC document is that there are multiple problems to be solved and no solution to the "WHOIS problem" will be achieved until all perspectives are acknowledged. And then the report immediately narrows the problem of WHOIS down to the gTLD space ignoring ccTLDs, RIRs, etc=8A I= f all perspectives are to be acknowledged, the wider use of WHOIS outside of gTLDs should be stated. 2. There are several sections on tiered access for multiple constituencies. One of the questions asked is how an actor with elevated access is to be identified. But there is another question in there: who is giving out these access credentials? Kudos to SSAC on section 3.3.2. -andy From dblumenthal@pir.org Fri Sep 21 11:05:58 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3428721E80BD for ; Fri, 21 Sep 2012 11:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.076 X-Spam-Level: X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THC7UWK9M451 for ; Fri, 21 Sep 2012 11:05:57 -0700 (PDT) Received: from mail.pir.org (173-10-164-41-BusName-washingtonDC.hfc.comcastbusiness.net [173.10.164.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9960721E80B9 for ; Fri, 21 Sep 2012 11:05:57 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Fri, 21 Sep 2012 14:05:56 -0400 From: Don Blumenthal To: "weirds@ietf.org" Date: Fri, 21 Sep 2012 14:05:50 -0400 Thread-Topic: [weirds] SAC055: SSAC Comment on the WHOIS Review Team Final Report Thread-Index: Ac2YI76SCzx5Y6RDSySHYkTTp9nU3A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] SAC055: SSAC Comment on the WHOIS Review Team Final Report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 18:05:58 -0000 On 9/21/12 9:25 AM, "Andy Newton" wrote: >First I've seen of it. Thanks. > >Having skimmed it, I have two general comments: > >1. The premise of this SSAC document is that there are multiple problems >to be solved and no solution to the "WHOIS problem" will be achieved until >all perspectives are acknowledged. And then the report immediately narrows >the problem of WHOIS down to the gTLD space ignoring ccTLDs, RIRs, etc=A9 = If >all perspectives are to be acknowledged, the wider use of WHOIS outside of >gTLDs should be stated. At least a couple of people on this list, including me, contributed to the report. Thanks for looking at it. WRT this issue, scope is a good point in the general scheme of whois issues. RIRs in particular general aren't part of discussions. However, the Whois Review Team Report that the SSAC was commenting on properly was limited to gTLDs. The Report was done to fulfill requirements of the ICANN/US Department of Commerce Affirmation of Commitments, which involved DNS issues only. On top of that, the cc space wouldn't be governed by an ICANN Whois policy. Don=20 From andy@arin.net Fri Sep 21 11:14:56 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9079721E80B9 for ; Fri, 21 Sep 2012 11:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAOxWK2kZB+G for ; Fri, 21 Sep 2012 11:14:55 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 1357221E80B7 for ; Fri, 21 Sep 2012 11:14:55 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id D2EB0165413; Fri, 21 Sep 2012 14:14:49 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 126DE165411; Fri, 21 Sep 2012 14:14:47 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 21 Sep 2012 14:14:27 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 14:14:47 -0400 From: Andy Newton To: Don Blumenthal , "weirds@ietf.org" Thread-Topic: [weirds] SAC055: SSAC Comment on the WHOIS Review Team Final Report Thread-Index: Ac2X9bOoYzgs5ITERnCcuvl99v4j/AABukIAABIpdgD//79uAA== Date: Fri, 21 Sep 2012 18:14:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] SAC055: SSAC Comment on the WHOIS Review Team Final Report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 18:14:56 -0000 On 9/21/12 2:05 PM, "Don Blumenthal" wrote: >On 9/21/12 9:25 AM, "Andy Newton" wrote: > >>First I've seen of it. Thanks. >> >>Having skimmed it, I have two general comments: >> >>1. The premise of this SSAC document is that there are multiple problems >>to be solved and no solution to the "WHOIS problem" will be achieved >>until >>all perspectives are acknowledged. And then the report immediately >>narrows >>the problem of WHOIS down to the gTLD space ignoring ccTLDs, RIRs, etc=A9 >>If >>all perspectives are to be acknowledged, the wider use of WHOIS outside >>of >>gTLDs should be stated. > >At least a couple of people on this list, including me, contributed to the >report. Thanks for looking at it. > >WRT this issue, scope is a good point in the general scheme of whois >issues. RIRs in particular general aren't part of discussions. However, >the Whois Review Team Report that the SSAC was commenting on properly was >limited to gTLDs. The Report was done to fulfill requirements of the >ICANN/US Department of Commerce Affirmation of Commitments, which involved >DNS issues only. On top of that, the cc space wouldn't be governed by an >ICANN Whois policy. Don, I have full faith that the members of the SSAC know the space quite well and know the larger scope of WHOIS. However, the point might need to be made repeatedly by the SSAC to others. The point is especially useful to answer such assertions that everybody can just go to http://www.internic.net and all the problems of WHOIS will be solved. -andy From dblumenthal@pir.org Fri Sep 21 11:30:19 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC8921F86E8 for ; Fri, 21 Sep 2012 11:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.076 X-Spam-Level: X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdWyMw6DxU3G for ; Fri, 21 Sep 2012 11:30:18 -0700 (PDT) Received: from mail.pir.org (173-10-164-41-BusName-washingtonDC.hfc.comcastbusiness.net [173.10.164.41]) by ietfa.amsl.com (Postfix) with ESMTP id AAFE621F86E3 for ; Fri, 21 Sep 2012 11:30:18 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Fri, 21 Sep 2012 14:30:17 -0400 From: Don Blumenthal To: Andy Newton , "weirds@ietf.org" Date: Fri, 21 Sep 2012 14:30:14 -0400 Thread-Topic: [weirds] SAC055: SSAC Comment on the WHOIS Review Team Final Report Thread-Index: Ac2YJyVnijrckxdYQPmj6Bd+UXyi0g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] SAC055: SSAC Comment on the WHOIS Review Team Final Report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 18:30:19 -0000 On 9/21/12 2:14 PM, "Andy Newton" wrote: Don, I have full faith that the members of the SSAC know the space quite >well and know the larger scope of WHOIS. However, the point might need to >be made repeatedly by the SSAC to others. The point is especially useful >to answer such assertions that everybody can just go to >http://www.internic.net and all the problems of WHOIS will be solved. > >-andy Agreed. I was just giving background on the scope of the Whois RT report that might be useful when looking at the SSAC comments on it. don From andy@arin.net Fri Sep 21 14:27:27 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B9121E808D for ; Fri, 21 Sep 2012 14:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtwtU10Uvm7k for ; Fri, 21 Sep 2012 14:27:26 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id BAFD821E803A for ; Fri, 21 Sep 2012 14:27:24 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 086801654A3; Fri, 21 Sep 2012 17:27:24 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id AF4E11654A0 for ; Fri, 21 Sep 2012 17:27:21 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 21 Sep 2012 17:26:58 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 17:27:21 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-00.txt Thread-Index: AQHNl/cGa32OKzPRrECa4fkIO4iZYpeVT84A Date: Fri, 21 Sep 2012 21:27:19 +0000 Message-ID: In-Reply-To: <20120921124542.17167.42026.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <430EEC5C788AFA47BB876785BA8B111E@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 21:27:27 -0000 > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 Section 11.1 establishes a registry for RDAP extensions. That's the newest thing: http://tools.ietf.org/html/draft-ietf-weirds-using-http-00#section-11.1 Your comments are solicited. -andy From fobispo@isc.org Fri Sep 21 14:49:35 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA2421F8619 for ; Fri, 21 Sep 2012 14:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lCleirHXJvw for ; Fri, 21 Sep 2012 14:49:34 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2595721F8527 for ; Fri, 21 Sep 2012 14:49:34 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B240B5F9949; Fri, 21 Sep 2012 21:49:24 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from dhcp-98.sql1.isc.org (dhcp-98.sql1.isc.org [149.20.50.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3259A216C3B; Fri, 21 Sep 2012 21:49:23 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Francisco Obispo In-Reply-To: Date: Fri, 21 Sep 2012 14:49:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6818CC88-3110-4D58-B21F-FA591F2CBC30@isc.org> References: To: Andy Newton X-Mailer: Apple Mail (2.1498) Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 21:49:35 -0000 This is really good, I'm glad to see that we are moving in the right = direction. Cheers! On Sep 21, 2012, at 2:27 PM, Andy Newton wrote: >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 >=20 >=20 > Section 11.1 establishes a registry for RDAP extensions. That's the = newest > thing: > = http://tools.ietf.org/html/draft-ietf-weirds-using-http-00#section-11.1 >=20 > Your comments are solicited. >=20 > -andy >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From aservin@lacnic.net Sat Sep 22 06:47:31 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7961E21F867F for ; Sat, 22 Sep 2012 06:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9mB+rTTyEUP for ; Sat, 22 Sep 2012 06:47:27 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 45B3F21F8661 for ; Sat, 22 Sep 2012 06:47:27 -0700 (PDT) Received: from [192.168.1.133] (r186-49-0-225.dialup.adsl.anteldata.net.uy [186.49.0.225]) by mail.lacnic.net.uy (Postfix) with ESMTP id 1072C308445 for ; Sat, 22 Sep 2012 10:47:23 -0300 (UYT) Message-ID: <505DC169.7050203@lacnic.net> Date: Sat, 22 Sep 2012 10:47:21 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] Requirements document X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 22 Sep 2012 13:47:31 -0000 On 19/09/2012 11:09, Murray S. Kucherawy wrote: > I haven't heard much in the way of support or demand for a > requirements document to be developed/maintained, even if we decide up > front that we don't plan to publish it in the end, so I'm going to let > draft-kucherawy-weirds-requirements expire. If the WG feels we should > keep this up, please say so and we can hopefully identify a different > editor. > > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Hi, I think this is a valuable document and I see no harm if you continue being an author/editor as you role of "consumer of" WEIRDS data. I would suggest that it would be good to add also "WEIRDS operators" from numbers (I could work on it) and names. That would a team of 3 editors from different background and possible needs that could gather the interest and requirements of the heterogeneous users of WEIRDS. We already have a good set of known requirements (that is why we are producing I+D already) but I guess there are some still missing, not well understood or not agreed requirements that we could document here. Best regards, as From aservin@lacnic.net Thu Sep 27 05:54:22 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C493621F84C8 for ; Thu, 27 Sep 2012 05:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuSlmiXJ1Qg5 for ; Thu, 27 Sep 2012 05:54:22 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8355F21F84FA for ; Thu, 27 Sep 2012 05:54:21 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:f06f:2cb7:c623:1ee8]) by mail.lacnic.net.uy (Postfix) with ESMTP id 33A35308427 for ; Thu, 27 Sep 2012 09:54:16 -0300 (UYT) Message-ID: <50644C77.6090909@lacnic.net> Date: Thu, 27 Sep 2012 09:54:15 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: weirds@ietf.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: [weirds] WHOIS Technical Requirements Survey Invitation (Avail Until 31 OCT 2012) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2012 12:54:22 -0000 You may be interested in the survey. One question (well, two) asked who should do the work of data modelling, ICANN or the IETF. https://limesurvey.icann.org/index.php?sid=71483&lang=en https://www.icann.org/en/news/announcements/announcement-17sep12-en.htm Regards, as From andy@hxr.us Thu Sep 27 06:37:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ACC21F84EC for ; Thu, 27 Sep 2012 06:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYQv0qmDq74J for ; Thu, 27 Sep 2012 06:37:05 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D171C21F84EB for ; Thu, 27 Sep 2012 06:37:04 -0700 (PDT) Received: by bkcjc3 with SMTP id jc3so1828300bkc.31 for ; Thu, 27 Sep 2012 06:37:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=7AL8m3JIHsMkASYnUyCwK+QdizQ/ZrmPWMLrARX4fYg=; b=WbDYs4nDCCE7Tn1UIq27ePwqHuF7EGh2P2nS26S+GWLi18b0b4xX20zv6lzRiTpTlJ 36SfX5sb7rZ/F7aE+b515Bw3ghL48DNHWjC8PAxf0Tg/GKuTSABMjXAuKC9yTsdFC+Xm t5mtn/bQZyayIWUmgsFXpe/tOdrPkKELnwmDph57gPFJIikTg0tfQt/3hUo4vtN1+zwV 7JFU+tarNmUtXS0lJKK8pBeR3YcwkTlRkj8Wt4MT6fW5f51vYcf0ZQja24a+EaNGGZ+G vq4OPgw/6GYcs1vGqUkX+6YJtSv9P7T8dKLhviyw2ZSmJPMdXgDwiF4XKkHQB84ck4io XJ+A== MIME-Version: 1.0 Received: by 10.112.25.167 with SMTP id d7mr1592394lbg.74.1348753023794; Thu, 27 Sep 2012 06:37:03 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Thu, 27 Sep 2012 06:37:03 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: <50644C77.6090909@lacnic.net> References: <50644C77.6090909@lacnic.net> Date: Thu, 27 Sep 2012 09:37:03 -0400 Message-ID: From: Andrew Newton To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQniKtQtCbH/frE11RyaFeHpSfBhHwyBE/ceOMJk1yYnn5wfCa8H6gi4nHKnPFNSR1luJOjd Cc: weirds@ietf.org Subject: Re: [weirds] WHOIS Technical Requirements Survey Invitation (Avail Until 31 OCT 2012) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2012 13:37:05 -0000 On Thu, Sep 27, 2012 at 8:54 AM, Arturo Servin wrote: > > You may be interested in the survey. > > One question (well, two) asked who should do the work of data > modelling, ICANN or the IETF. > > https://limesurvey.icann.org/index.php?sid=71483&lang=en > > https://www.icann.org/en/news/announcements/announcement-17sep12-en.htm > > Regards, > as I took the survey. Not only do they ask who should do the data modeling, a lot of the questions that are technical in nature push only one solution. Also, the sections switch off intermingling terminology. Also, it is very long. -andy From sm@resistor.net Thu Sep 27 14:48:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B298021F8491 for ; Thu, 27 Sep 2012 14:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv4iGvUGGzoc for ; Thu, 27 Sep 2012 14:48:12 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBCD21F8493 for ; Thu, 27 Sep 2012 14:48:12 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8RLm0vG010424; Thu, 27 Sep 2012 14:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348782485; bh=sdq2RZsejVJ4uKYMEf/ZsDQOo+UP+CAC8NgDkxGymBM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=u4Z06kRusIr5DfUi1Xh/itB42lgn2x8MzZveUwfXYrA7S5Grrm3pRJZZbONcJynGJ E6n4SPaUTWneY7kVZ/xmgASsqU12s32MQSpQZSd+jJ06t1ePYHPd5S0Vj8BjY3DwNT 4lgREwOZPmb0gc8YnSSgq3384idx7VVqg2ndygIY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1348782485; i=@resistor.net; bh=sdq2RZsejVJ4uKYMEf/ZsDQOo+UP+CAC8NgDkxGymBM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Z2YLRyKhnDZ8TMIF5cnlSXr6gwhC5JmpQMVlNQrTrArEilmtIKXyFzDo9aNjtCGes EORdfOVqtQniC/EAUXRVCHO31VwY6lKM4wSeDsRyuCnV+Yni3HsKxeMxxWzQO+hXNh v0AdR5W6wmdF1YHlw0fp/mvjYoupHPB2cOpSzt6k= Message-Id: <6.2.5.6.2.20120927134821.0a3de260@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 27 Sep 2012 14:21:45 -0700 To: Andy Newton From: SM In-Reply-To: References: <20120921124542.17167.42026.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2012 21:48:12 -0000 Hi Andy, At 14:27 21-09-2012, Andy Newton wrote: >Your comments are solicited. You asked, I nit. :-) Please note that this is not a review. There are a lot of normative references. Are all of them really necessary? The RFC 2119 boilerplate is missing. In the Abstract Section the usage of RDAP is described as using HTTP. There isn't any mention of RESTful as in the Introduction Section. It is better not to restate HTTP requirements. The HTTP folks might not like that. :-) The question I would ask is what is the document about. I would get rid of the SAC-051. As far as I am aware this working group is not producing a specification in accordance with the SSAC Report. I suggest looking at the document from a specification perspective. That may make it easier to get the flow of how to organize the material. There isn't any Security Considerations section. It's better to start thinking of that early in the process. In Section 4.1: "Accept: applicaiton/rdap+json;level=0" There is a typo for "application". Regards, -sm From sm@resistor.net Thu Sep 27 14:53:24 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485A921F841D for ; Thu, 27 Sep 2012 14:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu9ukRwHd992 for ; Thu, 27 Sep 2012 14:53:23 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE95521F841A for ; Thu, 27 Sep 2012 14:53:23 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8RLrIOJ025318 for ; Thu, 27 Sep 2012 14:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348782803; bh=M+CeqKUWHIkaAFIkL1LaatC7cZWs8rCwe8LsuiwqOYQ=; h=Date:To:From:Subject:Cc; b=AGO4PGgBo4kzVE/mggUqvN886fdCEgFtGX+bi3pDwqHjlWGbQUwi5EWUE5dnB/YCa zntIq+2nK42WYHcPvFL+qpdhOhiguqUb2o4BS9HPpVEmzM/JUWjsRhyldlvzoX9vS+ TReb0evtmIqJeBcjJyFaYPkRn1H6/yjsssD5CNvk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1348782803; i=@resistor.net; bh=M+CeqKUWHIkaAFIkL1LaatC7cZWs8rCwe8LsuiwqOYQ=; h=Date:To:From:Subject:Cc; b=TP9B+kuyVv7WrwWrDyRm8WV6oWYyTECBaJGJHWDSrW9mPb1oQmk4o5fyCgAzuDZwS TC9R3AS/vmxJHKKofEAR6JfI1wLDkIjUg3MR+BM8dhvdeR1z29jTUQBjn7qmbDcjvU /Ou9QVejpCxOWzgEF3hUemDdcpQuT1wPPdEXctKY= Message-Id: <6.2.5.6.2.20120927143342.0a7102a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 27 Sep 2012 14:49:37 -0700 To: weirds@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [weirds] Comments on draft-ietf-weirds-rdap-sec-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2012 21:53:24 -0000 Hello, These comments are on draft-ietf-weirds-rdap-sec-00. Please note that this is not a review. In the Introduction Section: "One goal of RDAP is to provide security services that do not exist in the WHOIS protocol" One of the questions that may be asked is why is security not part of the protocol. RFC 4949 is more of a glossary. If I recall correctly, it has been used for some specification. I am not sure whether it is a correct reference. In Section 3.5: "TBD: does it make sense to talk about proof of integrity and data origin authentication for responses?" I would say yes. I suggest forgetting the law enforcement angle and look at this in terms of data integrity. As a quick comment, I think that it may be easier to avoid non-repudiation. It may be easier to focus on "securing" the protocol instead of looking at this from a data point of view. Regards, -sm From andy@arin.net Fri Sep 28 05:54:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1EA21F8512 for ; Fri, 28 Sep 2012 05:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtqk1lkL1S2K for ; Fri, 28 Sep 2012 05:54:07 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 7491521F84CD for ; Fri, 28 Sep 2012 05:54:07 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 7A13F213650; Fri, 28 Sep 2012 08:54:06 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id C7BE221363C; Fri, 28 Sep 2012 08:54:05 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 28 Sep 2012 08:53:28 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.151]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 08:53:46 -0400 From: Andy Newton To: SM Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-00.txt Thread-Index: AQHNl/cGa32OKzPRrECa4fkIO4iZYpeVT84AgAmvg4CAAMFVgA== Date: Fri, 28 Sep 2012 12:53:45 +0000 Message-ID: In-Reply-To: <6.2.5.6.2.20120927134821.0a3de260@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <6CD2FD8DE40ADF45B139F95ED7A8818D@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2012 12:54:08 -0000 On 9/27/12 5:21 PM, "SM" wrote: >There are a lot of normative references. Are all of them really >necessary? Since the references for the data types are now in json-response, we can probably break some of them away. > >The RFC 2119 boilerplate is missing. Probably because we aren't use 2119 language. > >In the Abstract Section the usage of RDAP is described as using >HTTP. There isn't any mention of RESTful as in the Introduction Section. Good point. > >It is better not to restate HTTP requirements. The HTTP folks might >not like that. :-) Ok. > >The question I would ask is what is the document about. I would get >rid of the SAC-051. As far as I am aware this working group is not >producing a specification in accordance with the SSAC Report. I >suggest looking at the document from a specification >perspective. =20 Well, the reference to SAC-051 isn't as important under a unified model as it was before. However, the term "RDAP" does come from SAC-051. >That may make it easier to get the flow of how to >organize the material. There isn't any Security Considerations >section. It's better to start thinking of that early in the process. See draft-ietf-weirds-rdap-sec. > >In Section 4.1: > > "Accept: applicaiton/rdap+json;level=3D0" > >There is a typo for "application". Good catch. Also, I need to take out the level stuff per a thread here earlier. -andy From sm@resistor.net Fri Sep 28 08:47:16 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801DA21F863F for ; Fri, 28 Sep 2012 08:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coBxTZURc-+9 for ; Fri, 28 Sep 2012 08:47:15 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA81E21F85A2 for ; Fri, 28 Sep 2012 08:47:15 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8SFlAVd027832 for ; Fri, 28 Sep 2012 08:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348847234; bh=RZwNcv4PmN/byl6lVQ5oQ1dqJcsc26Fxk5Wy3g5hzwA=; h=Date:To:From:Subject:Cc; b=Ne27qveLnF3KYtLwbul59S35qJJLbu5yIzHEvRTriv0z5IEuLUWfhv9D3qiSPqSiP dPN/s/YrR8QWnvazu2AFuC0iXUPg+zjhZyfwFcmMZOKE9y8vMEK7uanYGVjIaci3yd 020Jp2octu0Z6h8W7Ju5Gd3n1ITRv9DO4tGkmOps= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1348847234; i=@resistor.net; bh=RZwNcv4PmN/byl6lVQ5oQ1dqJcsc26Fxk5Wy3g5hzwA=; h=Date:To:From:Subject:Cc; b=PdYsDpfxil8NjfKqhA6MxsrFzTlEa5xGOFyxC5kPTqubygSggeXavlc66Sge93PsA ytFllkcuwd4ZYc9FMw8ch7n1bG27dy2r+yC4BPsfkWfR6mTxdJldZ1c4FE0wQlQCI1 q98z+flQAASL7HhchwwFYFNvxu/Ud7k8X8ywWxmk= Message-Id: <6.2.5.6.2.20120928070525.0b79b210@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 28 Sep 2012 08:00:06 -0700 To: weirds@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [weirds] Comments on draft-ietf-weirds-rdap-query-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2012 15:47:16 -0000 Hello, Here are some quick comment on draft-ietf-weirds-rdap-query-00. Please note that this is not a review. The RFC 2119 boilerplate is missing. There is a long list of normative references. Could the list be pruned to what is really needed? From the Introduction Section: "The protocol described in this specification is intended to address deficiencies with the WHOIS protocol [RFC3912] that have been identified over time, including: o Lack of standardized command structures, o lack of standardized output and error structures, o lack of support for internationalization and localization, and o lack of support for user identification, authentication, and access control." I don't see any mention of user identification, authentication and access control in the draft. If that is being addressed in another draft, I suggest having a pointer to the draft for now. I suggest deferring the question of where the material should be until the work is in better shape. 'While HTTP contains mechanisms for servers to authenticate clients and for clients to authenticate servers (from which authorization schemes may be built), both authentication of clients and servers and authorization for access to data are out-of-scope of this document. In general, these matters require "policy" and are not the domain of technical standards bodies.' The draft mentions that the intention is to address deficiencies, e.g. authentication. It then argues that authentication and authorization are out of scope for the document. Is that a good idea? As a general comment, if a matter is a policy decision, it might be easier to say so instead of explaining that it is not in the domain of technical standard bodies. "The patterns described in this document purposefully do not encompass all of the methods employed in the WHOIS and RESTful web services of all of the RIRs and DNRs." I suggest expanding RIR and DNR on first use. "The intent of the patterns described here are to enable lookups of networks by IP address, autonomous system numbers by number, reverse DNS meta-data by domain, domains by name, name servers by name, registrars by name, and entities (such as contacts) by identifier. It is envisioned that each registry will continue to maintain NICNAME/WHOIS and/or RESTful web services specific to their needs and those of their constituencies, and the information retrieved through the patterns described here may reference such services." I suggest forgetting about ICANN, RIRs, gTLDs and ccTLDs. It may be easier to explain which type of queries are being defined in the specification and leave it at that. "WHOIS services, in general, are read-only services. Therefore URL [RFC3986] patterns presented here are only applicable to the HTTP [RFC2616] GET and HEAD methods." Why? It's easier to say that this is about an information retrieval mechanism and which methods should be used. "Additionally, resource management, provisioning and update functions are out of scope for this document. Registries have various and divergent methods covering these functions, and it is unlikely a uniform approach for these functions will ever be possible." As the above was not part of the problem description, it's easier to ignore all of that instead of providing an explanation. In Section 2.1: "Semantically, the simpler form using the address can be thought of as a CIDR block with a length of 32 for IPv4 and a length of 128 for IPv6." This sounds like tutorial material. In Section 4: "Clients with graphical user interfaces may prefer a U-label since this is more visually recognizable and familiar than A-label strings, but clients of programmatic interfaces may wish to submit and display A-labels or may not be able to input U-labels with their keyboard configuration." I suggest avoiding user interface details. Regards, -sm From andy@arin.net Fri Sep 28 09:10:06 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6C21F8499 for ; Fri, 28 Sep 2012 09:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRUTpHaUr74w for ; Fri, 28 Sep 2012 09:10:06 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id BDA2E21F8489 for ; Fri, 28 Sep 2012 09:10:05 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 331C3213683; Fri, 28 Sep 2012 12:10:05 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 45410213647; Fri, 28 Sep 2012 12:10:04 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 28 Sep 2012 12:09:38 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.151]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 12:09:57 -0400 From: Andy Newton To: SM , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-rdap-query-00 Thread-Index: AQHNnZCNNYd1tFvc/0qNdYj2kVtAepef7ESA Date: Fri, 28 Sep 2012 16:09:56 +0000 Message-ID: In-Reply-To: <6.2.5.6.2.20120928070525.0b79b210@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2012 16:10:06 -0000 Thanks SM. By my count your tab for Atlanta is now pre-populated with three beers. On 9/28/12 11:00 AM, "SM" wrote: >The RFC 2119 boilerplate is missing. There is a long list of >normative references. Could the list be pruned to what is really needed? We can take a look at the reference list. As for 2119 language, there is only one "MUST" in the document (outside of boilerplate). We can take that out or convert to 2119 language. >I don't see any mention of user identification, authentication and >access control in the draft. If that is being addressed in another >draft, I suggest having a pointer to the draft for now. Yes, that would be the rdap-sec draft. >The draft mentions that the intention is to address deficiencies, >e.g. authentication. It then argues that authentication and >authorization are out of scope for the document. Is that a good idea? Unfortunately, stating repeatedly that the IETF is a standards body and doesn't do policy seems necessary in the Whois space. At least that is my experience. Now, we should probably make that text normative in the rdap-sec draft so we don't have to repeat it everywhere. >As a general comment, if a matter is a policy decision, it might be >easier to say so instead of explaining that it is not in the domain >of technical standard bodies. > > "The patterns described in this document purposefully do not encompass > all of the methods employed in the WHOIS and RESTful web services of > all of the RIRs and DNRs." > >I suggest expanding RIR and DNR on first use. > > "The intent of the patterns described here are to enable lookups of > networks by IP address, autonomous system numbers by number, > reverse DNS meta-data by domain, domains by name, name servers by > name, registrars by name, and entities (such as contacts) by > identifier. It is envisioned that each registry will continue to > maintain NICNAME/WHOIS and/or RESTful web services specific to their > needs and those of their constituencies, and the information retrieved > through the patterns described here may reference such services." > >I suggest forgetting about ICANN, RIRs, gTLDs and ccTLDs. It may be >easier to explain which type of queries are being defined in the >specification and leave it at that. This may be the wrong place to do it, but identifying the target audience is important I think. > "WHOIS services, in general, are read-only services. Therefore URL > [RFC3986] patterns presented here are only applicable to the HTTP > [RFC2616] GET and HEAD methods." > >Why? It's easier to say that this is about an information retrieval >mechanism and which methods should be used. > > "Additionally, resource management, provisioning and update functions > are out of scope for this document. Registries have various and > divergent methods covering these functions, and it is unlikely a > uniform approach for these functions will ever be possible." > >As the above was not part of the problem description, it's easier to >ignore all of that instead of providing an explanation. I beg to differ. ARIN has multiple RESTful services and we have had people confuse their purpose. It is best to identify the target audience for clarity. Now, we can perhaps argue if this is the right place to do it. >In Section 2.1: > > "Semantically, the simpler form using the address can be thought of as > a CIDR block with a length of 32 for IPv4 and a length of 128 for > IPv6." > >This sounds like tutorial material. Yup, it is. But so are examples in RFCs and we do that all the time. Text to add clarity is a good thing, I think. > >In Section 4: > > "Clients with graphical user interfaces may prefer a U-label since this > is more visually recognizable and familiar than A-label strings, but > clients of programmatic interfaces may wish to submit and display > A-labels or may not be able to input U-labels with their keyboard > configuration." > >I suggest avoiding user interface details. Conversion between A-label and U-label is important, and noting where in the system that conversion occurs is very important. IMHO. Actually, I think this nit check deserves two beers. -andy From sm@resistor.net Fri Sep 28 12:58:15 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0821F8464 for ; Fri, 28 Sep 2012 12:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOsWYa63VyDd for ; Fri, 28 Sep 2012 12:58:14 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EB021F8460 for ; Fri, 28 Sep 2012 12:58:14 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8SJw3bR003733; Fri, 28 Sep 2012 12:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348862288; bh=3oumlkSOVN/hekIV5h151oej+mxvBacIMlNApQNEBLg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IpN7qkekpRIVUfmGo2xq18MAAw8pD7kkfbNxFWHxQs49YoPx08aWLxL3y5yKSBqL8 XkZjv8/ZH6fl9A6fWeW3p16GiQcLhJ+nFrXybcr8FJdgcqMhut6PyzxAjGaDnWhEG6 lrFAEbKuPWBtBdjrTTLJUXjVFPG8cvgO8Y5YKT8M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1348862288; i=@resistor.net; bh=3oumlkSOVN/hekIV5h151oej+mxvBacIMlNApQNEBLg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2x9+XREoiRMAc6hnjM0DpWMSWdySrnsq9kNcVaUyQjOAYP1VvH5VUSciXcE8Wo6m8 4fARU8hloxW51qRNPvaPhMoruhTBTcFDMdsOZDeMJKNxT6Est6xEsQCY59fPw7Q2yw KxIxLxn7rnlxC1bdRKlUNY3VwroRYq3xvYCnOs3Y= Message-Id: <6.2.5.6.2.20120928110502.0b77e240@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 28 Sep 2012 12:36:43 -0700 To: Andy Newton From: SM In-Reply-To: References: <6.2.5.6.2.20120928070525.0b79b210@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2012 19:58:15 -0000 Hi Andy, At 09:09 28-09-2012, Andy Newton wrote: >Thanks SM. By my count your tab for Atlanta is now pre-populated with >three beers. Thanks. :-) >Unfortunately, stating repeatedly that the IETF is a standards body and >doesn't do policy seems necessary in the Whois space. At least that is my >experience. Now, we should probably make that text normative in the >rdap-sec draft so we don't have to repeat it everywhere. I understand your intent and I am not disagreeing with it. You may have noticed that my reading of the text is different from the intent. The document will be reflecting IETF Consensus. The paragraph, taken by itself, is incorrect as it can be read as a general statement. It is appropriate to specify a mechanism to ensure interoperability. >I beg to differ. ARIN has multiple RESTful services and we have had people >confuse their purpose. It is best to identify the target audience for >clarity. Now, we can perhaps argue if this is the right place to do it. With all due respect I think that we are talking about two different things here. My point was about a specification defining the Unified Registration Data Access Protocol Query Format. It's not about WHOIS and RESTful web services provided by ARIN. I agree that it is best to identify the target audience for clarity. I'll write this as general comments as it may be relevant for the other drafts. (i) What is the purpose of the draft? (ii) What is the target audience? >Yup, it is. But so are examples in RFCs and we do that all the time. Text >to add clarity is a good thing, I think. Some of these RFCs end up causing headaches. >Conversion between A-label and U-label is important, and noting where in >the system that conversion occurs is very important. IMHO. > >Actually, I think this nit check deserves two beers. It's my lucky day; two beers for a nit. :-) In Section 2.4: "Internationalized names represented in A-label format [RFC5890] are also valid name server names." As you settled for A-label format, you could use the "wire format" argument for the protocol. You can then leave it to draft-ietf-weirds-json-response-00 to address other internationalization-related issues. Regards, -sm