From nobody Fri Oct 3 14:13:38 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E94B1A70FE for ; Fri, 3 Oct 2014 14:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d8JJLP4FLMa for ; Fri, 3 Oct 2014 14:13:28 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E9D1A702F for ; Fri, 3 Oct 2014 14:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412370809; x=1443906809; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ihBZcIPr3bFPMttDCOhqYGlbAmcra48rSkZ3zsg0jII=; b=AOhy8CUje9dgxoquHqWqK+X/ml4gp4AG5hZgx2DRvugDgEgsEG33EWbN 7wKouOONnhqrqep891cOeSlOfRzURp0lfmHaWFekb5omoTSFVaM2A800M rEOOZNzvNiS7ofiaBGI7OOKUknxu2ef3g0M7yWbYJZkB8xFAztpEknfy3 w=; X-IronPort-AV: E=McAfee;i="5600,1067,7580"; a="75412305" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 03 Oct 2014 14:13:28 -0700 X-IronPort-AV: E=Sophos;i="5.04,650,1406617200"; d="scan'208";a="31451778" Received: from nasanexhc16.na.qualcomm.com ([10.45.158.213]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Oct 2014 14:13:27 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc16.na.qualcomm.com (10.45.158.213) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 3 Oct 2014 14:13:27 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 3 Oct 2014 14:13:24 -0700 Message-ID: <542F1165.5020507@qti.qualcomm.com> Date: Fri, 3 Oct 2014 16:13:09 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (129.46.53.226) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/mqYt2-BaQEo3eAnGSG80goa_m3M Subject: [weirds] AD Reviews of documents coming X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 21:13:34 -0000 If you've been following, you'll notice that I failed to get my AD Reviews of the document set completed in time to make it on the 10/16 telechat as we had planned. (In my own defense, things did get to me a bit later than expected, and it was an impressive telechat this week, but that's water under the bridge.) I am going to get my reviews done this weekend. I'd ask that the authors and WG be prepared early next week to address any of my comments that might need answering prior to me sending out the Last Call. If I get them Last Called this coming week, we can definitely get them on the 10/30 telechat. I know we said that we'd do 10/16 or close the WG. But if the chairs and WG are OK with it, I'm OK with the 10/30 telechat. I'll plan on that unless I hear differently. Thanks for your hard work getting these done. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Oct 3 17:29:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6884A1A89E7 for ; Fri, 3 Oct 2014 17:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2ZViqvO-trk for ; Fri, 3 Oct 2014 17:29:06 -0700 (PDT) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0481A89E5 for ; Fri, 3 Oct 2014 17:29:05 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKVC8/ULPePPaQlNI1upE5AI7GGyazfSa8@postini.com; Fri, 03 Oct 2014 17:29:05 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s940T4dO023181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 20:29:04 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 3 Oct 2014 20:29:03 -0400 From: "Hollenbeck, Scott" To: Pete Resnick , "weirds@ietf.org" Thread-Topic: [weirds] AD Reviews of documents coming Thread-Index: AQHP307pkANpnNeYj0mKDXPIrd7ydpwfFVUg Date: Sat, 4 Oct 2014 00:29:04 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494D9726@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <542F1165.5020507@qti.qualcomm.com> In-Reply-To: <542F1165.5020507@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/e_mdU9g0lh_Xd3RMWZUFdqgCGEM Subject: Re: [weirds] AD Reviews of documents coming X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 00:29:07 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Pete Resnick > Sent: Friday, October 03, 2014 5:13 PM > To: weirds@ietf.org > Subject: [weirds] AD Reviews of documents coming >=20 > If you've been following, you'll notice that I failed to get my AD > Reviews of the document set completed in time to make it on the 10/16 > telechat as we had planned. (In my own defense, things did get to me a > bit later than expected, and it was an impressive telechat this week, > but that's water under the bridge.) I am going to get my reviews done > this weekend. I'd ask that the authors and WG be prepared early next > week to address any of my comments that might need answering prior to > me > sending out the Last Call. If I get them Last Called this coming week, > we can definitely get them on the 10/30 telechat. >=20 > I know we said that we'd do 10/16 or close the WG. But if the chairs > and > WG are OK with it, I'm OK with the 10/30 telechat. I'll plan on that > unless I hear differently. If you're OK with 10/30 it's certainly OK with me. Two more weeks won't hur= t anything. Scott From nobody Sat Oct 4 04:35:18 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0D41A026C for ; Sat, 4 Oct 2014 04:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmt-TIFPCDwJ for ; Sat, 4 Oct 2014 04:35:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BAB471A029C for ; Sat, 4 Oct 2014 04:35:13 -0700 (PDT) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0C25240402; Sat, 4 Oct 2014 07:35:11 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: <542F1165.5020507@qti.qualcomm.com> Date: Sat, 4 Oct 2014 07:35:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <14FEC960-D794-447D-AFD0-E868B4512357@viagenie.ca> References: <542F1165.5020507@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Te189cAF-ioLVsJiI0u7A9oxLQE Cc: weirds@ietf.org Subject: Re: [weirds] AD Reviews of documents coming X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 11:35:17 -0000 Le 2014-10-03 =E0 17:13, Pete Resnick a = =E9crit : > If you've been following, you'll notice that I failed to get my AD = Reviews of the document set completed in time to make it on the 10/16 = telechat as we had planned. (In my own defense, things did get to me a = bit later than expected, I thought the role of an AD was to compensate the wg delays by using his = own buffer and do instant review? ;-) my fault for delays on bootstrap. I apologize. > and it was an impressive telechat this week, but that's water under = the bridge.) I am going to get my reviews done this weekend. I'd ask = that the authors and WG be prepared early next week to address any of my = comments will do diligently this time. Hopefully, they won't be too large ;-) Marc. > that might need answering prior to me sending out the Last Call. If I = get them Last Called this coming week, we can definitely get them on the = 10/30 telechat. >=20 > I know we said that we'd do 10/16 or close the WG. But if the chairs = and WG are OK with it, I'm OK with the 10/30 telechat. I'll plan on that = unless I hear differently. >=20 > Thanks for your hard work getting these done. >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Sat Oct 4 08:04:29 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272861A1A68 for ; Sat, 4 Oct 2014 08:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jci2kZFKTmn for ; Sat, 4 Oct 2014 08:04:26 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 602571A0005 for ; Sat, 4 Oct 2014 08:04:26 -0700 (PDT) Received: from [192.168.1.100] (unknown [221.195.49.238]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0Dpj4R5DDBUl8AIAA--.19749S2; Sat, 04 Oct 2014 23:04:25 +0800 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ning Kong X-Mailer: iPhone Mail (12A405) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494D9726@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Sat, 4 Oct 2014 23:04:25 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <29FE4D8D-6B66-4D9F-A190-0FAC6BCF385B@cnnic.cn> References: <542F1165.5020507@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F494D9726@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-CM-TRANSID: AQAAf0Dpj4R5DDBUl8AIAA--.19749S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUY87k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26r1I 6r4UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAFwI0_Cr 1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAa Y2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4 A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Av z4vE14v_XrWl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17 MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I 0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU0 nmRUUUUUU== X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/374XiZcPM84M5mf-kOYuwEDX3FI Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Reviews of documents coming X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 15:04:28 -0000 > If you're OK with 10/30 it's certainly OK with me. Two more weeks won't hu= rt anything. +1 Ning= From nobody Mon Oct 6 21:59:28 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF691A1B17 for ; Mon, 6 Oct 2014 21:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbemPQhEcOFh for ; Mon, 6 Oct 2014 21:59:24 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E261A911E for ; Mon, 6 Oct 2014 21:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412657965; x=1444193965; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=BaqTjp/Mk2vVb31eKK5Sc7d0rXXJJmxIqAJCC/lj/WY=; b=vROns49DunY4AB+PxNKUgjxa7a7V+s9DIshHNtuJjr/VcM/LYGJDrGxN sRZOmyF59MUVeYKUOmTDcZPGM/IPV1fYxyFe+0EWA1tHr3is10QsU+Q0E ndFHIHI6+YGBozEuaeXKJNwjipwWHJVjj/C25A0NBK1EUrfevxTTG57zt g=; X-IronPort-AV: E=McAfee;i="5600,1067,7583"; a="164104683" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2014 21:59:24 -0700 X-IronPort-AV: E=Sophos;i="5.04,667,1406617200"; d="scan'208";a="819015040" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Oct 2014 21:59:23 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 6 Oct 2014 21:59:23 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 6 Oct 2014 21:59:05 -0700 Message-ID: <54337316.50708@qti.qualcomm.com> Date: Mon, 6 Oct 2014 23:59:02 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Th5g1JEqCL1CkUHUBe5mi5jadtU Subject: [weirds] AD Evaluation of draft-ietf-weirds-object-inventory-04 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 04:59:26 -0000 Summary: Ready for Last Call, needs a few small changes. I don't think any of these issues are controversial. Addressing them should be quite quick, and then I'm happy to Last Call. (If the timing is such that you can't do a rev in short order, I can Last Call it as-is, but would prefer to get the changes.) The nits checker reports long lines, "weird spacing", and pre-5378 boilerplate. A fix to the line-length/spacing issues would be appreciated, and removal of the pre-5378 boilerplate would be great. (I don't see anything plausibly pre-5378 in here.) I'm happy to ignore the 2606/5735 warnings; the examples in 5.4.1 are appropriate, I think, but it might be nice to check with the folks you are using as examples to make sure they are OK with their data appearing in an RFC. You mention in several places the "top three" labels or data elements, but give no reason anywhere in the document why that's an interesting thing of note. If that fact was used for some reason, you should probably mention it in section 1 or 3. 6.1 - The definition of "list of resources" isn't great. I don't know what an "Internet resource" is, and I don't know what "include" means in the context of a definition. 6.2 - s/handle/identifier 10 - The division of "Normative" and "Informative" references in this document strikes me as somewhat arbitrary. I'd probably make them all "Informative". pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Oct 6 22:00:02 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE96D1A911E for ; Mon, 6 Oct 2014 21:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHYEBW1ivBXt for ; Mon, 6 Oct 2014 21:59:56 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCEB1A1B17 for ; Mon, 6 Oct 2014 21:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412657996; x=1444193996; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=Zg2II7X0HJxszdD8gh9axot31m+FFHyo9IejlAPKWXo=; b=WWXjEwiViMLc+6GWpoNbBBOv8IOpReGDe6iMRY3X6aeCkugf2bNb+Z1V WjVotKqFJVPlRUb+bLQOKHvseV+CHrWRnlm4H8hXxFGCYFhNNvM3UlrYz +DVcrs9GpFWeGL4BsjWgFPPtkMuYdy/HeutACxsHs4RoouGA/Ui8M1S7v o=; X-IronPort-AV: E=McAfee;i="5600,1067,7583"; a="75568086" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2014 21:59:55 -0700 X-IronPort-AV: E=Sophos;i="5.04,667,1406617200"; d="scan'208";a="750169198" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Oct 2014 21:59:55 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc11.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 6 Oct 2014 21:59:54 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 6 Oct 2014 21:59:23 -0700 Message-ID: <54337328.8010605@qti.qualcomm.com> Date: Mon, 6 Oct 2014 23:59:20 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/sI2nIhzAk44eg6Ymk2Avn266YTI Subject: [weirds] AD Evaluation of draft-ietf-weirds-rdap-query-14 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 04:59:58 -0000 Summary: Ready for Last Call, needs a few small changes, and I have a few questions. I don't think any of these issues are controversial. Addressing them should be quite quick, and then I'm happy to Last Call. (If the timing is such that you can't do a rev in short order, I can Last Call it as-is, but would prefer to get the changes.) 2 - A reference to using-http should probably appear pretty close to the top of this section. 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. and It is also envisioned that each registry will continue to maintain WHOIS and/or RESTful web services Don't you mean "other web services", not "RESTful web services", in each of these places? RDAP-over-HTTP is the RESTful web service in this context, isn't it? Suggest changing "JSON [RFC7159] result formatting and processing" to "The specification of these entities". The current wording is a bit awkward. 3 - Suggest changing "For entities: Retrieve a base URL for the service" to "For entities, a base URL is retrieved for the service" and changing "For help: Retrieve a base URL for any service" to "For help, a base URL for any service". 3.1.1 - I think you can s/[RFC1166]/dotted-decimal here. 3.1.3/3.1.4 - Internationalized domain names represented in either A-label or U-label format [RFC5890] are also valid domain names. Please add on to the end, "See section 4 for information on character encoding for the U-label format." 4 - I think you should swap sections 4.1 and 4.2. The reference to section 4 from 3.1.3, 3.1.4, 3.2.1, and 3.2.2 should lead the reader to the encoding stuff right away. I think it's more useful to have 4.2 appear first. Or you could move all (or most) of 4.2 into section 6 and then refer to it there. 4.2 - You may want to add to the second paragraph: UTF-8 encoded strings are then appropriately percent-encoded [RFC3986] in the query URL. and then maybe start the third paragraph with "After parsing any percent-encoding, ". Maybe check with some URLy people about whether I got the wording right. 6. I don't really understand the normative reference to 4290. Why is this normative? -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Oct 6 22:00:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C934D1A9124 for ; Mon, 6 Oct 2014 22:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjL-e5-bHSnE for ; Mon, 6 Oct 2014 22:00:28 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442E11A1B17 for ; Mon, 6 Oct 2014 22:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412658029; x=1444194029; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=l7eMKoSzSvbUOZZmi+R7Qauy/LyZ0ZJ9tYi/sKbMdiE=; b=OEkQrfSh76C0ohRvyN2qcNfrTc0K4hqNRRWkReuckglxi0f5n8divtzL oIOKlF4E5woko2cpIMg/IiDAbeANg7mEDJv1T2dnm0/++eqY9D9K9kImM nkUKkt0PJOyUQTqQrw5nXEefFyklgcwpFE47yExaiHA6MH6qUL7c3MegL I=; X-IronPort-AV: E=McAfee;i="5600,1067,7583"; a="164104907" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2014 22:00:28 -0700 X-IronPort-AV: E=Sophos;i="5.04,667,1406617200"; d="scan'208";a="750170054" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Oct 2014 22:00:25 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 6 Oct 2014 22:00:24 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 6 Oct 2014 22:00:05 -0700 Message-ID: <54337343.4050101@qti.qualcomm.com> Date: Mon, 6 Oct 2014 23:59:47 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.46.201.191) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/w16bQpAD7X29C2MN8_Efgl0al3s Subject: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 05:00:31 -0000 Summary: Almost ready for Last Call, but definitely needs a rev first None of these issues are complicated or showstoppers, but there are a number of them, along with a few questions. So I'd like to have the WG address these before I Last Call the document. Throughout - Use of "client" and "server" in this document sometimes seems strained. Mostly you're talking about interpreters/parsers and producers/generators. You might want to review this throughout. I've made some specific comments below. Also note that I have not reviewed all of the examples in detail. I hope the WG has done a good scrub. 1 - I would mention in the first paragraph that using-http defines a communications protocol for exchanging queries and responses. It seems like maybe the Terminology section should come before everything else in this section, given that a lot of the terminology is used here. In the second to last paragraph, either lowercase the MUST or make it "needs to". It's not an interoperability statement. 3.1 - I think if you take my suggestion in the intro, you don't need this section. 3.2 - You went a little MUST/SHOULD/MAY crazy in this section. I hope the following suggested replacements are helpful (and I replace "client" with "parser" and "server" with "generator" in my example): Paragraph 1: Parsers of these JSON responses SHOULD ignore unrecognized JSON attributes in responses. Generators can insert values into the JSON responses which are not specified in this document, but that does not constitute an error in the response. Generators which insert such unspecified values into JSON responses SHOULD have names prefixed with a short identifier followed by an underscore followed by a meaningful name. These short identifiers aid software implementers with identifying the specification of the JSON name, and failure to use one could cause an implementer to assume the generator is erroneously using a name from this specification. This allowance does not apply to jCard ([RFC7095]) objects. The full JSON name (the prefix plus the underscore plus the meaningful name) SHOULD adhere to the character and name limitations of the prefix registry described in [I-D.ietf-weirds-using-http]. Failure to use these limitations could result in slower adoption as these limitations have been given to aid some client programming models. Next to last paragraph: Parsers processing JSON responses need to be prepared for values specified in this document to be absent from a response, as no JSON value listed is required to appear in a response. In other words, generators are free to not included values based on their own policies. 4 - I don't think the reference to 1166 is necessary. Dotted-decimal notation is well-known enough. Simply strike, "described in [RFC1166]", and the reference. 5.1 - Oh, do I hate the word "conformance"! Of course, I will likely survive. I also wonder why you went with "rdap_level_0" instead of a numeric RFC number here. But again, I will live. When custom JSON values are inserted into responses, conformance to those custom specifications SHOULD use a string prefixed with the appropriate identifier from the IANA RDAP Extensions registry specified in [I-D.ietf-weirds-using-http]. So, I presume that "SHOULD" is there because collisions would be bad. If that is the case, I would simply say, "MUST use a string...in order to avoid collisions", because I can't think of a good reason not to. If slower adoption (noted later) is the only reason for the SHOULD, then it's bogus and ought to be removed. 5.2 - The "value", "rel", and "href" JSON values MUST be specified. All other JSON values are optional. I presume the "MUST be specified" is there because this is a requirement of 5988, not because it is a new requirement of this document. If so, change that to "are required by [RFC5988]". If this is a new requirement of this document, then there should be an explanation of why this is required, and the "optional" in the second sentence should be "OPTIONAL". 5.5 - If you're going to use a SHOULD, I should be able to figure out why this is a requirement and what exceptions there are to make it a SHOULD and not a MUST. Neither is clear. If this isn't a real requirement, then I would change "SHOULD be" it "is" and be done with it. 5.9 - This data structure, named "objectClassName", gives the object class name of a particular object as a string. This aids clients in identifying the type of object being processed. Servers MUST NOT omit this string so that clients can more easily identify the type of object. "Aids" clients? "MUST NOT omit this string so that clients can more easily identify"? These seem like really weak reasons. How about simply the following? This data structure, named "objectClassName", gives the object class name of a particular object as a string. This identifies the type of object being processed. An objectClassName is REQUIRED in all RDAP response objects so that the type of the object can be interpreted. 6 - When present, clients MAY use the self link for caching data. I don't understand that MAY. What option is trying to be conveyed here? Is this a using-http thing? Self links SHOULD contain a "type" element containing the "application/rdap+json" media type when referencing RDAP object instances as defined by this document. Again, no explanation of why it SHOULD contain a "type" element, and no explanation of a reason for an exception. Please explain. Clients SHOULD NOT assume self links without this media type are represented as RDAP objects as defined by this document. I'm not sure how to implement a "SHOULD NOT assume". Do you really mean something like the following? Clients MAY/SHOULD/MUST discard objects containing self links without a media type, as they might not be RDAP objects as defined by this document. 6.1 - For illustrative purposes, it does not include rdapConformance or notices data structures. That sentence occurs a lot throughout the document. Are rdapConformance or notices required? If not, I would strike this sentence. If they are required, you had better say so back in section 5. I would move the following: Entities may also have other entities embedded with them in an array. This can be used to model an organization with specific individuals fulfilling designated roles of responsibility. The following is an elided example of an entity with embedded entities. and Figure 13 *below* the bulleted list. It confused me here. o vcardArray -- a JSON vCard with the entity's contact information s/a JSON vCard/one or more JSON vCards. It is an array, after all. 6.4/6.5 - o country -- a string containing the name of the two-character country code of the network Strike "the name of". 7 - A client MAY simply use the HTTP response code as the server is not required to include error data in the response body. However, if a client wishes to parse the error data, it SHOULD first check that the Content-Type header contains the appropriate media type. This paragraph seems more appropriate for the using-http document. 11.1 - Seems like a reference to rdap-sec might be useful here. I find it weird (no pun intended) to have an individual be the contact/author for a standards registration. Shouldn't it be the IESG or the WG or something? Maybe I'll ask Barry. 11.2 - This registry should be governed by a designated expert or multiple designated experts. Registration of values into this registry should be accomplished by providing the information above to the designated expert(s). Probably simpler (and clearer) for IANA if you simply say, "This registry is to be operated under the "Expert Review" policy defined in RFC 5226." The IESG will make sure about the one or multiple experts, and IANA wil make sure that they get the appropriate information. Just before 11.2.1, please add: "The following sections provide initial registrations into this registry." I still find it strange to have an individual registrant for these registrations. I did not review the individual registrations in detail. 13.1 - Servers and clients MAY optionally support other character encodings. How does *that* work? How is a different encoding indicated? This seems like a discussion for the using-http document. 14 - I suspect you're going to be asked for more here. I don't have the expertise to give you advice in this area, but you might want to check with Alissa Cooper about who might. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Oct 6 22:01:17 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2242E1A9124 for ; Mon, 6 Oct 2014 22:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARAhQp_aHxWL for ; Mon, 6 Oct 2014 22:01:00 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB831A1B17 for ; Mon, 6 Oct 2014 22:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412658060; x=1444194060; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=+/lA3xKU1OK8XOGvIx59RC6JLGajmPdZOC1ye87gl/E=; b=qQAImujapHGUuv2QWULlq5DR6ZtKTfK8q6cT+oJlyvi9SXmZxarkdj0q Aa5oZOnQ6o+FfRonGODGvjW3yES7vJ4v3a5+gr5GwFLPqn+yRSIkDvgRS kyc/MVMDm6wZuRtqpOBxiJ5RenG3pia+DXvzBjBkFFvpYAATx8KiiKTzC 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7583"; a="75568120" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2014 22:00:59 -0700 X-IronPort-AV: E=Sophos;i="5.04,667,1406617200"; d="scan'208";a="750170243" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Oct 2014 22:01:00 -0700 Received: from NASANEXM01F.na.qualcomm.com (172.30.48.1) by nasanexhc06.na.qualcomm.com (172.30.48.21) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 6 Oct 2014 22:00:59 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 6 Oct 2014 22:00:41 -0700 Message-ID: <54337372.2010105@qti.qualcomm.com> Date: Tue, 7 Oct 2014 00:00:34 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.46.201.191) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ypi6gNoB38irug65h_YFh95FFYM Subject: [weirds] AD Evaluation of draft-ietf-weirds-using-http-12 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 05:01:11 -0000 Summary: Small changes and then ready for Last Call. I don't think any of these issues are controversial. Addressing them should be quite quick, and then I'm happy to Last Call. 1 - This is the basic usage pattern for this protocol: I really think you need to be clearer about bootstrap and base URLs in this section. You should also use an example that's closer to the examples in rdap-query. I suggest the following replacement text for 1 & 2: 1. A client determines an appropriate server to query along with the appropriate base URL to use in such queries. [I-D.ietf-weirds-bootstrap] describes one method to determine the server and the base URL. See Appendix C for more information. 2. A client issues an HTTP (or HTTPS) query using GET [RFC7231]. As an example, a query for the network registration 192.0.2.0 might be http://example.com/rdap/ip/192.0.2.0 [I-D.ietf-weirds-rdap-query] details the various queries used in RDAP. Strike the last sentence of item 3. Of course non-standard things can be used. They're not standard. No need to mention them here. Mentioning them in the design criteria in section 3 is more than sufficient. (I'm not a big fan of it appearing there either, but it's acceptable as a design criteria.) 4.1 - Move the first sentence after the second and third, and make the second and third active voice: Clients use the GET method to retrieve a response body and use the HEAD method to determine existence of data on the server. Clients SHOULD use either the HTTP GET or HEAD methods (see [RFC7231]). I think it flows much better this way. 5 - at a minimum clients SHOULD understand the response codes described in this section as they will be in common use by servers. The SHOULD in there seems silly. I think what you really mean is: this section defines the minimal set of response codes in common use by servers that a client will need to understand. 5.5 - Clients that do not honor the Retry-After header may stricter limits placed upon them. Do you mean, "Servers may place stricter limits upon clients that do not honor the Retry-After header"? That's probably a clearer way to say it. 9.2 - The mechanism for including a language identifier in a response will be defined in subsequent documents describing specific response formats. Instead, I think it's better to say: [I-D.ietf-weirds-json-response] provides such a mechanism. Appendix A/B - I think you should include "/rdap" in the query examples, the same way you have rdap-query examples. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Oct 6 22:01:39 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6EB1A1B17 for ; Mon, 6 Oct 2014 22:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1swg96aLR_tV for ; Mon, 6 Oct 2014 22:01:22 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625D31A912D for ; Mon, 6 Oct 2014 22:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412658083; x=1444194083; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ExmvWoKuiRd9TgnrR4d+Q8mvLA6fwPqfAcf8g1Mp72k=; b=u9dsT6u7QjECaZneexla8Z4IfQAdTh+QFghvvx+Fy0KvfXj1rkaxm0jE rdPnXfm+BfgKBPW0Eb91MIr+8y5Z9McGvIe2TAyoehOMu4Mh3kzQMMFOV cz+3q/Qa8tL8QHM/QDBlLTXJwkRDrSZ5d2irnGS5naDgFj3GS9bjxtoiz c=; X-IronPort-AV: E=McAfee;i="5600,1067,7583"; a="72373460" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2014 22:01:22 -0700 X-IronPort-AV: E=Sophos;i="5.04,667,1406617200"; d="scan'208";a="750170294" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Oct 2014 22:01:22 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 6 Oct 2014 22:01:21 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 6 Oct 2014 22:01:08 -0700 Message-ID: <54337380.3000006@qti.qualcomm.com> Date: Tue, 7 Oct 2014 00:00:48 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (129.46.53.236) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/K3VHzC7Zxoz_p8QD4x5Y--6f-X4 Subject: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 05:01:26 -0000 Summary: Ready for re-Last Call This document is ready to go. I could go straight to the IESG with this, but I'm inclined to give it another Last Call with all of the documents so that people can read them as a set. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Oct 6 22:01:52 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F02A1A1B17 for ; Mon, 6 Oct 2014 22:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD9i4Lv_BMLw for ; Mon, 6 Oct 2014 22:01:49 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141781A911E for ; Mon, 6 Oct 2014 22:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412658109; x=1444194109; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=BNI/SNGwQMjl8dLn5Uf0V/KWPmgQKT7eH3UVmRZrIEk=; b=GubEK1DCocsbPUGj2hgGHFYI0FTsPTDmqATZFtuLmYsus2Acs4qCiKmG ylGf+yEIJdO8mHH/cIC2rzLH7NcYcbBp2WchujyJkTbf/418BOcjkEMLK RnWJKUrYfVgn8kQsPkt+72ojZ/XC3f7J3VUsc69Dvm+et7JT+aGMhJwxj o=; X-IronPort-AV: E=McAfee;i="5600,1067,7583"; a="76198084" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2014 22:01:48 -0700 X-IronPort-AV: E=Sophos;i="5.04,667,1406617200"; d="scan'208";a="750170312" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Oct 2014 22:01:48 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 6 Oct 2014 22:01:47 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 6 Oct 2014 22:01:46 -0700 Message-ID: <543373B9.30402@qti.qualcomm.com> Date: Tue, 7 Oct 2014 00:01:45 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2k3vhS2BgrmwskD-9LB5_DcNkOU Subject: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 05:01:51 -0000 Summary: Not ready for Last Call. I've got some real concerns with this document that need to be addressed before I'm willing to Last Call it. Overall, I have no problem with the idea that this document is putting forward in order to have a bootstrap. However: 3 - The RDAP Bootstrap Service Registries are made available as JSON [RFC7159] objects. The JSON registry output... First of all, I don't know what you mean by "the JSON registry output", though I have a suspicion you're talking about the registry when it is retrieved as a JSON object. But you're making a mish-mash of what is the registry itself, how it's defined, and how it's retrieved. Here's my attempt at a replacement for the entire first paragraph that I think is *marginally* clearer: This document defines four RDAP Bootstrap Service Registries, specified in Sections 4 and 5. Each of these registries will have some metadata information about the registry itself, and the contents each registry will be a list of services. This document describes each of the registries as a JSON object. Information regarding how the information in this registry is made available by IANA is noted in Section 12. All four registries follow the same general structure. Described as a JSON object, each registry starts with a series of members that contain metadata about the registry such as a version identifier, a timestamp of the publication date of the registry and a description. Following that is in a "services" member which contains the registry items themselves, as an array. Each item of the array contains a second level array, with two elements, each of them being an array (third-level arrays). The first third-level array, named 'Entry array', contains all entries that have the same set of base RDAP URLs. The second third-level array, named 'Service URL array', contains the list of base RDAP URLs usable for the entries found in the 'Entry array'. There is no assumption of sorting except that the two arrays found in each second-level array MUST appear in the correct order: 'Entry array' first followed by 'Service URL array'. An example structure of the JSON output of a RDAP Bootstrap Service Registry is illustrated: But I've got to say that I don't really like that at either. It's one of the most convoluted ways I've ever seen to describe an IANA registry. I am not convinced that this will pass an IETF Last Call, let alone an IESG review. I really think you should have defined the registry in terms of a simple table with two columns, the first being the "Entries" column, and the second being the "Base URLs" column, and for each row in the table, there would be the entries for that particular service and the base URLs for that particular set of entries. Then, later in the document, you could describe the retrievable JSON format. The way you have it, you've tried to jam together the definition of the registry with the retrievable format of the registry. I am prepared to be convinced that this is ready to move forward, but at this point I am not inclined to Last Call this document. On the JSON itself: I presume that services is an array of an array of arrays to somehow shrink the size of the entries, but given that you're depending on the ordering of the second-level array, it sure would have been easier to track what the heck is in this thing if services were an array of objects containing arrays instead: { ... "services": [ { entries : ["entry1", "entry2", "entry3"], baseurls : [ "https://registry.example.com/myrdap/", "http://registry.example.com/myrdap/" ] }, { entries : ["entry4"], baseurls : [ "http://example.org/" ] } ] } Is the "array of arrays of arrays" idea a done deal? Other more minor comments: Throughout - Update RFC 4627 to RFC 7159 3 - Internationalized Domain Names labels used as entries or base RDAP URLs in the registries defined in this document MUST be only represented using their A-Label form as defined in [RFC5890]. Doesn't this contradict what appears in rdap-query? 7 - s/the client SHOULD provide/the client provides 8 - o If the client knows the existence of an RDAP aggregator or redirector and trusts that service, then it could send the query to the redirector, which would redirect the client if it knows the authoritative server that client has not found. I think you need to mention the base URL here: o If the client has previously discovered an RDAP aggregator or redirector and its associated base URL, and the client trusts that service, then it could send the query to the redirector, which would redirect the client if it knows the authoritative server that client has not found. 12 - IANA is requested to implement the following registries in JSON format conformant to the syntax defined in Section 10. That's incorrect, and it seems it was an uncorrection from -06 to -07. IANA doesn't "implement" registries. The registry is created by IANA. Independently, we are asking IANA to provide a JSON representation of the registry to be retrieved. Furthermore, nowhere in this section does it ever tell IANA that it is expected to populate these registries from its own data. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Oct 7 04:32:18 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B00F1A1B8E for ; Tue, 7 Oct 2014 04:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7ZfGsedBQBb for ; Tue, 7 Oct 2014 04:32:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 955B41A1B9A for ; Tue, 7 Oct 2014 04:32:11 -0700 (PDT) Received: from h118.viagenie.ca (h118.viagenie.ca [206.123.31.118]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3F66B40220; Tue, 7 Oct 2014 07:32:10 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: <543373B9.30402@qti.qualcomm.com> Date: Tue, 7 Oct 2014 07:32:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> References: <543373B9.30402@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/DZ4GE-tBIhkcOx3AnJ9Yat-Mbmo Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 11:32:17 -0000 Le 2014-10-07 =E0 01:01, Pete Resnick a = =E9crit : thanks for your review. > Summary: Not ready for Last Call. >=20 > I've got some real concerns with this document that need to be = addressed before I'm willing to Last Call it. >=20 > Overall, I have no problem with the idea that this document is putting = forward in order to have a bootstrap. However: >=20 > 3 - >=20 > The RDAP Bootstrap Service Registries are made available as JSON > [RFC7159] objects. The JSON registry output... >=20 > First of all, I don't know what you mean by "the JSON registry = output", this text was actually a suggestion from someone. We just put it. I'm = happy to change it. > though I have a suspicion you're talking about the registry when it is = retrieved as a JSON object. But you're making a mish-mash of what is the = registry itself, how it's defined, and how it's retrieved. Here's my = attempt at a replacement for the entire first paragraph that I think is = *marginally* clearer: >=20 > This document defines four RDAP Bootstrap Service Registries, > specified in Sections 4 and 5. Each of these registries will have > some metadata information about the registry itself, and the = contents > each registry will be a list of services. This document describes > each of the registries as a JSON object. Information regarding how > the information in this registry is made available by IANA is noted > in Section 12. >=20 > All four registries follow the same general structure. Described as = a > JSON object, each registry starts with a series of members that > contain metadata about the registry such as a version identifier, a > timestamp of the publication date of the registry and a description. > Following that is in a "services" member which contains the = registry > items themselves, as an array. Each item of the array contains a > second level array, with two elements, each of them being an array > (third-level arrays). The first third-level array, named 'Entry > array', contains all entries that have the same set of base RDAP > URLs. The second third-level array, named 'Service URL array', > contains the list of base RDAP URLs usable for the entries found in > the 'Entry array'. There is no assumption of sorting except that = the > two arrays found in each second-level array MUST appear in the > correct order: 'Entry array' first followed by 'Service URL array'. > An example structure of the JSON output of a RDAP Bootstrap Service > Registry is illustrated: >=20 >=20 > But I've got to say that I don't really like that at either. It's one = of the most convoluted ways I've ever seen to describe an IANA registry. = I am not convinced that this will pass an IETF Last Call, let alone an = IESG review. I really think you should have defined the registry in = terms of a simple table with two columns, the first being the "Entries" = column, and the second being the "Base URLs" column, and for each row in = the table, there would be the entries for that particular service and = the base URLs for that particular set of entries. Then, later in the = document, you could describe the retrievable JSON format. The way you = have it, you've tried to jam together the definition of the registry = with the retrievable format of the registry. I am prepared to be = convinced that this is ready to move forward, but at this point I am not = inclined to Last Call this document. - fine. I have to say again that IANA looked at it (both the technical = people and the registration people) and they were fine with the text. - the json format evolved into multiple level arrays, as requested by = implementors. A two columns table won't really show this structure. So = in some ways, we are just not used to define registries in complex JSON = formats. I guess I'm the guiney pig... >=20 > On the JSON itself: I presume that services is an array of an array of = arrays to somehow shrink the size of the entries, but given that you're = depending on the ordering of the second-level array, it sure would have = been easier to track what the heck is in this thing if services were an = array of objects containing arrays instead: >=20 > { > ... > "services": [ > { > entries : ["entry1", "entry2", "entry3"], > baseurls : [ > "https://registry.example.com/myrdap/", > "http://registry.example.com/myrdap/" > ] > }, > { > entries : ["entry4"], > baseurls : [ > "http://example.org/" > ] > } > ] > } >=20 > Is the "array of arrays of arrays" idea a done deal? I let implementors to comment on this one. >=20 > Other more minor comments: >=20 > Throughout - Update RFC 4627 to RFC 7159 >=20 > 3 - >=20 > Internationalized Domain Names labels used as entries or base RDAP > URLs in the registries defined in this document MUST be only > represented using their A-Label form as defined in [RFC5890]. >=20 > Doesn't this contradict what appears in rdap-query? humm. good point. This addition was from a review comment. I guess we = should think about this one. >=20 > 7 - s/the client SHOULD provide/the client provides >=20 > 8 - >=20 > o If the client knows the existence of an RDAP aggregator or > redirector and trusts that service, then it could send the query > to the redirector, which would redirect the client if it knows = the > authoritative server that client has not found. >=20 > I think you need to mention the base URL here: >=20 > o If the client has previously discovered an RDAP aggregator or > redirector and its associated base URL, and the client trusts = that > service, then it could send the query to the redirector, which > would redirect the client if it knows the authoritative server > that client has not found. >=20 > 12 - >=20 > IANA is requested to implement the following registries in JSON > format conformant to the syntax defined in Section 10. >=20 > That's incorrect, and it seems it was an uncorrection from -06 to -07. = IANA doesn't "implement" registries. The registry is created by IANA. = Independently, we are asking IANA to provide a JSON representation of = the registry to be retrieved. ok. >=20 > Furthermore, nowhere in this section does it ever tell IANA that it is = expected to populate these registries from its own data. yes. it is. In fact, we don't want, since the entries will be submitted = by the "owners" of the data, which will submit it through the policy = defined by IANA. The relevant text is: " It is envisioned that these new registries will have similar entries than the corresponding IANA allocation registries, such as [ipv4reg], [ipv6reg], [asreg], [domainreg], and possibly similar registration policies. Given that the data required by RDAP clients is limited compared to the content of the existing corresponding registries, and given that this data has to be made available in a JSON format using a specific key/value structure, this document is not defining an extension of the existing IANA allocation registries. The registration policies for the new registries of this document are left to IANA. " >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Tue Oct 7 05:22:59 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FF81A1BDC for ; Tue, 7 Oct 2014 05:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnUzDp_WyqhM for ; Tue, 7 Oct 2014 05:22:52 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6261A1BDA for ; Tue, 7 Oct 2014 05:22:37 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKVDPbDexPwa3MoyIsQk7Yhjb2Dm6vqj4C@postini.com; Tue, 07 Oct 2014 05:22:38 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 s97CMZM5025239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Oct 2014 08:22:35 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 08:22:34 -0400 From: "Hollenbeck, Scott" To: Pete Resnick , "weirds@ietf.org" Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-rdap-query-14 Thread-Index: AQHP4euQKBVF86H/CEmKyuod/hBhopwkf4xw Date: Tue, 7 Oct 2014 12:22:34 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494DC3F4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <54337328.8010605@qti.qualcomm.com> In-Reply-To: <54337328.8010605@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/rp6_B42gPVLB2bCq2aIQME1yLao Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-rdap-query-14 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 12:22:57 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Pete Resnick > Sent: Tuesday, October 07, 2014 12:59 AM > To: weirds@ietf.org > Subject: [weirds] AD Evaluation of draft-ietf-weirds-rdap-query-14 >=20 > Summary: Ready for Last Call, needs a few small changes, and I have a > few questions. >=20 > I don't think any of these issues are controversial. Addressing them > should be quite quick, and then I'm happy to Last Call. (If the timing > is such that you can't do a rev in short order, I can Last Call it > as-is, but would prefer to get the changes.) I'd much rather go to last call with all known issues addressed. I'll rev t= he doc. > 2 - A reference to using-http should probably appear pretty close to > the > top of this section. OK. > 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. >=20 > and >=20 > It is also envisioned that each > registry will continue to maintain WHOIS and/or RESTful web > services >=20 > Don't you mean "other web services", not "RESTful web services", in > each > of these places? RDAP-over-HTTP is the RESTful web service in this > context, isn't it? I think that's true, but I vaguely recall Andy saying that ARIN had somethi= ng else going on, too. Maybe he can chime in to confirm. "other web service= s" seems safe no matter what. > Suggest changing "JSON [RFC7159] result formatting and processing" to > "The specification of these entities". The current wording is a bit > awkward. OK. > 3 - Suggest changing "For entities: Retrieve a base URL for the > service" > to "For entities, a base URL is retrieved for the service" and changing > "For help: Retrieve a base URL for any service" to "For help, a base > URL > for any service". OK. > 3.1.1 - I think you can s/[RFC1166]/dotted-decimal here. OK. > 3.1.3/3.1.4 - >=20 > Internationalized domain names represented in > either A-label or U-label format [RFC5890] are also valid domain > names. >=20 > Please add on to the end, "See section 4 for information on character > encoding for the U-label format." OK. > 4 - I think you should swap sections 4.1 and 4.2. The reference to > section 4 from 3.1.3, 3.1.4, 3.2.1, and 3.2.2 should lead the reader to > the encoding stuff right away. I think it's more useful to have 4.2 > appear first. Or you could move all (or most) of 4.2 into section 6 and > then refer to it there. I'll move 4.2 to Section 6 (where it will become 6.1) and refer to it appro= priately. > 4.2 - You may want to add to the second paragraph: >=20 > UTF-8 encoded strings are then appropriately percent-encoded > [RFC3986] in the query URL. >=20 > and then maybe start the third paragraph with "After parsing any > percent-encoding, ". Maybe check with some URLy people about whether I > got the wording right. OK. > 6. I don't really understand the normative reference to 4290. Why is > this normative? It shouldn't be since we're only referencing it for descriptive purposes. I= 'll make it an Informative reference. Scott From nobody Tue Oct 7 06:23:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71A01A1F73 for ; Tue, 7 Oct 2014 06:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH1H_KnU7LH0 for ; Tue, 7 Oct 2014 06:23:13 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 6E22F1A1F20 for ; Tue, 7 Oct 2014 06:23:13 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 14649213762; Tue, 7 Oct 2014 09:23:13 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 32CF921373D; Tue, 7 Oct 2014 09:23:09 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 09:24:27 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 09:23:08 -0400 From: Andy Newton To: "Hollenbeck, Scott" , Pete Resnick , "weirds@ietf.org" Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-rdap-query-14 Thread-Index: AQHP4eucbkC5SYzkFESVghbBh9eh1Jwk0fUA///N24A= Date: Tue, 7 Oct 2014 13:23:07 +0000 Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494DC3F4@BRN1WNEXMBX01.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.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <31CE25E15436284F8527B47D58B4A132@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ah7wZRNtYVBnOnFexKki4KYqdx4 Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-rdap-query-14 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 13:23:17 -0000 On 10/7/14, 8:22 AM, "Hollenbeck, Scott" wrote: >> 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. >>=20 >> and >>=20 >> It is also envisioned that each >> registry will continue to maintain WHOIS and/or RESTful web >> services >>=20 >> Don't you mean "other web services", not "RESTful web services", in >> each >> of these places? RDAP-over-HTTP is the RESTful web service in this >> context, isn't it? > >I think that's true, but I vaguely recall Andy saying that ARIN had >something else going on, too. Maybe he can chime in to confirm. "other >web services" seems safe no matter what. Yes, both ARIN and RIPE NCC have RESTful web services for Whois that predate RDAP. The intent was that we were not trying to replicate all that can be done with those services. I think =B3=8Aemployed in the WHOIS and other RESTful web services=8A=B2 wo= uld fix it. -andy From nobody Tue Oct 7 06:56:03 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190811A6F1D for ; Tue, 7 Oct 2014 06:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY-VbJ4Zk5Hl for ; Tue, 7 Oct 2014 06:55: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 E88591ACD9A for ; Tue, 7 Oct 2014 06:55:05 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 9FA932137B0; Tue, 7 Oct 2014 09:55:05 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id E7C1E2137A8; Tue, 7 Oct 2014 09:55:04 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 09:57:05 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 09:55:04 -0400 From: Andy Newton To: Marc Blanchet , Pete Resnick Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 Thread-Index: AQHP4evQt9B8e+TxVUafxU5Yqf2oW5wkw9+A///k2wA= Date: Tue, 7 Oct 2014 13:55:03 +0000 Message-ID: In-Reply-To: <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <528BEA72E43EB641ACB38AEDED61B225@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/wjnAvt_XMyJFF6xCiUiIANT0suc Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 13:55:59 -0000 On 10/7/14, 7:32 AM, "Marc Blanchet" wrote: >>On the JSON itself: I presume that services is an array of an array of >>arrays to somehow shrink the size of the entries, but given that you're >>depending on the ordering of the second-level array, it sure would have >>been easier to track what the heck is in this thing if services were an >>array of objects containing arrays instead: >>=20 >> { >> ... >> "services": [ >> { >> entries : ["entry1", "entry2", "entry3"], >> baseurls : [ >> "https://registry.example.com/myrdap/", >> "http://registry.example.com/myrdap/" >> ] >> }, >> { >> entries : ["entry4"], >> baseurls : [ >> "http://example.org/" >> ] >> } >> ] >> } >>=20 >> Is the "array of arrays of arrays" idea a done deal? > >I let implementors to comment on this one. Speaking as an implementor, using objects would make the JSON more self-descriptive and is probably how I would have done this. That being said, the current array of array of arrays didn=B9t really confuse me after reading the draft. I=B9d prefer this not change unless we have good reason. -andy From nobody Tue Oct 7 07:51:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11A41ACDDD for ; Tue, 7 Oct 2014 07:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7lzSXxtjt03 for ; Tue, 7 Oct 2014 07:51:14 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id DEDD01ACDD5 for ; Tue, 7 Oct 2014 07:51:13 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 96879213752; Tue, 7 Oct 2014 10:51:13 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 581DA213716; Tue, 7 Oct 2014 10:51:12 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 10:52:30 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 10:51:11 -0400 From: Andy Newton To: Pete Resnick , "weirds@ietf.org" Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 Thread-Index: AQHP4eugIrOKmkiu6021uSTAWOZWZJwkuGuA Date: Tue, 7 Oct 2014 14:51:11 +0000 Message-ID: In-Reply-To: <54337343.4050101@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8DE9B720CF4178468F0E8249A7635B5F@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/jmugpKgWrZ9zDCG8u_yCqUZyMjc Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:51:16 -0000 Pete, For the things that need discussion or a reply, response is inline... On 10/7/14, 12:59 AM, "Pete Resnick" wrote: > >Also note that I have not reviewed all of the examples in detail. I hope >the WG has done a good scrub. Tom Harrison has found a couple of issues here (that oddly enough passed my JSON validator) which I=B9ll try to incorporate. >3.2 - You went a little MUST/SHOULD/MAY crazy in this section. I hope >the following suggested replacements are helpful (and I replace "client" >with "parser" and "server" with "generator" in my example): > >Paragraph 1: > > Parsers of these JSON responses SHOULD ignore unrecognized JSON > attributes in responses. Generators can insert values into the JSON > responses which are not specified in this document, but that does not > constitute an error in the response. Generators which insert such > unspecified values into JSON responses SHOULD have names prefixed > with a short identifier followed by an underscore followed by a > meaningful name. These short identifiers aid software implementers > with identifying the specification of the JSON name, and failure to > use one could cause an implementer to assume the generator is > erroneously using a name from this specification. This allowance > does not apply to jCard ([RFC7095]) objects. The full JSON name (the > prefix plus the underscore plus the meaningful name) SHOULD adhere to > the character and name limitations of the prefix registry described > in [I-D.ietf-weirds-using-http]. Failure to use these limitations > could result in slower adoption as these limitations have been given > to aid some client programming models. > >Next to last paragraph: > > Parsers processing JSON responses need to be prepared for values > specified in this document to be absent from a response, as no JSON > value listed is required to appear in a response. In other words, > generators are free to not included values based on their own > policies. As an implementor, I find the change of the wording to parser/generator more confusing. The JSON parser and generators I have dealt with are libraries, and the decision to ignore/insert takes place by the RDAP client or server implementation that uses those libraries. >5.2 - > > The > "value", "rel", and "href" JSON values MUST be specified. All other > JSON values are optional. > >I presume the "MUST be specified" is there because this is a requirement >of 5988, not because it is a new requirement of this document. If so, >change that to "are required by [RFC5988]". If this is a new requirement >of this document, then there should be an explanation of why this is >required, and the "optional" in the second sentence should be "OPTIONAL". Good catch. RFC 5988 doesn=B9t seem to say what is and what is not required= , though one could get the notion that these are the ones required because the others all classified as =B3link parameters=B2. RFC 4287, which is wher= e RFC 5988 gets the link structure, only requires href. And that makes sense as without href it isn=B9t a link. So we should change this so that href is MUST and everything else is OPTIONAL. Does that work? >5.5 - If you're going to use a SHOULD, I should be able to figure out >why this is a requirement and what exceptions there are to make it a >SHOULD and not a MUST. Neither is clear. If this isn't a real >requirement, then I would change "SHOULD be" it "is" and be done with it. I think it is a MUST. If they want to link to an RDAP entity, for interoperability the link MUST have the right structure. >6 - > > When present, clients MAY use the self link for caching data. > >I don't understand that MAY. What option is trying to be conveyed here? >Is this a using-http thing? Clients are required to cache the data at this granularity. So it shouldn=B9t be a MAY. Perhaps changing it to =B3can=B2 works. > > Self links SHOULD contain a "type" element containing the > "application/rdap+json" media type when referencing RDAP object > instances as defined by this document. > >Again, no explanation of why it SHOULD contain a "type" element, and no >explanation of a reason for an exception. Please explain. No this should be a MUST to guarantee interoperability. Sorry about that. > > Clients SHOULD NOT assume > self links without this media type are represented as RDAP objects as > defined by this document. > >I'm not sure how to implement a "SHOULD NOT assume". Do you really mean >something like the following? > > Clients MAY/SHOULD/MUST discard objects containing self links without > a media type, as they might not be RDAP objects as defined by this > document. Given the change of the SHOULD to a MUST for creating the self links, I think we can take out that paragraph entirely. > >6.1 - > > For illustrative purposes, it does not include rdapConformance or > notices data structures. > >That sentence occurs a lot throughout the document. Are rdapConformance >or notices required? If not, I would strike this sentence. If they are >required, you had better say so back in section 5. > >I would move the following: > > Entities may also have other entities embedded with them in an array. > This can be used to model an organization with specific individuals > fulfilling designated roles of responsibility. > > The following is an elided example of an entity with embedded > entities. I don=B9t understand this. Move it to where? If you mean remove, why? It is describing the example that follows and without that description I think the example doesn=B9t work. > >and Figure 13 *below* the bulleted list. It confused me here. > > o vcardArray -- a JSON vCard with the entity's contact information > >s/a JSON vCard/one or more JSON vCards. It is an array, after all. Actually, we should be calling them jCards. I thought I had changed that. But the reference to a singular jCard is intentional. We want contact information for a specific entity, and the jCard standard allows that to occur within an array. However, we don=B9t want the serialization of an entire address book of jCards referencing unrelated entities=8A which the jCard standard also specifies. >11.1 - Seems like a reference to rdap-sec might be useful here. > >I find it weird (no pun intended) to have an individual be the >contact/author for a standards registration. Shouldn't it be the IESG or >the WG or something? Maybe I'll ask Barry. I was just following the example of other registrations. I think it should be the IESG. >11.2 - > > This registry should be governed by a designated expert or multiple > designated experts. Registration of values into this registry should > be accomplished by providing the information above to the designated > expert(s). > >Probably simpler (and clearer) for IANA if you simply say, "This >registry is to be operated under the "Expert Review" policy defined in >RFC 5226." The IESG will make sure about the one or multiple experts, >and IANA wil make sure that they get the appropriate information. > >Just before 11.2.1, please add: "The following sections provide initial >registrations into this registry." > >I still find it strange to have an individual registrant for these >registrations. Do you mean this specific initial registrations or all the registrations? I=B9m fine changing these initial ones to IESG. >13.1 - > > Servers > and clients MAY optionally support other character encodings. > >How does *that* work? How is a different encoding indicated? This seems >like a discussion for the using-http document. As far as I=B9m concerned, everything I18N related is black magic. But in this specific case, we should either take that out or say something like: Servers and clients can use other character encodings provided they have negotiated data transfer with those encodings via a non-standard mechanism. I lean toward taking it out entirely. > >14 - I suspect you're going to be asked for more here. I don't have the >expertise to give you advice in this area, but you might want to check >with Alissa Cooper about who might. I=B9ll send her a message asking for review. -andy From nobody Tue Oct 7 07:58:21 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2A01ACDFA for ; Tue, 7 Oct 2014 07:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1PzqM89kBkI for ; Tue, 7 Oct 2014 07:58:17 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 3827F1ACDF8 for ; Tue, 7 Oct 2014 07:58:17 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id E614721373B; Tue, 7 Oct 2014 10:58:16 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 29646213737; Tue, 7 Oct 2014 10:58:16 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 11:00:16 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 10:58:15 -0400 From: Andy Newton To: Pete Resnick , "weirds@ietf.org" Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-using-http-12 Thread-Index: AQHP4eu6Z9bqlDs/vk6GM79mRLPRN5wkumMA Date: Tue, 7 Oct 2014 14:58:14 +0000 Message-ID: In-Reply-To: <54337372.2010105@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F1917C8695B0D43A404C6017B731081@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/xXv1gJDYJxT8FG-BBpOlnrq2BBw Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-12 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:58:19 -0000 Pete, Thanks for the review and comments. I agree with them all and will rev the document as soon as possible. -andy On 10/7/14, 1:00 AM, "Pete Resnick" wrote: >Summary: Small changes and then ready for Last Call. > >I don't think any of these issues are controversial. Addressing them >should be quite quick, and then I'm happy to Last Call. > >1 - > > This is the basic usage pattern for this protocol: > >I really think you need to be clearer about bootstrap and base URLs in >this section. You should also use an example that's closer to the >examples in rdap-query. I suggest the following replacement text for 1 & >2: > > 1. A client determines an appropriate server to query along with > the appropriate base URL to use in such queries. > [I-D.ietf-weirds-bootstrap] describes one method to determine the > server and the base URL. See Appendix C for more information. > > 2. A client issues an HTTP (or HTTPS) query using GET [RFC7231]. As > an example, a query for the network registration 192.0.2.0 might > be > > http://example.com/rdap/ip/192.0.2.0 > > [I-D.ietf-weirds-rdap-query] details the various queries used in > RDAP. > >Strike the last sentence of item 3. Of course non-standard things can be >used. They're not standard. No need to mention them here. Mentioning >them in the design criteria in section 3 is more than sufficient. (I'm >not a big fan of it appearing there either, but it's acceptable as a >design criteria.) > >4.1 - Move the first sentence after the second and third, and make the >second and third active voice: > > Clients use the GET method to retrieve a response body and use the > HEAD method to determine existence of data on the server. Clients > SHOULD use either the HTTP GET or HEAD methods (see [RFC7231]). > >I think it flows much better this way. > >5 - > > at a minimum clients SHOULD understand the response codes > described in this section as they will be in common use by servers. > >The SHOULD in there seems silly. I think what you really mean is: > > this section defines the minimal set of response codes in common use > by servers that a client will need to understand. > >5.5 - > > Clients that > do not honor the Retry-After header may stricter limits placed upon > them. > >Do you mean, "Servers may place stricter limits upon clients that do not >honor the Retry-After header"? That's probably a clearer way to say it. > >9.2 - > > The mechanism for including a language identifier in a response will > be defined in subsequent documents describing specific response > formats. > >Instead, I think it's better to say: > > [I-D.ietf-weirds-json-response] provides such a mechanism. > >Appendix A/B - > >I think you should include "/rdap" in the query examples, the same way >you have rdap-query examples. > >pr > >--=20 >Pete Resnick >Qualcomm Technologies, Inc. - +1 (858)651-4478 > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds > From nobody Tue Oct 7 08:12:48 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8737E1ACE09; Tue, 7 Oct 2014 08:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKJuCippf1pn; Tue, 7 Oct 2014 08:12:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1D61ACE0E; Tue, 7 Oct 2014 08:12:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141007151243.23270.5451.idtracker@ietfa.amsl.com> Date: Tue, 07 Oct 2014 08:12:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/bysIdOfvSiOrtPFH4ALyH_ZZGSI Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-15.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 15:12:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Registration Data Access Protocol Query Format Authors : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-15.txt Pages : 19 Date : 2014-10-07 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. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-query-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 7 08:15:57 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57AB1A030A for ; Tue, 7 Oct 2014 08:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-mh3MEF3Bra for ; Tue, 7 Oct 2014 08:15:53 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02011A030C for ; Tue, 7 Oct 2014 08:15:52 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKVDQDqMxf4p6PpqyCd32762Z8xy2Kpggh@postini.com; Tue, 07 Oct 2014 08:15:52 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 s97FFpeG030815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 Oct 2014 11:15:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 11:15:50 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: I-D Action: draft-ietf-weirds-rdap-query-15.txt Thread-Index: AQHP4kEw4oBgYCRxpUKlAA1V9zalrpwkvfYg Date: Tue, 7 Oct 2014 15:15:50 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494DCB32@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141007151243.23270.5451.idtracker@ietfa.amsl.com> In-Reply-To: <20141007151243.23270.5451.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/a6slQHhJaBKRxlEOzFbcbLrGNf8 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-15.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 15:15:55 -0000 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, October 07, 2014 11:13 AM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: I-D Action: draft-ietf-weirds-rdap-query-15.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Extensible Internet Registration > Data Service Working Group of the IETF. >=20 > Title : Registration Data Access Protocol Query > Format > Authors : Andrew Lee Newton > Scott Hollenbeck > Filename : draft-ietf-weirds-rdap-query-15.txt > Pages : 19 > Date : 2014-10-07 Modified to address our AD's review comments. Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-query-15 Scott From nobody Tue Oct 7 09:38:09 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539B21ACE31 for ; Tue, 7 Oct 2014 09:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olLL7NnEseWD for ; Tue, 7 Oct 2014 09:38:05 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D766A1ACE3D for ; Tue, 7 Oct 2014 09:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412699886; x=1444235886; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2aoO7FBCQvicZKgWMg1xtKi38PUgLgiwQQt10827Q78=; b=FNLWjzKjyJuPi+OreHZKEqOEG5kQxD963y4J8z0lAdR+e37Z3fKOfn7b U1Hm2v8bagZsKfyGqdlMbqQ4pQK/zhUo3nZCrPZbrTZAafr8177SdXmuJ pz40X366jodXeuXVnTcmI9QJGmB6NDScs/4IEkud87vqZ52v0vFhYVRYv 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7584"; a="164240194" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Oct 2014 09:38:05 -0700 X-IronPort-AV: E=Sophos;i="5.04,671,1406617200"; d="scan'208";a="819386936" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Oct 2014 09:38:05 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 09:38:04 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 7 Oct 2014 09:37:57 -0700 Message-ID: <543416CE.8040503@qti.qualcomm.com> Date: Tue, 7 Oct 2014 11:37:34 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <54337328.8010605@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F494DC3F4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494DC3F4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/E8X6Zq0BJVah12bj87pZMil3340 Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-rdap-query-14 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:38:07 -0000 On 10/7/14 7:22 AM, Hollenbeck, Scott wrote: > I'd much rather go to last call with all known issues addressed. I'll rev the doc. Just looked at the rev with Andy's suggested change. All looks good. Ready to go. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Oct 7 09:55:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EBD1ACE9E for ; Tue, 7 Oct 2014 09:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S6CijAVnHxu for ; Tue, 7 Oct 2014 09:55:07 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072BA1ACE83 for ; Tue, 7 Oct 2014 09:55:06 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so9667085wgh.21 for ; Tue, 07 Oct 2014 09:55:05 -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=ieJLdlvi0Fd3wMqsFuEH5X4+tnIMPxtV55Ru25RmQac=; b=Xb9gjVj4sci7pmeNvOrJ4DUKxKYM7a1l38Y6Hoa8KsKjlaQAbCu6eCyeq0DTRm7dXF 21hjF7xIWnxUspbJciOorE2678RI2RsxeSOvP7uu+96CdumoVaRCaDK3ANLy/q1Ye5Ck 0dLm7HxbML9SOOsq6sybE1OL4+dDP8oSN/iQ0S8r/8sYXhn0++PTisCn6bn+mV7tHxTX FNV8sOEs+bxyEx4jaxkcoY2cm962ck7C/bo8pDB3uH1Pza0Ialgfu6yAoBsFNw/s6v9t 2/rNwVZUvq4UCl++eWt5vBmvu9QDBfJdOqn7cEcctRy49h+velmKOYStmv/h3INW2gRg c85Q== MIME-Version: 1.0 X-Received: by 10.180.10.38 with SMTP id f6mr5891597wib.30.1412700905482; Tue, 07 Oct 2014 09:55:05 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 7 Oct 2014 09:55:05 -0700 (PDT) In-Reply-To: <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> References: <543373B9.30402@qti.qualcomm.com> <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> Date: Tue, 7 Oct 2014 09:55:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: Marc Blanchet Content-Type: multipart/alternative; boundary=001a11c25d08a52faf0504d80f17 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/H5Y1HvCFo-Tk06krd0vFxaZlYNs Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:55:13 -0000 --001a11c25d08a52faf0504d80f17 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 7, 2014 at 4:32 AM, Marc Blanchet wrote: > > The RDAP Bootstrap Service Registries are made available as JSON > > [RFC7159] objects. The JSON registry output... > > > > First of all, I don't know what you mean by "the JSON registry output", > > this text was actually a suggestion from someone. We just put it. I'm > happy to change it. > It's possible that this was my suggestion, or at least derived from one. More generally, I tried during WGLC to nudge this in a different direction anticipating IESG friction, but I wasn't successful. The issue, with which Pete now appears to agree, is that we should make clear distinctions between creation and description of the registry, and then our expectations for how the registry's content will be made available. Since the way IANA stores these things is completely opaque to us, describing the registry in general terms is a lot more useful to them than describing them in terms of the output we ultimately want. By analogy, one would normally provide a database schema before describing how to put things into the database and what a dump of the database would be expected to contain (and in what format). I know Marc and others have had repeated conversations with IANA at the meetings to ensure they get what it is we need here, but still the form of our IANA Considerations in this document is an issue. Suppose, for example, that IANA has a complete staff change before this document gets to them. All of the context of those hallway track conversations is lost and would need to be repeated. I think that, instead, we should do this in a more conventional way. I look at IANA Considerations as a work order. An IETF action for IANA needs them to do these specific things when making new registries: 1) Create a registry, to include the name of the registry and the names, descriptions, and syntaxes of the fields within it. (schema) 2) Describe the policy by which the registry will be updated. (We're a special case here, I know.) 3) Provide initial registry entries (if any; for us, they should just mirror what the other IANA registries contain). 4) Specify how the registry's contents should be made available (uncommon, but we need it for RDAP). In -07, the authors added a JSON description which I think satisfies (4) above. I don't have any particular feelings about the chosen format (array-of-arrays-of-arrays), as long as the syntax we want is clearly specified. I think we have prose that covers (2) and (3). However, I think (1) is basically mixed into the current prose and example, and should instead be made explicit before the example. > > But I've got to say that I don't really like that at either. It's one of > the most convoluted ways I've ever seen to describe an IANA registry. I am > not convinced that this will pass an IETF Last Call, let alone an IESG > review. I really think you should have defined the registry in terms of a > simple table with two columns, the first being the "Entries" column, and > the second being the "Base URLs" column, and for each row in the table, > there would be the entries for that particular service and the base URLs > for that particular set of entries. Then, later in the document, you could > describe the retrievable JSON format. The way you have it, you've tried to > jam together the definition of the registry with the retrievable format of > the registry. I am prepared to be convinced that this is ready to move > forward, but at this point I am not inclined to Last Call this document. > Does my suggestion help at all? > - fine. I have to say again that IANA looked at it (both the technical > people and the registration people) and they were fine with the text. > See above. > - the json format evolved into multiple level arrays, as requested by > implementors. A two columns table won't really show this structure. So in > some ways, we are just not used to define registries in complex JSON > formats. I guess I'm the guiney pig... > I don't care so much about the format (especially since I'm not implementing this) so I'm happy to yield to implementers. I do think it needs to be clearly specified though, and I think what you added in -07 is a big help. Pete, maybe Barry could also take an early look at least at that part? > 3 - > > > > Internationalized Domain Names labels used as entries or base RDAP > > URLs in the registries defined in this document MUST be only > > represented using their A-Label form as defined in [RFC5890]. > > > > Doesn't this contradict what appears in rdap-query? > > humm. good point. This addition was from a review comment. I guess we > should think about this one. > WG (especially implementers and those with I18N fu), please speak up! > Furthermore, nowhere in this section does it ever tell IANA that it is > expected to populate these registries from its own data. > > yes. it is. In fact, we don't want, since the entries will be submitted by > the "owners" of the data, which will submit it through the policy defined > by IANA. The relevant text is: > " > It is envisioned that these new registries will have similar entries > than the corresponding IANA allocation registries, such as [ipv4reg], > [ipv6reg], [asreg], [domainreg], and possibly similar registration > policies. Given that the data required by RDAP clients is limited > compared to the content of the existing corresponding registries, and > given that this data has to be made available in a JSON format using > a specific key/value structure, this document is not defining an > extension of the existing IANA allocation registries. The > registration policies for the new registries of this document are > left to IANA. > " > Pete, I think that's right, modulo a bit of wordsmithing. Would it be better placed elsewhere in the document? -MSK --001a11c25d08a52faf0504d80f17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 7, 2014 at 4:32 AM, Marc Blanchet <ma= rc.blanchet@viagenie.ca> wrote:
>=C2=A0= =C2=A0The RDAP Bootstrap Service Registries are made available as JSON
>=C2=A0 =C2=A0[RFC7159] objects.=C2=A0 The JSON registry output...
>
> First of all, I don't know what you mean by "the JSON registr= y output",

this text was actually a suggestion from someone. We just put it. I&= #39;m happy to change it.

It's poss= ible that this was my suggestion, or at least derived from one.

More generally, I tried during WGLC to nudge this in a different dir= ection anticipating IESG friction, but I wasn't successful.=C2=A0 The i= ssue, with which Pete now appears to agree, is that we should make clear di= stinctions between creation and description of the registry, and then our e= xpectations for how the registry's content will be made available.=C2= =A0 Since the way IANA stores these things is completely opaque to us, desc= ribing the registry in general terms is a lot more useful to them than desc= ribing them in terms of the output we ultimately want.=C2=A0 By analogy, on= e would normally provide a database schema before describing how to put thi= ngs into the database and what a dump of the database would be expected to = contain (and in what format).

I know Marc and others have had repeat= ed conversations with IANA at the meetings to ensure they get what it is we= need here, but still the form of our IANA Considerations in this document = is an issue.=C2=A0 Suppose, for example, that IANA has a complete staff cha= nge before this document gets to them.=C2=A0 All of the context of those ha= llway track conversations is lost and would need to be repeated.=C2=A0 I th= ink that, instead, we should do this in a more conventional way.

I look at IANA Considerations as a work order.=C2=A0 An IETF action= for IANA needs them to do these specific things when making new registries= :

1) Create a registry, to include the name of the regist= ry and the names, descriptions, and syntaxes of the fields within it.=C2=A0= (schema)
2) Describe the policy by which the registry will b= e updated.=C2=A0 (We're a special case here, I know.)
3) = Provide initial registry entries (if any; for us, they should just mirror w= hat the other IANA registries contain).
4) Specify how the re= gistry's contents should be made available (uncommon, but we need it fo= r RDAP).

In -07, the authors added a JSON description whi= ch I think satisfies (4) above.=C2=A0 I don't have any particular feeli= ngs about the chosen format (array-of-arrays-of-arrays), as long as the syn= tax we want is clearly specified.=C2=A0 I think we have prose that covers (= 2) and (3).=C2=A0 However, I think (1) is basically mixed into the current = prose and example, and should instead be made explicit before the example.<= br>=C2=A0
> But I've got to say that I don't really like that at= either. It's one of the most convoluted ways I've ever seen to des= cribe an IANA registry. I am not convinced that this will pass an IETF Last= Call, let alone an IESG review. I really think you should have defined the= registry in terms of a simple table with two columns, the first being the = "Entries" column, and the second being the "Base URLs" = column, and for each row in the table, there would be the entries for that = particular service and the base URLs for that particular set of entries. Th= en, later in the document, you could describe the retrievable JSON format. = The way you have it, you've tried to jam together the definition of the= registry with the retrievable format of the registry. I am prepared to be = convinced that this is ready to move forward, but at this point I am not in= clined to Last Call this document.

Does my suggestion help at all?
=C2=A0
- fine. I have to say again that IANA looked at it (both the technical peop= le and the registration people) and they were fine with the text.
=

See above.
=C2=A0
- the json format evolved into multiple level arrays, as requested by imple= mentors.=C2=A0 A two columns table won't really show this structure.=C2= =A0 So in some ways, we are just not used to define registries in complex J= SON formats. I guess I'm the guiney pig...

I don't care so much about the format (especially since I'm= not implementing this) so I'm happy to yield to implementers.=C2=A0 I = do think it needs to be clearly specified though, and I think what you adde= d in -07 is a big help.

Pete, maybe Barry could also take= an early look at least at that part?

> 3 -
>
>=C2=A0 =C2=A0Internationalized Domain Names labels used as entries or b= ase RDAP
>=C2=A0 =C2=A0URLs in the registries defined in this document MUST be on= ly
>=C2=A0 =C2=A0represented using their A-Label form as defined in [RFC589= 0].
>
> Doesn't this contradict what appears in rdap-query?

humm. good point. This addition was from a review comment. I guess w= e should think about this one.

WG (espe= cially implementers and those with I18N fu), please speak up!

> Furthermore, nowhere in this section does it ever tell IANA that= it is expected to populate these registries from its own data.

yes. it is. In fact, we don't want, since the entries will be su= bmitted by the "owners" of the data, which will submit it through= the policy defined by IANA. The relevant text is:
"
=C2=A0 =C2=A0It is envisioned that these new registries will have similar e= ntries
=C2=A0 =C2=A0than the corresponding IANA allocation registries, such as [ip= v4reg],
=C2=A0 =C2=A0[ipv6reg], [asreg], [domainreg], and possibly similar registra= tion
=C2=A0 =C2=A0policies.=C2=A0 Given that the data required by RDAP clients i= s limited
=C2=A0 =C2=A0compared to the content of the existing corresponding registri= es, and
=C2=A0 =C2=A0given that this data has to be made available in a JSON format= using
=C2=A0 =C2=A0a specific key/value structure, this document is not defining = an
=C2=A0 =C2=A0extension of the existing IANA allocation registries.=C2=A0 Th= e
=C2=A0 =C2=A0registration policies for the new registries of this document = are
=C2=A0 =C2=A0left to IANA.
"

Pete, I th= ink that's right, modulo a bit of wordsmithing.=C2=A0 Would it be bette= r placed elsewhere in the document?

-MSK
--001a11c25d08a52faf0504d80f17-- From nobody Tue Oct 7 10:06:02 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4413A1ACEC1 for ; Tue, 7 Oct 2014 10:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh56E4qUU1sk for ; Tue, 7 Oct 2014 10:05:57 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C9A1ACEB8 for ; Tue, 7 Oct 2014 10:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412701557; x=1444237557; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OqcGDQmgEBJydExcUpIPHJmYe7A5VeEwSm8O5OPn4A8=; b=bS38KVsYkPh5QFi9EYv0o6FbYpbKV3pDPVCEUv/jc0sZogqLxwIT/Kes Q8tGW9x/UXtdX0YDti31HR2ntuLILLl9WubrQ3i1UeR4B8Tz3mzRp2p6Y siPl58oFRqnz4SyO5LHP6SF9RuC2iEmVf0CJTYiCObm2YRtYKonQmzZLd E=; X-IronPort-AV: E=McAfee;i="5600,1067,7584"; a="164246346" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine02.qualcomm.com with ESMTP; 07 Oct 2014 10:05:57 -0700 X-IronPort-AV: E=Sophos;i="5.04,671,1406617200"; d="scan'208";a="31470761" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Oct 2014 10:05:56 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by NASANEXHC17.na.qualcomm.com (10.45.158.129) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 10:05:56 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 7 Oct 2014 10:05:37 -0700 Message-ID: <54341D5D.9050109@qti.qualcomm.com> Date: Tue, 7 Oct 2014 12:05:33 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/hGJQFOngxD_g8Ban_Q0lcnnbzqE Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:06:00 -0000 On 10/7/14 9:51 AM, Andy Newton wrote: > For the things that need discussion or a reply, response is inline... > > On 10/7/14, 12:59 AM, "Pete Resnick" wrote: > > >> Also note that I have not reviewed all of the examples in detail. I hope >> the WG has done a good scrub. >> > Tom Harrison has found a couple of issues here (that oddly enough passed > my JSON validator) which I¹ll try to incorporate. > Cool. >> 3.2 - You went a little MUST/SHOULD/MAY crazy in this section. I hope >> the following suggested replacements are helpful (and I replace "client" >> with "parser" and "server" with "generator" in my example): >> >> Paragraph 1: >> >> Parsers of these JSON responses SHOULD ignore unrecognized JSON >> attributes in responses. Generators can insert values into the JSON >> responses which are not specified in this document, but that does not >> constitute an error in the response. Generators which insert such >> unspecified values into JSON responses SHOULD have names prefixed >> with a short identifier followed by an underscore followed by a >> meaningful name. These short identifiers aid software implementers >> with identifying the specification of the JSON name, and failure to >> use one could cause an implementer to assume the generator is >> erroneously using a name from this specification. This allowance >> does not apply to jCard ([RFC7095]) objects. The full JSON name (the >> prefix plus the underscore plus the meaningful name) SHOULD adhere to >> the character and name limitations of the prefix registry described >> in [I-D.ietf-weirds-using-http]. Failure to use these limitations >> could result in slower adoption as these limitations have been given >> to aid some client programming models. >> >> Next to last paragraph: >> >> Parsers processing JSON responses need to be prepared for values >> specified in this document to be absent from a response, as no JSON >> value listed is required to appear in a response. In other words, >> generators are free to not included values based on their own >> policies. >> > As an implementor, I find the change of the wording to parser/generator > more confusing. The JSON parser and generators I have dealt with are > libraries, and the decision to ignore/insert takes place by the RDAP > client or server implementation that uses those libraries. > That's OK. I can certainly live with the client/server language. Just a preference. Are you OK with the rest of my suggested changes (switching the terms back to client/server) in this section? >> 5.2 - >> >> The >> "value", "rel", and "href" JSON values MUST be specified. All other >> JSON values are optional. >> >> I presume the "MUST be specified" is there because this is a requirement >> of 5988, not because it is a new requirement of this document. If so, >> change that to "are required by [RFC5988]". If this is a new requirement >> of this document, then there should be an explanation of why this is >> required, and the "optional" in the second sentence should be "OPTIONAL". >> > Good catch. RFC 5988 doesn¹t seem to say what is and what is not required, > though one could get the notion that these are the ones required because > the others all classified as ³link parameters². RFC 4287, which is where > RFC 5988 gets the link structure, only requires href. And that makes sense > as without href it isn¹t a link. So we should change this so that href is > MUST and everything else is OPTIONAL. Does that work? > Yep, that sounds OK. >> 5.5 - If you're going to use a SHOULD, I should be able to figure out >> why this is a requirement and what exceptions there are to make it a >> SHOULD and not a MUST. Neither is clear. If this isn't a real >> requirement, then I would change "SHOULD be" it "is" and be done with it. >> > I think it is a MUST. If they want to link to an RDAP entity, for > interoperability the link MUST have the right structure. > Well, this might get into one of those cases of, "Why MUST you do this?" "Because if you don't, you're an idiot." If someone doesn't use "rel" of "related" and "type" of "application/rdap+json", does the an interpreter of such an event blow up, or does it just not accomplish something useful? If the latter, change "SHOULD be" (or "MUST be") to "is" and be done with it. >> 6 - >> >> When present, clients MAY use the self link for caching data. >> >> I don't understand that MAY. What option is trying to be conveyed here? >> Is this a using-http thing? >> > Clients are required to cache the data at this granularity. So it > shouldn¹t be a MAY. Perhaps changing it to ³can² works. > Makes sense. >> Self links SHOULD contain a "type" element containing the >> "application/rdap+json" media type when referencing RDAP object >> instances as defined by this document. >> >> Again, no explanation of why it SHOULD contain a "type" element, and no >> explanation of a reason for an exception. Please explain. >> > No this should be a MUST to guarantee interoperability. Sorry about that. > > >> Clients SHOULD NOT assume >> self links without this media type are represented as RDAP objects as >> defined by this document. >> >> I'm not sure how to implement a "SHOULD NOT assume". Do you really mean >> something like the following? >> >> Clients MAY/SHOULD/MUST discard objects containing self links without >> a media type, as they might not be RDAP objects as defined by this >> document. >> > Given the change of the SHOULD to a MUST for creating the self links, I > think we can take out that paragraph entirely. > OK. >> 6.1 - >> >> For illustrative purposes, it does not include rdapConformance or >> notices data structures. >> >> That sentence occurs a lot throughout the document. Are rdapConformance >> or notices required? If not, I would strike this sentence. If they are >> required, you had better say so back in section 5. >> >> I would move the following: >> >> Entities may also have other entities embedded with them in an array. >> This can be used to model an organization with specific individuals >> fulfilling designated roles of responsibility. >> >> The following is an elided example of an entity with embedded >> entities. >> > I don¹t understand this. Move it to where? If you mean remove, why? It is > describing the example that follows and without that description I think > the example doesn¹t work. > > >> and Figure 13 *below* the bulleted list. It confused me here. >> Sorry, I wasn't clear: I suggested moving that paragraph, and Figure 13, below the bulleted list. >> o vcardArray -- a JSON vCard with the entity's contact information >> >> s/a JSON vCard/one or more JSON vCards. It is an array, after all. >> > Actually, we should be calling them jCards. I thought I had changed that. > But the reference to a singular jCard is intentional. We want contact > information for a specific entity, and the jCard standard allows that to > occur within an array. However, we don¹t want the serialization of an > entire address book of jCards referencing unrelated entitiesŠ which the > jCard standard also specifies. > Ah. OK, then it's just the name of the member that confused me. Perhaps just calling it a "jcard"? But I'm OK with it either way. >> 11.1 - Seems like a reference to rdap-sec might be useful here. >> >> I find it weird (no pun intended) to have an individual be the >> contact/author for a standards registration. Shouldn't it be the IESG or >> the WG or something? Maybe I'll ask Barry. >> > I was just following the example of other registrations. I think it should > be the IESG. > Let's go with IESG. Barry can comment when it gets to IESG Eval. >> 11.2 - >> >> This registry should be governed by a designated expert or multiple >> designated experts. Registration of values into this registry should >> be accomplished by providing the information above to the designated >> expert(s). >> >> Probably simpler (and clearer) for IANA if you simply say, "This >> registry is to be operated under the "Expert Review" policy defined in >> RFC 5226." The IESG will make sure about the one or multiple experts, >> and IANA wil make sure that they get the appropriate information. >> >> Just before 11.2.1, please add: "The following sections provide initial >> registrations into this registry." >> >> I still find it strange to have an individual registrant for these >> registrations. >> > Do you mean this specific initial registrations or all the registrations? > I¹m fine changing these initial ones to IESG. > The initial ones. >> 13.1 - >> >> Servers >> and clients MAY optionally support other character encodings. >> >> How does *that* work? How is a different encoding indicated? This seems >> like a discussion for the using-http document. >> > As far as I¹m concerned, everything I18N related is black magic. But in > this specific case, we should either take that out or say something like: > > Servers and clients can use other character encodings provided > they have negotiated data transfer with those encodings via a > non-standard mechanism. > > I lean toward taking it out entirely. > Taking it out works for me. >> 14 - I suspect you're going to be asked for more here. I don't have the >> expertise to give you advice in this area, but you might want to check >> with Alissa Cooper about who might. >> > I¹ll send her a message asking for review. > Excellent. Thanks. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Oct 7 12:35:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC7D1A19EB for ; Tue, 7 Oct 2014 12:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLF4UX2mib6s for ; Tue, 7 Oct 2014 12:35: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 665951A0104 for ; Tue, 7 Oct 2014 12:35:12 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 20EF82137E4; Tue, 7 Oct 2014 15:35:12 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 1D86C2137D7; Tue, 7 Oct 2014 15:35:11 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 15:37:11 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 15:35:10 -0400 From: Andy Newton To: Pete Resnick Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 Thread-Index: AQHP4eugIrOKmkiu6021uSTAWOZWZJwkuGuAgABom4CAACnNAA== Date: Tue, 7 Oct 2014 19:35:10 +0000 Message-ID: References: <54341D5D.9050109@qti.qualcomm.com> In-Reply-To: <54341D5D.9050109@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/uHseA11D5t0dbh-bJAjJLZSglsM Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 19:35:14 -0000 On Oct 7, 2014, at 1:05 PM, Pete Resnick wrote: >>> 3.2 - You went a little MUST/SHOULD/MAY crazy in this section. I hope >>> the following suggested replacements are helpful (and I replace "client= " >>> with "parser" and "server" with "generator" in my example): >>>=20 >>> Paragraph 1: >>>=20 >>> Parsers of these JSON responses SHOULD ignore unrecognized JSON >>> attributes in responses. Generators can insert values into the JSON >>> responses which are not specified in this document, but that does no= t >>> constitute an error in the response. Generators which insert such >>> unspecified values into JSON responses SHOULD have names prefixed >>> with a short identifier followed by an underscore followed by a >>> meaningful name. These short identifiers aid software implementers >>> with identifying the specification of the JSON name, and failure to >>> use one could cause an implementer to assume the generator is >>> erroneously using a name from this specification. This allowance >>> does not apply to jCard ([RFC7095]) objects. The full JSON name (th= e >>> prefix plus the underscore plus the meaningful name) SHOULD adhere t= o >>> the character and name limitations of the prefix registry described >>> in [I-D.ietf-weirds-using-http]. Failure to use these limitations >>> could result in slower adoption as these limitations have been given >>> to aid some client programming models. >>>=20 >>> Next to last paragraph: >>>=20 >>> Parsers processing JSON responses need to be prepared for values >>> specified in this document to be absent from a response, as no JSON >>> value listed is required to appear in a response. In other words, >>> generators are free to not included values based on their own >>> policies. >>> =20 >> As an implementor, I find the change of the wording to parser/generator >> more confusing. The JSON parser and generators I have dealt with are >> libraries, and the decision to ignore/insert takes place by the RDAP >> client or server implementation that uses those libraries. >> =20 >=20 > That's OK. I can certainly live with the client/server language. Just a p= reference. Are you OK with the rest of my suggested changes (switching the = terms back to client/server) in this section? >=20 Absolutely! I=92ll incorporate them. >>> 5.5 - If you're going to use a SHOULD, I should be able to figure out >>> why this is a requirement and what exceptions there are to make it a >>> SHOULD and not a MUST. Neither is clear. If this isn't a real >>> requirement, then I would change "SHOULD be" it "is" and be done with i= t. >>> =20 >> I think it is a MUST. If they want to link to an RDAP entity, for >> interoperability the link MUST have the right structure. >> =20 >=20 > Well, this might get into one of those cases of, "Why MUST you do this?" = "Because if you don't, you're an idiot." If someone doesn't use "rel" of "r= elated" and "type" of "application/rdap+json", does the an interpreter of s= uch an event blow up, or does it just not accomplish something useful? If t= he latter, change "SHOULD be" (or "MUST be") to "is" and be done with it. There is no requirement to link an event to an RDAP entity, or to link the = actor of the event to any identifier. But, if a registry wanted to link an = event to an RDAP entity, this is what they MUST do. This is the current wording: The 'links' array in this data structure is provided for references to the event actor. If the event actor being referenced is an RDAP entity, the link reference SHOULD be made with "rel" of "related" and "type" of "application/rdap+json=94. Changing the SHOULD to MUST seems appropriate to me. That=92s what they MUS= T do to link to an RDAP entity. Or perhaps this slight change: The 'links' array in this data structure is provided for references to the event actor. If the event actor being referenced is to be an RDA= P entity, the link reference MUST have a "rel" of "related=94 and a "type" of "application/rdap+json=94. -andy= From nobody Tue Oct 7 13:40:24 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F8A1A8846 for ; Tue, 7 Oct 2014 13:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEAeu-0YQY-z for ; Tue, 7 Oct 2014 13:40:21 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DB01A1AA2 for ; Tue, 7 Oct 2014 13:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412714421; x=1444250421; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=D7TDFIjlo8QDw+R8HfVKmwHgIdeRf45QpuiKYL6VIAk=; b=cyWH/fedKJ0T3bxOIJyfpYca2Lt8Zn3pMkFtgaiIXJ4p1KxUrB2HDqDU IZenQEqwus6QzLcJU14C2bfKptJHQn8WfIHuEmEzQGuQSlowqKjvSLt7J mn1I3i8RHzFLCMBFMtIcnCRUqAMTH2vKLwmpifER5kEOXPzr8YIw2Kl4D 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7584"; a="75612797" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Oct 2014 13:40:21 -0700 X-IronPort-AV: E=Sophos;i="5.04,672,1406617200"; d="scan'208";a="764972716" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Oct 2014 13:40:11 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 13:40:06 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 7 Oct 2014 13:40:06 -0700 Message-ID: <54344FA4.8020301@qti.qualcomm.com> Date: Tue, 7 Oct 2014 15:40:04 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Andy Newton References: <54341D5D.9050109@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.46.201.192) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/SauKmQIzcqeBKa7ig69ORFfFgK0 Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:40:23 -0000 On 10/7/14 2:35 PM, Andy Newton wrote: > That’s what they MUST do to link to an RDAP entity. Or perhaps this slight change: > > The 'links' array in this data structure is provided for references > to the event actor. If the event actor being referenced is to be an RDAP > entity, the link reference MUST have a "rel" of "related” and a > "type" of "application/rdap+json”. > I won't belabor this one if I'm in the rough, but just one more attempt. :-) In 5.5, you have: The "events" array consists of objects, each with the following members: You could have said: The "events" array MUST consist of objects, and each object MUST have the following members: But I would say that if you did so, you were being a goofball. Yes, it is true that if you want to use "events", the array *will* consist of objects, and each object *will* have such and so members, but MUST indicates that you might somehow choose to do otherwise and that you MUST NOT do otherwise. The reason we don't have to use MUST in this case is because if you don't have an array of objects with the appropriate members, you simply don't have an "events" array. You don't need a MUST when the statement is definitional. Same thing above. If you're going to link to an RDAP entity, you *will* use a "rel" of "related” and a "type" of "application/rdap+json". If you don't do that, you're simply not linking to an RDAP entity. There's no other path to take. So I'm suggesting: The 'links' array in this data structure is provided for references to the event actor. In order to reference an RDAP entity, a "rel" of "related" and a "type" of "application/rdap+json" is used in the link reference. If you disagree, I'll just go weep in my beer. But seriously, I'm fine if you want the MUST. I just find it kind of silly. Sounds like you're all set to go on the rest except for the privacy considerations. If you don't hear back soon, make the other changes and we can deal with whatever comments we get in Last Call. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Oct 7 14:00:00 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033DF1A8871 for ; Tue, 7 Oct 2014 13:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcz7GUi_674L for ; Tue, 7 Oct 2014 13:59:50 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 389891A8862 for ; Tue, 7 Oct 2014 13:59:50 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id DD5401650C6; Tue, 7 Oct 2014 16:59:49 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 3E0D416505A; Tue, 7 Oct 2014 16:59:49 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 17:02:07 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 16:59:48 -0400 From: Andy Newton To: Pete Resnick Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 Thread-Index: AQHP4eugIrOKmkiu6021uSTAWOZWZJwkuGuAgABom4CAACnNAIAAEiIAgAAFg4A= Date: Tue, 7 Oct 2014 20:59:47 +0000 Message-ID: <6F7CB3B5-7239-4017-AD60-8194238C1142@arin.net> References: <54341D5D.9050109@qti.qualcomm.com> <54344FA4.8020301@qti.qualcomm.com> In-Reply-To: <54344FA4.8020301@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5C004CD464FDC441B8A8AA20D79CF6B1@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/JrGn7WjiAqbagWqCrzRy-5dSY9U Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:59:56 -0000 On Oct 7, 2014, at 4:40 PM, Pete Resnick wrote: > Same thing above. If you're going to link to an RDAP entity, you *will* u= se a "rel" of "related=94 and a "type" of "application/rdap+json". If you d= on't do that, you're simply not linking to an RDAP entity. There's no other= path to take. So I'm suggesting: >=20 > The 'links' array in this data structure is provided for references > to the event actor. In order to reference an RDAP entity, a "rel" of > "related" and a "type" of "application/rdap+json" is used in the link > reference. >=20 > If you disagree, I'll just go weep in my beer. But seriously, I'm fine if= you want the MUST. I just find it kind of silly. Ah. We=92re saying the same thing. I don=92t especially care either way, so= I=92ll take your suggestion. -andy= From nobody Tue Oct 7 14:02:46 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D031A8868 for ; Tue, 7 Oct 2014 14:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z0ygAVAqrIf for ; Tue, 7 Oct 2014 14:02:42 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB161A8872 for ; Tue, 7 Oct 2014 14:02:41 -0700 (PDT) Received: (qmail 26933 invoked from network); 7 Oct 2014 21:02:40 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 7 Oct 2014 21:02:40 -0000 Date: 7 Oct 2014 21:02:18 -0000 Message-ID: <20141007210218.965.qmail@ary.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/rjQQez_EqB_HLe78sFL-bTGI80I Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:02:43 -0000 >> Internationalized Domain Names labels used as entries or base RDAP >> URLs in the registries defined in this document MUST be only >> represented using their A-Label form as defined in [RFC5890]. >> >> Doesn't this contradict what appears in rdap-query? Yeah, but the contexts are different. Personally, I don't think it's likely that you can write a very useful IDN RDAP client that doesn't understand how to convert between A-labels and U-labels, but people who wrote the servers argued that it was no big deal to convert at their end, so be it. For the bootstrap, it seems to me that allowing mixed representations in the bootstrap file would make something that's already somewhat confusing hopelessly moreso. I suppose the mixed formats could be useful for names like exámple.com. R's, John From nobody Tue Oct 7 14:34:17 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F281A876F for ; Tue, 7 Oct 2014 14:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOTjI92r1aMJ for ; Tue, 7 Oct 2014 14:34:14 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757C91A02D7 for ; Tue, 7 Oct 2014 14:34:14 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id hq11so5478231vcb.7 for ; Tue, 07 Oct 2014 14:34:13 -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=+sRMrWOBIx9JpW7jL2qQuik5z5kJ1IKe9Pffq7EKVMo=; b=C5P18tKoFzbwexkZXQlu0mPGN06l4fS/HgzZfRVse1QqL0Ss/FJ9A5Ya2+NuFoq/Lo YqhyEskqFHSC10PX58EHKEapNkruDOWlwJOxm2OxQ2n14WsSLoMjmePAieuvxbdScOlw KGTLTJADBtLhrSNaJLbqm23Ziymsb/DkG2OsRblsJjsLIq1G/j66dksnEcH+9ZFMNvmR dbUyU5VQnRFz6JmaV9riPUQJk901ncIqZR1vNpcs1RMl1tWjoKH4MBQNl2n/ibdwWbtN zTYhP+lA35pobn55LZuQGtYz3o/LY+SR//8joAjl6QPe45I9TVbjwjNAatFx2xf1JdUk eNOA== MIME-Version: 1.0 X-Received: by 10.53.3.162 with SMTP id bx2mr4940417vdd.56.1412717653657; Tue, 07 Oct 2014 14:34:13 -0700 (PDT) Received: by 10.52.79.66 with HTTP; Tue, 7 Oct 2014 14:34:13 -0700 (PDT) In-Reply-To: <542F1165.5020507@qti.qualcomm.com> References: <542F1165.5020507@qti.qualcomm.com> Date: Tue, 7 Oct 2014 14:34:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11340076ea0e260504dbf5a8 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2mfTxmI4SPLTzxcf9L4Lrby1BJQ Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Reviews of documents coming X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:34:15 -0000 --001a11340076ea0e260504dbf5a8 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 3, 2014 at 2:13 PM, Pete Resnick wrote: > I know we said that we'd do 10/16 or close the WG. But if the chairs and > WG are OK with it, I'm OK with the 10/30 telechat. I'll plan on that unless > I hear differently. > Grumble. I'd be happier if we'd stuck to our agreed timeline and managed to get everything actually finished and in the RFC Editor queue by IETF 91, but let's go with what we have. I'd also rather have all of the LCs start and end together even though a couple of the documents are now ready, but that's really for you to decide since scheduling is now in your hands. Thanks for your hard work getting these done. +1. -MSK --001a11340076ea0e260504dbf5a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 3, 2014 at 2:13 PM, Pete Resnick <pre= snick@qti.qualcomm.com> wrote:
=
I know we said th= at we'd do 10/16 or close the WG. But if the chairs and WG are OK with = it, I'm OK with the 10/30 telechat. I'll plan on that unless I hear= differently.

Grumble.=C2=A0 I'd be= happier if we'd stuck to our agreed timeline and managed to get everyt= hing actually finished and in the RFC Editor queue by IETF 91, but let'= s go with what we have.

I'd also rather have all of t= he LCs start and end together even though a couple of the documents are now= ready, but that's really for you to decide since scheduling is now in = your hands.

Thanks for your hard work getting these done.

+1.

= -MSK
--001a11340076ea0e260504dbf5a8-- From nobody Tue Oct 7 14:45:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5E11A8706 for ; Tue, 7 Oct 2014 14:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HedvMKUiPWDt for ; Tue, 7 Oct 2014 14:44: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 A499F1A888D for ; Tue, 7 Oct 2014 14:44:55 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 5E948165137; Tue, 7 Oct 2014 17:44:55 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id A11A71650D0; Tue, 7 Oct 2014 17:44:54 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 17:46:54 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 17:44:54 -0400 From: Andy Newton To: Pete Resnick Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 Thread-Index: AQHP4eugIrOKmkiu6021uSTAWOZWZJwlbxGA Date: Tue, 7 Oct 2014 21:44:53 +0000 Message-ID: References: <54337343.4050101@qti.qualcomm.com> In-Reply-To: <54337343.4050101@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7275B1729577604F85CCE05C6488C36C@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/7FxBiZFfOp-QMhHuQhL_bWxnrFs Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:44:58 -0000 One last thing on this one, Pete=85 On Oct 7, 2014, at 12:59 AM, Pete Resnick wrote= : > 7 - >=20 > A client MAY simply use the HTTP response code as the server is not > required to include error data in the response body. However, if a > client wishes to parse the error data, it SHOULD first check that the > Content-Type header contains the appropriate media type. >=20 > This paragraph seems more appropriate for the using-http document. Using-http already has this: If a server wishes to respond that it has an empty result set (that is, no data appropriately satisfying the query), it returns a 404 response code. Optionally, it MAY include additional information regarding the negative answer in the HTTP entity body. So I think the paragraph you mentioned from Section 7 of json-response can = simply be deleted. -andy= From nobody Tue Oct 7 14:56:18 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3041A0103 for ; Tue, 7 Oct 2014 14:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXktkXskT-eC for ; Tue, 7 Oct 2014 14:56:15 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE12C1A028B for ; Tue, 7 Oct 2014 14:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412718960; x=1444254960; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4vPuNbzt665wnF4Gv1bmTryd8k1JxR3vuYDZlBUtkgE=; b=laMFYpFtB7TrglcTPCY9V7aUudG4gZ2QxiiLPY1O7kMEEHXBy4GqfnWg E3Lr/PmmfJMRJCrcNbp5n72mFb0BYShUL9x3K6aw8KYdne+vhtsAoA2Wv 3lTUJ34boSR7TWFf11G5vEGLfv/Wi7oylhcbOPGnLEqp/Q/6hY+OURtx2 g=; X-IronPort-AV: E=McAfee;i="5600,1067,7584"; a="164365152" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Oct 2014 14:55:45 -0700 X-IronPort-AV: E=Sophos;i="5.04,673,1406617200"; d="scan'208";a="725011942" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Oct 2014 14:55:26 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc15.na.qualcomm.com (129.46.52.215) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 14:55:25 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 7 Oct 2014 14:55:23 -0700 Message-ID: <54346136.3070304@qti.qualcomm.com> Date: Tue, 7 Oct 2014 16:55:02 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Andy Newton References: <54337343.4050101@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (129.46.53.226) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/J5QWEuK2czOihDkR5Dg75cFVPWA Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-json-response-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:56:17 -0000 On 10/7/14 4:44 PM, Andy Newton wrote: > One last thing on this one, Pete… > > On Oct 7, 2014, at 12:59 AM, Pete Resnick wrote: > > >> 7 - >> >> A client MAY simply use the HTTP response code as the server is not >> required to include error data in the response body. However, if a >> client wishes to parse the error data, it SHOULD first check that the >> Content-Type header contains the appropriate media type. >> >> This paragraph seems more appropriate for the using-http document. >> > Using-http already has this: > > If a server wishes to respond that it has an empty result set (that > is, no data appropriately satisfying the query), it returns a 404 > response code. Optionally, it MAY include additional information > regarding the negative answer in the HTTP entity body. > > So I think the paragraph you mentioned from Section 7 of json-response can simply be deleted. > I agree. Thanks. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Oct 7 15:09:41 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2578E1A88E1; Tue, 7 Oct 2014 15:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRrwxRUViXwP; Tue, 7 Oct 2014 15:09:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0388C1A892A; Tue, 7 Oct 2014 15:09:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141007220932.20696.4443.idtracker@ietfa.amsl.com> Date: Tue, 07 Oct 2014 15:09:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/QIPjvtmNhowjgj0mbjJ0ilYLWZs Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-13.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 22:09:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : HTTP usage in the Registration Data Access Protocol (RDAP) Authors : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-13.txt Pages : 19 Date : 2014-10-07 Abstract: This document is one of a collection that together describe the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-using-http-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-using-http-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 7 18:41:56 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE3E1A8AE8 for ; Tue, 7 Oct 2014 18:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.238 X-Spam-Level: X-Spam-Status: No, score=-0.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhxJUtSjsII7 for ; Tue, 7 Oct 2014 18:41:51 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id E47BB1A8AE0 for ; Tue, 7 Oct 2014 18:41:50 -0700 (PDT) Received: from [192.168.101.248] (unknown [218.241.119.111]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMJBNljRUpEIJAA--.21088S2; Wed, 08 Oct 2014 09:41:44 +0800 (CST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: <54337316.50708@qti.qualcomm.com> Date: Wed, 8 Oct 2014 09:41:32 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54337316.50708@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0ApMJBNljRUpEIJAA--.21088S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ZFWrGw4fWr13KFW8tF4fKrg_yoW8CF15pa y3tr17Cr18Cw1xGw1jkw17tw15Zr4rJr45J3W5Wr1I93s8Wa48Jr48Kws8Za43GrsYk3Wr tr4fKF1UC3WrZ3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkIb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAC Y4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJV W8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6w4l42xK 82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGw C20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48J MIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMI IF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU5mQ6tUUUUU== X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Gd4v0ZPKLeDRk1e67Onw7dED-7Q Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-object-inventory-04 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 01:41:54 -0000 Hi Pete, Thanks for your review. We=A1=AFll rev the document according to your = comments ASAP. Ning =D4=DA 2014=C4=EA10=D4=C27=C8=D5=A3=AC=CF=C2=CE=E712:59=A3=ACPete = Resnick =D0=B4=B5=C0=A3=BA > Summary: Ready for Last Call, needs a few small changes. >=20 > I don't think any of these issues are controversial. Addressing them = should be quite quick, and then I'm happy to Last Call. (If the timing = is such that you can't do a rev in short order, I can Last Call it = as-is, but would prefer to get the changes.) >=20 > The nits checker reports long lines, "weird spacing", and pre-5378 = boilerplate. A fix to the line-length/spacing issues would be = appreciated, and removal of the pre-5378 boilerplate would be great. (I = don't see anything plausibly pre-5378 in here.) I'm happy to ignore the = 2606/5735 warnings; the examples in 5.4.1 are appropriate, I think, but = it might be nice to check with the folks you are using as examples to = make sure they are OK with their data appearing in an RFC. >=20 > You mention in several places the "top three" labels or data elements, = but give no reason anywhere in the document why that's an interesting = thing of note. If that fact was used for some reason, you should = probably mention it in section 1 or 3. >=20 > 6.1 - The definition of "list of resources" isn't great. I don't know = what an "Internet resource" is, and I don't know what "include" means in = the context of a definition. >=20 > 6.2 - s/handle/identifier >=20 > 10 - The division of "Normative" and "Informative" references in this = document strikes me as somewhat arbitrary. I'd probably make them all = "Informative". >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Tue Oct 7 19:28:23 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075CA1A900A for ; Tue, 7 Oct 2014 19:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9oeZMqvkoBG for ; Tue, 7 Oct 2014 19:28:21 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657EE1A8F4D for ; Tue, 7 Oct 2014 19:28:21 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s982SKVi029095 for ; Wed, 8 Oct 2014 11:28:20 +0900 X-AuditID: ac120820-b7fc78e000001dd0-d2-5434a143b021 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 1A.29.07632.341A4345; Wed, 8 Oct 2014 11:28:19 +0900 (JST) Date: Wed, 08 Oct 2014 11:27:53 +0900 (JST) Message-Id: <20141008.112753.179293785.kambe@jprs.co.jp> To: weirds@ietf.org From: Naoki Kambe In-Reply-To: References: <543373B9.30402@qti.qualcomm.com> <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> Organization: Japan Registry Services Co., Ltd. X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsWyRoiFT9d5oUmIwbzHFhbzu46zODB6LFny kymAMYrLJiU1J7MstUjfLoEr4+jn18wF3wUqjmw5wtjAOIG3i5GTQ0LARKJlSysThC0mceHe erYuRi4OIYGTjBIvz/xiBkmwCGhLXN7ymA3E5hWwkDi5bD9Yg4iAsMTil+9YQGxhAVeJGz+P g9WzCahILLu3GaiGg4NTIFBixsNakLCQwEpGiRmzfEHC/AL6ElObUiDW2kk0/QWZwgE0XVDi 7w5hkDCzgK7E3RXrGCFseYntb+cwT2Dkn4VQNQtJ1SwkVQsYmVcxyuSnpekWp+alFOemGxjq lVTm62UVFBXrJYPoTYzggONQ2ME445TBIUYBDkYlHt6OVpMQIdbEsuLK3EOMkhxMSqK8zjOA QnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4I6OBcrwpiZVVqUX5MClpDhYlcV5m495gIYH0xJLU 7NTUgtQimKwMB4eSBO/H+UCNgkWp6akVaZk5JQhpJg5OkOE8QMNfg9TwFhck5hZnpkPkTzEa cmz4+rKXiePEbxDZcPpDL5MQS15+XqqUOK/2AqAGAZCGjNI8uJmvGMWBXhPm/Q4yjgeYbOCm vQJaxAS0aFW/MciikkSElFQDY8e9ma+a5obHTJkWxPcwcO9km55Xk66+u8yZ/UWTh2+WBkdu gbhY9cOEd3/vRUTpzX7lZHLxb+efuFiXpqZy3qvXq66cTNqxZU2f2+F9aobfa+bzSoT0v3mz TsOjqTJLQPd8YaLV+miPyUmRKsYndfY7GuqeyK+V77of2JybtPPxwsdJjHHPlFiKMxINtZiL ihMBIK+aivMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/xnguJqrrwgjmXQu7GmMSqV2vRpQ Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 02:28:23 -0000 Hello, From: "Murray S. Kucherawy" Date: Tue, 7 Oct 2014 09:55:05 -0700 > On Tue, Oct 7, 2014 at 4:32 AM, Marc Blanchet > wrote: ... > > 3 - > > > > > > Internationalized Domain Names labels used as entries or base RDAP > > > URLs in the registries defined in this document MUST be only > > > represented using their A-Label form as defined in [RFC5890]. > > > > > > Doesn't this contradict what appears in rdap-query? > > > > humm. good point. This addition was from a review comment. I guess we > > should think about this one. > > > > WG (especially implementers and those with I18N fu), please speak up! I also think the above comment is good point. As for the entry part of the domain bootstrap file, I certainly suggested it should support A-label. Because the draft didn't mention about IDN formats, and I thought the format should be fixed in either one and it might not be so hard for the bootstrap parser to check the entries in the A-label format. But considering consistency with the rdap-query draft, I think the IDN entry in the domain bootstrap file should support both formats (A-label and U-label). However I think the corresponding base URLs should be same. Because such entries are not independent domain names. So an example of an IDN entry supporting both formats is: ... [ ["xn--zckzah", "$B%F%9%H(B"], [ "https://example.net/rdap/", "http://example.net/rdap/" ] ] ... As for the base URL part having IDN, I didn't have much strong opinion. However I think an A-label format is still preferred. Because the using-http draft seems for me to say IRI should be transformed to URI before querying in Section 9.1: 9.1. URIs and IRIs Clients can use IRIs [RFC3987] for internal use as they see fit, but MUST transform them to URIs [RFC3986] for interaction with RDAP servers. RDAP servers MUST use URIs in all responses, and again clients can transform these URIs to IRIs for internal use as they see fit. Any comments or any questions are welcome. Regards, Naoki Kambe From nobody Wed Oct 8 10:34:03 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B581ACD3F for ; Wed, 8 Oct 2014 10:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7-_fY3-92IL for ; Wed, 8 Oct 2014 10:34:01 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 001841ACD3D for ; Wed, 8 Oct 2014 10:34:00 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hy10so7194602vcb.15 for ; Wed, 08 Oct 2014 10:34:00 -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=FKVsnX4fPIFm9wh+pVc57Yf0sYNg2StA8o4JdF5zeq4=; b=I95fR8m4MPeyOrC8wn1wabeb+um5wEHdZODMr2lyoiO3sY6CCOrzbSrezsmPt2bSh6 nRZiIo+iJBW3r4l7w7nOFEQZpDgUy0/+QTgJkWzGhseeV3s3XWBpUW0r1kOTtuXhGFiH +JZJPmAZDZbGbcfZl+Y2TErJKtpIxwMV/o6HSeT/wyNpj0qfwnoJGGW3kf2caKyupHQu dP+gWLbuS8k53bZ/5vcxD61+IxCWYMnPtJux2Ue1A2sApp+f8kXXf712pbYNzhliAUxQ CfuDwG2QQUa4zYEZm8zeBXmyFt0r3pub5btsoVJvnIo9xAjA1EZrpukkCdw/DMVDSyC8 5LHQ== MIME-Version: 1.0 X-Received: by 10.221.62.133 with SMTP id xa5mr12446455vcb.41.1412789640136; Wed, 08 Oct 2014 10:34:00 -0700 (PDT) Received: by 10.52.79.66 with HTTP; Wed, 8 Oct 2014 10:34:00 -0700 (PDT) Date: Wed, 8 Oct 2014 10:34:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11347a0aa4a2cc0504ecb8d9 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/3ND-H7c4k4mPeBWZOktEDaIo7h4 Subject: [weirds] Obligatory timeline reminder X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 17:34:02 -0000 --001a11347a0aa4a2cc0504ecb8d9 Content-Type: text/plain; charset=UTF-8 Colleagues, Our revised timeline has us getting all six documents on the 10/30 telechat. Backtracking from there, we need to complete a two-week IETF Last Call no later than 10/29, which means it needs to start by 10/15, which is one week from today. That presumes that the IETF Last Call produces no feedback requiring document changes, which is quite possibly not a safe assumption (especially on bootstrap's IANA stuff and internationalization), so it sure would be prudent for us to have a buffer there in case something does come up. Therefore... Authors: Can we get realistic estimates for when your revisions based on AD Evaluation will be posted? If there are open issues, please help to drive discussion on them. Pete: I believe you have the token on bootstrap, at least in part. Everyone else: There was at least one open issue on the bootstrap document having to do with internationalization. One person has responded with an opinion. Please participate in the discussion; whatever change is made now has to have WG consensus before it can advance. -MSK, WEIRDS "Nag early, nag often" co-chair --001a11347a0aa4a2cc0504ecb8d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

Our revised timeline ha= s us getting all six documents on the 10/30 telechat.=C2=A0 Backtracking fr= om there, we need to complete a two-week IETF Last Call no later than 10/29= , which means it needs to start by 10/15, which is one week from today.=C2= =A0 That presumes that the IETF Last Call produces no feedback requiring do= cument changes, which is quite possibly not a safe assumption (especially o= n bootstrap's IANA stuff and internationalization), so it sure would be= prudent for us to have a buffer there in case something does come up.
<= br>
Therefore...

Authors: Can we get realistic = estimates for when your revisions based on AD Evaluation will be posted?=C2= =A0 If there are open issues, please help to drive discussion on them.
<= br>
Pete: I believe you have the token on bootstrap, at leas= t in part.

Everyone else: There was at least one open issue on= the bootstrap document having to do with internationalization.=C2=A0 One p= erson has responded with an opinion.=C2=A0 Please participate in the discus= sion; whatever change is made now has to have WG consensus before it can ad= vance.

-MSK, WEIRDS "Nag early, nag often" co-chair<= br>

--001a11347a0aa4a2cc0504ecb8d9-- From nobody Wed Oct 8 12:18:09 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15901A1A6E for ; Wed, 8 Oct 2014 12:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAhkCJYeOFwO for ; Wed, 8 Oct 2014 12:18:04 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id A3D891A1A83 for ; Wed, 8 Oct 2014 12:18:00 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 4C2E7213825; Wed, 8 Oct 2014 15:18:00 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id DF24721380E; Wed, 8 Oct 2014 15:17:59 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 8 Oct 2014 15:19:58 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Wed, 8 Oct 2014 15:17:59 -0400 From: Andy Newton To: "Murray S. Kucherawy" Thread-Topic: [weirds] Obligatory timeline reminder Thread-Index: AQHP4x4Q7RbTWPrdUkmR+/AWXHdH/Jwm1fcA Date: Wed, 8 Oct 2014 19:17:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <899CA858917D1745A3763587909E53F9@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/vH0EUqK2XPu1mKbbu2SzouBEEVg Cc: "weirds@ietf.org" Subject: Re: [weirds] Obligatory timeline reminder X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:18:07 -0000 On Oct 8, 2014, at 1:34 PM, Murray S. Kucherawy wrote= : > Authors: Can we get realistic estimates for when your revisions based on = AD Evaluation will be posted? If there are open issues, please help to dri= ve discussion on them. Edits on json-response are under way and should be finished either today or= tomorrow. However, I=92ve still heard nothing about a privacy consideratio= ns review. -andy= From nobody Wed Oct 8 12:49:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE841A0211 for ; Wed, 8 Oct 2014 12:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dtGmIfv916i for ; Wed, 8 Oct 2014 12:49:38 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3781A019B for ; Wed, 8 Oct 2014 12:49:38 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hy4so7500049vcb.28 for ; Wed, 08 Oct 2014 12:49:37 -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=d2WkbDJLqvkeoiaJcDwJD0JDex8UvWtunx1tiwwJU+Q=; b=zrt/uNiiJ29eFdctDHXJAmyYIQDnis8PYf9rXhcjNbXHSvY8e6mGTMqGH5uKJcYe4j Mvc+QCR4jOnh/4Bsai2jErXwE7iTAc1DvgO8pgwVT7exvcSLuIlL9pODFjSomUp9Fb8P Hzd3V1Ce8LTsA9H/ol0a4rTq6Xiv/47ohrICdgM66I7KVfWq2L/9XqQDvgS6eon46fox JJqAKZlSndLFuIHjqURuM2jUx+1Mn5d5QBdAixSCyILouE9uBPw6eneeHQUQkGg4hkx7 46jfZ/xPAW4x2uaRqDwKgyckHxIa6JsWnPAWHIeAbFrFDjNSjLTVeKq20f1p7s3lsn8s +q8w== MIME-Version: 1.0 X-Received: by 10.52.227.39 with SMTP id rx7mr11199310vdc.13.1412797773953; Wed, 08 Oct 2014 12:49:33 -0700 (PDT) Received: by 10.52.79.66 with HTTP; Wed, 8 Oct 2014 12:49:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Oct 2014 12:49:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=089e01161ba674c82c0504ee9d85 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/QnirUDeyjMtddoxpc_IHjoex8qY Cc: "weirds@ietf.org" Subject: Re: [weirds] Obligatory timeline reminder X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:49:41 -0000 --089e01161ba674c82c0504ee9d85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 8, 2014 at 12:17 PM, Andy Newton wrote: > > On Oct 8, 2014, at 1:34 PM, Murray S. Kucherawy > wrote: > > > Authors: Can we get realistic estimates for when your revisions based o= n > AD Evaluation will be posted? If there are open issues, please help to > drive discussion on them. > > Edits on json-response are under way and should be finished either today > or tomorrow. However, I=E2=80=99ve still heard nothing about a privacy > considerations review. > > -andy I reviewed it during WGLC and I thought it was fine. Since you specifically asked (and from the No Good Deed Goes Unpunished department), off the top of my head I have two other suggestions, which you can take or leave as you see fit: (1) "Privacy Considerations" to me refers to the IAB's recommendations about how to make sure privacy issues are addressed, which were published in RFC6973. Invoking that section name might cause people to compare what you're saying here to what's said in there. You might want to give it a once-over to see if it inspires you to say anything more than what you already have. (2) In RFC7070 I took a run at doing exactly what I said above. You might similarly find Section 8 of that RFC useful. -MSK --089e01161ba674c82c0504ee9d85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 8, 2014 at 12:17 PM, Andy Newton <andy@arin.net> wrote:

On Oct 8, 2014, at 1:34 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:

> Authors: Can we get realistic estimates for when your revisions based = on AD Evaluation will be posted?=C2=A0 If there are open issues, please hel= p to drive discussion on them.

Edits on json-response are under way and should be finished either t= oday or tomorrow. However, I=E2=80=99ve still heard nothing about a privacy= considerations review.

-andy

= I reviewed it during WGLC and I thought it was fine.=C2=A0 Since you specif= ically asked (and from the No Good Deed Goes Unpunished department), off th= e top of my head I have two other suggestions, which you can take or leave = as you see fit:

(1) "Privacy Considerations" to me refers = to the IAB's recommendations about how to make sure privacy issues are = addressed, which were published in RFC6973.=C2=A0 Invoking that section nam= e might cause people to compare what you're saying here to what's s= aid in there.=C2=A0 You might want to give it a once-over to see if it insp= ires you to say anything more than what you already have.

(2) In RFC7070 I took a run at doing exactly what I = said above.=C2=A0 You might similarly find Section 8 of that RFC useful.
-MSK
--089e01161ba674c82c0504ee9d85-- From nobody Wed Oct 8 14:47:28 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F151A1A72 for ; Wed, 8 Oct 2014 14:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K4UbUJX3NXJ for ; Wed, 8 Oct 2014 14:47:25 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id A89B71A1A6F for ; Wed, 8 Oct 2014 14:47:25 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 4FEAC16510D; Wed, 8 Oct 2014 17:47:25 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id E026F1650D1; Wed, 8 Oct 2014 17:47:24 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 8 Oct 2014 17:49:41 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Wed, 8 Oct 2014 17:47:24 -0400 From: Andy Newton To: "Murray S. Kucherawy" Thread-Topic: [weirds] Obligatory timeline reminder Thread-Index: AQHP4x4Q7RbTWPrdUkmR+/AWXHdH/Jwm1fcAgAAI0YCAACDugA== Date: Wed, 8 Oct 2014 21:47:23 +0000 Message-ID: <842847C2-9B93-44AB-811D-753B01D9A445@arin.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6AF92720CB262F499E12682980BB65D2@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/--gOLpbis6gpH1eX9cb2iNDugE4 Cc: "weirds@ietf.org" Subject: Re: [weirds] Obligatory timeline reminder X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 21:47:26 -0000 On Oct 8, 2014, at 3:49 PM, Murray S. Kucherawy wrote= : > (1) "Privacy Considerations" to me refers to the IAB's recommendations ab= out how to make sure privacy issues are addressed, which were published in = RFC6973. Invoking that section name might cause people to compare what you= 're saying here to what's said in there. You might want to give it a once-= over to see if it inspires you to say anything more than what you already h= ave. >=20 > (2) In RFC7070 I took a run at doing exactly what I said above. You migh= t similarly find Section 8 of that RFC useful. Good idea. Having just read both 6973 and 7070, I don=92t really see much m= ore that can be added specifically regarding the JSON serialization of RDAP= data. But I=92m willing to take suggestions. -andy= From nobody Wed Oct 8 15:04:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0401A1A7E for ; Wed, 8 Oct 2014 15:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgYmOOi274eE for ; Wed, 8 Oct 2014 15:03:56 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893B51A0028 for ; Wed, 8 Oct 2014 15:03:56 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hy4so20921vcb.14 for ; Wed, 08 Oct 2014 15:03:55 -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=zStdaw4f/MBLCuh47HiPL6AxQks6T4U7mqiiPayNxso=; b=uCAEIu9lvMqvu8hOqHIPZTPmi5rPN9/7Rt1dz/WgtfAydehWPLNBzKiVrY55amGZj9 JvPs7+s4igx3yhTvJaay0xrjGMkI91CMsg34DV/K3Pum4tjrAxKaF5o53L3Nsp2IhPjn uC8diZZod8H4jQpXuvuYAdjYmnn+lHrqqnKqOOQSyN2zVSscjB7kLwmLX1onRPv6xPo9 5veMs5B3hj93loArbQLhBRTFzaJvhlhGkkI4wcn6gSGJj8L16xGvguC+pF/wYR0W4vVy OgiKEYDQnQf6vUyeAotmMN3q5bCToNaBpzdvx0IB5Lj/ijAEng71mVjkaFBQ1YhK/Eys pOmA== MIME-Version: 1.0 X-Received: by 10.221.59.2 with SMTP id wm2mr14063544vcb.52.1412805835755; Wed, 08 Oct 2014 15:03:55 -0700 (PDT) Received: by 10.52.79.66 with HTTP; Wed, 8 Oct 2014 15:03:55 -0700 (PDT) In-Reply-To: <842847C2-9B93-44AB-811D-753B01D9A445@arin.net> References: <842847C2-9B93-44AB-811D-753B01D9A445@arin.net> Date: Wed, 8 Oct 2014 15:03:55 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=001a11334f10fa188f0504f07d49 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/A1FgUigwp3lyrg8H2TCsfXeMKxY Cc: "weirds@ietf.org" Subject: Re: [weirds] Obligatory timeline reminder X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 22:03:59 -0000 --001a11334f10fa188f0504f07d49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 8, 2014 at 2:47 PM, Andy Newton wrote: > Good idea. Having just read both 6973 and 7070, I don=E2=80=99t really se= e much > more that can be added specifically regarding the JSON serialization of > RDAP data. But I=E2=80=99m willing to take suggestions I don't think I have anything specific to JSON. I could probably come up with some more general privacy things, but if what's in 7070 and 6973 didn't give you any ideas, then I don't have much else to suggest either. -MSK --001a11334f10fa188f0504f07d49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11334f10fa188f0504f07d49-- From nobody Thu Oct 9 04:39:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C2B1ACD7A; Thu, 9 Oct 2014 04:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRKZ7dsqs_8q; Thu, 9 Oct 2014 04:39:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0F81ACDCF; Thu, 9 Oct 2014 04:39:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141009113910.20495.54019.idtracker@ietfa.amsl.com> Date: Thu, 09 Oct 2014 04:39:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/jqD9P1cKSmJ52PUO4kkpehIcnTc Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-10.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 11:39:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : JSON Responses for the Registration Data Access Protocol (RDAP) Authors : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-json-response-10.txt Pages : 90 Date : 2014-10-09 Abstract: This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-json-response-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-json-response-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 9 19:33:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB31F1A0086; Thu, 9 Oct 2014 19:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUt-Ta9RjUK3; Thu, 9 Oct 2014 19:33:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 817CE1A0089; Thu, 9 Oct 2014 19:33:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010023334.18245.7605.idtracker@ietfa.amsl.com> Date: Thu, 09 Oct 2014 19:33:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/jdMAzLj4QFls7u-kHsAhVcsMRnQ Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-object-inventory-05.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 02:33:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Registration Data Access Protocol Object Inventory Analysis Authors : Linlin Zhou Ning Kong Sean Shen Arturo Servin Filename : draft-ietf-weirds-object-inventory-05.txt Pages : 31 Date : 2014-10-09 Abstract: WHOIS output objects from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) were collected and analyzed. This document describes the statistical analysis process and result of existing WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-object-inventory-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-object-inventory-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 9 20:26:39 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155091A00D4 for ; Thu, 9 Oct 2014 20:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qt8biVxZT-IM for ; Thu, 9 Oct 2014 20:26:35 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBA81A00D6 for ; Thu, 9 Oct 2014 20:26:33 -0700 (PDT) Received: from [218.241.103.207] (unknown [218.241.103.207]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QJDIUTdUoAIKAA--.22362S3; Fri, 10 Oct 2014 11:26:13 +0800 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7EB604D5-E359-441F-8452-51C1B2077820" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: Date: Fri, 10 Oct 2014 11:18:50 +0800 Message-Id: <61C911F7-241F-4EA0-8083-247466E770F2@cnnic.cn> References: To: "Murray S. Kucherawy" , Pete Resnick X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0A5QJDIUTdUoAIKAA--.22362S3 X-Coremail-Antispam: 1UD129KBjvJXoW7uw1kur48tFW7WryDCw1Dtrb_yoW8Xry8p3 yakr4akFn5Jr48Kw48Gw1jq3y0v3y8Gw4UJFn8tw1UZFZ8Ga4YyryIya1Yvay3uFs3Zryj vr15uF4kJr93ArDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Kb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI 8067AKxVWUGwA2048vs2IY020Ec7CjxVAFwI0_Jrv_JF4l8cAvFVAK0II2c7xJM28CjxkF 64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0cI8IcV CY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIE c7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAv7VC0I7IYx2IY67AKxV WUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI 7VAKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_Gr4l42xK82IYc2Ij64vIr4 1l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK 67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI 8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAv wI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14 v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUcmL9UUUUU X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/HRr7UtrQadfN1foPP7yvZNLAp8o Cc: "weirds@ietf.org" Subject: Re: [weirds] Obligatory timeline reminder X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 03:26:38 -0000 --Apple-Mail=_7EB604D5-E359-441F-8452-51C1B2077820 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Murray and Pete, draft-ietf-weirds-object-inventory-05 based on AD Evaluation is just = posted. Cheers, Ning =D4=DA 2014=C4=EA10=D4=C29=C8=D5=A3=AC=C9=CF=CE=E71:34=A3=ACMurray S. = Kucherawy =D0=B4=B5=C0=A3=BA > Colleagues, >=20 > Our revised timeline has us getting all six documents on the 10/30 = telechat. Backtracking from there, we need to complete a two-week IETF = Last Call no later than 10/29, which means it needs to start by 10/15, = which is one week from today. That presumes that the IETF Last Call = produces no feedback requiring document changes, which is quite possibly = not a safe assumption (especially on bootstrap's IANA stuff and = internationalization), so it sure would be prudent for us to have a = buffer there in case something does come up. >=20 > Therefore... >=20 > Authors: Can we get realistic estimates for when your revisions based = on AD Evaluation will be posted? If there are open issues, please help = to drive discussion on them. >=20 > Pete: I believe you have the token on bootstrap, at least in part. >=20 > Everyone else: There was at least one open issue on the bootstrap = document having to do with internationalization. One person has = responded with an opinion. Please participate in the discussion; = whatever change is made now has to have WG consensus before it can = advance. >=20 > -MSK, WEIRDS "Nag early, nag often" co-chair >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_7EB604D5-E359-441F-8452-51C1B2077820 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312

Hi Murray and = Pete,

draft-ietf-weirds-object-inventory-05 based on AD = Evaluation is just posted.

Cheers,
Ning



Colleagues,

Our revised timeline has = us getting all six documents on the 10/30 telechat.  Backtracking = from there, we need to complete a two-week IETF Last Call no later than = 10/29, which means it needs to start by 10/15, which is one week from = today.  That presumes that the IETF Last Call produces no feedback = requiring document changes, which is quite possibly not a safe = assumption (especially on bootstrap's IANA stuff and = internationalization), so it sure would be prudent for us to have a = buffer there in case something does come = up.

Therefore...

Authors: Can we get = realistic estimates for when your revisions based on AD Evaluation will = be posted?  If there are open issues, please help to drive = discussion on them.

Pete: I believe you have the = token on bootstrap, at least in part.

Everyone else: There = was at least one open issue on the bootstrap document having to do with = internationalization.  One person has responded with an = opinion.  Please participate in the discussion; whatever change is = made now has to have WG consensus before it can = advance.

-MSK, WEIRDS "Nag early, nag often" = co-chair

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

= --Apple-Mail=_7EB604D5-E359-441F-8452-51C1B2077820-- From nobody Fri Oct 10 15:00:36 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D191A8861 for ; Fri, 10 Oct 2014 15:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKFWOfrJLr9h for ; Fri, 10 Oct 2014 15:00:32 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203DA1A884D for ; Fri, 10 Oct 2014 15:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1412978433; x=1444514433; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=V0k5OFEZU4MuhR5uZS+3O9hfzDjb+KCAeCTP2UuftcI=; b=CiLqJ+0XYgD0N3olkG7Bjc6/JLHlswn5sD0O56+cUm+UQVkDU0cQmgxY 8s3cJRdQMMi/uP3Og7sNDrxdbdIczg0HNpZm5Xb5TFI3056FSgRxpwpWD EDxw9IedJYU1jIZvzWe7yxpgTF81oSGjDRAAH6r3Yp2ROCASlPTN2D/Nc g=; X-IronPort-AV: E=McAfee;i="5600,1067,7587"; a="165557950" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Oct 2014 15:00:32 -0700 X-IronPort-AV: E=Sophos;i="5.04,694,1406617200"; d="scan'208";a="767444707" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Oct 2014 15:00:31 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 10 Oct 2014 15:00:31 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 10 Oct 2014 15:00:30 -0700 Message-ID: <543856E3.8080705@qti.qualcomm.com> Date: Fri, 10 Oct 2014 17:00:03 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.46.201.191) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/DkffPqK4Mu3Ys1W7oS7zvhfbtBQ Cc: "weirds@ietf.org" Subject: Re: [weirds] Obligatory timeline reminder X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:00:35 -0000 On 10/8/14 12:34 PM, Murray S. Kucherawy wrote: > Pete: I believe you have the token on bootstrap, at least in part. OK, so I have failed to get everything to Marc by yesterday as I promised him privately. Still working at it. My apologies. Here's my plan: - I'm going to Last Call the other 5 documents today. That way there's only one document on the IESG agenda with the "Only just completed Last Call" warning on the ballot. - I'll note in the -rdap-query Last Call that -bootstrap is coming soon. - I'm going to finish up with bootstrap ASAP. I will do everything I can to get comments to Marc tonight or tomorrow so we can hopefully have it out to Last Call early next week. You'll start seeing notices soon. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Oct 10 15:09:08 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6991AD45F for ; Fri, 10 Oct 2014 15:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHsZ1uJlP4qO; Fri, 10 Oct 2014 15:09:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9C41AD43C; Fri, 10 Oct 2014 15:08:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-object-inventory@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010220856.2309.15687.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:08:56 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/BM7K0nYD0jW_Yofu3DRiUoxKABc Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:09:05 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ From nobody Fri Oct 10 15:11:31 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E59F1AD41C for ; Fri, 10 Oct 2014 15:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bj9rHTFcz2Q for ; Fri, 10 Oct 2014 15:11:29 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B231A8716 for ; Fri, 10 Oct 2014 15:11:28 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id pn19so4150722lab.28 for ; Fri, 10 Oct 2014 15:11:26 -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=QBB6ZR00T/ORgN1wZA9QwbPiTLzUjwKiWcPAmy47jBg=; b=kE9LVNg7BQXpdGVy0a75kdv59yKVblEHqRBKweORefTUOcpKo+gxsktMba7i6tjTtY 0V0rSgBeQy77cpEbvzRUP/gP0ABUq9A83snsmC4/ZzQfGwGXcitoUwz2SytIfpPHHS7P 9sNFUrBiBRhi0pz5MazHfLADy+zUeGbrVE1nh1ZHyZ/+dwvZegHSgoDqFwiDhRvylA1R vrJUcf4zqdzO0+n1DTEjdZG/5+ti2l9uxKTvUTKjAFoQt1i9HmMpvi1MKQkGgrzg3yWU 2vCwIOqB5H66j1MHsQZyzCInUgwnXvI3HumJL1joBtvFw02GU4y23/E3NLUPjA3nFjt3 hrGQ== MIME-Version: 1.0 X-Received: by 10.152.115.229 with SMTP id jr5mr7809390lab.7.1412979086888; Fri, 10 Oct 2014 15:11:26 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Fri, 10 Oct 2014 15:11:26 -0700 (PDT) In-Reply-To: <543856E3.8080705@qti.qualcomm.com> References: <543856E3.8080705@qti.qualcomm.com> Date: Fri, 10 Oct 2014 15:11:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c354588c9460050518d4d7 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/IHk_1nb6wP5-E6X1wfYfNeLVq7A Cc: "weirds@ietf.org" Subject: Re: [weirds] Obligatory timeline reminder X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:11:30 -0000 --001a11c354588c9460050518d4d7 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 10, 2014 at 3:00 PM, Pete Resnick wrote: > > - I'm going to finish up with bootstrap ASAP. I will do everything I can > to get comments to Marc tonight or tomorrow so we can hopefully have it out > to Last Call early next week. > > I'm going to take a run at some of bootstrap tonight as well, to try to help get it across the finish line. I'll post my suggestions to the list ASAP. -MSK --001a11c354588c9460050518d4d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 10, 2014 at 3:00 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:

- I'm going to finish up with bootstrap ASAP. I will do everything I ca= n to get comments to Marc tonight or tomorrow so we can hopefully have it o= ut to Last Call early next week.


I'm going to take a run at some of= bootstrap tonight as well, to try to help get it across the finish line.= =C2=A0 I'll post my suggestions to the list ASAP.

-MSK
--001a11c354588c9460050518d4d7-- From nobody Fri Oct 10 15:14:02 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6961AD463; Fri, 10 Oct 2014 15:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc57kcqAJ3PE; Fri, 10 Oct 2014 15:13:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 503131AD423; Fri, 10 Oct 2014 15:13:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141010221358.10730.80045.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:13:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/WxHa1VFD80-poVq95ZjhWgQA1qI Cc: weirds@ietf.org Subject: [weirds] Last Call: (Registration Data Access Protocol Object Inventory Analysis) to Informational RFC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 10 Oct 2014 22:13:59 -0000 The IESG has received a request from the Web Extensible Internet Registration Data Service WG (weirds) to consider the following document: - 'Registration Data Access Protocol Object Inventory Analysis' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract WHOIS output objects from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) were collected and analyzed. This document describes the statistical analysis process and result of existing WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 10 15:14:27 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE12E1AD455 for ; Fri, 10 Oct 2014 15:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDRLUV0R-ulR; Fri, 10 Oct 2014 15:14:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C771AD423; Fri, 10 Oct 2014 15:13:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-object-inventory@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010221359.10730.65313.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:13:59 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/sJueAzBNnPSbafGW1LD2E27IsIg Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:14:15 -0000 Last call has been made for draft-ietf-weirds-object-inventory and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ From nobody Fri Oct 10 15:14:52 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8941AD469 for ; Fri, 10 Oct 2014 15:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYC8dAoG4avy; Fri, 10 Oct 2014 15:14:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2DC1AD473; Fri, 10 Oct 2014 15:14:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-using-http@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010221428.31860.25979.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:14:28 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/DFgST2TYgZKQJeo_asQrZim3uws Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:14:49 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ From nobody Fri Oct 10 15:18:52 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72F61AD446 for ; Fri, 10 Oct 2014 15:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUapL_vFnDYZ; Fri, 10 Oct 2014 15:18:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 309BF1A88C1; Fri, 10 Oct 2014 15:18:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010221842.31905.84063.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:18:42 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/lDZDvJ6ZnvS2Oes6Eo0m-31apuk Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:18:46 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ From nobody Fri Oct 10 15:20:23 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9531AD452 for ; Fri, 10 Oct 2014 15:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArVBmQGSi6is; Fri, 10 Oct 2014 15:20:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E071AD457; Fri, 10 Oct 2014 15:19:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010221947.12980.58897.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:19:47 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/pYzVwMlcvEVXfVvBzJ0iQJvE9i4 Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:20:17 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ From nobody Fri Oct 10 15:21:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D23C1A88C1 for ; Fri, 10 Oct 2014 15:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju1KfTz0IKxK; Fri, 10 Oct 2014 15:21:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2E31AD43C; Fri, 10 Oct 2014 15:21:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010222104.3460.90632.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:21:04 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/kb7sWjAzxLEHT6QCW1u8fv4HJWM Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:21:12 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ From nobody Fri Oct 10 15:22:15 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AAF1AD46A; Fri, 10 Oct 2014 15:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETZyqGxbFkZC; Fri, 10 Oct 2014 15:22:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 049A31A88C5; Fri, 10 Oct 2014 15:22:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141010222207.8413.95671.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:22:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/_HkDrROW4xt8YbmC4l-jjvvCANc Cc: weirds@ietf.org Subject: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 10 Oct 2014 22:22:10 -0000 The IESG has received a request from the Web Extensible Internet Registration Data Service WG (weirds) to consider the following document: - 'HTTP usage in the Registration Data Access Protocol (RDAP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that this is a second Last Call. During its initial IESG Evaluation, the IESG had several issues to address. This document has addressed those issues. Note also that this document refers to draft-ietf-weirds-bootstrap. Last Call for that document is coming soon, but review on this document can be done at this time. Abstract This document is one of a collection that together describe the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 10 15:22:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998951AD46D for ; Fri, 10 Oct 2014 15:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDBU6kpiXOdh; Fri, 10 Oct 2014 15:22:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2111AD457; Fri, 10 Oct 2014 15:22:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-using-http@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010222207.8413.61432.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:22:07 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NNX7KTP3d15uBAZNlVPtBv9nwno Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:22:15 -0000 Last call has been made for draft-ietf-weirds-using-http and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ From nobody Fri Oct 10 15:26:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE671AD47A; Fri, 10 Oct 2014 15:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M19-qeVnfjVe; Fri, 10 Oct 2014 15:25:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E601A889B; Fri, 10 Oct 2014 15:25:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141010222555.16655.23175.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:25:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NfdqGWiTuq6X4-pSPuk1Yv0HuZA Cc: weirds@ietf.org Subject: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 10 Oct 2014 22:25:57 -0000 The IESG has received a request from the Web Extensible Internet Registration Data Service WG (weirds) to consider the following document: - 'Registration Data Access Protocol Query Format' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that this document refers to draft-ietf-weirds-bootstrap. Last Call for that document is coming soon, but review on this document can be done at this time. 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. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 10 15:26:09 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2891AD47F for ; Fri, 10 Oct 2014 15:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWJ1uSWLgzdv; Fri, 10 Oct 2014 15:26:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B719B1AD3F7; Fri, 10 Oct 2014 15:25:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010222555.16655.76457.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:25:55 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/JDJOknN6iq9yqFA2lRHgBIEkTIM Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:26:03 -0000 Last call has been made for draft-ietf-weirds-rdap-query and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ From nobody Fri Oct 10 15:27:12 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559D31A88DB; Fri, 10 Oct 2014 15:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiNI0KsRX9mA; Fri, 10 Oct 2014 15:27:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3271A88BF; Fri, 10 Oct 2014 15:27:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141010222701.9684.92009.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:27:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/uW06hcMH3aLm7SzEk6YUH_ezV70 Cc: weirds@ietf.org Subject: [weirds] Last Call: (Security Services for the Registration Data Access Protocol) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 10 Oct 2014 22:27:07 -0000 The IESG has received a request from the Web Extensible Internet Registration Data Service WG (weirds) to consider the following document: - 'Security Services for the Registration Data Access Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that this is a second Last Call. During its initial IESG Evaluation, the IESG had several issues to address. This document has addressed those issues. Abstract The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services including authentication, authorization, availability, data confidentiality, and data integrity for RDAP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 10 15:27:23 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970601AD48D for ; Fri, 10 Oct 2014 15:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xE7MJ7qr6te2; Fri, 10 Oct 2014 15:27:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDDA1AD483; Fri, 10 Oct 2014 15:27:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010222702.9684.82421.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:27:02 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/plQD2ZEcIu-zr7Ekb-XHUJpL0RM Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:27:11 -0000 Last call has been made for draft-ietf-weirds-rdap-sec and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ From nobody Fri Oct 10 15:29:59 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35E01AD499; Fri, 10 Oct 2014 15:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COvdqDY06F01; Fri, 10 Oct 2014 15:29:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 666781A88CB; Fri, 10 Oct 2014 15:29:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141010222952.18899.38570.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:29:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/qGQg-SIhNyXPnOv_JfJ73j9SS0U Cc: weirds@ietf.org Subject: [weirds] Last Call: (JSON Responses for the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 10 Oct 2014 22:29:54 -0000 The IESG has received a request from the Web Extensible Internet Registration Data Service WG (weirds) to consider the following document: - 'JSON Responses for the Registration Data Access Protocol (RDAP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 10 15:30:08 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94751AD4A3 for ; Fri, 10 Oct 2014 15:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H502XmGM67_h; Fri, 10 Oct 2014 15:29:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BA91AD489; Fri, 10 Oct 2014 15:29:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010222952.18899.94245.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 15:29:52 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/aSeguM2jollBVlr4jj9QQyxhpXU Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:30:02 -0000 Last call has been made for draft-ietf-weirds-json-response and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ From nobody Sun Oct 12 20:49:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66071A8799 for ; Sun, 12 Oct 2014 20:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTwtm5fcWz2e for ; Sun, 12 Oct 2014 20:49:05 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4011A8790 for ; Sun, 12 Oct 2014 20:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413172145; x=1444708145; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=kn2HRIhLJ5T/pe3g5mhyLWpeRopVafwIMsmIQ+7YC2o=; b=dBnOysUAnq8zjPlrKETIFBIcbyl8tZwF2s28E0W719GzzXKka0QbMbEc gVXP4Bf734B9lSw+sng9F74gMvaB3QTOaCADIPWM0bgQU4Xj31vFc4wpE xUup2a++P6LzscRCYUl22Tz6vKZk93ePd8lrkF4lN/YwJkjIVoqDFArZk Y=; X-IronPort-AV: E=McAfee;i="5600,1067,7589"; a="75948126" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2014 20:49:05 -0700 X-IronPort-AV: E=Sophos;i="5.04,707,1406617200"; d="scan'208";a="728440272" Received: from nasanexhc03.na.qualcomm.com ([10.46.200.142]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Oct 2014 20:49:05 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by NASANEXHC03.na.qualcomm.com (10.46.200.142) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 12 Oct 2014 20:49:04 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 12 Oct 2014 20:49:04 -0700 Message-ID: <543B4BAF.8060602@qti.qualcomm.com> Date: Sun, 12 Oct 2014 22:49:03 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Marc Blanchet References: <543373B9.30402@qti.qualcomm.com> <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> In-Reply-To: <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (129.46.53.236) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/zS603b_LMN23RlYrcse7c9drexs Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 03:49:08 -0000 On 10/7/14 6:32 AM, Marc Blanchet wrote: > Le 2014-10-07 à 01:01, Pete Resnick a écrit : > > thanks for your review. > > >> Summary: Not ready for Last Call. >> >> I've got some real concerns with this document that need to be addressed before I'm willing to Last Call it. >> OK, Murray sent me some sample text that he thought might satisfy, and I think it does, so I'm going to steal pieces of it and suggest we use it. Here are my current thoughts: 1- I think making the following change to the introduction will go a long way in clarifying for me: OLD The proposed mechanism is based on the fact that allocation data for domain names and IP addresses are maintained by IANA, are publicly available and are in a structured format. The mechanism assumes some data structure within these registries. This document requests IANA to create these registries for the specific purpose of RDAP use, herein named RDAP Bootstrap Service registries. An RDAP client fetches the RDAP Bootstrap Service registries, extracts the data and then does a match with the query data to find the authoritative registration data server and appropriate query base URL. NEW TLDs, AS numbers, and network blocks are delegated by IANA to registrars that then issue further delegations and maintain information about them. Thus, obviously the bootstrap information needed by RDAP clients is best generated from data and processes already maintained by IANA, whose registries already exist at [ipv4reg], [ipv6reg], [asreg], and [domainreg]. The required new functionality in support of RDAP could be accomplished by augmenting these registries to contain new fields, or creating second parallel registries containing the extra fields whose entries mirror the existing ones. Either approach will satisfy the needs of this document. This document requests IANA to make these registries available for the specific purpose of RDAP use, herein named RDAP Bootstrap Service Registries. An RDAP client fetches the RDAP Bootstrap Service Registries, extracts the data and then does a match with the query data to find the authoritative registration data server and appropriate query base URL. END That makes it clear up front what we're asking IANA, and clients, to do. And then I think I'm fine with most of section 3, though I would like to put in some of the clarifications I had in my original comments: 3 - OLD The RDAP Bootstrap Service Registries are made available as JSON [RFC7159] objects. The JSON registry output starts with metadata such as a version identifier, a timestamp of the publication date of the registry and a description. There exists a "services" element, which is an array of arrays. Each second level array contains two elements, each of them being an array (third-level arrays). NEW The RDAP Bootstrap Service Registries will be made available as JSON [RFC7159] objects, to be retrieved via HTTP from a location as specified by IANA in section 12. The JSON object for each registry will start with a series of members that contain metadata about the registry such as a version identifier, a timestamp of the publication date of the registry and a description. Following that is a "services" member which contains the registry items themselves, as an array. Each item of the array contains a second-level array, with two elements, each of them being a third-level array. END > - I have to say again that IANA looked at it (both the technical people and the registration people) and they were fine with the text. > I'm not worried about IANA. I'm sure between the text and what you've explained, they can handle it. I'm shooting for making it clear to the IETF folks who are reading it. With the above suggested, and what I've got down for section 12 below, I think it will be much clearer for them. > - the json format evolved into multiple level arrays, as requested by implementors. A two columns table won't really show this structure. So in some ways, we are just not used to define registries in complex JSON formats. I guess I'm the guiney pig... > I think, given Andy's comment, best to leave it be at this point. Going through my other points: >> Throughout - Update RFC 4627 to RFC 7159 >> Don't forget that one. >> 3 - >> >> Internationalized Domain Names labels used as entries or base RDAP >> URLs in the registries defined in this document MUST be only >> represented using their A-Label form as defined in [RFC5890]. >> >> Doesn't this contradict what appears in rdap-query? >> > humm. good point. This addition was from a review comment. I guess we should think about this one. > I think between Naoki and John L's comment, I'm OK with leaving this, as the context is different. >> 7 - s/the client SHOULD provide/the client provides >> >> 8 - >> >> o If the client knows the existence of an RDAP aggregator or >> redirector and trusts that service, then it could send the query >> to the redirector, which would redirect the client if it knows the >> authoritative server that client has not found. >> >> I think you need to mention the base URL here: >> >> o If the client has previously discovered an RDAP aggregator or >> redirector and its associated base URL, and the client trusts that >> service, then it could send the query to the redirector, which >> would redirect the client if it knows the authoritative server >> that client has not found. >> > ok. > Cool. Looking forward to the update. >> 12 - >> >> IANA is requested to implement the following registries in JSON >> format conformant to the syntax defined in Section 10. >> >> That's incorrect, and it seems it was an uncorrection from -06 to -07. IANA doesn't "implement" registries. The registry is created by IANA. Independently, we are asking IANA to provide a JSON representation of the registry to be retrieved. >> > ok. > >> Furthermore, nowhere in this section does it ever tell IANA that it is expected to populate these registries from its own data. > > yes. it is. In fact, we don't want, since the entries will be submitted by the "owners" of the data, which will submit it through the policy defined by IANA. The relevant text is: > " > It is envisioned that these new registries will have similar entries > than the corresponding IANA allocation registries, such as [ipv4reg], > [ipv6reg], [asreg], [domainreg], and possibly similar registration > policies. Given that the data required by RDAP clients is limited > compared to the content of the existing corresponding registries, and > given that this data has to be made available in a JSON format using > a specific key/value structure, this document is not defining an > extension of the existing IANA allocation registries. The > registration policies for the new registries of this document are > left to IANA. > " > Given what I suggest for the introduction, and stealing some of Murray's text, and moving the 12.5 info up to the beginning of section 12, here's what I suggest in order to make it clearer: OLD IANA is requested to implement the following registries in JSON format conformant to the syntax defined in Section 10. NEW IANA is requested to make the RDAP Bootstrap Services Registries described below available as JSON objects, the syntax of which are described by section 10. The process for adding or updating entries into these registries does not correspond to the registration policies described in [RFC5226]; as stated earlier, these registries are generated from the data, processes, and policies maintained by IANA in their allocation registries ([ipv4reg], [ipv6reg], [asreg], and [domainreg]). IANA is expected to generate the RDAP Bootstrap Services Registries data from these above mentioned registries, according to their own registration policies. This document does not extend or otherwise change those policies. Each of the RDAP Bootstrap Services Registries needs to be made available for general public on-demand download in the JSON format at a location determined by IANA. IANA is also advised that the download demand for the RDAP Bootstrap Services Registries may be unusually high compared to other registries that exist already. The technical infrastructure by which registries are published may need to be reviewed. END And then strike section 12.5. (Leave 12.1 through 12.4 as they are.) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Oct 12 21:08:39 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB621ABC74 for ; Sun, 12 Oct 2014 21:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbRY7s12OQpj for ; Sun, 12 Oct 2014 21:08:22 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5451A9127 for ; Sun, 12 Oct 2014 21:08:18 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so5818842lbd.34 for ; Sun, 12 Oct 2014 21:08:17 -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=sWRoPK1xRRo/6fbXe1iQDCKwEXOKabTc+gbj9cEakxM=; b=oU0s4Ozyzk8MYgiBC6jLAEs8RTxsEdx4Hy14Ms6MZ7YFmFBXMVScYywlDUGcnJc1Hb x4wudMG3kSywo5HKahomq3fg3BxE/0W4rQTLSf6tOvIJsBe75gnuL2lzUfQFRPYZ30ch so9yJ9l/Dduv96iRgP+y8VQCDtbPL1u2u4meF7vl0wCfp0xzgLTnHRbl8AVkiXnS0KiP 2oZqsqPLNPHYdR+CksXhP6ZNwkiNVjKDAKmSEaMpXp5UN5S+BbPkelhWBgEebpu/LWKO MrDkWeRXvMIPs3YnfXDLEIHugukI0wyZCe3YeQ8aS4ozPD9xkMX0hEHeFQULlGq009Rm FowA== MIME-Version: 1.0 X-Received: by 10.112.182.42 with SMTP id eb10mr21293363lbc.7.1413173297315; Sun, 12 Oct 2014 21:08:17 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Sun, 12 Oct 2014 21:08:17 -0700 (PDT) In-Reply-To: <543B4BAF.8060602@qti.qualcomm.com> References: <543373B9.30402@qti.qualcomm.com> <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> <543B4BAF.8060602@qti.qualcomm.com> Date: Sun, 12 Oct 2014 21:08:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c36e3264835c0505460ca7 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/KPp11UTzrmTiattTLwqv1Uu7yzo Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 04:08:35 -0000 --001a11c36e3264835c0505460ca7 Content-Type: text/plain; charset=UTF-8 All of this looks great. A nit: On Sun, Oct 12, 2014 at 8:49 PM, Pete Resnick wrote: > NEW > The RDAP Bootstrap Service Registries will be made available as JSON > [RFC7159] objects, to be retrieved via HTTP from a location as > specified by IANA in section 12. The JSON object for each registry > will start with a series of members that contain metadata about the > registry such as a version identifier, a timestamp of the publication > date of the registry and a description. Following that is a > "services" member which contains the registry items themselves, as an > array. Each item of the array contains a second-level array, with two > elements, each of them being a third-level array. > END > "as specified by IANA in section 12" doesn't read right to me; IANA isn't specifying their download location in Section 12. Replace the first sentence with: The RDAP Bootstrap Service Registries will be made available as JSON [RFC7159] objects, as described in Section 12, to be retrieved via HTTP from a location to be specified by IANA. I'm not worried about IANA. I'm sure between the text and what you've > explained, they can handle it. I'm shooting for making it clear to the IETF > folks who are reading it. With the above suggested, and what I've got down > for section 12 below, I think it will be much clearer for them. > Right, or anyone from IANA or ICANN that might read this, now or later, having not been a party to our private discussions with IANA. The rest of Pete's suggestions look good to me. -MSK --001a11c36e3264835c0505460ca7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All of this looks great.=C2=A0 A nit:

On Sun, Oct 12, 2014 at 8:4= 9 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote= :
NEW
=C2=A0 =C2=A0The RDAP Bootstrap Service Registries will be made available a= s JSON
=C2=A0 =C2=A0[RFC7159] objects, to be retrieved via HTTP from a location as=
=C2=A0 =C2=A0specified by IANA in section 12.=C2=A0 The JSON object for eac= h registry
=C2=A0 =C2=A0will start with a series of members that contain metadata abou= t the
=C2=A0 =C2=A0registry such as a version identifier, a timestamp of the publ= ication
 =C2=A0 =C2=A0date of the registry and a description. Following that is a
=C2=A0 =C2=A0"services" member which contains the registry items = themselves, as an
=C2=A0 =C2=A0array. Each item of the array contains a second-level array, w= ith two
=C2=A0 =C2=A0elements, each of them being a third-level array.
END

"as sp= ecified by IANA in section 12" doesn't read right to me; IANA isn&= #39;t specifying their download location in Section 12.

R= eplace the first sentence with:

The RDAP Bootstrap Servic= e Registries will be made available as JSON [RFC7159] objects, as described= in Section 12, to be retrieved via HTTP from a location to be specified by= IANA.

I'm not worried about IANA. I'm sure between the text and what you&= #39;ve explained, they can handle it. I'm shooting for making it clear = to the IETF folks who are reading it. With the above suggested, and what I&= #39;ve got down for section 12 below, I think it will be much clearer for t= hem.

Right, or = anyone from IANA or ICANN that might read this, now or later, having not be= en a party to our private discussions with IANA.

The rest= of Pete's suggestions look good to me.

-MSK
--001a11c36e3264835c0505460ca7-- From nobody Mon Oct 13 07:32:45 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36721A0081 for ; Mon, 13 Oct 2014 07:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSNulCoN_9la for ; Mon, 13 Oct 2014 07:32:32 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id A2F451A00F1 for ; Mon, 13 Oct 2014 07:30:49 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 58450165187; Mon, 13 Oct 2014 10:30:49 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 7901A165110; Mon, 13 Oct 2014 10:30:48 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 13 Oct 2014 10:32:38 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Mon, 13 Oct 2014 10:30:47 -0400 From: Andy Newton To: "Murray S. Kucherawy" Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 Thread-Index: AQHP4evQt9B8e+TxVUafxU5Yqf2oW5wkw9+AgAjsmYCAAAVggIAAresA Date: Mon, 13 Oct 2014 14:30:46 +0000 Message-ID: References: <543373B9.30402@qti.qualcomm.com> <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> <543B4BAF.8060602@qti.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: multipart/alternative; boundary="_000_C37587AB32E64266906A39248FAD3037arinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/IGjDLNAm3kpbKQYHV-t_me3JyPY Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:32:39 -0000 --_000_C37587AB32E64266906A39248FAD3037arinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All looks good to me as well, fwiw. -andy On Oct 13, 2014, at 12:08 AM, Murray S. Kucherawy > wrote: All of this looks great. A nit: On Sun, Oct 12, 2014 at 8:49 PM, Pete Resnick > wrote: NEW The RDAP Bootstrap Service Registries will be made available as JSON [RFC7159] objects, to be retrieved via HTTP from a location as specified by IANA in section 12. The JSON object for each registry will start with a series of members that contain metadata about the registry such as a version identifier, a timestamp of the publication date of the registry and a description. Following that is a "services" member which contains the registry items themselves, as an array. Each item of the array contains a second-level array, with two elements, each of them being a third-level array. END "as specified by IANA in section 12" doesn't read right to me; IANA isn't s= pecifying their download location in Section 12. Replace the first sentence with: The RDAP Bootstrap Service Registries will be made available as JSON [RFC71= 59] objects, as described in Section 12, to be retrieved via HTTP from a lo= cation to be specified by IANA. I'm not worried about IANA. I'm sure between the text and what you've expla= ined, they can handle it. I'm shooting for making it clear to the IETF folk= s who are reading it. With the above suggested, and what I've got down for = section 12 below, I think it will be much clearer for them. Right, or anyone from IANA or ICANN that might read this, now or later, hav= ing not been a party to our private discussions with IANA. The rest of Pete's suggestions look good to me. -MSK _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds --_000_C37587AB32E64266906A39248FAD3037arinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
All looks good to me as well, fwiw.

-andy

On Oct 13, 2014, at 12:08 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

All of this looks great.  A nit:

On Sun, Oct 12, 2014 at 8:49 PM, Pete Resnick <presnick= @qti.qualcomm.com> wrote:
NEW
   The RDAP Bootstrap Service Registries will be made available a= s JSON
   [RFC7159] objects, to be retrieved via HTTP from a location as=
   specified by IANA in section 12.  The JSON object for eac= h registry
   will start with a series of members that contain metadata abou= t the
   registry such as a version identifier, a timestamp of the publ= ication
   date of the registry and a description. Following that = is a
   "services" member which contains the registry items = themselves, as an
   array. Each item of the array contains a second-level a= rray, with two
   elements, each of them being a third-level array.
END

"as specified by IANA in section 12" doesn't read right to m= e; IANA isn't specifying their download location in Section 12.

Replace the first sentence with:

The RDAP Bootstrap Service Registries will be made available as JSON [= RFC7159] objects, as described in Section 12, to be retrieved via HTTP from= a location to be specified by IANA.

I'm not worried about IANA. I'm sure between the te= xt and what you've explained, they can handle it. I'm shooting for making i= t clear to the IETF folks who are reading it. With the above suggested, and= what I've got down for section 12 below, I think it will be much clearer for them.

Right, or anyone from IANA or ICANN that might read this, now or later= , having not been a party to our private discussions with IANA.

The rest of Pete's suggestions look good to me.

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

--_000_C37587AB32E64266906A39248FAD3037arinnet_-- From nobody Mon Oct 13 07:41:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FE11A016D for ; Mon, 13 Oct 2014 07:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.786 X-Spam-Level: X-Spam-Status: No, score=-7.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trrUFrNUFqND for ; Mon, 13 Oct 2014 07:41:05 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41EE1A0162 for ; Mon, 13 Oct 2014 07:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413211265; x=1444747265; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=2KHHOT9WjK28DKykClZh86iHA4nnAwq74cI4K/DB3wU=; b=oAsBtfA76znWK5HYF2ag4j/5kloAIoOewbxJA8ei2PZL4L5k7R0whNaK sP+UliN51gwKBK1y3J8z7u8PXfjmgg+zVnN4uRdGtetyi8ly8i/Z+vqIh UokoHwt5SYmV34cc5g3/+uQm0H/FZNipQyFlgf6p/MHbYay54z1NjXQRo k=; X-IronPort-AV: E=McAfee;i="5600,1067,7589"; a="75973917" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 13 Oct 2014 07:41:05 -0700 X-IronPort-AV: E=Sophos; i="5.04,711,1406617200"; d="scan'208,217"; a="31511972" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Oct 2014 07:41:05 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc15.na.qualcomm.com (129.46.52.215) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 13 Oct 2014 07:41:04 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 13 Oct 2014 07:41:03 -0700 Message-ID: <543BE47E.3040107@qti.qualcomm.com> Date: Mon, 13 Oct 2014 09:41:02 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <543373B9.30402@qti.qualcomm.com> <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> <543B4BAF.8060602@qti.qualcomm.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070100060008060706080806" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/8EUHurWLWXNt-lyH5398V_HeLls Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:41:07 -0000 --------------070100060008060706080806 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 10/12/14 11:08 PM, Murray S. Kucherawy wrote: > All of this looks great. A nit: > > On Sun, Oct 12, 2014 at 8:49 PM, Pete Resnick > > wrote: > > NEW > The RDAP Bootstrap Service Registries will be made available as > JSON > [RFC7159] objects, to be retrieved via HTTP from a location as > specified by IANA in section 12. The JSON object for each registry > will start with a series of members that contain metadata about the > registry such as a version identifier, a timestamp of the > publication > date of the registry and a description. Following that is a > "services" member which contains the registry items themselves, > as an > array. Each item of the array contains a second-level array, > with two > elements, each of them being a third-level array. > END > > > "as specified by IANA in section 12" doesn't read right to me; IANA > isn't specifying their download location in Section 12. Oh? Where is it going to be specified? I thought that when IANA updates all of the "requested to do X" to "has done X", they'd add in the locations. But if not: > Replace the first sentence with: > > The RDAP Bootstrap Service Registries will be made available as JSON > [RFC7159] objects, as described in Section 12, to be retrieved via > HTTP from a location to be specified by IANA. Not quite right, since the JSON stuff is not really specified in Section 12. How about: The RDAP Bootstrap Service Registries, as specified in Section 12, will be made available as JSON [RFC7159] objects, to be retrieved via HTTP from a location as specified by IANA. > I'm not worried about IANA. I'm sure between the text and what > you've explained, they can handle it. I'm shooting for making it > clear to the IETF folks who are reading it. With the above > suggested, and what I've got down for section 12 below, I think it > will be much clearer for them. > > > Right, or anyone from IANA or ICANN that might read this, now or > later, having not been a party to our private discussions with IANA. > > The rest of Pete's suggestions look good to me. Thanks, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------070100060008060706080806 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 10/12/14 11:08 PM, Murray S. Kucherawy wrote:
All of this looks great.  A nit:

On Sun, Oct 12, 2014 at 8:49 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
NEW
   The RDAP Bootstrap Service Registries will be made available as JSON
   [RFC7159] objects, to be retrieved via HTTP from a location as
   specified by IANA in section 12.  The JSON object for each registry
   will start with a series of members that contain metadata about the
   registry such as a version identifier, a timestamp of the publication
   date of the registry and a description. Following that is a
   "services" member which contains the registry items themselves, as an
   array. Each item of the array contains a second-level array, with two
   elements, each of them being a third-level array.
END

"as specified by IANA in section 12" doesn't read right to me; IANA isn't specifying their download location in Section 12.

Oh? Where is it going to be specified?

I thought that when IANA updates all of the "requested to do X" to "has done X", they'd add in the locations.

But if not:

Replace the first sentence with:

The RDAP Bootstrap Service Registries will be made available as JSON [RFC7159] objects, as described in Section 12, to be retrieved via HTTP from a location to be specified by IANA.

Not quite right, since the JSON stuff is not really specified in Section 12. How about:

The RDAP Bootstrap Service Registries, as specified in Section 12, will be made available as JSON [RFC7159] objects, to be retrieved via HTTP from a location as specified by IANA.

I'm not worried about IANA. I'm sure between the text and what you've explained, they can handle it. I'm shooting for making it clear to the IETF folks who are reading it. With the above suggested, and what I've got down for section 12 below, I think it will be much clearer for them.

Right, or anyone from IANA or ICANN that might read this, now or later, having not been a party to our private discussions with IANA.

The rest of Pete's suggestions look good to me.

Thanks,

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------070100060008060706080806-- From nobody Mon Oct 13 11:11:11 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5B31A1B6F for ; Mon, 13 Oct 2014 11:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aaw_TMGYHvd for ; Mon, 13 Oct 2014 11:11:02 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570921A1AE6 for ; Mon, 13 Oct 2014 11:11:02 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so6960170lbd.34 for ; Mon, 13 Oct 2014 11:10:59 -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=GVNe1ul5suPQq/RIz0TGpcRW2DEkAb9VVLBphknKYiU=; b=DLr1yeySrTq2chA71EC9aKCBc/aYkdyBTaTsSzvdrfbebzwE2MwcAPQnWoVG86CC9T +Dtr9OnhMURHIirXqIwYZaRIGqxRB/CUAF9Qun0usf8e/qMqA76NKiAC4pJzXFK3kNRw 0n4HQwirtrOREQx2xJA6P/0DbX9IkI4oxLDy0PsaNhVR8AWYqM8XjBnDYJ+auCQxAhb/ hernbauZSJ5IlimX0K7Ub+1UDXJAXyKPtIGBtbpsYJWGFuWACRdcsRRVDU5H+KHWozem NjqvDeS5z5H3o85TkheJD6r0acxqa1vlszxhIquxlIeuyErW51Ov80GONk6LcFuTd0Ro Hk0Q== MIME-Version: 1.0 X-Received: by 10.152.36.230 with SMTP id t6mr199889laj.88.1413223859480; Mon, 13 Oct 2014 11:10:59 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Mon, 13 Oct 2014 11:10:59 -0700 (PDT) In-Reply-To: <543BE47E.3040107@qti.qualcomm.com> References: <543373B9.30402@qti.qualcomm.com> <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> <543B4BAF.8060602@qti.qualcomm.com> <543BE47E.3040107@qti.qualcomm.com> Date: Mon, 13 Oct 2014 11:10:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=089e0160c0dc21ef9b050551d267 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/rQQPNn7CU6CV4H6Yid5QZYlguaY Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:11:09 -0000 --089e0160c0dc21ef9b050551d267 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 13, 2014 at 7:41 AM, Pete Resnick wrote: > "as specified by IANA in section 12" doesn't read right to me; IANA > isn't specifying their download location in Section 12. > > > Oh? Where is it going to be specified? > > I thought that when IANA updates all of the "requested to do X" to "has > done X", they'd add in the locations. > > But if not: > Oh, I hadn't thought that they might make such a permanent commitment inside the RFC itself. If they do, then groovy; should we add a placeholder in our version of the draft for it? > > The RDAP Bootstrap Service Registries, as specified in Section 12, will be > made available as JSON [RFC7159] objects, to be retrieved via HTTP from a > location as specified by IANA. > Also groovy. -MSK --089e0160c0dc21ef9b050551d267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 13, 2014 at 7:41 AM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
=20
"as specified by IANA in section 12" doesn't = read right to me; IANA isn't specifying their download location in Section 12.

 Oh? Where is it going to be specified?

I thought that when IANA updates all of the "requested to do X" t= o "has done X", they'd add in the locations.

But if not:

Oh, I hadn't thought that they might make such a permanent commitmen= t inside the RFC itself.=C2=A0 If they do, then groovy; should we add a pla= ceholder in our version of the draft for it?
=C2=A0

The RDAP Bootstrap Service Registries, as specified in Section 12, will be made available as JSON [RFC7159] objects, to be retrieved via HTTP from a location as specified by IANA.

Also groovy.
=C2=A0
-MSK
=
--089e0160c0dc21ef9b050551d267-- From nobody Mon Oct 13 12:22:45 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1115C1A8AD0 for ; Mon, 13 Oct 2014 12:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqYPQVNSWYxF for ; Mon, 13 Oct 2014 12:22:35 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 572A01A8AF5 for ; Mon, 13 Oct 2014 12:22:35 -0700 (PDT) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8D00B4034D; Mon, 13 Oct 2014 15:22:33 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_71B2D3F2-96AB-46AB-90B6-6E283DBA4833" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: Date: Mon, 13 Oct 2014 12:22:31 -0700 Message-Id: <61AD5977-0A32-4CC0-96D3-C3AEEE5564C1@viagenie.ca> References: <543373B9.30402@qti.qualcomm.com> <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> <543B4BAF.8060602@qti.qualcomm.com> <543BE47E.3040107@qti.qualcomm.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ClTSbNmJ8z_9VkjVp7TCfO-9igc Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 19:22:41 -0000 --Apple-Mail=_71B2D3F2-96AB-46AB-90B6-6E283DBA4833 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2014-10-13 =E0 11:10, Murray S. Kucherawy a = =E9crit : > On Mon, Oct 13, 2014 at 7:41 AM, Pete Resnick = wrote: >> "as specified by IANA in section 12" doesn't read right to me; IANA = isn't specifying their download location in Section 12. >=20 > Oh? Where is it going to be specified? >=20 > I thought that when IANA updates all of the "requested to do X" to = "has done X", they'd add in the locations. >=20 > But if not: >=20 > Oh, I hadn't thought that they might make such a permanent commitment = inside the RFC itself. If they do, then groovy; should we add a = placeholder in our version of the draft for it? IANA normally does not. Moreover, there was a request from IANA people = to make sure we are _not_ imposing location, since they will have to be = hosted on their caching infrastructure which might have an influence on = the location. So unless I'm hearing big voices, I'm not going to change = the draft to put a placeholder for the location. Marc. > =20 >=20 > The RDAP Bootstrap Service Registries, as specified in Section 12, = will be made available as JSON [RFC7159] objects, to be retrieved via = HTTP from a location as specified by IANA. >=20 > Also groovy. > =20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_71B2D3F2-96AB-46AB-90B6-6E283DBA4833 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Le 2014-10-13 =E0 11:10, Murray S. = Kucherawy <superuser@gmail.com> a =E9crit = :

On Mon, Oct 13, 2014 at 7:41 AM, Pete = Resnick <presnick@qti.qualcomm.com> = wrote:
=20
"as specified by IANA in section 12" doesn't = read right to me; IANA isn't specifying their download location in Section 12.

 Oh? Where is it going to be specified?

I thought that when IANA updates all of the "requested to do X" to "has done X", they'd add in the locations.

But if not:

Oh, I = hadn't thought that they might make such a permanent commitment inside = the RFC itself.  If they do, then groovy; should we add a = placeholder in our version of the draft for = it?

IANA = normally does not.  Moreover, there was a request from IANA people = to make sure we are _not_ imposing location, since they will have to be = hosted on their caching infrastructure which might have an influence on = the location.  So unless I'm hearing big voices, I'm not going to = change the draft to put a placeholder for the = location.

Marc.


 

The RDAP Bootstrap Service Registries, as specified in Section 12, will be made available as JSON [RFC7159] objects, to be retrieved via HTTP from a location as specified by IANA.

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

= --Apple-Mail=_71B2D3F2-96AB-46AB-90B6-6E283DBA4833-- From nobody Mon Oct 13 13:06:23 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B763A1A0022; Mon, 13 Oct 2014 13:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7rPJkvU-_tq; Mon, 13 Oct 2014 13:06:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6191A000F; Mon, 13 Oct 2014 13:06:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013200620.22168.44377.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 13:06:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/HUPpCesK30Dr95cJ4fc0M8K21-0 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-bootstrap-08.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:06:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Finding the Authoritative Registration Data (RDAP) Service Author : Marc Blanchet Filename : draft-ietf-weirds-bootstrap-08.txt Pages : 16 Date : 2014-10-13 Abstract: This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-bootstrap-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 13 13:11:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796201A0029 for ; Mon, 13 Oct 2014 13:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH4Z959rEUFz for ; Mon, 13 Oct 2014 13:10:55 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0381A0022 for ; Mon, 13 Oct 2014 13:10:55 -0700 (PDT) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C4D184034D for ; Mon, 13 Oct 2014 16:10:53 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: <20141013200620.22168.44377.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 13:10:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <294F639A-81A7-4F70-88E9-6860221331CB@viagenie.ca> References: <20141013200620.22168.44377.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/mno_Oabo3lFa_iSrbKvmPfRDdW4 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-bootstrap-08.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:10:57 -0000 Hello, this new version (shall) incorporates all AD review comments, based on = latest email threads of Pete and Murray and others who responded to = various issues. IMHO, ready for next step. Marc. Le 2014-10-13 =E0 13:06, internet-drafts@ietf.org a =E9crit : >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Extensible Internet Registration = Data Service Working Group of the IETF. >=20 > Title : Finding the Authoritative Registration Data = (RDAP) Service > Author : Marc Blanchet > Filename : draft-ietf-weirds-bootstrap-08.txt > Pages : 16 > Date : 2014-10-13 >=20 > Abstract: > This document specifies a method to find which Registration Data > Access Protocol (RDAP) server is authoritative to answer queries for > a requested scope, such as domain names, IP addresses or Autonomous > System numbers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-bootstrap-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Mon Oct 13 13:20:58 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5F41A003B for ; Mon, 13 Oct 2014 13:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOAY53m6x2TH for ; Mon, 13 Oct 2014 13:20:54 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9977A1A0033 for ; Mon, 13 Oct 2014 13:20:53 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id hz20so7180889lab.25 for ; Mon, 13 Oct 2014 13:20:52 -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=WcLA2fS8C4oIw1G+v4fHVOflGalgnOC5zvinIYTjtsk=; b=L0oYdc38Ec+ivcGVds15sf4lJXLCqeLvVynW06VPXq48PWKZ6kyS/sT/yD2pyedgEN hLaQZ6X6X/FSl/BmzXLEgRXGcNnBRJ+wOYWu/KT1HNQApCd4VLQ9w6sm2efzOabeL8pa fXfeUxZw4K9qVKmrLmyP5bcCZcQfIztEMTnHfc5FMnNp5a3+3lgBvAeObWCVNr6tmBmH bsM4ZY847K8FhQE7WlVujCBNCbDZEcxWjSmR8cB30Qs8ClgU/WSsBc0/baaH4D9HQCPF N6MW4JMm+410FEAoFHQQjlHFZ9+iXRiMPOQzSHx/ramdEBJmjiQ0FTw8zAC1Xeb6XdKx GXWg== MIME-Version: 1.0 X-Received: by 10.152.234.36 with SMTP id ub4mr794140lac.25.1413231651888; Mon, 13 Oct 2014 13:20:51 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Mon, 13 Oct 2014 13:20:51 -0700 (PDT) In-Reply-To: <61AD5977-0A32-4CC0-96D3-C3AEEE5564C1@viagenie.ca> References: <543373B9.30402@qti.qualcomm.com> <444EDD61-7BAE-4999-9C19-FB09FF081066@viagenie.ca> <543B4BAF.8060602@qti.qualcomm.com> <543BE47E.3040107@qti.qualcomm.com> <61AD5977-0A32-4CC0-96D3-C3AEEE5564C1@viagenie.ca> Date: Mon, 13 Oct 2014 13:20:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: Marc Blanchet Content-Type: multipart/alternative; boundary=001a11344e5a98a4ca050553a21a Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/O5SyUQnbiP6S0ATLjIpQcDqVPkE Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:20:55 -0000 --001a11344e5a98a4ca050553a21a Content-Type: text/plain; charset=UTF-8 On Mon, Oct 13, 2014 at 12:22 PM, Marc Blanchet wrote: > IANA normally does not. Moreover, there was a request from IANA people to > make sure we are _not_ imposing location, since they will have to be hosted > on their caching infrastructure which might have an influence on the > location. So unless I'm hearing big voices, I'm not going to change the > draft to put a placeholder for the location. > > Works for me. Worst case, we deal with it during IESG Evaluation when IANA chimes in with their formal review comments. -MSK --001a11344e5a98a4ca050553a21a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 13, 2014 at 12:22 PM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
IANA normally does not.= =C2=A0 Moreover, there was a request from IANA people to make sure we are _= not_ imposing location, since they will have to be hosted on their caching = infrastructure which might have an influence on the location.=C2=A0 So unle= ss I'm hearing big voices, I'm not going to change the draft to put= a placeholder for the location.


Works for me.=C2=A0 Worst case, we deal with it during IESG Evaluation w= hen IANA chimes in with their formal review comments.

-MSK
--001a11344e5a98a4ca050553a21a-- From nobody Mon Oct 13 14:42:53 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BD01A0169 for ; Mon, 13 Oct 2014 14:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.786 X-Spam-Level: X-Spam-Status: No, score=-7.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU_SW0gTVx0D for ; Mon, 13 Oct 2014 14:42:50 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32B31A0164 for ; Mon, 13 Oct 2014 14:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413236570; x=1444772570; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Nb63ncfqEUVKTIYxqObO+2dcIoSMnZN2PfQAbQ8MR44=; b=clvI8U9E/ph1gEup67qX4WmQnCjHP/2lsbIIizvHFVhilMLxj0ka3djq LkhJDDndG2tEe8EUcDxWUxaEtbhaZw7J8i9xLDKGJyESfl4RNDuTtQ6G9 6V8oux+nBAOk9azFtzJ5edCdbLYN8cQAaxtXNzUunRIQKHseW4tbU4/wG U=; X-IronPort-AV: E=McAfee;i="5600,1067,7590"; a="75996811" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Oct 2014 14:42:50 -0700 X-IronPort-AV: E=Sophos;i="5.04,713,1406617200"; d="scan'208,217";a="823697167" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Oct 2014 14:42:49 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 13 Oct 2014 14:42:49 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 13 Oct 2014 14:42:49 -0700 Message-ID: <543C4742.40804@qti.qualcomm.com> Date: Mon, 13 Oct 2014 16:42:26 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Marc Blanchet References: <20141013200620.22168.44377.idtracker@ietfa.amsl.com> <294F639A-81A7-4F70-88E9-6860221331CB@viagenie.ca> In-Reply-To: <294F639A-81A7-4F70-88E9-6860221331CB@viagenie.ca> Content-Type: multipart/alternative; boundary="------------040901040300040904090207" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.46.201.192) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/yydRC0vOIEFyNWCeIJsonC3LciI Cc: "" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-bootstrap-08.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:42:52 -0000 --------------040901040300040904090207 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 10/13/14 3:10 PM, Marc Blanchet wrote: > this new version (shall) incorporates all AD review comments, based on latest email threads of Pete and Murray and others who responded to various issues. IMHO, ready for next step. > As mentioned in IM, you accidentally dropped 2 sentences in section 3. And you will look to clear up the registries/registrars thing that I screwed up. As soon as I see -09, I'll Last Call it. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------040901040300040904090207 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 10/13/14 3:10 PM, Marc Blanchet wrote: 
this new version (shall) incorporates all AD review comments, based on latest email threads of Pete and Murray and others who responded to various issues. IMHO, ready for next step.

As mentioned in IM, you accidentally dropped 2 sentences in section 3. And you will look to clear up the registries/registrars thing that I screwed up. As soon as I see -09, I'll Last Call it.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------040901040300040904090207-- From nobody Mon Oct 13 14:46:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788F11A01D8; Mon, 13 Oct 2014 14:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r5FpxMRVN-A; Mon, 13 Oct 2014 14:46:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A951A0194; Mon, 13 Oct 2014 14:46:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013214628.29563.5403.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 14:46:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/TQYnVFhgKBDkgvS1KwMx3LdlTpY Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-bootstrap-09.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:46:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Finding the Authoritative Registration Data (RDAP) Service Author : Marc Blanchet Filename : draft-ietf-weirds-bootstrap-09.txt Pages : 16 Date : 2014-10-13 Abstract: This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-bootstrap-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 13 14:47:48 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD8D1A01F2 for ; Mon, 13 Oct 2014 14:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9YylCx_9XX7 for ; Mon, 13 Oct 2014 14:47:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEC51A0194 for ; Mon, 13 Oct 2014 14:47:44 -0700 (PDT) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EE4F441323; Mon, 13 Oct 2014 17:47:42 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9F2763CE-9F07-4173-8031-29EB6D24952A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: <543C4742.40804@qti.qualcomm.com> Date: Mon, 13 Oct 2014 14:47:41 -0700 Message-Id: <1DE8006C-7623-475B-BA76-EF084D17FAB4@viagenie.ca> References: <20141013200620.22168.44377.idtracker@ietfa.amsl.com> <294F639A-81A7-4F70-88E9-6860221331CB@viagenie.ca> <543C4742.40804@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NWqH80ybZICGilKOuNDFjgXvDKw Cc: "" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-bootstrap-08.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:47:46 -0000 --Apple-Mail=_9F2763CE-9F07-4173-8031-29EB6D24952A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2014-10-13 =E0 14:42, Pete Resnick a = =E9crit : > On 10/13/14 3:10 PM, Marc Blanchet wrote: >>=20 >> this new version (shall) incorporates all AD review comments, based = on latest email threads of Pete and Murray and others who responded to = various issues. IMHO, ready for next step. >> =20 >=20 > As mentioned in IM, you accidentally dropped 2 sentences in section 3. = And you will look to clear up the registries/registrars thing that I = screwed up. As soon as I see -09, I'll Last Call it. done. -09 posted.=20 Marc. >=20 > pr > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 --Apple-Mail=_9F2763CE-9F07-4173-8031-29EB6D24952A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Le 2014-10-13 =E0 14:42, Pete Resnick = <presnick@qti.qualcomm.com>= ; a =E9crit :

On 10/13/14 3:10 PM, Marc Blanchet wrote: 
this new version (shall) incorporates all AD review =
comments, based on latest email threads of Pete and Murray and others =
who responded to various issues. IMHO, ready for next step.

As mentioned in IM, you accidentally dropped 2 sentences in section 3. And you will look to clear up the registries/registrars thing that I screwed up. As soon as I see -09, I'll Last Call = it.

done. -09 = posted. 

Marc.



pr
--=20
Pete Resnick <http://www.qualcomm.com/~p=
resnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

= --Apple-Mail=_9F2763CE-9F07-4173-8031-29EB6D24952A-- From nobody Mon Oct 13 15:25:34 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A7D1A0439; Mon, 13 Oct 2014 15:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvGda-h2bjJi; Mon, 13 Oct 2014 15:25:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E29881A07BE; Mon, 13 Oct 2014 15:25:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141013222529.3885.55218.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 15:25:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/OFWZ-mpY-dNLD9H_BbgxRirKtmQ Cc: weirds@ietf.org Subject: [weirds] Last Call: (Finding the Authoritative Registration Data (RDAP) Service) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 13 Oct 2014 22:25:31 -0000 The IESG has received a request from the Web Extensible Internet Registration Data Service WG (weirds) to consider the following document: - 'Finding the Authoritative Registration Data (RDAP) Service' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Oct 13 15:25:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960CA1A1A0C for ; Mon, 13 Oct 2014 15:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRYXWD7-dwax; Mon, 13 Oct 2014 15:25:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB4F1A19F1; Mon, 13 Oct 2014 15:25:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, mszucs@afilias.info, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013222531.3885.90467.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 15:25:31 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/bK8U36rHpSK2wZok_ps_bnkU1TQ Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 22:25:35 -0000 Last call has been made for draft-ietf-weirds-bootstrap and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ From nobody Fri Oct 17 07:16:07 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AD51A1A80; Fri, 17 Oct 2014 07:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZUOh9sc2Ui7; Fri, 17 Oct 2014 07:15:58 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83CA1A1A1D; Fri, 17 Oct 2014 07:15:58 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 17 Oct 2014 07:15:56 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Fri, 17 Oct 2014 07:15:56 -0700 From: Edward Lewis To: "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard Thread-Index: AQHP5Ni/5FUUmZIO10SIXwNWQzinhpw0klIA Date: Fri, 17 Oct 2014 14:15:56 +0000 Message-ID: References: <20141010222207.8413.95671.idtracker@ietfa.amsl.com> In-Reply-To: <20141010222207.8413.95671.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3496385754_8995116" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/PDSH73bE3axbieLGJMe_U-J_WiA Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:16:00 -0000 --B_3496385754_8995116 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable A few comments, mostly nits: Comment 1 --------- Section 1. ## The registration data expected to be presented by this service is ## Internet resource registration data - registration of domain names ## and Internet number resources. These data is typically provided by Nit: ''These data is'': Perhaps - remove the =E2=80=98=E2=80=99The'' to start the paragraph and then ''Such dat= a are'' for the Nit. (Treat =E2=80=98=E2=80=99data'' consistently as singular or plural.) Comment 2 --------- Section 3. Nit: ''meant to return only one path of execution'' - perhaps ''follow one path''? Comment 3 --------- Section 5.6. Nit: ''As the use of RDAP is for public resources'' is a judgement call. Suggest rewording as ''When RDAP is for public resources, a value of =E2=80=98*=E2=80=99. . .'' Comment 4 --------- Section 6. Slight discomfort: I suppose this is not internationalizable given the nature of the programming tools being ASCII-based. So no formal objection, but a desire to allow identifiers to be able to break out of a ASCII-only set ''is a pony I'd like to have.'' No suggested change, but curious ... if ... Comment 5 --------- Section 7. Nit: ''It does require the RDAP clients MUST support HTTPS.'' Nit: ''This document made'' should be ''This document makes'' Comment 6 --------- Section 8.1 Addition to third paragraph: Suggestion: ''For documentation in other than the RFC series, IANA is requested to hold in escrow copies of the documentation.'' (This was needed for a DNS RR type defined in an ATM Forum document.) Comment 7 --------- Appendix B Nit: ''this is unlikely to have any known side effects'' - suggest ''this will be[/ought to be] compatible with the RDAP definition.'' --B_3496385754_8995116 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTzt8yWoj34MK2c4pZo 6oZggKdIZDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MTcxNDE1NTRaMA0GCSqGSIb3DQEBAQUABIIBAI2A9aByHCmMdyr3pfETs8UYH1CCRxs5ALiv qcN8MeO/WyA4RTW4Tbco34hl49sZIWM7fnNjY0Ar/SildSLMI7jV9Er9OnigtJwVUzZmh6/f x7lYdqgV/BYUhhrrt8Idy2TKqBRcM3SnFvMwBtHWseryDl2IPmEEtP2f0CD7S0ZTQl3Aj5b9 oPOvmIgNEJt/JGHi4k1yeusy/o7ZsoTwGwfb9J/Bs7wDLy+/2Ckaq7OyIDJLP6AZBYwlfEOO hV1CVpQMOEHAXh6B6EVCdf3c52P/hmwBmE0SaQce8MZc27TFyGh79148YUTo515odHXbluVl N66vfWbqwQV7DW4qwqo= --B_3496385754_8995116-- From nobody Fri Oct 17 07:48:58 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A2C1A0058; Fri, 17 Oct 2014 07:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKXZH9RGSQIA; Fri, 17 Oct 2014 07:48:51 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B0E1A0047; Fri, 17 Oct 2014 07:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413557331; x=1445093331; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SZvJ6j52QmJOUjn8JE53Z+9MQ3oQkSlNIGm/3A16u/s=; b=wAdd0fKdiPgltL/HzaPz+OfGDYqOTYNwjooYMGFjfQwYFCnk1Zv0H6Qm arEBrX9magj65ChKPLyoP3fpCH88FZRg3o0V1+9HM5WSr0VXpHI2Jml70 +VEJ9TpIoO+EG9m2Hyay04PB+sewYLJpbaE0wiz05oAxrO+9uvvLf1V30 U=; X-IronPort-AV: E=McAfee;i="5600,1067,7593"; a="167424566" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Oct 2014 07:48:49 -0700 X-IronPort-AV: E=Sophos;i="5.04,739,1406617200"; d="scan'208";a="826424572" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Oct 2014 07:48:49 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 17 Oct 2014 07:48:48 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 17 Oct 2014 07:48:48 -0700 Message-ID: <54412C4D.4000604@qti.qualcomm.com> Date: Fri, 17 Oct 2014 09:48:45 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Edward Lewis References: <20141010222207.8413.95671.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/SmKWjZjlu_e1Bn5znWx8ZXJDmcc Cc: "ietf@ietf.org" , "weirds@ietf.org" , "iesg@ietf.org" Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:48:53 -0000 I'll leave the authors to respond on the nits; at first glance they all seem reasonable to address. On the two more substantive items: On 10/17/14 9:15 AM, Edward Lewis wrote: > Comment 4 > --------- > > Section 6. > > > Slight discomfort: I suppose this is not internationalizable given the > nature > of the programming tools being ASCII-based. So no formal objection, but a > desire to allow identifiers to be able to break out of a ASCII-only set > ''is > a pony I'd like to have.'' > > No suggested change, but curious ... if ... > Do note that the restriction described says SHOULD. To quote 2119, "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." You *could* go look at http://www.unicode.org/reports/tr31/ about using Unicode in identifiers, or you could go look at the Identifier Class in the soon-to-be-released https://datatracker.ietf.org/doc/draft-ietf-precis-framework/, and then try to use one of these for your prefixes, but you had better fully understand what you are embarking on. :-) > Comment 6 > --------- > > Section 8.1 > > Addition to third paragraph: > > Suggestion: ''For documentation in other than the RFC series, IANA is > requested > to hold in escrow copies of the documentation.'' (This was needed for a DNS > RR type defined in an ATM Forum document.) > This sounds like something that is not unique to this particular document (that is, any registry that uses "Specification Required" would have this issue), and might have weird copyright issues. I'm inclined *not* to put this in the IANA Considerations of this document, but rather mention this issue to IANA and/or IAB folks and let them work out a policy to deal with this on all registries that use "Specification Required", if that is needed. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Oct 17 09:01:45 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D721A1B5F; Fri, 17 Oct 2014 09:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuWOfrGEruSA; Fri, 17 Oct 2014 09:01:39 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DCF1A0047; Fri, 17 Oct 2014 09:01:39 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 17 Oct 2014 09:01:36 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Fri, 17 Oct 2014 09:01:37 -0700 From: Edward Lewis To: "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlitw== Date: Fri, 17 Oct 2014 16:01:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3496392094_9367160" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2IoEVbqSl-LDvtHLz4BkRmwotHs Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:01:43 -0000 --B_3496392094_9367160 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable A couple of comments Comment 1 Section 1.1 Nit: the detail on REST and RESTful seems out of place in a list of acronyms and abbreviations. Comment 2 Section 2 ## 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. Nit: should be "it is unlikely that a uniform approach ... is needed for interoperability." Comment 3 Section 3.2 Confusion: domain/domains and entity/entities plural forms are defined externally to the list, but nameserver/nameservers plural form is not. I think that is just an inconstency. The word ''match'' is used referring to a FQDN. Does this mean to imply ''match'' as defined in RFC 1034 (where '*' matches anything)? And what is throwing me is that this begins talking about testing to see if something exists and then seems to start talking about finding inexact matches (the plurals). It reads as if the first paragraph doesn't relate to the rest of the section. Comment 4 Section 3.2.1 and 3.2.2 Confusion: Both 3.2.1 and 3.2.2 cover searching for name servers. Why are two approaches presented? http://example.com/rdap/nameservers?name=3Dns1.example*.com and http://example.com/rdap/domains?nsLdhName=3Dns1.example*.com I suppose this isn't a major issue, but seems awkward. Comment 5 Section 4.2 Needed work: What is a "name-record" ? I can imagine a few different meanings, which is the problem. Is this a "registration" , i.e., the mapping of the network object to an entity (set)? Are associated "name-records" like variants of IDNs? Are they related in a IP hierarchy, or somehow jointly registered objects? Comment 6 Section 4.2 - later on Confusion: It sounds here that a client cannot set up an expectation that it's query will return something specific or return a list, which is bad (meaning the client can=E2=80=99t set expectation). A client ought to be able to know what it will get back, even if it is an error. What I mean is 'returning information that was not explicitly selected by an exact-match lookup' is ... is bothering me. Maybe these terms need to be ironed out better: search vs. lookup and what does match mean. I do see match defined - after it is used a few times. And in section 3.2, I first ran into the confusion of search v. lookup. (In the DNS world, we distunguish this by saying DNS does not search, it does a lookup.) Comment 7 Section 5 Suggestion: this seems to be begging for a "standard" definition of an non-standard extension prefix - or everyone will use "custom_" because that is the example here. (Name collisions.) And if a custom one becomes a standard, can the transition be eased? (TXT to SPF issue.) And how do we encourage more standard and fewer uniques (the EPP[EXT] issue)? Comment 8 Section 6 Suggestion: Shouldn't RDAP applications be considered to be IDNA2008 aware? The argument for this is in RFC 6912. Or is that pressing a policy into the protocol needlessly? Comment 9 Section 8 ## Search functionality also increases the privacy risk of disclosing ## object relationships that might not otherwise be obvious. For ## example, a search that returns IDN variants [RFC6927] that do not ## explicitly match a client-provided search pattern can disclose ## information about registered domain names that might not be otherwise ## available. Implementers need to consider the policy and privacy ## implications of returning information that was not explicitly ## requested. I think this can improved by mentioning that implementers need to =E2=80=9Cconsider policy and privacy implications, e.g., by checking for authorization to release information to the requestor, in all cases and especially here, when returning information that was not explicitly requested.=E2=80=9D In general, I=E2=80=99ve always been a little suspect on RDAP=E2=80=99s search ability = and now carefully reading the last call documents am still a little shaky on it. Perhaps the word =E2=80=9Csearch=E2=80=9D to me has a wider definition than is bei= ng applied here, where RDAP just looks for a common pre-amble (prefix, starting string, whatever you want to call it). I am aware of the perils of unicode, sigh, but I wish there was a chance to have a search definition that was free of ASCII assumptions and was always mindful of the authorization to =E2=80=9Crelease=E2=80=9D information. I am aware I=E2=80=99m saying this very late in the game. I=E2=80=99m willing to accep= t the definition going forward as is. But I wanted to drop the comment somewhere. But please add in, where implementers =E2=80=9Cconsider=E2=80=9D, mention o= f the authorization model. This is because I can see operators pulling open source tools for this from the shelf, they won=E2=80=99t be handcrafting the code= , and need some place to =E2=80=9Cconfigure this=E2=80=9D. --B_3496392094_9367160 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQP62SGme1LVJjHwtrk wRk/BEfRfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MTcxNjAxMzRaMA0GCSqGSIb3DQEBAQUABIIBABv6Ag83HZ+RVcwrhKUKX4tJMY8Y0pOTmA7A jk5PcXPhpAy6I6P0QmFpNE5AOUCxgVsxay0X8YMOu9vHWkADM6I1Kcf/JdsRx0K81XpoL6FT SE37mMpY8s6mEHOeeHfojlyhG6gTx8vO1oBp7hP+FXBHJhpGdrmLf74IISzuRHYXh16ohrVz FQs6zq+UkgLx1zAmtXRWKbMH11c5qJ3Wv4IoU0xpIMUjKAyD4RbeKN9JG5ph0Bx88AL0VNcZ lBlixVxXKgpPQgx+rU6B7uqfZqKI7ZUo7yVM6dUMHX9ueT23bKuaeUrw/kPzu7TdmdzlACuA vn9PU/g7puYh1xSDxNw= --B_3496392094_9367160-- From nobody Fri Oct 17 10:41:41 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7141A00CA; Fri, 17 Oct 2014 10:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJMaNAMxgh5Q; Fri, 17 Oct 2014 10:41:36 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6D41A00BE; Fri, 17 Oct 2014 10:41:36 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 17 Oct 2014 10:41:34 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Fri, 17 Oct 2014 10:41:35 -0700 From: Edward Lewis To: "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: [weirds] Last Call: (JSON Responses for the Registration Data Access Protocol (RDAP)) to Proposed Standard Thread-Index: AQHP5NnL18pLdtHOa0+nueL24+s+6Zw0y8QA Date: Fri, 17 Oct 2014 17:41:34 +0000 Message-ID: References: <20141010222952.18899.38570.idtracker@ietfa.amsl.com> In-Reply-To: <20141010222952.18899.38570.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3496398092_9641501" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/gQqRvXDAdvIThookaHaHI4dPd3Q Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (JSON Responses for the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:41:39 -0000 --B_3496398092_9641501 Content-type: multipart/alternative; boundary="B_3496398092_9658793" --B_3496398092_9658793 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Just two nits: Comment 1 In section 5.2 the term/phrase =E2=80=9Cfirst-class=E2=80=9D as in "name server model=E2=80= =9D is used twice but never defined. I don=E2=80=99t have a suggested fix. Comment 2 While looking for something else, I noted one use of =E2=80=9Csecure DNSSEC=E2=80=9D in section 14, probably meant =E2=80=9Csecure DNS=E2=80=9D there. --B_3496398092_9658793 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Just two nits:

=
Comment 1

In section 5.2 the term/phrase= “first-class” as in "name server model” is used twice but= never defined.

I don’t have a suggested fix.=

Comment 2

While looking f= or something else, I noted one use of “secure DNSSEC” in section= 14, probably meant “secure DNS” there.
--B_3496398092_9658793-- --B_3496398092_9641501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQb9I5+L+HFVYN+Dnga Qid3tJtlOjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MTcxNzQxMzJaMA0GCSqGSIb3DQEBAQUABIIBADyYP2qpl+Ai0K3bOsETmmcNVO3QSTR2JgNP /0kyL3lIokxS8Ff0xV7pbH7JxvnxY0CJwrfQl9HZ8Wl3Ny6q6Bse7V18C5Deot/DyRZvJMjk jiZALjhFI1O/PAPeZVhh6VeDDoUkg9yT7r3WCprrc5CCBZOtmzDGIT1Czq1dC171BpRJzX9s FrAAHHLIltlhsqr40v8G/ZqIab1xtSSpxIXpx/hFeBX/fIfoAJBVWxK3Db0tCfF5dVaO6nKP XBlm+hKnM3LVtVlfy7xvO3M9L7Rt6dmGqd654Kr7kln5+wIRM5LysWnylV2TSXNpYjnHog1A 6r1X+tyOZ/Z+RNB5/0Y= --B_3496398092_9641501-- From nobody Tue Oct 21 03:50:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9E91A0469 for ; Tue, 21 Oct 2014 03:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKcwEXmksRP0 for ; Tue, 21 Oct 2014 03:50:06 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26D01A04BA for ; Tue, 21 Oct 2014 03:49:57 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKVEY6VSJDLSFcrYQrnUJKC8XTwByteStC@postini.com; Tue, 21 Oct 2014 03:49:57 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9LAnuSp004052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Oct 2014 06:49:56 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 06:49:56 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: Gen-ART Last Call review of draft-ietf-weirds-rdap-query-15 Thread-Index: AQHP6/pOs+r/8NJ5TUe2roa8ne51KZw450zwgAF6HFA= Date: Tue, 21 Oct 2014 10:49:55 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494EF902@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <544452CA.3060102@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2cTRDfuNjP6h-ZI6hlg-0pDzZ6o Subject: [weirds] FW: Gen-ART Last Call review of draft-ietf-weirds-rdap-query-15 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 10:50:08 -0000 RllJLCBmb2xrcy4NCg0KU2NvdHQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEhvbGxlbmJlY2ssIFNjb3R0IA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDIwLCAyMDE0IDg6MjAg QU0NClRvOiAnQnJpYW4gRSBDYXJwZW50ZXInOyBkcmFmdC1pZXRmLXdlaXJkcy1yZGFwLXF1ZXJ5 LmFsbEB0b29scy5pZXRmLm9yZzsgR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtDQpTdWJqZWN0OiBS RTogR2VuLUFSVCBMYXN0IENhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtd2VpcmRzLXJkYXAtcXVl cnktMTUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENh cnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogU3Vu ZGF5LCBPY3RvYmVyIDE5LCAyMDE0IDg6MTAgUE0NCj4gVG86IGRyYWZ0LWlldGYtd2VpcmRzLXJk YXAtcXVlcnkuYWxsQHRvb2xzLmlldGYub3JnOyBHZW5lcmFsIEFyZWENCj4gUmV2aWV3IFRlYW0N Cj4gU3ViamVjdDogR2VuLUFSVCBMYXN0IENhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtd2VpcmRz LXJkYXAtcXVlcnktMTUNCj4gDQo+IEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIg Zm9yIHRoaXMgZHJhZnQuIEZvciBiYWNrZ3JvdW5kIG9uDQo+IEdlbi1BUlQsIHBsZWFzZSBzZWUg dGhlIEZBUSBhdA0KPiA8aHR0cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvYXJlYS9nZW4vdHJhYy93 aWtpL0dlbkFydGZhcT4uDQo+IA0KPiBQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9u ZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMNCj4geW91IG1heSByZWNlaXZlLg0K PiANCj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtd2VpcmRzLXJkYXAtcXVlcnktMTUudHh0DQo+IFJl dmlld2VyOiBCcmlhbiBDYXJwZW50ZXINCj4gUmV2aWV3IERhdGU6IDIwMTQtMTAtMjANCj4gSUVU RiBMQyBFbmQgRGF0ZTogMjAxNC0xMC0yNA0KPiBJRVNHIFRlbGVjaGF0IGRhdGU6IDIwMTQtMTAt MzANCj4gDQo+IFN1bW1hcnk6ICAgQWxtb3N0IHJlYWR5DQo+IC0tLS0tLS0tDQo+IA0KPiBNYWpv ciBJc3N1ZXM6DQo+IC0tLS0tLS0tLS0tLS0NCj4gDQo+IFNlY3Rpb24gMy4xLjEgc2F5czoNCj4g DQo+ICAgIlRoZSByZXN0cmljdGVkDQo+ICAgIHJ1bGVzIHRvIHdyaXRlIGEgdGV4dCByZXByZXNl bnRhdGlvbiBvZiBhbiBJUHY2IGFkZHJlc3MgW1JGQzU5NTJdDQo+IGFyZQ0KPiAgICBub3QgbWFu ZGF0b3J5LiINCj4gDQo+IFdoeSBub3QgbWFrZSA1OTUyIGF0IGxlYXN0IGEgU0hPVUxEPyBQZXJz b25hbGx5LCBJIHdvdWxkIG1ha2UgaXQgYQ0KPiBNVVNULiBBcyA1OTUyIGl0c2VsZiBzdGF0ZXMs DQo+IHRoZSBhbWJpZ3VpdHkgb2YgdGhlIFJGQyA0MjkxIGZvcm1hdCBjcmVhdGVzIG1hbnkgcHJv YmxlbXMuIDU5NTIgaW4gYW55DQo+IGNhc2UgcmVxdWlyZXMgdGhhdA0KPiAiYWxsIGltcGxlbWVu dGF0aW9ucyBtdXN0IGFjY2VwdCBhbmQgYmUgYWJsZSB0byBoYW5kbGUgYW55IGxlZ2l0aW1hdGUN Cj4gUkZDIDQyOTEgZm9ybWF0IiwNCj4gc28gbWFraW5nIGNvbmZvcm1hbmNlIHdpdGggNTk1MiBh IFNIT1VMRCBvciBNVVNUIHdvbid0IGJyZWFrIGFueXRoaW5nLg0KPiANCj4gTWlub3IgaXNzdWVz Og0KPiAtLS0tLS0tLS0tLS0tDQo+IA0KPiBTZWN0aW9uIDMuMS4xIHNheXM6DQo+IA0KPiAgICJI b3dldmVyLCB0aGUgem9uZSBpZCBbUkZDNDAwN10gaXMgbm90IGFwcHJvcHJpYXRlIGluDQo+ICAg IHRoaXMgY29udGV4dCBhbmQgdGhlcmVmb3JlIHByb2hpYml0ZWQuIg0KPiANCj4gQWdyZWVkLCBi dXQgeW91IHByb2JhYmx5IGFsc28gbmVlZCB0byBleGNsdWRlIHRoZSBleHRlbmRlZCBVUkkgc3lu dGF4DQo+IGZvciB0aGlzIFtSRkM2ODc0XSwNCj4gc2luY2UgeW91ciBiYXNlIHJlZmVyZW5jZSBp cyB0aGUgVVJJIHN5bnRheCBbUkZDMzk4Nl0gd2hpY2ggaXMgdXBkYXRlZA0KPiBieSA2ODc0Lg0K PiBUaGlzIGlzIGp1c3QgZm9yIGNsYXJpZmljYXRpb24sIHNpbmNlIDY4NzQgZG9lcyBub3QgY2hh bmdlIHRoZSBBQk5GDQo+IHByb2R1Y3Rpb24NCj4gZm9yIElQdjZhZGRyZXNzLg0KDQpUaGFua3Mg Zm9yIHRoZSBmZWVkYmFjaywgQnJpYW4uIEkndmUgYXNrZWQgQW5keSB0byByZXZpZXcgdGhlIGNv bW1lbnRzIGFib3ZlIHNpbmNlIHRoZXkgcmVmZXIgdG8gb2JqZWN0cyB0aGF0IGFyZSBwcmltYXJp bHkgdXNlZCBieSBhZGRyZXNzIHJlZ2lzdHJpZXMuDQoNCj4gIjEwLjIuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzDQo+IA0KPiAgICBbUkVTVF0gICAgIEZpZWxkaW5nLCBSLiBhbmQgUi4gVGF5bG9y LCAiUHJpbmNpcGxlZCBEZXNpZ24gb2YgdGhlDQo+ICAgICAgICAgICAgICAgTW9kZXJuIFdlYiBB cmNoaXRlY3R1cmUiLCBBQ00gVHJhbnNhY3Rpb25zIG9uIEludGVybmV0DQo+ICAgICAgICAgICAg ICAgVGVjaG5vbG9neSBWb2wuIDIsIE5vLiAyLCBNYXkgMjAwMi4iDQo+IA0KPiBUaGUgdGV4dCBp biBzZWN0aW9uIDEuMSBpbXBsaWVzIHRoYXQgdGhpcyBpcyAiYSBkb2N0b3JhbCBkaXNzZXJ0YXRp b24iLg0KPiBJdCBpc24ndC4NCg0KVGhhbmtzIGZvciBjYXRjaGluZyB0aGF0LiBJIGNhbiBjaGFu Z2UgdGhlIHJlZmVyZW5jZSB0byB0aGlzICh1c2VkIGluIFJGQyA3MjUyKToNCg0KW1JFU1RdICAg ICBGaWVsZGluZywgUi4sICJBcmNoaXRlY3R1cmFsIFN0eWxlcyBhbmQgdGhlIERlc2lnbiBvZg0K ICAgICAgICAgICBOZXR3b3JrLWJhc2VkIFNvZnR3YXJlIEFyY2hpdGVjdHVyZXMiLCBQaC5ELiBE aXNzZXJ0YXRpb24sDQogICAgICAgICAgIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYSwgSXJ2aW5l LCAyMDAwLA0KICAgICAgICAgICA8aHR0cDovL3d3dy5pY3MudWNpLmVkdS9+ZmllbGRpbmcvcHVi cy9kaXNzZXJ0YXRpb24vDQogICAgICAgICAgIGZpZWxkaW5nX2Rpc3NlcnRhdGlvbi5wZGY+Lg0K DQpTY290dA0K From nobody Tue Oct 21 03:50:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF101A0469 for ; Tue, 21 Oct 2014 03:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6QA46S2f9GQ for ; Tue, 21 Oct 2014 03:50:24 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D89B1A03FF for ; Tue, 21 Oct 2014 03:50:23 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKVEY6bl/oRWlu66P9kDRyxEZFuIH9RIAI@postini.com; Tue, 21 Oct 2014 03:50:23 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9LAoMaK004121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Oct 2014 06:50:22 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 06:50:21 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: Gen-ART review of draft-ietf-weirds-rdap-sec-09 Thread-Index: Ac/rwUIQou+UqyLTRGO9+RCo9ywghAAn5ZJAAC77BUA= Date: Tue, 21 Oct 2014 10:50:21 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494EF91C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <7594FB04B1934943A5C02806D1A2204B1D4AF4C2@ESESSMB209.ericsson.se> 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_831693C2CDA2E849A7D7A712B24E257F494EF91CBRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/UBefBwoXS9V7B6Uqr0Q9zQRYYIo Subject: [weirds] FW: Gen-ART review of draft-ietf-weirds-rdap-sec-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 10:50:32 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F494EF91CBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, folks. Scott From: Hollenbeck, Scott Sent: Monday, October 20, 2014 9:18 AM To: 'Christer Holmberg'; gen-art@ietf.org Cc: draft-ietf-weirds-rdap-sec.all@tools.ietf.org Subject: RE: Gen-ART review of draft-ietf-weirds-rdap-sec-09 Thanks for the comments, Christer. More below. Scott From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Sunday, October 19, 2014 7:46 PM To: gen-art@ietf.org Cc: draft-ietf-weirds-rdap-sec.all@tools.ietf.org Subject: Gen-ART review of draft-ietf-weirds-rdap-sec-09 (Re-send with correct subject) I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at Document: draft-ietf-weirds-rdap-sec-09 Reviewer: Christer Holmberg Review Date: 19 October 2014 IETF LC End Date: 24 October 2014 IETF Telechat Date: 30 October 2014 Summary: I have found a number of issues. They are = of editorial nature, but makes it difficult to understand the mechanism. I = ask the authors to look at those, and consider if/how they can be addressed= . Major Issues: None Minor Issues: None Q1_GENERAL: In the Introduction, you say that one of the goal of RDAP is to provide sec= urity services, that do not exist in WHOIS. However, in section 3 you then say that RDAP doesn't provide any of these s= ecurity services, but relies on other protocols. First, I think you need to re-formulate the text in the Introduction, and t= alk about how other protocols can be used to provide security services for = RDAP. [SAH] The introduction currently states "This document describes how each o= f these services is achieved by RDAP". The details are described in later s= ections. I'm comfortable with changing "This document describes how each of= these services is achieved by RDAP" to "This document describes how each o= f these services is achieved by RDAP using features that are available in o= ther protocol layers", but I think it's more appropriate to leave the detai= ls where they are and not replicate them in the introduction. Second, there is no text on why "other protocols" couldn't be used to provi= de security services for WHOIS. I think you need to say that, if you want to claim that RDAP provides better security than WHOI= S. [SAH] This document isn't focused on WHOIS deficiencies. The reference to R= FC 3912 provides a pointer to WHOIS and its lack of security services. Q2_GENERAL: In some places you say that additional/alternative mechanisms= may be defined in the future. I think it would be good to in the Introduction indicate that additional/alternative mechanisms can be add= ed in the future. [SAH] OK, that's reasonable. Q3_GENERAL: You start some subsections by describing what WHOIS does/does= n't do. I think you should first describe of the specific security service is provided for RDAP, and then later describe= e.g. why the same cannot be provided for WHOIS [SAH] Since this document isn't focused on WHOIS deficiencies I don't think= this is necessary. Q4_3_1_1: Section 3.1.1. says: "Federated authentication mechanisms use= d by RDAP are OPTIONAL." That statement is confusing. Does it mean that everything els= e in the document is mandatory to support? [SAH] Good point. I can modify that sentence and the second sentence in tha= t paragraph as follows: "Federated authentication mechanisms MAY be used by RDAP. If used, they MUS= T be fully supported by HTTP." Q5_3_3: The name of section 3.3 is "Availability". I don't see how th= at is a security service, and the text mostly talks about throttling. Would it be more appropriate to say "Request throttling" instea= d? [SAH] The property of availability is described in Section 4 of RFC 4949. I= believe the text is appropriate as-is. Q6_3_4: Section 3.4 says: "Web services such as RDAP commonly use HTTP Over TLS [RFC281= 8] to provide that protection by encrypting all traffic sent on the connection between client and server." To me that sounds like something from a BCP document. I think= you should say that the document defines the usage of HTTP over TLS for providing the security service. [SAH] OK. I can change the sentence to "RDAP SHOULD use HTTP Over TLS [RFC2= 818] to provide that protection by encrypting all traffic sent on the conne= ction between client and server". I'm sure there are people who will sugges= t that MUST is better than SHOULD, but that adds a requirement that hasn't = been discussed in the WG. WG chairs - what do you think? Editorial nits: None Regards, Christer --_000_831693C2CDA2E849A7D7A712B24E257F494EF91CBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI, = folks.

=  

Scott

=  

From: Hollenbe= ck, Scott
Sent: Monday, October 20, 2014 9:18 AM
To: 'Christer Holmberg'; gen-art@ietf.org
Cc: draft-ietf-weirds-rdap-sec.all@tools.ietf.org
Subject: RE: Gen-ART review of draft-ietf-weirds-rdap-sec-09

 

Thank= s for the comments, Christer. More below.

=  

Scott

=  

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Sunday, October 19, 2014 7:46 PM
To: gen-art@ietf.org
Cc: draft-ietf-weirds-rdap-sec.all@tools.ietf.org
Subject: Gen-ART review of draft-ietf-weirds-rdap-sec-09<= /span>

 

(Re-send with correct subject)

 

I am the assigned Gen-ART reviewer for this draft= . For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

 

Document:      &nbs= p;             =      draft-ietf-weirds-rdap-sec-09

 

Reviewer:      &nbs= p;            &= nbsp;       Christer Holmberg

 

Review Date:      &= nbsp;            &nb= sp; 19 October 2014

 

IETF LC End Date:     &n= bsp;       24 October = 2014

 

IETF Telechat Date:     =     30 October 2014

 

Summary:       = ;            &n= bsp;     I have found a number of issues. They are of editorial nature, but m= akes it difficult to understand the mechanism. I ask the authors to look at= those, and consider if/how they can be addressed.

 

Major Issues: None

 

Minor Issues: None

 

Q1_GENERAL:

 

In the Introduction, y= ou say that one of the goal of RDAP is to provide security services, that d= o not exist in WHOIS.

 

However, in section 3 = you then say that RDAP doesn’t provide any of these security services= , but relies on other protocols.

 

First, I think you nee= d to re-formulate the text in the Introduction, and talk about how other pr= otocols can be used to provide security services for RDAP.

[S= AH] The introduction currently states “This document describes how ea= ch of these services is achieved by RDAP”. The details are described = in later sections. I’m comfortable with changing “This document describes how each of these services is achieved by R= DAP” to “This document describes how each of these services is = achieved by RDAP using features that are available in other protocol layers= ”, but I think it’s more appropriate to leave the details where they are and not replicate them in the introduction.

 

Second, there is no te= xt on why “other protocols” couldn’t be used to provide s= ecurity services for WHOIS. I think you need to

say that, if you want = to claim that RDAP provides better security than WHOIS.

[S= AH] This document isn’t focused on WHOIS deficiencies. The reference = to RFC 3912 provides a pointer to WHOIS and its lack of security services.<= o:p>

 

Q2_GENERAL:

 

        &= nbsp;     In some places you say that additional/altern= ative mechanisms may be defined in the future. I think it would be good to = in

the Introduction indic= ate that additional/alternative mechanisms can be added in the future.=

[S= AH] OK, that’s reasonable.

 

Q3_GENERAL:

 

        &= nbsp;     You start some subsections by describing what= WHOIS does/doesn’t do. I think you should first describe of

the specific security = service is provided for RDAP, and then later describe e.g. why the same can= not be provided

for WHOIS

[SAH] Since this document isn’t focused on W= HOIS deficiencies I don’t think this is necessary.<= /p>

 

Q4_3_1_1:

 

        &= nbsp;     Section 3.1.1. says: “Federated authent= ication mechanisms used by RDAP are OPTIONAL.”

 

        &= nbsp;     That statement is confusing. Does it mean tha= t everything else in the document is mandatory to support?

[S= AH] Good point. I can modify that sentence and the second sentence in that = paragraph as follows:

 

&#= 8220;Federated authentication mechanisms MAY be used by RDAP. If used, they= MUST be fully supported by HTTP.”

 

Q5_3_3:

 

        &= nbsp;     The name of section 3.3 is “Availabilit= y”. I don’t see how that is a security service, and the text mo= stly talks about

throttling. Would it b= e more appropriate to say “Request throttling” instead?

[S= AH] The property of availability is described in Section 4 of RFC 4949. I b= elieve the text is appropriate as-is.

 

 

Q6_3_4:

 

        &= nbsp;     Section 3.4 says:

 

        &= nbsp;     “Web services such as RDAP commonly use= HTTP Over TLS [RFC2818] to provide that protection by encrypting all<= /o:p>

         =      traffic sent on the connection between client and = server.”

 

        &= nbsp;     To me that sounds like something from a BCP d= ocument. I think you should say that the document defines

the usage of HTTP over= TLS for providing the security service.

[S= AH] OK. I can change the sentence to “RDAP SHOULD use HTTP Over TLS [= RFC2818] to provide that protection by encrypting all traffic sent on the c= onnection between client and server”. I’m sure there are people who will suggest that MUST is better than SHOULD, bu= t that adds a requirement that hasn’t been discussed in the WG. WG ch= airs – what do you think?

 

Editorial nits: None

 

 

Regards,

 

Christer

 

--_000_831693C2CDA2E849A7D7A712B24E257F494EF91CBRN1WNEXMBX01vc_-- From nobody Tue Oct 21 05:15:33 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F9B1A1B26; Tue, 21 Oct 2014 05:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWRp2h7YoF3F; Tue, 21 Oct 2014 05:15:21 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA701A1B2D; Tue, 21 Oct 2014 05:14:50 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKVEZOOuuHU6Y03ENGj8ebi73gE/VnXwTp@postini.com; Tue, 21 Oct 2014 05:15:20 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9LCEm5W003698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 08:14:48 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 08:14:47 -0400 From: "Hollenbeck, Scott" To: Sarah Banks , "" , "draft-ietf-weirds-rdap-query.all@tools.ietf.org" Thread-Topic: OPS-DIR Review of draft-ietf-weirds-rdap-query Thread-Index: AQHP7NBqXufhXrOPI06XioFso+X0z5w6c6oQ Date: Tue, 21 Oct 2014 12:14:47 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494EFB20@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <6332B2BF-2CAF-40B0-A1FD-97E3469B49ED@encrypted.net> In-Reply-To: <6332B2BF-2CAF-40B0-A1FD-97E3469B49ED@encrypted.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/dYTyovPpILtDU1giEksj5vjg3js Cc: "weirds@ietf.org" Subject: Re: [weirds] OPS-DIR Review of draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 12:15:23 -0000 Thanks for the review comments, Sarah. More below... Scott > -----Original Message----- > From: Sarah Banks [mailto:sbanks@encrypted.net] > Sent: Monday, October 20, 2014 9:43 PM > To: ; draft-ietf-weirds-rdap-query.all@tools.ietf.org > Subject: OPS-DIR Review of draft-ietf-weirds-rdap-query >=20 > Hello, > I've reviewed draft-ietf-weirds-rdap-query-15 for its operational > impact. >=20 > Summary: The document is well written, thorough, provides ample > discussion and examples, and even provides a change log in it's > appendix. I have no objections to this document and believe it should > be published >=20 > There are 2 nits from the nits checker for down refs. I just ran the draft through the id-nits checker myself and found an unused= reference to RFC 7159. It's a remnant from earlier text that was recently = removed. The reference will be removed. The downref warnings are to RFCs 952 and 1166 and Unicode-UAX15. I think th= ose are OK. There's also a warning about informative reference RFC 1594 ("where XXXX is= a fully-qualified (relative to the root) domain name [RFC1594]") having be= en obsoleted by RFC 2664. The text we refer to exists in 1594, but not in 2= 664. There may be a better reference for "domain name" - perhaps RFCs 952 a= nd 1123? > Overall, I found the document very easy to read through, walking > through the problem it's trying to solve, addressing each add section > by section, with discussion points for each, and examples for each, > too. One minor (personal) nit, is the requirement that WHOIS servers > that don't or can't respond to a request SHOULD return a 501 error > (RFC7231). In trying to provide some structure, it'd be nice to know > explicitly that the server has/had an issue responding to the request. > If the server chooses not to return a 501 in the event of an error, > then what? Would anyone in the WG object to this being a MUST? That would address the = ambiguity. > This aside, the document is ready for publication. Thanks again, Scott From nobody Tue Oct 21 05:52:18 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9821A1B5F; Tue, 21 Oct 2014 05:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl2B9kf3fb5b; Tue, 21 Oct 2014 05:52:04 -0700 (PDT) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E043F1A1AE1; Tue, 21 Oct 2014 05:51:42 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKVEZW3aig2/VumXAIelIKYgRevU8VTgwc@postini.com; Tue, 21 Oct 2014 05:52:03 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9LCpe46008024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 08:51:40 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 08:51:39 -0400 From: "Hollenbeck, Scott" To: Edward Lewis , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlit5w6fdGg Date: Tue, 21 Oct 2014 12:51:39 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494EFBE3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04B8_01CFED0C.38F8E5A0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/yko7OZT5CelCSA8bLroREbAPri4 Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 12:52:07 -0000 ------=_NextPart_000_04B8_01CFED0C.38F8E5A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Edward Lewis [mailto:edward.lewis@icann.org] > Sent: Friday, October 17, 2014 12:02 PM > To: ietf@ietf.org; iesg@ietf.org > Cc: weirds@ietf.org; Hollenbeck, Scott; Andy Newton > Subject: Re: Last Call: > (Registration Data Access Protocol Query Format) to Proposed Standard Thanks for the feedback, Ed. > A couple of comments >=20 > Comment 1 >=20 > Section 1.1 >=20 > Nit: the detail on REST and RESTful seems out of place in a list of > acronyms and abbreviations. The "detail" is no more than a sentence or two. I'm inclined to leave = that nit alone. > Comment 2 >=20 > Section 2 >=20 > ## 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. >=20 > Nit: should be "it is unlikely that a uniform approach ... is needed > for > interoperability." Agreed. > Comment 3 >=20 >=20 > Section 3.2 >=20 > Confusion: domain/domains and entity/entities plural forms are defined > externally to the list, but nameserver/nameservers plural form is > not. I think that is just an inconstency. I don't understand this comment. The text I'm looking at in Section 3.2 = includes search path segment definitions for "domains", "nameservers", = and "entities". The singular forms used for lookups are defined in = Section 3.1. What am I missing? > The word ''match'' is used referring to a FQDN. Does this mean to > imply > ''match'' as defined in RFC 1034 (where '*' matches anything)? Matching is described in Section 4.1. > And what is throwing me is that this begins talking about testing to > see > if something exists and then seems to start talking about finding > inexact > matches (the plurals). >=20 > It reads as if the first paragraph doesn't relate to the rest of the > section. Hmm, OK. That first paragraph (which describes using the HTTP HEAD = method to check for object existence) could be moved to Section 3.1. > Comment 4 >=20 > Section 3.2.1 and 3.2.2 >=20 > Confusion: Both 3.2.1 and 3.2.2 cover searching for name servers. Why > are > two approaches presented? >=20 > http://example.com/rdap/nameservers?name=3Dns1.example*.com > and > http://example.com/rdap/domains?nsLdhName=3Dns1.example*.com >=20 > I suppose this isn't a major issue, but seems awkward. 3.2.1 describes searching for *domains*. 3.2.2 describes searching for = *name servers*. > Comment 5 >=20 > Section 4.2 >=20 > Needed work: What is a "name-record" ? I can imagine a few different > meanings, which is the problem. Is this a "registration" , i.e., the > mapping of the network object to an entity (set)? Are associated > "name-records" like variants of IDNs? Are they related in a IP > hierarchy, > or somehow jointly registered objects? I believe this text came from John Klensin. My understanding of the = meaning is that the term refers to a row in a relational database. Would = it be clearer to just say "record" or "entry" instead of "name record"? > Comment 6 >=20 >=20 > Section 4.2 - later on >=20 > Confusion: It sounds here that a client cannot set up an expectation > that > it's query will return something specific or return a list, which is > bad > (meaning the client can=E2=80=99t set expectation). A client ought to = be able > to > know what it will get back, even if it is an error. What I mean is > 'returning information that was not explicitly selected by an exact- > match > lookup' is ... is bothering me. >=20 > Maybe these terms need to be ironed out better: search vs. lookup and > what > does match mean. I do see match defined - after it is used a few > times. > And in section 3.2, I first ran into the confusion of search v. = lookup. >=20 > (In the DNS world, we distunguish this by saying DNS does not search, > it > does a lookup.) Can you suggest appropriate text? > Comment 7 >=20 > Section 5 >=20 > Suggestion: this seems to be begging for a "standard" definition of an > non-standard extension prefix - or everyone will use "custom_" because > that is the example here. (Name collisions.) And if a custom one > becomes > a standard, can the transition be eased? (TXT to SPF issue.) And how > do > we encourage more standard and fewer uniques (the EPP[EXT] issue)? Note the reference to Section 6 of the using-http document. It describes = an IANA registry for these prefixes. > Comment 8 >=20 > Section 6 >=20 > Suggestion: Shouldn't RDAP applications be considered to be IDNA2008 > aware? The argument for this is in RFC 6912. Or is that pressing a > policy > into the protocol needlessly? One of the authors of RFC 6912 (Andrew Sullivan) was very helpful in = developing the text for this section. I would defer to his guidance. > Comment 9 >=20 >=20 > Section 8 >=20 > ## Search functionality also increases the privacy risk of = disclosing > ## object relationships that might not otherwise be obvious. For > ## example, a search that returns IDN variants [RFC6927] that do not > ## explicitly match a client-provided search pattern can disclose > ## information about registered domain names that might not be > otherwise > ## available. Implementers need to consider the policy and privacy > ## implications of returning information that was not explicitly > ## requested. >=20 > I think this can improved by mentioning that implementers need to > =E2=80=9Cconsider policy and privacy implications, e.g., by checking = for > authorization to release information to the requestor, in all cases = and > especially here, when returning information that was not explicitly > requested.=E2=80=9D >=20 >=20 > In general, I=E2=80=99ve always been a little suspect on = RDAP=E2=80=99s search ability > and > now carefully reading the last call documents am still a little shaky > on > it. Perhaps the word =E2=80=9Csearch=E2=80=9D to me has a wider = definition than is > being > applied here, where RDAP just looks for a common pre-amble (prefix, > starting string, whatever you want to call it). I am aware of the > perils > of unicode, sigh, but I wish there was a chance to have a search > definition that was free of ASCII assumptions and was always mindful = of > the authorization to =E2=80=9Crelease=E2=80=9D information. >=20 > I am aware I=E2=80=99m saying this very late in the game. I=E2=80=99m = willing to > accept > the definition going forward as is. But I wanted to drop the comment > somewhere. But please add in, where implementers = =E2=80=9Cconsider=E2=80=9D, mention > of > the authorization model. This is because I can see operators pulling > open > source tools for this from the shelf, they won=E2=80=99t be = handcrafting the > code, > and need some place to =E2=80=9Cconfigure this=E2=80=9D. How about this? OLD: "Implementers need to consider the policy and privacy implications of = returning information that was not explicitly requested." NEW: "Implementers need to consider the policy and privacy implications of = returning information that was not explicitly requested. Clients should = only receive information that they are explicitly authorized to = receive." Scott ------=_NextPart_000_04B8_01CFED0C.38F8E5A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISCzCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggeGMIIGbqADAgECAhBINamF8XD8u43P2ICxcxmGMA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDIxODAwMDAwMFoXDTE1MDIxODIzNTk1 OVowdjEnMCUGCSqGSIb3DQEJARYYc2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tMRowGAYDVQQDDBFI b2xsZW5iZWNrLCBTY290dDEWMBQGA1UECwwNRU5URVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNp Z24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4SzlP6x5P6I6j49cR7c7X exUgfitPoeKrE0MrgiRAnSdzCa69iwbk+uA15/fEDZR0ddwn0RPQ5+vIXV+pOEOlRk84znAyOOSh Iam8D0CiCOiNv28drXgq0HWRdp+cFw1MSihGdVntMcYMexVNvAeYGuU9gtC6afNVYVBjkWDfNzwy em3dYv04DfKtAJkCg4tIXh93uTpBsoS5IADJ4GtMPdwvTmXJ2ucHqMjHKYjdaC+pO/ebVv+RFnus ihDVQjX/oYwS8FqYYSNT+SwyMF35NVXcVl4uuMeHWD7/G65RnnvIz8B6vGQ7hTcLE35cEc31O0kR vSWgaNJKh8E6C+EtAgMBAAGjggO6MIIDtjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAW BgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4EFgQUVoVKaC1xEPB9EWKq3dWrwskIufkwTwYD VR0RBEgwRoEYc2hvbGxlbmJlY2tAdmVyaXNpZ24uY29toCoGCisGAQQBgjcUAgOgHAwac2hvbGxl bmJAdmNvcnAuYWQudnJzbi5jb20wHwYDVR0jBBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFx BggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUFBzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5j b20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8vZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUz RCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIwU2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlm aWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUzRCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0kl MjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUyMENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRy dXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUz RCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2kt Y3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVz dENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8v d3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29t L3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQME ARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUBEAMEHjAcBhJghkgBhvhFARABAgIBAYvxxgkWBjI0 NzY2NDA5BgpghkgBhvhFARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFD NWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQAEp6rtILYuQhcsKJhBBRYuzdb6psiNZdof/abX5TWf IiNqLDTmHg0FURIjUDORjN3A8pJPuDQve/VRDYGiorD/eTYV/1BC4vUoP6e4xOC79bfaKnTxeS6F L2CV7N5LtlutH7ybwx/y70zm3TM8QJAUNnKiYmEh6JruuMCEptTFlIQw9tWHsSd+YFEnFWplO1Bv wyMXEHgHj+ImUYqrmbcvBXzPfFzVSYWUffZWwFkhwtWnwmcNLokAOTpeqtg2X4XCdyQue1GNkckM Utc8fMO0PajcxEwBwuVNIUwDYi1w/3IrdgLjcxgEyuz6o11YENiN8AmnzekGV2iQrJaOF/UvMYIF BzCCBQMCAQEwgd4wgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5h Z2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNz IDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEg1qYXxcPy7jc/Y gLFzGYYwCQYFKw4DAhoFAKCCAv0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTQxMDIxMTI1MTM2WjAjBgkqhkiG9w0BCQQxFgQUMQaOlBiKxpml5CNJzeBHNk5QTGsw gbcGCSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEW MAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQME AgEwCgYIKoZIhvcNAgUwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3Jr MTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFD MEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRl IEF1dGhvcml0eQIQSDWphfFw/LuNz9iAsXMZhjCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEg1qYXxcPy7jc/YgLFzGYYwDQYJKoZIhvcNAQEB BQAEggEAtijdm8IkFeKQaUAekPyYUMXwN8dFHh47gVX7rvKFt6+quZOOzN6/Jj47SjthH6JavwiL /prDrU6U1vZmiIlv6gcBCfjLhXa/2jUSyrHKijruHsTQjgNblzz3eA+xeqnsQNY6jbKBgTZePfLQ M7r+MnK5MAgUyw7MwNuWEmVcwI3XYT7CGPc3Kj3NG/jviPxL/E4rlxfJxL5QioGpjVTVcsgsdG7h tBykx4PwUSo87I4uTLrMFu6Jolbdol997wvYL/5Lx7DTUBxKAFRne1g+99/kptdDoIc0sYqdKrTu cYRkQ+adEjJ3NwU2eOUGFY4iBWLf31nyRZvUTH3J5KqMmwAAAAAAAA== ------=_NextPart_000_04B8_01CFED0C.38F8E5A0-- From nobody Tue Oct 21 06:35:39 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2662C1A6EF2; Tue, 21 Oct 2014 06:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJXIvlIbUOAI; Tue, 21 Oct 2014 06:35:14 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0361A6EEF; Tue, 21 Oct 2014 06:35:14 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 21 Oct 2014 06:35:11 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 21 Oct 2014 06:35:11 -0700 From: Edward Lewis To: "Hollenbeck, Scott" , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlit5w6fdGggABH2wA= Date: Tue, 21 Oct 2014 13:35:11 +0000 Message-ID: References: <831693C2CDA2E849A7D7A712B24E257F494EFBE3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494EFBE3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3496728908_163581" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/X0vYECxJehD40e94nAIOUJaLVJs Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:35:29 -0000 --B_3496728908_163581 Content-type: multipart/alternative; boundary="B_3496728908_122586" --B_3496728908_122586 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable A few =E2=80=9Ccomebacks=E2=80=9D in-line. From: "Hollenbeck, Scott" Date: Tuesday, October 21, 2014 at 8:51 To: Edward Lewis , "ietf@ietf.org" = , "iesg@ietf.org" Cc: "weirds@ietf.org" , Andy Newton Subject: RE: Last Call: (Registratio= n Data Access Protocol Query Format) to Proposed Standard >> -----Original Message----- >> From: Edward Lewis [mailto:edward.lewis@icann.org] >> Sent: Friday, October 17, 2014 12:02 PM >> To: ietf@ietf.org; iesg@ietf.org >> Cc: weirds@ietf.org; Hollenbeck, Scott; Andy Newton >> Subject: Re: Last Call: >> (Registration Data Access Protocol Query Format) to Proposed Standard >=20 > Thanks for the feedback, Ed. >=20 >> A couple of comments >> =20 >> Comment 1 >> =20 >> Section 1.1 >> =20 >> Nit: the detail on REST and RESTful seems out of place in a list of >> acronyms and abbreviations. >=20 > The "detail" is no more than a sentence or two. I'm inclined to leave tha= t nit > alone. >=20 >> Comment 2 >> =20 >> Section 2 >> =20 >> ## 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. >> =20 >> Nit: should be "it is unlikely that a uniform approach ... is needed >> for >> interoperability." >=20 > Agreed. >=20 >> Comment 3 >> =20 >> =20 >> Section 3.2 >> =20 >> Confusion: domain/domains and entity/entities plural forms are defined >> externally to the list, but nameserver/nameservers plural form is >> not. I think that is just an inconstency. >=20 > I don't understand this comment. The text I'm looking at in Section 3.2 > includes search path segment definitions for "domains", "nameservers", an= d > "entities". The singular forms used for lookups are defined in Section 3.= 1. > What am I missing? That in the bullets you have: o 'domains': ... o 'nameservers': ... o 'entities': =E2=80=A6 And in prose you have: For the domain and entity objects described in this document the plural object forms are "domains" and "entities=E2=80=9D. Merely the mismatch in the =E2=80=9Cnumber of parameters=E2=80=9D (- the prose doesn=E2=80=99= t mention nameservers) >> The word ''match'' is used referring to a FQDN. Does this mean to >> imply >> ''match'' as defined in RFC 1034 (where '*' matches anything)? >=20 > Matching is described in Section 4.1. The you have a =E2=80=9Cforward reference here - using =E2=80=9Cmatch=E2=80=9D in 3.2 (and in= the context of a =E2=80=9Cfully-qualified domain name), then later in the document defining it in 4.1. I=E2=80=99ve seen this problem when implementers read the RFCs. They might read = 3.2 and assume match as defined in the DNS. Match is such an overloaded term i= t deserves qualification (or an adjective). >=20 >> And what is throwing me is that this begins talking about testing to >> see >> if something exists and then seems to start talking about finding >> inexact >> matches (the plurals). >> =20 >> It reads as if the first paragraph doesn't relate to the rest of the >> section. >=20 > Hmm, OK. That first paragraph (which describes using the HTTP HEAD method= to > check for object existence) could be moved to Section 3.1. >=20 >> Comment 4 >> =20 >> Section 3.2.1 and 3.2.2 >> =20 >> Confusion: Both 3.2.1 and 3.2.2 cover searching for name servers. Why >> are >> two approaches presented? >> =20 >> http://example.com/rdap/nameservers?name=3Dns1.example*.com >> and >> http://example.com/rdap/domains?nsLdhName=3Dns1.example*.com >> =20 >> I suppose this isn't a major issue, but seems awkward. >=20 > 3.2.1 describes searching for *domains*. 3.2.2 describes searching for *n= ame > servers*. Then maybe the example =E2=80=9Cns1.example*.com=E2=80=9D ought to be just "example*.co= m.=E2=80=9D? >=20 >> Comment 5 >> =20 >> Section 4.2 >> =20 >> Needed work: What is a "name-record" ? I can imagine a few different >> meanings, which is the problem. Is this a "registration" , i.e., the >> mapping of the network object to an entity (set)? Are associated >> "name-records" like variants of IDNs? Are they related in a IP >> hierarchy, >> or somehow jointly registered objects? >=20 > I believe this text came from John Klensin. My understanding of the meani= ng is > that the term refers to a row in a relational database. Would it be clear= er to > just say "record" or "entry" instead of "name record"? I=E2=80=99ll go with what was meant. As a reader, my note is that the term may b= e a little too abstract. Perhaps: Conceptually, a search-query-matching record in a database may be linked to an associated record, which may also be linked to another such record, and so on. That is, if =E2=80=9Clinked to=E2=80=9D is the right term. Perhaps =E2=80=9Cassociated with=E2= =80=9D (knowing that term is in the title). Of perhaps this Conceptually, a search-query-matching record in a database may be a member of a set of one or more records associated with a registration event [if that=E2=80=99s the appropriate grouping]. (Sorry about the formatting - I=E2=80=99ve lost control of how this mail reader d= oes formatting.) I have a new comment coming from re-reading this section: If an implementation is to return more than one name-record in response to a query, information from the records thereby identified is returned. >From that I would assume the draft is saying all associated records would b= e too - and later we talk about issues with authorization to release information. I=E2=80=99d change the =E2=80=9Cis returned=E2=80=9D to =E2=80=9Cis subject to be inc= luded in a response (pending other considerations [and maybe cite the Security Considerations]).=E2=80=9D Oh, wait, that=E2=80=99s in the next paragraph. Perhaps using the word =E2=80=9Cset=E2=80=9D might make 4.2 work better. Uh, see below... >=20 >> Comment 6 >> =20 >> =20 >> Section 4.2 - later on >> =20 >> Confusion: It sounds here that a client cannot set up an expectation >> that >> it's query will return something specific or return a list, which is >> bad >> (meaning the client can=E2=80=99t set expectation). A client ought to be abl= e >> to >> know what it will get back, even if it is an error. What I mean is >> 'returning information that was not explicitly selected by an exact- >> match >> lookup' is ... is bothering me. >> =20 >> Maybe these terms need to be ironed out better: search vs. lookup and >> what >> does match mean. I do see match defined - after it is used a few >> times. >> And in section 3.2, I first ran into the confusion of search v. lookup. >> =20 >> (In the DNS world, we distunguish this by saying DNS does not search, >> it >> does a lookup.) >=20 > Can you suggest appropriate text? 4.2. Associated Records Conceptually, any query-matching record in the registry's database might be a member of a set of related records, related in some fashion as defined by the registry. (E.g., variants of an IDN.) When constructing the response, the entire set ought to be considered as candidates for inclusion. However= , the construction of the final response needs to be mindful of privacy and other data-releasing policies when assembling the RDAP response set. Note too that due to the nature of searching, there may be a list of query-matching records. Each one of those is subject to being a member of = a set as described in the previous paragraph. What is ultimately returned in a response will be the union of all the sets and be filtered by whatever policies are in place. >=20 >> Comment 7 >> =20 >> Section 5 >> =20 >> Suggestion: this seems to be begging for a "standard" definition of an >> non-standard extension prefix - or everyone will use "custom_" because >> that is the example here. (Name collisions.) And if a custom one >> becomes >> a standard, can the transition be eased? (TXT to SPF issue.) And how >> do >> we encourage more standard and fewer uniques (the EPP[EXT] issue)? >=20 > Note the reference to Section 6 of the using-http document. It describes = an > IANA registry for these prefixes. Then I=E2=80=99d change this: Custom path segments can be created by prefixing the segment with a unique identifier followed by an underscore character (0x5F). To: Custom path segments SHOULD be created by prefixing the segment with a unique identifier followed by an underscore character (0x5F). (A one word change, =E2=80=9Ccan=E2=80=9D to =E2=80=9CSHOULD=E2=80=9D.) >=20 >> Comment 8 >> =20 >> Section 6 >> =20 >> Suggestion: Shouldn't RDAP applications be considered to be IDNA2008 >> aware? The argument for this is in RFC 6912. Or is that pressing a >> policy >> into the protocol needlessly? >=20 > One of the authors of RFC 6912 (Andrew Sullivan) was very helpful in > developing the text for this section. I would defer to his guidance. >=20 >> Comment 9 >> =20 >> =20 >> Section 8 >> =20 >> ## Search functionality also increases the privacy risk of disclosing >> ## object relationships that might not otherwise be obvious. For >> ## example, a search that returns IDN variants [RFC6927] that do not >> ## explicitly match a client-provided search pattern can disclose >> ## information about registered domain names that might not be >> otherwise >> ## available. Implementers need to consider the policy and privacy >> ## implications of returning information that was not explicitly >> ## requested. >> =20 >> I think this can improved by mentioning that implementers need to >> =E2=80=9Cconsider policy and privacy implications, e.g., by checking for >> authorization to release information to the requestor, in all cases and >> especially here, when returning information that was not explicitly >> requested.=E2=80=9D >> =20 >> =20 >> In general, I=E2=80=99ve always been a little suspect on RDAP=E2=80=99s search abil= ity >> and >> now carefully reading the last call documents am still a little shaky >> on >> it. Perhaps the word =E2=80=9Csearch=E2=80=9D to me has a wider definition than is >> being >> applied here, where RDAP just looks for a common pre-amble (prefix, >> starting string, whatever you want to call it). I am aware of the >> perils >> of unicode, sigh, but I wish there was a chance to have a search >> definition that was free of ASCII assumptions and was always mindful of >> the authorization to =E2=80=9Crelease=E2=80=9D information. >> =20 >> I am aware I=E2=80=99m saying this very late in the game. I=E2=80=99m willing to >> accept >> the definition going forward as is. But I wanted to drop the comment >> somewhere. But please add in, where implementers =E2=80=9Cconsider=E2=80=9D, menti= on >> of >> the authorization model. This is because I can see operators pulling >> open >> source tools for this from the shelf, they won=E2=80=99t be handcrafting the >> code, >> and need some place to =E2=80=9Cconfigure this=E2=80=9D. >=20 > How about this? >=20 > OLD: > "Implementers need to consider the policy and privacy implications of > returning information that was not explicitly requested." >=20 > NEW: > "Implementers need to consider the policy and privacy implications of > returning information that was not explicitly requested. Clients should o= nly > receive information that they are explicitly authorized to receive." Almost=E2=80=A6=E2=80=9DServers should only send information that clients are explicitl= y authorized to receive.=E2=80=9D The way it is worded is impossible to "enforce." >=20 > Scott >=20 --B_3496728908_122586 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
A few “comebacks” in-line.

From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Tuesday, October 21, 2014 at 8:51
To: Edward Lewis <edward.lewis@icann.org>, "ietf@ietf.org" <ietf@ietf.org= >, "iesg@ietf.org" <iesg@ietf.org>
Cc: = "weirds@ietf.org" <weirds@ietf.org>, Andy Newton <andy@arin.net>
= Subject: RE: Last Call: <draft-ietf-weirds-rdap-query-15.txt> = (Registration Data Access Protocol Query Format) to Proposed Standard

<= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4= df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
-----Original Message---= --
From: Edward Lewis [ma= ilto:edward.lewis@icann.org]
Sent: Friday, October 17, 2014 1= 2:02 PM
Cc: weirds@ietf.org; Hollenbeck, Scott; Andy Newton
<= div> Subject: Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt>
(Registration Data Access Protocol Query Format) to Proposed Standar= d

Thanks for the feedback, Ed.

A couple o= f comments
Comment 1
Section 1= .1
Nit: the detail on REST and RESTful seems out of p= lace in a list of
acronyms and abbreviations.
<= div>
The "detail" is no more than a sentence or two. I'm incli= ned to leave that nit alone.

Comment 2
Section 2
##   Additionally, resource management, provisioni= ng and update
functions
##   are out of scop= e for this document.  Registries have various and
##&nb= sp;  divergent methods covering these functions, and it is unlikely a
##   uniform approach for these functions will ever be p= ossible.
Nit: should be "it is unlikely that a unifor= m approach ... is needed
for
interoperability."
<= /blockquote>

Agreed.

Comment 3
=
Section 3.2
Confusion: domain/domains and entit= y/entities plural forms are defined
externally to the list, but n= ameserver/nameservers plural form is
not.  I think that= is just an inconstency.

I don't under= stand this comment. The text I'm looking at in Section 3.2 includes search p= ath segment definitions for "domains", "nameservers", and "entities". The si= ngular forms used for lookups are defined in Section 3.1. What am I missing?=

That in th= e bullets you have:
o 'domains': ... o 'nameservers': ... o 'entities': … 
And in prose you have:
For the domain and entity objects described in =
this document the plural object forms are "domains" and "entities”.
=

Merely=
 the mismatch in the “number of parameters” (- the prose doesn&#=
8217;t mention nameservers)
<= /div>
The word ''match'' is used referring to= a FQDN.  Does this mean to
imply
''match'' = as defined in RFC 1034 (where '*' matches anything)?
=
Matching is described in Section 4.1.

The you have a “forward refe= rence here - using “match” in 3.2 (and in the context of a ̶= 0;fully-qualified domain name), then later in the document defining it in 4.= 1.

I’ve seen this problem when implem= enters read the RFCs.  They might read 3.2 and assume match as defined = in the DNS.  Match is such an overloaded term it deserves qualification= (or an adjective).

=

=
And what is throwing me= is that this begins talking about testing to
see
if s= omething exists and then seems to start talking about finding
ine= xact
matches (the plurals).
It reads as if= the first paragraph doesn't relate to the rest of the
section.

Hmm, OK. That first paragraph (which de= scribes using the HTTP HEAD method to check for object existence) could be m= oved to Section 3.1.

Comment 4
Section 3.2.1 and 3.2.2
Confusion: Both 3.2.1 and 3.2.2 cover searching for na= me servers.  Why
are
two approaches presente= d?
and
I suppose this isn't a major issue, but seems awkward.
=

3.2.1 describes searching for *domains*. 3.2.2 describes= searching for *name servers*.

Then maybe the example “ns1.example*.com” ou= ght to be just "example*.com.”?


Comme= nt 5
Section 4.2
Needed work: = What is a "name-record" ?  I can imagine a few different
meanings, which is the problem.  Is this a "registration" , i.e.= , the
mapping of the network object to an entity (set)? &nbs= p;Are associated
"name-records" like variants of IDNs?  = ;Are they related in a IP
hierarchy,
or somehow jointl= y registered objects?

I believe this t= ext came from John Klensin. My understanding of the meaning is that the term= refers to a row in a relational database. Would it be clearer to just say "= record" or "entry" instead of "name record"?
<= /span>

I’ll go with what was meant.  A= s a reader, my note is that the term may be a little too abstract.

Perhaps:

Conce=
ptually, a search-query-matching record in a database may be linked to an
   associated record, which may also be linked to another such
   record, and so on.
That is, if “linked to” is the right term.  Perhaps &#= 8220;associated with” (knowing that term is in the title).  Of pe= rhaps this

Conceptually, a search-query-matching record in a database may b=
e a member
of a set of one or more records associated with a regis=
tration event [if that’s
the appropriate grouping].

(Sorry about the formatting - I’ve lost control of ho= w this mail reader does formatting.)

I have a new comment coming from re-reading this section:
<= div style=3D"font-family: Calibri, sans-serif;">
If an implementation is t=
o return more than one
   name-record in response to a query, information from the records
   thereby identified is returned.
From that I would assume the draft is saying all asso= ciated records would be too - and later we talk about issues with authorizat= ion to release information.  I’d change the “is returned= 221; to “is subject to be included in a response (pending other consid= erations [and maybe cite the Security Considerations]).”
Oh, wait, that’s in the next paragraph.

Perhaps using the word “set” might make 4.2 work better.<= /div>

Uh, see below...
<= span id=3D"OLK_SRC_BODY_SECTION" style=3D"font-family: Calibri, sans-serif;">

Comment 6
Section 4.2 - later on
Confusion: It s= ounds here that a client cannot set up an expectation
that
<= div> it's query will return something specific or return a list, which is
bad
(meaning the client can’t set expectation).&nb= sp; A client ought to be able
to
know what it wil= l get back, even if it is an error.  What I mean is
're= turning information that was not explicitly selected by an exact-
= match
lookup' is ... is bothering me.
May= be these terms need to be ironed out better: search vs. lookup and
what
does match mean.  I do see match defined - after= it is used a few
times.
And in section 3.2, I first r= an into the confusion of search v. lookup.
(In the DN= S world, we distunguish this by saying DNS does not search,
it
does a lookup.)

Can you sugge= st appropriate text?

4.2.  Associated Recor=
ds

Conceptually, any query-matching record in the registry's database might be=
 a member of a set of related records, related in some fashion as defined by=
 the registry. (E.g., variants of an IDN.)  When constructing the response, =
the entire set ought to be considered as candidates for inclusion.  However,=
 the construction of the final response needs to be mindful of privacy and o=
ther data-releasing policies when assembling the RDAP response set.
Note too that due to the nature of searching, there may be a list of query= -matching records. Each one of those is subject to being a member of a set = as described in the previous paragraph. What is ultimately returned in a re= sponse will be the union of all the sets and be filtered by whatever policie= s are in place.
Comment 7
Section 5
Sugges= tion: this seems to be begging for a "standard" definition of an
= non-standard extension prefix - or everyone will use "custom_" because
=
that is the example here.  (Name collisions.)  And= if a custom one
becomes
a standard, can the transitio= n be eased?  (TXT to SPF issue.)  And how
do<= /div>
we encourage more standard and fewer uniques (the EPP[EXT] issue)= ?

Note the reference to Section 6 of t= he using-http document. It describes an IANA registry for these prefixes.

Then I’d change= this:

Custom path segments can be created by =
prefixing the segment with a
   unique identifier followed by an underscore character (0x5F).
=
To:
Custom path segments SHOULD be created by prefixing the segment with a unique identifier followed by an underscore character (0x5F).
(A one word change, “can” to “SHOULD”.)
<= div>
Comment 8
=
Section 6
Suggestion: Shouldn't RDA= P applications be considered to be IDNA2008
aware? The argument f= or this is in RFC 6912.  Or is that pressing a
policy
into the protocol needlessly?

One of the authors of RFC 6912 (Andrew Sullivan) was very helpful in devel= oping the text for this section. I would defer to his guidance.
Comment 9
=
Section 8
##  = ; Search functionality also increases the privacy risk of disclosing
##   object relationships that might not otherwise be obvious.=   For
##   example, a search that returns IDN= variants [RFC6927] that do not
##   explicitly match a= client-provided search pattern can disclose
##   infor= mation about registered domain names that might not be
otherwise<= /div>
##   available.  Implementers need to conside= r the policy and privacy
##   implications of returning= information that was not explicitly
##   requested.
I think this can improved by mentioning that implemente= rs need to
“consider policy and privacy implications, e.g.,= by checking for
authorization to release information to the requ= estor, in all cases and
especially here, when returning informati= on that was not explicitly
requested.”
In general, I’ve always been a little suspect on RDAP&#= 8217;s search ability
and
now carefully reading the la= st call documents am still a little shaky
on
it. =  Perhaps the word “search” to me has a wider definition tha= n is
being
applied here, where RDAP just looks for a c= ommon pre-amble (prefix,
starting string, whatever you want to ca= ll it).  I am aware of the
perils
of unicode= , sigh, but I wish there was a chance to have a search
definition= that was free of ASCII assumptions and was always mindful of
the= authorization to “release” information.
= I am aware I’m saying this very late in the game.  I’m= willing to
accept
the definition going forward as is.=   But I wanted to drop the comment
somewhere. &nbs= p;But please add in, where implementers “consider”, mention
of
the authorization model.  This is because I c= an see operators pulling
open
source tools for this fr= om the shelf, they won’t be handcrafting the
code,
and need some place to “configure this”.

How about this?

OLD:
"I= mplementers need to consider the policy and privacy implications of returnin= g information that was not explicitly requested."

N= EW:
"Implementers need to consider the policy and privacy implicat= ions of returning information that was not explicitly requested. Clients sho= uld only receive information that they are explicitly authorized to receive.= "

Almost…R= 21;Servers should only send information that clients are explicitly authoriz= ed to receive.”

The way it is worded is impos= sible to "enforce."


Scott

 --B_3496728908_122586-- --B_3496728908_163581 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTInYmNMK5sDxgZLagU PpgYnB85uDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MjExMzM1MDhaMA0GCSqGSIb3DQEBAQUABIIBACiO1y0OmA7TktYtVBQ3scrdfxk/vMpGCU3X BYOYzpZYFNTBNw9/shL7DjURZxDpEZN+0UsdPgH0JshZBMofolm5A+O4EpszIE3ry2cCjBs7 nSn5a0LG4XI0r8OSBrIagdedp4O6UwHXKSiDy61jJFD1uluGbavTtne8p/rXN7QWY5APHWvE rIrryaa5LY97k21Cd58U/2aGhuPlexUIw/Tla2jgINMuvPXeOu9hHMS5btq/ix9EzDB5uU54 KxDoNeYXh7tElOP1MBM60mJvTVfwjUFBIOhLOLgvJR34L9ZUK6A3qTUnpeGexpVHsF6Gu96I XHGQOhXpzjOcc0rV3b4= --B_3496728908_163581-- From nobody Tue Oct 21 06:48:15 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C861A6F49; Tue, 21 Oct 2014 06:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzDA0Jskf4sC; Tue, 21 Oct 2014 06:48:04 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A26F1A6F2B; Tue, 21 Oct 2014 06:48:04 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 21 Oct 2014 06:48:02 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 21 Oct 2014 06:48:02 -0700 From: Edward Lewis To: "Hollenbeck, Scott" , Sarah Banks , "" , "draft-ietf-weirds-rdap-query.all@tools.ietf.org" Thread-Topic: [weirds] OPS-DIR Review of draft-ietf-weirds-rdap-query Thread-Index: AQHP7TWh/IGDJFck0UqVjJPdfQ5vtw== Date: Tue, 21 Oct 2014 13:48:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3496729679_177175" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/tPKBV67-r1Hq7sJsAY0NtdRZzTQ Cc: "weirds@ietf.org" Subject: Re: [weirds] OPS-DIR Review of draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:48:09 -0000 --B_3496729679_177175 Content-type: multipart/alternative; boundary="B_3496729679_179022" --B_3496729679_179022 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable From: , Scott Date: Tuesday, October 21, 2014 at 8:14 To: Sarah Banks , "" , "draft-ietf-weirds-rdap-query.all@tools.ietf.org" Cc: "weirds@ietf.org" Subject: Re: [weirds] OPS-DIR Review of draft-ietf-weirds-rdap-query > Thanks for the review comments, Sarah. More below... >=20 > Scott >=20 >=20 >> -----Original Message----- >> From: Sarah Banks [mailto:sbanks@encrypted.net] >> Sent: Monday, October 20, 2014 9:43 PM >> To: ; draft-ietf-weirds-rdap-query.all@tools.ietf.org >> Subject: OPS-DIR Review of draft-ietf-weirds-rdap-query >> =20 >>=20 >> Overall, I found the document very easy to read through, walking >> through the problem it's trying to solve, addressing each add section >> by section, with discussion points for each, and examples for each, >> too. One minor (personal) nit, is the requirement that WHOIS servers >> that don't or can't respond to a request SHOULD return a 501 error >> (RFC7231). In trying to provide some structure, it'd be nice to know >> explicitly that the server has/had an issue responding to the request. >> If the server chooses not to return a 501 in the event of an error, >> then what? >=20 > Would anyone in the WG object to this being a MUST? That would address th= e > ambiguity. Assuming =E2=80=9CWHOIS server" -> =E2=80=9CRDAP server" in the above, yes, a MUST. --B_3496729679_179022 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable


From: <Hollenbeck>, Scott <shollenbeck@verisign.com>
Date: Tuesday, October 21, 2014 at 8:14
= To: Sarah Banks <sbanks@encrypted.net>, "<ops-dir@ietf.org>" <ops-dir@ietf.org>, "draft-ietf-weirds-rdap-query.all@tools.ietf.org" <<= a href=3D"mailto:draft-ietf-weirds-rdap-query.all@tools.ietf.org">draft-ietf-w= eirds-rdap-query.all@tools.ietf.org>
Cc: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] OPS-DIR Review of draft-ietf-weird= s-rdap-query

Thanks for the review comments, Sarah. More below...
=
Scott


-----Original Message-----
From:= Sarah Banks [mailto:sbanks@encrypted.= net]
Sent: Monday, October 20, 2014 9:43 PM
Subject: OPS-DIR Review of draft-ietf-= weirds-rdap-query

Overall, I found the document very= easy to read through, walking
through the problem it's trying to solve, addressi= ng each add section
by section, with discussion points for each, = and examples for each,
too. One minor (personal) nit, is the requ= irement that WHOIS servers
that don't or can't respond to a reque= st SHOULD return a 501 error
(RFC7231). In trying to provide some= structure, it'd be nice to know
explicitly that the server has/h= ad an issue responding to the request.
If the server chooses not = to return a 501 in the event of an error,
then what?

Would anyone in the WG object to this being a MUST= ? That would address the ambiguity.

=
Assuming “WHOIS server" -> = 220;RDAP server" in the above, yes, a MUST.

--B_3496729679_179022-- --B_3496729679_177175 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTqN11YEHcyEyi21LAl IQhUqRbjBDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MjExMzQ3NTlaMA0GCSqGSIb3DQEBAQUABIIBAJwQJmMUU9OQTF7UZJvsV02pz2y8JS+kiNPG z4A/YDZQJzvoo1j98S6l/iYk7PEyr28bwDR0EpRbXXesfAJ9qlWl1rsJLyNv4PLr2Fx68XEN 37Z/VB6fSzGgOFbC6oWv/vc/FE7ATTh8mG/rIdZeN06ekZOmbaiNgnpcXNqHZy9CVgjYohcJ q2BDwtJCuU51dB+oHSb96a3vrDsQHB9py/ZZGjVj06ZBrcz4oi+2Be4YfA1ernhGAN+Jlqa6 JymHbLbgILDTBIqbVEd7KhR4tGcm+e+AS9O/mnoicUxpFm3idOl0yQg3y5NvITgBkQpd+0IA WAhWt5LB7fFgUroJsIY= --B_3496729679_177175-- From nobody Tue Oct 21 11:39:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01361A87B1; Tue, 21 Oct 2014 11:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJz97G_eVUt4; Tue, 21 Oct 2014 11:39:10 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADEE1A87AC; Tue, 21 Oct 2014 11:38:46 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKVEaoNH2Jww5EHYyUxcM/cWrxyjOjyJa/@postini.com; Tue, 21 Oct 2014 11:39:06 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9LIchgA016483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 14:38:43 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 14:38:43 -0400 From: "Hollenbeck, Scott" To: Edward Lewis , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlit5w6fdGggABH2wCAAB2o0A== Date: Tue, 21 Oct 2014 18:38:43 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494F04AF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F494EFBE3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05AA_01CFED3C.B5D01F50" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/pWm_HIaU3FmDjSfoLtwrpLdcyyE Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:39:16 -0000 ------=_NextPart_000_05AA_01CFED3C.B5D01F50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_05AB_01CFED3C.B5D01F50" ------=_NextPart_001_05AB_01CFED3C.B5D01F50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I apologize in advance for anyone who has issues with HTML-formatted = messages. Don=E2=80=99t do that, Ed ;) =20 Scott =20 From: Edward Lewis [mailto:edward.lewis@icann.org]=20 Sent: Tuesday, October 21, 2014 9:35 AM To: Hollenbeck, Scott; ietf@ietf.org; iesg@ietf.org Cc: weirds@ietf.org; Andy Newton Subject: Re: Last Call: = (Registration Data Access Protocol Query Format) to Proposed Standard =20 A few =E2=80=9Ccomebacks=E2=80=9D in-line. =20 From: "Hollenbeck, Scott" Date: Tuesday, October 21, 2014 at 8:51 To: Edward Lewis , "ietf@ietf.org" = , "iesg@ietf.org" Cc: "weirds@ietf.org" , Andy Newton Subject: RE: Last Call: = (Registration Data Access Protocol Query Format) to Proposed Standard =20 -----Original Message----- From: Edward Lewis [mailto:edward.lewis@icann.org] Sent: Friday, October 17, 2014 12:02 PM To: ietf@ietf.org; iesg@ietf.org Cc: weirds@ietf.org; Hollenbeck, Scott; Andy Newton Subject: Re: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard =20 Thanks for the feedback, Ed. =20 A couple of comments Comment 1 Section 1.1 Nit: the detail on REST and RESTful seems out of place in a list of acronyms and abbreviations. =20 The "detail" is no more than a sentence or two. I'm inclined to leave = that nit alone. =20 Comment 2 Section 2 ## 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. Nit: should be "it is unlikely that a uniform approach ... is needed for interoperability." =20 Agreed. =20 Comment 3 Section 3.2 Confusion: domain/domains and entity/entities plural forms are defined externally to the list, but nameserver/nameservers plural form is not. I think that is just an inconstency. =20 I don't understand this comment. The text I'm looking at in Section 3.2 = includes search path segment definitions for "domains", "nameservers", = and "entities". The singular forms used for lookups are defined in = Section 3.1. What am I missing? =20 That in the bullets you have: o 'domains': ... o 'nameservers': ... o 'entities': =E2=80=A6 And in prose you have: For the domain and entity objects described in this document the plural = object forms are "domains" and "entities=E2=80=9D. Merely the mismatch in the =E2=80=9Cnumber of parameters=E2=80=9D (- the = prose doesn=E2=80=99t mention nameservers) =20 [SAH] OK, now I see that. Will fix. =20 The word ''match'' is used referring to a FQDN. Does this mean to imply ''match'' as defined in RFC 1034 (where '*' matches anything)? =20 Matching is described in Section 4.1. =20 The you have a =E2=80=9Cforward reference here - using = =E2=80=9Cmatch=E2=80=9D in 3.2 (and in the context of a = =E2=80=9Cfully-qualified domain name), then later in the document = defining it in 4.1. =20 I=E2=80=99ve seen this problem when implementers read the RFCs. They = might read 3.2 and assume match as defined in the DNS. Match is such an = overloaded term it deserves qualification (or an adjective). =20 [SAH] I=E2=80=99ll add a sentence for the forward reference to 4.1 =20 And what is throwing me is that this begins talking about testing to see if something exists and then seems to start talking about finding inexact matches (the plurals). It reads as if the first paragraph doesn't relate to the rest of the section. =20 Hmm, OK. That first paragraph (which describes using the HTTP HEAD = method to check for object existence) could be moved to Section 3.1. =20 Comment 4 Section 3.2.1 and 3.2.2 Confusion: Both 3.2.1 and 3.2.2 cover searching for name servers. Why are two approaches presented? http://example.com/rdap/nameservers?name=3Dns1.example*.com and http://example.com/rdap/domains?nsLdhName=3Dns1.example*.com I suppose this isn't a major issue, but seems awkward. =20 3.2.1 describes searching for *domains*. 3.2.2 describes searching for = *name servers*. =20 Then maybe the example =E2=80=9Cns1.example*.com=E2=80=9D ought to be = just "example*.com.=E2=80=9D? =20 [SAH] No. I assume you=E2=80=99re looking at the example in Section = 3.2.1. It describes a method of searching for domain information by name = server name, and in this case the name server name can be represented = with a pattern. As it says in the text, =E2=80=9CThe following URL would = be used to search for domains delegated to name servers matching the = "ns1.example*.com" pattern=E2=80=9D. =20 =20 Comment 5 Section 4.2 Needed work: What is a "name-record" ? I can imagine a few different meanings, which is the problem. Is this a "registration" , i.e., the mapping of the network object to an entity (set)? Are associated "name-records" like variants of IDNs? Are they related in a IP hierarchy, or somehow jointly registered objects? =20 I believe this text came from John Klensin. My understanding of the = meaning is that the term refers to a row in a relational database. Would = it be clearer to just say "record" or "entry" instead of "name record"? =20 I=E2=80=99ll go with what was meant. As a reader, my note is that the = term may be a little too abstract. =20 Perhaps: =20 Conceptually, a search-query-matching record in a database may be linked = to an associated record, which may also be linked to another such record, and so on. =20 That is, if =E2=80=9Clinked to=E2=80=9D is the right term. Perhaps = =E2=80=9Cassociated with=E2=80=9D (knowing that term is in the title). = Of perhaps this =20 Conceptually, a search-query-matching record in a database may be a = member of a set of one or more records associated with a registration event [if = that=E2=80=99s the appropriate grouping]. =20 (Sorry about the formatting - I=E2=80=99ve lost control of how this mail = reader does formatting.) =20 I have a new comment coming from re-reading this section: If an implementation is to return more than one name-record in response to a query, information from the records thereby identified is returned. >From that I would assume the draft is saying all associated records = would be too - and later we talk about issues with authorization to = release information. I=E2=80=99d change the =E2=80=9Cis = returned=E2=80=9D to =E2=80=9Cis subject to be included in a response = (pending other considerations [and maybe cite the Security = Considerations]).=E2=80=9D =20 Oh, wait, that=E2=80=99s in the next paragraph. =20 Perhaps using the word =E2=80=9Cset=E2=80=9D might make 4.2 work better. =20 Uh, see below... =20 Comment 6 Section 4.2 - later on Confusion: It sounds here that a client cannot set up an expectation that it's query will return something specific or return a list, which is bad (meaning the client can=E2=80=99t set expectation). A client ought to = be able to know what it will get back, even if it is an error. What I mean is 'returning information that was not explicitly selected by an exact- match lookup' is ... is bothering me. Maybe these terms need to be ironed out better: search vs. lookup and what does match mean. I do see match defined - after it is used a few times. And in section 3.2, I first ran into the confusion of search v. lookup. (In the DNS world, we distunguish this by saying DNS does not search, it does a lookup.) =20 Can you suggest appropriate text? =20 4.2. Associated Records =20 Conceptually, any query-matching record in the registry's database might = be a member of a set of related records, related in some fashion as = defined by the registry. (E.g., variants of an IDN.) When constructing = the response, the entire set ought to be considered as candidates for = inclusion. However, the construction of the final response needs to be = mindful of privacy and other data-releasing policies when assembling the = RDAP response set. Note too that due to the nature of searching, there may be a list of = query-matching records. Each one of those is subject to being a member = of a set as described in the previous paragraph. What is ultimately = returned in a response will be the union of all the sets and be filtered = by whatever policies are in place. =20 [SAH] I=E2=80=99m OK with this. =20 =20 Comment 7 Section 5 Suggestion: this seems to be begging for a "standard" definition of an non-standard extension prefix - or everyone will use "custom_" because that is the example here. (Name collisions.) And if a custom one becomes a standard, can the transition be eased? (TXT to SPF issue.) And how do we encourage more standard and fewer uniques (the EPP[EXT] issue)? =20 Note the reference to Section 6 of the using-http document. It describes = an IANA registry for these prefixes. =20 Then I=E2=80=99d change this: =20 Custom path segments can be created by prefixing the segment with a unique identifier followed by an underscore character (0x5F). To: Custom path segments SHOULD be created by prefixing the segment with a unique identifier followed by an underscore character (0x5F). (A one word change, =E2=80=9Ccan=E2=80=9D to =E2=80=9CSHOULD=E2=80=9D.) =20 [SAH] That would open up a different can of worms with respect to = =E2=80=9Cwhat if they don=E2=80=99t?=E2=80=9D questions. With no one = else pushing back on this point (at least not yet) I=E2=80=99d prefer to = not introduce a 2119 term here. =20 =20 Comment 8 Section 6 Suggestion: Shouldn't RDAP applications be considered to be IDNA2008 aware? The argument for this is in RFC 6912. Or is that pressing a policy into the protocol needlessly? =20 One of the authors of RFC 6912 (Andrew Sullivan) was very helpful in = developing the text for this section. I would defer to his guidance. =20 Comment 9 Section 8 ## Search functionality also increases the privacy risk of disclosing ## object relationships that might not otherwise be obvious. For ## example, a search that returns IDN variants [RFC6927] that do not ## explicitly match a client-provided search pattern can disclose ## information about registered domain names that might not be otherwise ## available. Implementers need to consider the policy and privacy ## implications of returning information that was not explicitly ## requested. I think this can improved by mentioning that implementers need to =E2=80=9Cconsider policy and privacy implications, e.g., by checking for authorization to release information to the requestor, in all cases and especially here, when returning information that was not explicitly requested.=E2=80=9D In general, I=E2=80=99ve always been a little suspect on RDAP=E2=80=99s = search ability and now carefully reading the last call documents am still a little shaky on it. Perhaps the word =E2=80=9Csearch=E2=80=9D to me has a wider = definition than is being applied here, where RDAP just looks for a common pre-amble (prefix, starting string, whatever you want to call it). I am aware of the perils of unicode, sigh, but I wish there was a chance to have a search definition that was free of ASCII assumptions and was always mindful of the authorization to =E2=80=9Crelease=E2=80=9D information. I am aware I=E2=80=99m saying this very late in the game. I=E2=80=99m = willing to accept the definition going forward as is. But I wanted to drop the comment somewhere. But please add in, where implementers = =E2=80=9Cconsider=E2=80=9D, mention of the authorization model. This is because I can see operators pulling open source tools for this from the shelf, they won=E2=80=99t be handcrafting = the code, and need some place to =E2=80=9Cconfigure this=E2=80=9D. =20 How about this? =20 OLD: "Implementers need to consider the policy and privacy implications of = returning information that was not explicitly requested." =20 NEW: "Implementers need to consider the policy and privacy implications of = returning information that was not explicitly requested. Clients should = only receive information that they are explicitly authorized to = receive." =20 Almost=E2=80=A6=E2=80=9DServers should only send information that = clients are explicitly authorized to receive.=E2=80=9D =20 The way it is worded is impossible to "enforce." =20 [SAH] OK! =20 Scott ------=_NextPart_001_05AB_01CFED3C.B5D01F50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I apologize = in advance for anyone who has issues with HTML-formatted messages. = Don=E2=80=99t do that, Ed ;)

 

Scott

 

From:= = Edward Lewis [mailto:edward.lewis@icann.org]
Sent: Tuesday, = October 21, 2014 9:35 AM
To: Hollenbeck, Scott; ietf@ietf.org; = iesg@ietf.org
Cc: weirds@ietf.org; Andy = Newton
Subject: Re: Last Call: = <draft-ietf-weirds-rdap-query-15.txt> (Registration Data Access = Protocol Query Format) to Proposed = Standard

 

A few = =E2=80=9Ccomebacks=E2=80=9D in-line.

 

From: "Hollenbeck, Scott" <shollenbeck@verisign.com>=
Date: Tuesday, October 21, 2014 at 8:51
To: Edward = Lewis <edward.lewis@icann.org>, = "ietf@ietf.org" <ietf@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Cc: = "weirds@ietf.org" = <weirds@ietf.org>, Andy = Newton <andy@arin.net>
Subject: = RE: Last Call: <draft-ietf-weirds-rdap-query-15.txt> = (Registration Data Access Protocol Query Format) to Proposed = Standard

 

-----Original = Message-----

From: Edward = Lewis [mailto:edward.lewis@icann.org]=

Sent: Friday, = October 17, 2014 12:02 PM

To: ietf@ietf.org; iesg@ietf.org

Cc: weirds@ietf.org; Hollenbeck, Scott; = Andy Newton

Subject: Re: = Last Call: = <draft-ietf-weirds-rdap-query-15.txt>

(Registration = Data Access Protocol Query Format) to Proposed = Standard

 

Thanks for the = feedback, Ed.

 

A couple of = comments

Comment = 1

Section = 1.1

Nit: the detail = on REST and RESTful seems out of place in a list = of

acronyms and = abbreviations.

 

The = "detail" is no more than a sentence or two. I'm inclined to = leave that nit alone.

 

Comment = 2

Section = 2

##   = 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.

Nit: should be = "it is unlikely that a uniform approach ... is = needed

for

interoperability= ."

 

Agreed.

 

Comment = 3

Section = 3.2

Confusion: = domain/domains and entity/entities plural forms are = defined

externally to = the list, but nameserver/nameservers plural form = is

not.  = I think that is just an = inconstency.

 

I don't = understand this comment. The text I'm looking at in Section 3.2 includes = search path segment definitions for "domains", = "nameservers", and "entities". The singular forms = used for lookups are defined in Section 3.1. What am I = missing?

 

That in the = bullets you have:

=C2=A0=C2=A0 o=C2=A0 'domains': =
...
=C2=A0=C2=A0 =
o=C2=A0 'nameservers': ...
=C2=A0=C2=A0 o=C2=A0 'entities': =
=E2=80=A6
And in prose =
you have:
For the domain and entity objects described in =
this document the plural object forms are "domains" and =
"entities=E2=80=9D.
Merely the =
mismatch in the =E2=80=9Cnumber of parameters=E2=80=9D (- the prose =
doesn=E2=80=99t mention nameservers)
 
[SAH] OK, now I see that. Will fix.
 

The word = ''match'' is used referring to a FQDN.  Does this mean = to

imply=

''match'' as = defined in RFC 1034 (where '*' matches = anything)?

 

Matching is = described in Section = 4.1.

 

The you have a = =E2=80=9Cforward reference here - using =E2=80=9Cmatch=E2=80=9D in 3.2 = (and in the context of a =E2=80=9Cfully-qualified domain name), then = later in the document defining it in = 4.1.

 

I=E2=80=99ve = seen this problem when implementers read the RFCs.  They might read = 3.2 and assume match as defined in the DNS.  Match is such an = overloaded term it deserves qualification (or an = adjective).

 

[SAH] = I=E2=80=99ll add a sentence for the forward reference to = 4.1

 

And what is = throwing me is that this begins talking about testing = to

see

if something = exists and then seems to start talking about = finding

inexact

matches (the = plurals).

It reads as if = the first paragraph doesn't relate to the rest of = the

section.

 

Hmm, OK. That = first paragraph (which describes using the HTTP HEAD method to check for = object existence) could be moved to Section = 3.1.

 

Comment = 4

Section 3.2.1 = and 3.2.2

Confusion: Both = 3.2.1 and 3.2.2 cover searching for name = servers.  Why

are

two approaches = presented?

and

I suppose this = isn't a major issue, but seems = awkward.

 

3.2.1 describes = searching for *domains*. 3.2.2 describes searching for *name = servers*.

 

Then maybe the = example =E2=80=9Cns1.example*.com=E2=80=9D ought to be just = "example*.com.=E2=80=9D?

 

[SAH] No. I = assume you=E2=80=99re looking at the example in Section 3.2.1. It = describes a method of searching for domain information by name server = name, and in this case the name server name can be represented with a = pattern. As it says in the text, =E2=80=9CThe following URL would be = used to search for domains delegated to name servers matching the = "ns1.example*.com" = pattern=E2=80=9D.

 

 

Comment = 5

Section = 4.2

Needed work: = What is a "name-record" ?  I can imagine a few = different

meanings, which = is the problem.  Is this a "registration" , i.e., = the

mapping of the = network object to an entity (set)?  Are = associated

"name-recor= ds" like variants of IDNs?  Are they related in a = IP

hierarchy,<= /o:p>

or somehow = jointly registered = objects?

 

I believe this = text came from John Klensin. My understanding of the meaning is that the = term refers to a row in a relational database. Would it be clearer to = just say "record" or "entry" instead of "name = record"?

 

I=E2=80=99ll go = with what was meant.  As a reader, my note is that the term may be = a little too abstract.

 

Perhaps:

 

Conceptually, a =
search-query-matching record in a database may be linked to =
an
=C2=A0=C2=A0 =
associated record, which may also be linked to another =
such
=C2=A0=C2=A0 record, and so =
on.
 

That is, if = =E2=80=9Clinked to=E2=80=9D is the right term.  Perhaps = =E2=80=9Cassociated with=E2=80=9D (knowing that term is in the title). =  Of perhaps this

 

Conceptually, a search-query-matching record in a =
database may be a member
of a set of one or more records associated with a =
registration event [if that=E2=80=99s
the appropriate =
grouping].
 
(Sorry about =
the formatting - I=E2=80=99ve lost control of how this mail reader does =
formatting.)

 

I have a new = comment coming from re-reading this = section:

If an implementation is to return more than =
one
=C2=A0=C2=A0 =
name-record in response to a query, information from the =
records
=C2=A0=C2=A0 thereby identified is =
returned.

From that I = would assume the draft is saying all associated records would be too - = and later we talk about issues with authorization to release = information.  I=E2=80=99d change the =E2=80=9Cis returned=E2=80=9D = to =E2=80=9Cis subject to be included in a response (pending other = considerations [and maybe cite the Security = Considerations]).=E2=80=9D

 

Oh, wait, = that=E2=80=99s in the next paragraph.

 

Perhaps using = the word =E2=80=9Cset=E2=80=9D might make 4.2 work = better.

 

Uh, see =
below...

 

Comment = 6

Section 4.2 - = later on

Confusion: It = sounds here that a client cannot set up an = expectation

that<= /span>

it's query will = return something specific or return a list, which = is

bad

(meaning the = client can=E2=80=99t set expectation).  A client ought to be = able

to

know what it = will get back, even if it is an error.  What I mean = is

'returning = information that was not explicitly selected by an = exact-

match=

lookup' is ... = is bothering me.

Maybe these = terms need to be ironed out better: search vs. lookup = and

what<= /span>

does match = mean.  I do see match defined - after it is used a = few

times.

And in section = 3.2, I first ran into the confusion of search v. = lookup.

(In the DNS = world, we distunguish this by saying DNS does not = search,

it

does a = lookup.)

 

Can you suggest = appropriate = text?

 

4.2.=C2=A0 =
Associated Records
 
Conceptually, any query-matching record in the =
registry's database might be a member of a set of related records, =
related in some fashion as defined by the registry. (E.g., variants of =
an IDN.)=C2=A0 When constructing the response, the entire set ought to =
be considered as candidates for inclusion.=C2=A0 However, the =
construction of the final response needs to be mindful of privacy and =
other data-releasing policies when assembling the RDAP response =
set.
Note too =
that due to the nature of searching, there may be a list of =
query-matching records.=C2=A0 Each one of those is subject to being a =
member of a set as described in the previous paragraph.=C2=A0 What is =
ultimately returned in a response will be the union of all the sets and =
be filtered by whatever policies are in =
place.
 
[SAH] I=E2=80=99m OK with this.
 

 

Comment = 7

Section = 5

Suggestion: = this seems to be begging for a "standard" definition of = an

non-standard = extension prefix - or everyone will use "custom_" = because

that is the = example here.  (Name collisions.)  And if a custom = one

becomes

a standard, can = the transition be eased?  (TXT to SPF issue.)  And = how

do

we encourage = more standard and fewer uniques (the EPP[EXT] = issue)?

 

Note the = reference to Section 6 of the using-http document. It describes an IANA = registry for these = prefixes.

 

Then = I=E2=80=99d change this:

 

Custom path =
segments can be created by prefixing the segment with =
a
=C2=A0=C2=A0 =
unique identifier followed by an underscore character =
(0x5F).
To:
Custom path segments SHOULD be created by =
prefixing the segment with a
=C2=A0=C2=A0 unique identifier followed by an =
underscore character (0x5F).

(A one word = change, =E2=80=9Ccan=E2=80=9D to = =E2=80=9CSHOULD=E2=80=9D.)

 

[SAH] That = would open up a different can of worms with respect to =E2=80=9Cwhat if = they don=E2=80=99t?=E2=80=9D questions. With no one else pushing back on = this point (at least not yet) I=E2=80=99d prefer to not introduce a 2119 = term here.

 

 

Comment = 8

Section = 6

Suggestion: = Shouldn't RDAP applications be considered to be = IDNA2008

aware? The = argument for this is in RFC 6912.  Or is that pressing = a

policy

into the = protocol needlessly?

 

One of the = authors of RFC 6912 (Andrew Sullivan) was very helpful in developing the = text for this section. I would defer to his = guidance.

 

Comment = 9

Section = 8

##   = Search functionality also increases the privacy risk of = disclosing

##   = object relationships that might not otherwise be = obvious.  For

##   = example, a search that returns IDN variants [RFC6927] that do = not

##   = explicitly match a client-provided search pattern can = disclose

##   = information about registered domain names that might not = be

otherwise

##   = available.  Implementers need to consider the policy and = privacy

##   = implications of returning information that was not = explicitly

##   = requested.

I think this = can improved by mentioning that implementers need = to

=E2=80=9Cconside= r policy and privacy implications, e.g., by checking = for

authorization = to release information to the requestor, in all cases = and

especially = here, when returning information that was not = explicitly

requested.=E2=80= =9D

In general, = I=E2=80=99ve always been a little suspect on RDAP=E2=80=99s search = ability

and

now carefully = reading the last call documents am still a little = shaky

on

it.  P= erhaps the word =E2=80=9Csearch=E2=80=9D to me has a wider definition = than is

being=

applied here, = where RDAP just looks for a common pre-amble = (prefix,

starting = string, whatever you want to call it).  I am aware of = the

perils

of unicode, = sigh, but I wish there was a chance to have a = search

definition that = was free of ASCII assumptions and was always mindful = of

the = authorization to =E2=80=9Crelease=E2=80=9D = information.

I am aware = I=E2=80=99m saying this very late in the game.  I=E2=80=99m = willing to

accept

the definition = going forward as is.  But I wanted to drop the = comment

somewhere. =  But please add in, where implementers =E2=80=9Cconsider=E2=80=9D, = mention

of

the = authorization model.  This is because I can see operators = pulling

open<= /span>

source tools = for this from the shelf, they won=E2=80=99t be handcrafting = the

code,=

and need some = place to =E2=80=9Cconfigure = this=E2=80=9D.

 

How about = this?

 

OLD:<= /span>

"Implemente= rs need to consider the policy and privacy implications of returning = information that was not explicitly = requested."

 

NEW:<= /span>

"Implemente= rs need to consider the policy and privacy implications of returning = information that was not explicitly requested. Clients should only = receive information that they are explicitly authorized to = receive."

<= p class=3DMsoNormal> 

Almost=E2=80=A6=E2= =80=9DServers should only send information that clients are explicitly = authorized to receive.=E2=80=9D

 

The way it is = worded is impossible to = "enforce."

 

[SAH] = OK!

 

Scott

------=_NextPart_001_05AB_01CFED3C.B5D01F50-- ------=_NextPart_000_05AA_01CFED3C.B5D01F50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISCzCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggeGMIIGbqADAgECAhBINamF8XD8u43P2ICxcxmGMA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDIxODAwMDAwMFoXDTE1MDIxODIzNTk1 OVowdjEnMCUGCSqGSIb3DQEJARYYc2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tMRowGAYDVQQDDBFI b2xsZW5iZWNrLCBTY290dDEWMBQGA1UECwwNRU5URVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNp Z24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4SzlP6x5P6I6j49cR7c7X exUgfitPoeKrE0MrgiRAnSdzCa69iwbk+uA15/fEDZR0ddwn0RPQ5+vIXV+pOEOlRk84znAyOOSh Iam8D0CiCOiNv28drXgq0HWRdp+cFw1MSihGdVntMcYMexVNvAeYGuU9gtC6afNVYVBjkWDfNzwy em3dYv04DfKtAJkCg4tIXh93uTpBsoS5IADJ4GtMPdwvTmXJ2ucHqMjHKYjdaC+pO/ebVv+RFnus ihDVQjX/oYwS8FqYYSNT+SwyMF35NVXcVl4uuMeHWD7/G65RnnvIz8B6vGQ7hTcLE35cEc31O0kR vSWgaNJKh8E6C+EtAgMBAAGjggO6MIIDtjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAW BgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4EFgQUVoVKaC1xEPB9EWKq3dWrwskIufkwTwYD VR0RBEgwRoEYc2hvbGxlbmJlY2tAdmVyaXNpZ24uY29toCoGCisGAQQBgjcUAgOgHAwac2hvbGxl bmJAdmNvcnAuYWQudnJzbi5jb20wHwYDVR0jBBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFx BggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUFBzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5j b20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8vZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUz RCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIwU2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlm aWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUzRCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0kl MjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUyMENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRy dXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUz RCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2kt Y3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVz dENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8v d3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29t L3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQME ARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUBEAMEHjAcBhJghkgBhvhFARABAgIBAYvxxgkWBjI0 NzY2NDA5BgpghkgBhvhFARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFD NWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQAEp6rtILYuQhcsKJhBBRYuzdb6psiNZdof/abX5TWf IiNqLDTmHg0FURIjUDORjN3A8pJPuDQve/VRDYGiorD/eTYV/1BC4vUoP6e4xOC79bfaKnTxeS6F L2CV7N5LtlutH7ybwx/y70zm3TM8QJAUNnKiYmEh6JruuMCEptTFlIQw9tWHsSd+YFEnFWplO1Bv wyMXEHgHj+ImUYqrmbcvBXzPfFzVSYWUffZWwFkhwtWnwmcNLokAOTpeqtg2X4XCdyQue1GNkckM Utc8fMO0PajcxEwBwuVNIUwDYi1w/3IrdgLjcxgEyuz6o11YENiN8AmnzekGV2iQrJaOF/UvMYIF BzCCBQMCAQEwgd4wgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5h Z2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNz IDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEg1qYXxcPy7jc/Y gLFzGYYwCQYFKw4DAhoFAKCCAv0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTQxMDIxMTgzODQyWjAjBgkqhkiG9w0BCQQxFgQUIAvaac8q2Koyq6Zz/tSIFaFR/Cgw gbcGCSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEW MAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQME AgEwCgYIKoZIhvcNAgUwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3Jr MTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFD MEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRl IEF1dGhvcml0eQIQSDWphfFw/LuNz9iAsXMZhjCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEg1qYXxcPy7jc/YgLFzGYYwDQYJKoZIhvcNAQEB BQAEggEATujTN7cVfMmDkZRQgCYu8J6x/C8Fbogp2S3qg+WDPFwloiW0IdFPm3VSNfpvJjf9HWxg W1UK9OR73XMP64tI6VPibWKhMDjhWZyzs9yUhNGLT2UqwA14Of0rA6KkH5nwGM9NCUDLReIuP6nJ XGlottF80MCcjvsibaWwIHXl3b0AsdasWaZnXBcM8oqmsa8Ej9oiE0Z6EfEnV60SQIp7JxtJfqJE Wah38cH32Q5NagiMU5WMf2rTEspkmTzNuOMp228snkxmRL+aBCBabFnWnI9D80US771huiitaLPS UW+46GEiqeJr8p+wfEfFFhtMtMjWzIFo8f67MZKDZZHUbgAAAAAAAA== ------=_NextPart_000_05AA_01CFED3C.B5D01F50-- From nobody Tue Oct 21 14:06:45 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E391A871D for ; Tue, 21 Oct 2014 14:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvNEMORKFp3v; Tue, 21 Oct 2014 14:06:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 357051A8717; Tue, 21 Oct 2014 14:06:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-object-inventory@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021210638.10565.49799.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 14:06:38 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/1Pvcea7FeC_h4N_uwRJZcY2RwUk Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:06:43 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ From nobody Tue Oct 21 14:07:04 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882BC1A8722 for ; Tue, 21 Oct 2014 14:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWHCSMeTknKj; Tue, 21 Oct 2014 14:06:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F78B1A8711; Tue, 21 Oct 2014 14:06:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-using-http@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021210639.10565.20885.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 14:06:39 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/OWy1dpF-s4fdxhyt_VcO1CzifKs Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:06:51 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ From nobody Tue Oct 21 16:29:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57691A8824 for ; Tue, 21 Oct 2014 16:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tlHhFuUfAHi for ; Tue, 21 Oct 2014 16:28:53 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CDA1A87DB for ; Tue, 21 Oct 2014 16:28:51 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kq14so2405415pab.6 for ; Tue, 21 Oct 2014 16:28:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uFy4qY780ew3G9N70qEY9HVJPYa6rmnBb+hTVa/pSXQ=; b=UGAo5hRSS8Gq1vG8M4Uv4EYhfjdvwL5yIe+xd0tZHR5AsOMttTVVA/D1Igt9OWDBvl k4j1g5wTVUll689gr0ZQiszjgjaayQlfM6m9mhJhMZP1Znu/zKGvFWlBeTXlfB3sUvZE wZ9KRkMrfMbrgoWxEQufv4Y+ZKV2S/Osmp7Y1GNd+bIQiXn7XiTvm7s1oeLH1AptuHFw enLjB/7fZhKyMlhpSQWWekvbaN3l/udJIE6Ceim/e7DcQ6kXNmRxuvCVQpsA7GLS4CRJ 0LeLq3I/I+gX1cBsE39CDdPQgrceOE5byyZskTJhTxBme4eqv9B1y+siWnaJNMl3eDko w4TQ== X-Gm-Message-State: ALoCoQnpNtirUAXNQ3U2MmSw7JKssA8z454R3paH8gSMPaefkaDtGOz6wMIzjP5r0xruBOsP1nnM MIME-Version: 1.0 X-Received: by 10.68.177.164 with SMTP id cr4mr5919789pbc.142.1413934131624; Tue, 21 Oct 2014 16:28:51 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Tue, 21 Oct 2014 16:28:51 -0700 (PDT) X-Originating-IP: [71.191.38.92] In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494F04AF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F494EFBE3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494F04AF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Tue, 21 Oct 2014 19:28:51 -0400 Message-ID: From: Andrew Newton To: "Hollenbeck, Scott" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/3LOrR_vd_k775_wOJKYNgalvnlg Cc: Edward Lewis , "weirds@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 23:28:54 -0000 On Tue, Oct 21, 2014 at 2:38 PM, Hollenbeck, Scott wrote: > Note the reference to Section 6 of the using-http document. It describes = an > IANA registry for these prefixes. > ... > > > [SAH] That would open up a different can of worms with respect to =E2=80= =9Cwhat if > they don=E2=80=99t?=E2=80=9D questions. With no one else pushing back on = this point (at > least not yet) I=E2=80=99d prefer to not introduce a 2119 term here. I agree with Scott, especially given the reference to Section 6 of draft-ietf-weirds-using-http. -andy From nobody Tue Oct 21 16:33:21 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9865C1A8824 for ; Tue, 21 Oct 2014 16:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIyaL12SQX_7 for ; Tue, 21 Oct 2014 16:33:17 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651E41A87DB for ; Tue, 21 Oct 2014 16:33:17 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id kx10so2406668pab.37 for ; Tue, 21 Oct 2014 16:33:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fHHTRZvQGo5RxPQz0dtVw418G063t2n3EyqwiMp96fc=; b=TEQU1j88wvU+z2Nvx/4HBbCGR7y2z61QYFVfyhcQ4hhs3lYMmIF0TcdWncIL27QpDV Yz0xf5ECZulb40wFXui9TAXdlk/TiyH3YI0gZfW1EzgAIUJXn8uZoLAcfrB7XtNO/McZ e02dVNhyNlkY2YEyDhXINHxAS1gfbjCGE15t8PbXrZqoDavqLMZpCUgrOHHQ1Y0Lre6y PjABtDoiTVkcXdjYahXPgmFdfptHT9ShpjkKKt27eCYi53lqtydZ2Ka5crrdFuwOXjx1 PY9OEaIV2PrREPsyBh9lngsfmCf1ZWoLZ/unLeeRXwqM9zb9LsPI6Q8QjK/1iuklPPMT oUGA== X-Gm-Message-State: ALoCoQlc9LR4m7KrYVAHfde2aFYKG611C/+LvOWR1O8VVWkVSXcjwOZJ8Ss4b5FEGxSr3abjCVoj MIME-Version: 1.0 X-Received: by 10.68.176.98 with SMTP id ch2mr383837pbc.150.1413934397007; Tue, 21 Oct 2014 16:33:17 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Tue, 21 Oct 2014 16:33:16 -0700 (PDT) X-Originating-IP: [71.191.38.92] In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494EF91C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <7594FB04B1934943A5C02806D1A2204B1D4AF4C2@ESESSMB209.ericsson.se> <831693C2CDA2E849A7D7A712B24E257F494EF91C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Tue, 21 Oct 2014 19:33:16 -0400 Message-ID: From: Andrew Newton To: "Hollenbeck, Scott" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/jeANT73CiNoB0urzhpy-FtMbmis Cc: "weirds@ietf.org" Subject: Re: [weirds] FW: Gen-ART review of draft-ietf-weirds-rdap-sec-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 23:33:18 -0000 On Tue, Oct 21, 2014 at 6:50 AM, Hollenbeck, Scott wrote: > =E2=80=9CWeb services such as RDAP commonly use HTTP Over T= LS > [RFC2818] to provide that protection by encrypting all > > traffic sent on the connection between client and server.= =E2=80=9D > > > > To me that sounds like something from a BCP document. I thi= nk > you should say that the document defines > > the usage of HTTP over TLS for providing the security service. > > [SAH] OK. I can change the sentence to =E2=80=9CRDAP SHOULD use HTTP Over= TLS > [RFC2818] to provide that protection by encrypting all traffic sent on th= e > connection between client and server=E2=80=9D. I=E2=80=99m sure there are= people who will > suggest that MUST is better than SHOULD, but that adds a requirement that > hasn=E2=80=99t been discussed in the WG. WG chairs =E2=80=93 what do you = think? Not a wg chair, but I'm fine with this change. -andy From nobody Tue Oct 21 16:42:59 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D111A8839; Tue, 21 Oct 2014 16:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1vfg49o6qov; Tue, 21 Oct 2014 16:42:53 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5641A8843; Tue, 21 Oct 2014 16:42:49 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id D62B61651D2; Tue, 21 Oct 2014 19:42:48 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 471F01651BE; Tue, 21 Oct 2014 19:42:48 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 21 Oct 2014 19:45:24 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Tue, 21 Oct 2014 19:42:47 -0400 From: Andy Newton To: "Hollenbeck, Scott" , Sarah Banks , "" , "draft-ietf-weirds-rdap-query.all@tools.ietf.org" Thread-Topic: [weirds] OPS-DIR Review of draft-ietf-weirds-rdap-query Thread-Index: AQHP7NBs2/V2colaR06q1vYLArlwrJw6uqOAgAB9JwA= Date: Tue, 21 Oct 2014 23:42:46 +0000 Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494EFB20@BRN1WNEXMBX01.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.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <9058092C0CD238448D989AF508283E71@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/sWpqg49HStCR80gks03z3XZNVNc Cc: "weirds@ietf.org" Subject: Re: [weirds] OPS-DIR Review of draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 23:42:55 -0000 On 10/21/14, 8:14 AM, "Hollenbeck, Scott" wrote: >> Overall, I found the document very easy to read through, walking >> through the problem it's trying to solve, addressing each add section >> by section, with discussion points for each, and examples for each, >> too. One minor (personal) nit, is the requirement that WHOIS servers >> that don't or can't respond to a request SHOULD return a 501 error >> (RFC7231). In trying to provide some structure, it'd be nice to know >> explicitly that the server has/had an issue responding to the request. >> If the server chooses not to return a 501 in the event of an error, >> then what? > >Would anyone in the WG object to this being a MUST? That would address >the ambiguity. Well, servers that cannot respond to a request (501 - Not Implemented) and wish to convey that information MUST use a 501. So.. OLD If a server receives a query that it cannot process because it is not implemented it SHOULD return an HTTP 501 [RFC7231 ] error. NEW A server MUST return an HTTP 501 (Not Implemented) [RFC7231] to inform a client of unsupported queries. -andy From nobody Tue Oct 21 17:01:06 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82151A8848; Tue, 21 Oct 2014 17:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJiqibQPVnvz; Tue, 21 Oct 2014 17:01:00 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5C81A884C; Tue, 21 Oct 2014 17:01:00 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id D55DF21378E; Tue, 21 Oct 2014 20:00:59 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 4A4DA21378A; Tue, 21 Oct 2014 20:00:57 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 21 Oct 2014 20:03:33 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Tue, 21 Oct 2014 20:00:56 -0400 From: Andy Newton To: "Hollenbeck, Scott" , "weirds@ietf.org" , Brian E Carpenter Thread-Topic: [weirds] FW: Gen-ART Last Call review of draft-ietf-weirds-rdap-query-15 Thread-Index: AQHP7YtAoX6wbNXirke522jeQzAwJQ== Date: Wed, 22 Oct 2014 00:00:56 +0000 Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494EF902@BRN1WNEXMBX01.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.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <91A90A6CD3D01A41873CCE473BCFE814@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/EdZ_GMYEF-Ag5QscfpWf2W7bMgY Cc: General Area Review Team Subject: Re: [weirds] FW: Gen-ART Last Call review of draft-ietf-weirds-rdap-query-15 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:01:02 -0000 On 10/21/14, 6:49 AM, "Hollenbeck, Scott" wrote: >>Major Issues: >> ------------- >>=20 >> Section 3.1.1 says: >>=20 >> "The restricted >> rules to write a text representation of an IPv6 address [RFC5952] >> are >> not mandatory." >>=20 >> Why not make 5952 at least a SHOULD? Personally, I would make it a >> MUST. As 5952 itself states, >> the ambiguity of the RFC 4291 format creates many problems. 5952 in any >> case requires that >> "all implementations must accept and be able to handle any legitimate >> RFC 4291 format", >> so making conformance with 5952 a SHOULD or MUST won't break anything. >>=20 Thanks for pointing out that sentence from 5952. Given that, though I don=B9t see a MUST has helpful and in fact it might be confusing. My recommendation is: OLD Any valid IPv6 text address format [RFC4291] can be used, compressed or not compressed. The restricted rules to write a text representation of an IPv6 address [RFC5952 ] are not mandatory. NEW Any valid IPv6 text address format [RFC4291] can be used The rules to write a text representation of an IPv6 address [RFC5952] are RECOMMENDED. >> Minor issues: >> ------------- >>=20 >> Section 3.1.1 says: >>=20 >> "However, the zone id [RFC4007] is not appropriate in >> this context and therefore prohibited." >>=20 >> Agreed, but you probably also need to exclude the extended URI syntax >> for this [RFC6874], >> since your base reference is the URI syntax [RFC3986] which is updated >> by 6874. >> This is just for clarification, since 6874 does not change the ABNF >> production >> for IPv6address. Do you mean that we should change the reference of IPv6address from RFC 3986 to RFC 6874? If so, that=B9s a good suggestion and I agree. Otherwise, I=B9m confused. -andy From nobody Tue Oct 21 17:10:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED411A8852; Tue, 21 Oct 2014 17:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjHN-oRg5ax9; Tue, 21 Oct 2014 17:10:00 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 074EE1A884B; Tue, 21 Oct 2014 17:10:00 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id B313B213790; Tue, 21 Oct 2014 20:09:59 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id B802321378A; Tue, 21 Oct 2014 20:09:48 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 21 Oct 2014 20:11:43 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Tue, 21 Oct 2014 20:09:47 -0400 From: Andy Newton To: Edward Lewis , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: [weirds] Last Call: (JSON Responses for the Registration Data Access Protocol (RDAP)) to Proposed Standard Thread-Index: AQHP5Nm9WdxGEwIyRkam9UqgzrbtU5w03IoAgAZyuoA= Date: Wed, 22 Oct 2014 00:09:47 +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.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: multipart/alternative; boundary="_000_D06C6D0F30F47andyarinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/INqHl_LLJ-e3dMaXUF-xxYzBC_4 Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (JSON Responses for the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:10:09 -0000 --_000_D06C6D0F30F47andyarinnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Edward Lewis > Date: Friday, October 17, 2014 at 1:41 PM To: "ietf@ietf.org" >, "iesg@ietf.org" > Cc: "weirds@ietf.org" >, Andrew Newton >, Scott Ho= llenbeck > Subject: Re: [weirds] Last Call: (= JSON Responses for the Registration Data Access Protocol (RDAP)) to Propose= d Standard Just two nits: Comment 1 In section 5.2 the term/phrase =93first-class=94 as in "name server model= =94 is used twice but never defined. I don=92t have a suggested fix. It=92s a generic term of art. Do we really want to be defining it in RFCs? http://en.wikipedia.org/wiki/First-class_citizen Comment 2 While looking for something else, I noted one use of =93secure DNSSEC=94 in= section 14, probably meant =93secure DNS=94 there. Yup. Will fix. -andy --_000_D06C6D0F30F47andyarinnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7EE59415428A5F4DB0EDF1B966064A9C@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: Edward Lewis <edward.lewis@icann.org>
Date: Friday, October 17, 2014 at 1= :41 PM
To: "ietf@ietf.org" <ietf@i= etf.org>, "iesg@ietf.org&q= uot; <iesg@ietf.org>
Cc: "weirds@ietf.org" <= weirds@ietf.org>, Andrew Newton <andy@arin.net>, Scott Hollenbeck <shollenbeck@verisign.com>
Subject: Re: [weirds] Last Call: &l= t;draft-ietf-weirds-json-response-10.txt> (JSON Responses for the Regist= ration Data Access Protocol (RDAP)) to Proposed Standard

Just two nits:

Comment 1

In section 5.2 the term/phrase =93first-class=94 as in "name serv= er model=94 is used twice but never defined.

I don=92t have a suggested fix.

It=92s a generic term of art. Do we really want to be defining it in R= FCs?
http://en.wikipedia.org/wiki/First-class_citizen


Comment 2

While looking for something else, I noted one use of =93secure DNSSEC= =94 in section 14, probably meant =93secure DNS=94 there.

Yup. Will fix.

-andy
--_000_D06C6D0F30F47andyarinnet_-- From nobody Tue Oct 21 17:34:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FF71A8875 for ; Tue, 21 Oct 2014 17:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFi18q7f81sR for ; Tue, 21 Oct 2014 17:34:04 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF9A1A8883 for ; Tue, 21 Oct 2014 17:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=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: mime-version; bh=RayItf4D6mjI68gZSjZ8C/skgL7ok5/5f70eGeH8P0g=; b=LysOP+S9r/nhbkrLdGGJdVShAuzxf2G7GOlYuMMDyzfN93PbDdNEg2tIB2RppQ84/4sG2YCmhwliI vOwX3pTKPYHB+YO9eRp6aNB6+XCUfuc/wBuTAh5ZdMCVak+yFl67bSlxwvYzJdj68AUDoFuH9y41XX 3GpFywwi/A6G5pqw= Received: from iamda3.org.apnic.net (unknown [203.119.101.249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Wed, 22 Oct 2014 10:35:17 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by iamda3.org.apnic.net ([fe80::e195:c0e8:e814:db75%15]) with mapi id 14.01.0218.012; Wed, 22 Oct 2014 10:34:00 +1000 From: Byron Ellacott To: Edward Lewis , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard Thread-Index: AQHP5NinvmioUaVn20quxX6sWYfH95wzuGcAgAedooA= Date: Wed, 22 Oct 2014 00:33:59 +0000 Message-ID: References: <20141010222207.8413.95671.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3496818837_387975" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/-vymq8CeQtmRveo3XCy9wMEzyng Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:34:06 -0000 --B_3496818837_387975 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Responses inline... On 18/10/2014 12:15 am, "Edward Lewis" wrote: >Comment 1 >--------- > >Section 1. > >## The registration data expected to be presented by this service is >## Internet resource registration data - registration of domain names >## and Internet number resources. These data is typically provided by > >Nit: ''These data is'': >Perhaps - remove the =8C=B9The'' to start the paragraph and then ''Such data >are'' >for the Nit. (Treat =8C=B9data'' consistently as singular or plural.) Good catch. I suspect "These data is" was meant to be "This data is", using "data" as a collective noun. I agree with removing 'The', but personally prefer "This data is". >Comment 2 >--------- > >Section 3. > >Nit: ''meant to return only one path of execution'' - perhaps ''follow one >path''? How would s/return/require/ work for you? The notion is that a protocol matching this design intent would not lead to clients having branching or tree searching operations, so for me "follow one path" describes a client behaviour more than a protocol expectation. >Comment 3 >--------- > > >Section 5.6. > > >Nit: ''As the use of RDAP is for public resources'' is a judgement call. >Suggest >rewording as ''When RDAP is for public resources, a value of =8C*=B9. . .'' I agree with the premise of this nit. The entire sentence then reads: When RDAP is for public resources, a value of "*" is suitable for most cases. How about something a little less tortuous: A value of "*" is suitable when RDAP is used for public resources. >Comment 5 >--------- > >Section 7. > >Nit: ''It does require the RDAP clients MUST support HTTPS.'' >Nit: ''This document made'' should be ''This document makes'' =3D> "It does require that RDAP clients MUST support HTTPS." And agree on made =3D> makes. >Comment 7 > >--------- > > >Appendix B > >Nit: ''this is unlikely to have any known side effects'' - suggest ''this >will be[/ought to be] compatible with the RDAP definition.'' How about we be more assertive: "... this is compatible with the RDAP definition." Thanks for looking over the doc closely! --=20 bje --B_3496818837_387975 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR9gYJKoZIhvcNAQcCoIIR5zCCEeMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg+lMIIEATCCAumgAwIBAgIIU8lOAPvGhFEwDQYJKoZIhvcNAQEFBQAwczERMA8GA1UE AwwIc3RhZmYtY2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0 ZDERMA8GA1UEBwwIQnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUw HhcNMTMxMTEyMDU1MTQ3WhcNMTQxMTEyMDU1MTQ3WjCBkTETMBEGCgmSJomT8ixkAQEMA2Jq ZTEXMBUGA1UEAwwOQnlyb24gRWxsYWNvdHQxDjAMBgNVBCoMBUJ5cm9uMREwDwYDVQQEDAhF bGxhY290dDEPMA0GA1UECwwGUGVvcGxlMRYwFAYDVQQKDA1BUE5JQyBQdHkgTHRkMRUwEwYK CZImiZPyLGQBGRYFc3RhZmYwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9g/bQ CW31VKtGJAohgHr6wPUdspn5CG+/bDoPzlWB8vGqaPuKgF7MMzpiPY/gRtAI+I4c+UuhLqkl fDcHaRy6yZ3DDZZKE34D7OjoVfXJ7CxgEWi6KqygM2CyNY2t5nPy2e1a+BpLvW14Mn1lTB/J sBNigQJInuDMBjfgwVT68GkftAn4AmeygK33NOqbEbGidLtraHtpeP4Zwukd0HUVfyvVieol OzHeoSbIBHV/ooUrvkzL4c9NBhtaedV3klxkiYLSoVE9UcBvfMQqJdQnJMD+O+jpZT98xeDR bauFGwG15LeMa0deN6hTF04MmUdx87eq9vuIj/ezUcLwqpBtAgMBAAGjejB4MB0GA1UdDgQW BBRz5RndxQ/sYkGsGs8TdPAsGfkInTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFOA9t5Jb 7i6jsj5520WrMEIvAUusMA4GA1UdDwEB/wQEAwIB8jAYBgNVHREEETAPgQ1iamVAYXBuaWMu bmV0MA0GCSqGSIb3DQEBBQUAA4IBAQAU9kKxyg8CJ7zW9x+krey9Z4MBw56lNnvYRk2DnKYq OZoaXSa9MOXeXhZPgWmM8h0KGNgEObhyBzn5M7wRs5tCctQ3dnhlvw8WngukjPBFHR6VRkBt 13pxsQXjXjnsQknvRTPbpl+xEosbt1FKm2ugUZwt3Yiti4MMPA+/GLi/VaFBKSszTFqDly3k bbqcR7fuQRDOJtdr9QEDze214KHFh9ZPERbL7rtP0j0Vdv6Uw55vWvdjMwgSDzACc0PG+vU+ XrRmbRk0OjHI5R8Y8VwbEjm4vp8FDD/KGmED8mtN6Z6X5wOXs4NNTJlK+K2jh0lq9FCFTOKz VceANfKAB+jlMIIDyjCCArKgAwIBAgIIPavsDCZph2UwDQYJKoZIhvcNAQEFBQAwcjEQMA4G A1UEAwwHcm9vdC1jYTESMBAGA1UECwwJVGVjaG5pY2FsMRYwFAYDVQQKDA1BUE5JQyBQdHkg THRkMREwDwYDVQQHDAhCcmlzYmFuZTESMBAGCgmSJomT8ixkARkWAmNhMQswCQYDVQQGEwJB VTAeFw0xMDA1MTEwNDI4MDNaFw0xNTA1MTEwNDI4MDNaMHMxETAPBgNVBAMMCHN0YWZmLWNh MRIwEAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcM CEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0MiEFmgY2iWFOPCjkaRv0Ff06eogTjGFtQpPyTV0Dzer kNG60lssN/M6Io3zUWdt64mKMrAejxAwAzj6Elb9+MYtcx4bbk8PTpoBfuS7IX+fhIlnVidk 6njCuJhgO8S2nlYe3FJolYGtGDOhBijx8JEULdAX5M8O2KNA7foASbLRjWE6iRHqmz2z3tVP x79sZ+sTeRdHNYssa6kzT74/HYDcYKa+fEjiR6yVWnmVkjxQt11VfSwZepuOVx0eKlAXcySV g7uCVff+WkAm6mjfKT7E4Im76D8ZWRQASXzpVNA8pHvNSdG6S7MInvSHpmNBPBgTaVW18yKv r0zHxrfSvwIDAQABo2MwYTAdBgNVHQ4EFgQU4D23klvuLqOyPnnbRaswQi8BS6wwDwYDVR0T AQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRu2kzqvVxnb1LABqSlYmK/QEEVMjAOBgNVHQ8BAf8E BAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAKBcAtk35emwWXdNiLiXxRvBK8YytCDv/pJiKU6u bn1yhajPVt9ZXqxgY1GcufsZBJVoG22TbkWod3+ZAk2umEr5zpqNwRgJIEun7VL6T5m6XduL CGtfmQWa3ooM38kuakI3yVSNxdTOxsE14NAHrr/PhDmgQTDrOcMx3vGBCAWpLDV/Ou8z/eFU GR6Kpr/Otjo/eBvbLGYOUzl8RP15vCj4Qesx/IzXlfDEXPZtQdcjajhqwiTGBV82UFIHafsw FoX+mJesQH94fV+r4mZmwF+rEQyvTJqZzPVCkshmsNw1Vpbl1aB5JWmg+aqeYHa2rBDr/nI3 3cIGPgiJ37Xg7BwwggPJMIICsaADAgECAghQOd4DcnbzyzANBgkqhkiG9w0BAQUFADByMRAw DgYDVQQDDAdyb290LWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0 eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYT AkFVMB4XDTEwMDIxMjAwMzYyN1oXDTIwMDIxMjAwMzYyN1owcjEQMA4GA1UEAwwHcm9vdC1j YTESMBAGA1UECwwJVGVjaG5pY2FsMRYwFAYDVQQKDA1BUE5JQyBQdHkgTHRkMREwDwYDVQQH DAhCcmlzYmFuZTESMBAGCgmSJomT8ixkARkWAmNhMQswCQYDVQQGEwJBVTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAORqBZ2SPEqL3tvK1hlfR1AxbJM26Ncfu38xbrcHfiRQ AFH0zCSJVw2pFrSWzZwhvEOaiPlXqmVhr+HqkXDw36b8M6qlUX2Ib0zX05IB9vQ4U+gICaRm 8suxNiCU5tdKQKlVc9443QfF6LxCDm2dObC0mKTmpNaSQu7N5I/84QnHqDW2GrtOvGWdKflS iUG6BIDdUPiTy5VqgS6PRDGn0s93f3IkYQAuewz5q+i16O50b9bcFZdrdAB+kYdeM1Zxhsif c542BD8tvIGGAGgY+8m0Kg9Uh5sVOhIIRn2gWz4fjHsb9vAu667tTy3qZpWzgvbwK41Wa0TK NaXuCDmAPScCAwEAAaNjMGEwHQYDVR0OBBYEFG7aTOq9XGdvUsAGpKViYr9AQRUyMA8GA1Ud EwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUbtpM6r1cZ29SwAakpWJiv0BBFTIwDgYDVR0PAQH/ BAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQCqsByEzfjFsVWigcWbJRtHMg9a3oxirtu4lQ92 MOkxq8rr3rLsb0fMc2jIa8c/TOcsEetoj4KXUacNX/VeJFUulHuqQ+qwz/4RbsybgJAjKzzR 3NLF5yPT/eOsnKVRrU5OEOvtIr/BNLQFN9UqLmqZ2DvD1h4dFDHFqSFXTibkGWqyBcoDGkps guZvFYpUxqvIFMSWG6XjEF0kwu9JybkQ05fuaGHMvzphI8uiQA2CjKiZuWZEpNTbcIl594Ia i4UHDhgubyhxnUHVRwA9FJf6bPTkcCYPSqPagWuZ2eVoBrq0zdZHPnH+TfViM8Y8KeDPH/XQ Wqg9dsyrD30Mb+/5MIIEATCCAumgAwIBAgIIDkqMnA4YPYUwDQYJKoZIhvcNAQEFBQAwczER MA8GA1UEAwwIc3RhZmYtY2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMg UHR5IEx0ZDERMA8GA1UEBwwIQnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UE BhMCQVUwHhcNMTIxMTIxMDIzNDIyWhcNMTMxMTIxMDIzNDIyWjCBkTETMBEGCgmSJomT8ixk AQEMA2JqZTEXMBUGA1UEAwwOQnlyb24gRWxsYWNvdHQxDjAMBgNVBCoMBUJ5cm9uMREwDwYD VQQEDAhFbGxhY290dDEPMA0GA1UECwwGUGVvcGxlMRYwFAYDVQQKDA1BUE5JQyBQdHkgTHRk MRUwEwYKCZImiZPyLGQBGRYFc3RhZmYwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDSnSR4X1j0LS0PgEKd5Acn7pKKdXu4ADSviSt82+GTMi5FJvZYeYZD/GrtLCcA4YLXYO5/ RiGsog+9K5Q2bwJkV9gzFuld/yyc3fAma5j1c3VeT55I7qEmNJ0XgGWVjKGxAq7wEQTknFgm JVUqi8v3BxM6x06GSL9rbgN5zUeo8yucJU8W/bLtK1sULnw5GwxiNgYAm/w5Fe+Q3t88ojBd 7RHgSjalRzjVJMkFgSx8PL7d/lTv51Y/i0+FpxgiykQdcV76M2ggZAz+8N+eUlhnMW8snhll ZI5JDQGyegV5ETaBr43LcXytzoDAuOZr8Dh0cMINnM8A79XwI6Ogcq4JAgMBAAGjejB4MB0G A1UdDgQWBBRXo+moVw1om/WEdvGht2udbPP9PTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FOA9t5Jb7i6jsj5520WrMEIvAUusMA4GA1UdDwEB/wQEAwIB8jAYBgNVHREEETAPgQ1iamVA YXBuaWMubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQCG835gbKnnV8dR53Tx19TYkyd/TE1TGCmP gobp6CRq2gIu4envtpDBhH8HhH+9Rf2AUCguxEKA1jBCMKkt3pW59JNNXfYMlVMAPA0ARiEO 4aUiWD9GLme9M6jErqJhvU4b880MniKDl2FHN0pGc42k7u9AMBMbL8XB3xaoiwIbNBrt1j5E RCOTWVsk7XuuO/2XBr7ZVZru1pzuZl9sNDK/LnJ5ND/+waHv+IKrz+uu3mATNyhzax76VjSC u/HMXo0ziUOnpSg9Th1LpNcFsMUM7+41jSrHM7At96pLx1PDAHhaEw7KKnEiIbXYqv4oM+tc iqJ2yGvqMcNaGde4EhTMMYICFTCCAhECAQEwfzBzMREwDwYDVQQDDAhzdGFmZi1jYTESMBAG A1UECwwJVGVjaG5pY2FsMRYwFAYDVQQKDA1BUE5JQyBQdHkgTHRkMREwDwYDVQQHDAhCcmlz YmFuZTESMBAGCgmSJomT8ixkARkWAmNhMQswCQYDVQQGEwJBVQIIU8lOAPvGhFEwDQYJYIZI AWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgY/LzzwDnvyjwNTAq8yC0TXj4m5K6d6wrvmDu IEn5k18wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQxMDIy MDAzMzU3WjANBgkqhkiG9w0BAQEFAASCAQBRwRuz+4gtjepohWffkTTZ0Zxs6kQ/wba2Dfin CR7Q9Gx0/Lu3whB879g/cLaC64J18LX3F51BGF53g9KTOsyP4iAKSOIaYxz5Yc4VwB+ZL5jO W2XWW0VcLR5aAzIzYMz7VLH4J79UBjT1/a/MN9/FQU6huBDVK4uCt/zIEGjkrsg1H3dzi4pW 3yU2p7zR42FwYdlyF7htbxYBKuxZhyunGiKdj2EJZF4kzCwDZDOM6P0LNiO8/itbpcyA+GMl JT5kbqGOHYx4DHNSqE6B9nYhth78Rlp/L70bqQgfrvxNFeU0MaiK6twfn3W7h7kPkqZMp6y/ rvwjp7/DKSCPrksq --B_3496818837_387975-- From nobody Tue Oct 21 21:49:25 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33BA1A88A7; Tue, 21 Oct 2014 17:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh14VGsbwtUa; Tue, 21 Oct 2014 17:39:32 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D711A88AE; Tue, 21 Oct 2014 17:39:24 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id et14so2513498pad.31 for ; Tue, 21 Oct 2014 17:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dLUkPyJ6iTqPdyi8mLm7HOfoZTLRAHago+vUG3Qzmh4=; b=EsSPes938ZWmcdLZlzSk8+G0bNBFMZ9DKg0rsW0pZL2wVINnL61GGQHM7vGGuIT4Mc 42peitJagvgIhhXhvJHoOkfMgjtnir3qNNwTzYTkVbukAS72gqMfXtwArTLg3yqbNq0w Zox0OeP8g2xSH5kilqjS429WNXZGk6YB7KhyPqYfEcpfRWn2BbJzFuFM92HUwpyA6Q9l BngnlsD3LIefrD4OsLvuTfZKaxITV61F0NgIcbtkGRz9Ntiewr8JRP7gqN/ctYyh6pud vEgu56AOC4wog/5+GYRbAklIwqmx2ag7sjXZMxznZICj2kGoMkCNuh028QMRkqDa+uL/ grIA== X-Received: by 10.66.221.163 with SMTP id qf3mr3227945pac.39.1413938364170; Tue, 21 Oct 2014 17:39:24 -0700 (PDT) Received: from [192.168.178.23] (176.199.69.111.dynamic.snap.net.nz. [111.69.199.176]) by mx.google.com with ESMTPSA id ow7sm12839945pbc.30.2014.10.21.17.39.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 17:39:23 -0700 (PDT) Message-ID: <5446FCBD.60805@gmail.com> Date: Wed, 22 Oct 2014 13:39:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/uWPrL2qvxXrrheQ6d3ObC_cY74w X-Mailman-Approved-At: Tue, 21 Oct 2014 21:49:23 -0700 Cc: General Area Review Team , "weirds@ietf.org" Subject: Re: [weirds] FW: Gen-ART Last Call review of draft-ietf-weirds-rdap-query-15 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:39:34 -0000 Andy, On 22/10/2014 13:00, Andy Newton wrote: > On 10/21/14, 6:49 AM, "Hollenbeck, Scott" wr= ote: >=20 >>> Major Issues: >>> ------------- >>> >>> Section 3.1.1 says: >>> >>> "The restricted >>> rules to write a text representation of an IPv6 address [RFC5952] >>> are >>> not mandatory." >>> >>> Why not make 5952 at least a SHOULD? Personally, I would make it a >>> MUST. As 5952 itself states, >>> the ambiguity of the RFC 4291 format creates many problems. 5952 in a= ny >>> case requires that >>> "all implementations must accept and be able to handle any legitimate= >>> RFC 4291 format", >>> so making conformance with 5952 a SHOULD or MUST won't break anything= =2E >>> >=20 > Thanks for pointing out that sentence from 5952. Given that, though I > don=C2=B9t see a MUST has helpful and in fact it might be confusing. My= > recommendation is: >=20 > OLD >=20 > Any valid IPv6 text address format [RFC4291] can be used, compressed = or > not compressed. The restricted > rules to write a text representation of an IPv6 address [RFC5952 > ] are > not mandatory. >=20 > NEW >=20 > Any valid IPv6 text address format [RFC4291] can be used The rules to= > write a text representation of an > IPv6 address [RFC5952] are RECOMMENDED. >=20 Yes, I'm fine with that. >=20 >=20 >>> Minor issues: >>> ------------- >>> >>> Section 3.1.1 says: >>> >>> "However, the zone id [RFC4007] is not appropriate in >>> this context and therefore prohibited." >>> >>> Agreed, but you probably also need to exclude the extended URI syntax= >>> for this [RFC6874], >>> since your base reference is the URI syntax [RFC3986] which is update= d >>> by 6874. >>> This is just for clarification, since 6874 does not change the ABNF >>> production >>> for IPv6address. >=20 >=20 > Do you mean that we should change the reference of IPv6address from RFC= > 3986 to RFC 6874? If so, that=C2=B9s a good suggestion and I agree. Oth= erwise, > I=C2=B9m confused. 6874 slightly extends the syntax in 3986, but you want to explicitly exclude that extension. So I think this would cover it: OLD: The IPv4 and IPv6 address formats supported in this query are described in section 3.2.2 of [RFC3986], as IPv4address and IPv6address ABNF definitions. Any valid IPv6 text address format [RFC4291] can be used, compressed or not compressed. The restricted rules to write a text representation of an IPv6 address [RFC5952] are not mandatory. However, the zone id [RFC4007] is not appropriate in this context and therefore prohibited. NEW: The IPv4 and IPv6 address formats supported in this query are described in section 3.2.2 of [RFC3986], as IPv4address and IPv6address ABNF definitions. Any valid IPv6 text address format [RFC4291] can be used, compressed or not compressed. The rules to write a text representation of an IPv6 address [RFC5952] are RECOMMENDED. However, the zone id [RFC4007] is not appropriate in this context and therefore the corresponding syntax extension in [RFC6874] MUST NOT be used. (I sort of feel obliged to apologise, since there has been confusion in this area since RFC 2732, although the root problem was the choice of the colon in both IPv6 address syntax and URI syntax.) Brian From nobody Tue Oct 21 21:51:17 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFB61A8A9B for ; Tue, 21 Oct 2014 21:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekUWJ0QrG8Fs for ; Tue, 21 Oct 2014 21:51:15 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26481A8A9F for ; Tue, 21 Oct 2014 21:51:11 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so2207456lab.41 for ; Tue, 21 Oct 2014 21:51:10 -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=YLMJC+nAU8Vzu+s9Vh4s6hIcKXpqzYx4JnZ3XZwAP38=; b=G7WAN5G/92LoQnbbJiyBiwaRnc68tAanzl23SZGGBRFDCa8kKELfHIf7QZH5JqDmxI ehu7JN/hqvBEsg8ieI8uUwyvXVUFSxUt18cnxi8+GX2WLY8+NQCCl4JMiQk2w+N+Tb8H GmXvCeeWGwCSidDtaAO1hC/WDRKmWBajm1G7LR1Pp8+8IVfIVsemP//Fv9UXWCum1GiD f4NTI3IdW2Taqil3gRneHLMrnsXlDFYOkPzDf/5ofnyTjE4IMQU50eIIZ7KikoO/F9BZ nY1FUAZ5sTFQFiGpAsrPtEMzzGtpd2x4ReM5KjTF24/Ko9Xh1A0kCQJy1XPkLDc+Y88i T2Dg== MIME-Version: 1.0 X-Received: by 10.152.45.2 with SMTP id i2mr8299277lam.7.1413953470238; Tue, 21 Oct 2014 21:51:10 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Tue, 21 Oct 2014 21:51:10 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D4AF4C2@ESESSMB209.ericsson.se> <831693C2CDA2E849A7D7A712B24E257F494EF91C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Tue, 21 Oct 2014 21:51:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Newton Content-Type: multipart/alternative; boundary=001a11c1b51252aa590505fbb2df Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/AkjhLWtupRq38CcvyuRTP8blQWA Cc: "weirds@ietf.org" Subject: Re: [weirds] FW: Gen-ART review of draft-ietf-weirds-rdap-sec-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 04:51:16 -0000 --001a11c1b51252aa590505fbb2df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 21, 2014 at 4:33 PM, Andrew Newton wrote: > On Tue, Oct 21, 2014 at 6:50 AM, Hollenbeck, Scott > wrote: > > =E2=80=9CWeb services such as RDAP commonly use HTTP Over= TLS > > [RFC2818] to provide that protection by encrypting all > > > > traffic sent on the connection between client and server.= =E2=80=9D > > > > > > > > To me that sounds like something from a BCP document. I > think > > you should say that the document defines > > > > the usage of HTTP over TLS for providing the security service. > > > > [SAH] OK. I can change the sentence to =E2=80=9CRDAP SHOULD use HTTP Ov= er TLS > > [RFC2818] to provide that protection by encrypting all traffic sent on > the > > connection between client and server=E2=80=9D. I=E2=80=99m sure there a= re people who will > > suggest that MUST is better than SHOULD, but that adds a requirement th= at > > hasn=E2=80=99t been discussed in the WG. WG chairs =E2=80=93 what do yo= u think? > > Not a wg chair, but I'm fine with this change. > How about changing "SHOULD use" to simply "uses"? -MSK --001a11c1b51252aa590505fbb2df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 21, 2014 at 4:33 PM, Andrew Newton <andy@hxr.us> wrote:
On Tue, Oct 21, 2014 at = 6:50 AM, Hollenbeck, Scott
<shollenbeck@verisign.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=9CWeb ser= vices such as RDAP commonly use HTTP Over TLS
> [RFC2818] to provide that protection by encrypting all
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0traffic sent on = the connection between client and server.=E2=80=9D
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To me that sound= s like something from a BCP document. I think
> you should say that the document defines
>
> the usage of HTTP over TLS for providing the security service.
>
> [SAH] OK. I can change the sentence to =E2=80=9CRDAP SHOULD use HTTP O= ver TLS
> [RFC2818] to provide that protection by encrypting all traffic sent on= the
> connection between client and server=E2=80=9D. I=E2=80=99m sure there = are people who will
> suggest that MUST is better than SHOULD, but that adds a requirement t= hat
> hasn=E2=80=99t been discussed in the WG. WG chairs =E2=80=93 what do y= ou think?

Not a wg chair, but I'm fine with this change.
<= div>
--001a11c1b51252aa590505fbb2df-- From nobody Wed Oct 22 04:12:40 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77251A8F3F; Wed, 22 Oct 2014 04:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cItpcjVx81aw; Wed, 22 Oct 2014 04:12:25 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1023D1A8AED; Wed, 22 Oct 2014 04:12:25 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 22 Oct 2014 04:12:21 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Wed, 22 Oct 2014 04:12:21 -0700 From: Edward Lewis To: Byron Ellacott , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard Thread-Index: AQHP5Ni/5FUUmZIO10SIXwNWQzinhpw0klIAgAc5EoCAAG9DAA== Date: Wed, 22 Oct 2014 11:12:20 +0000 Message-ID: References: <20141010222207.8413.95671.idtracker@ietfa.amsl.com> 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.4.5.141003 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3496806732_1940658" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/sAHAgKAQ_y0egz3uYvfoSyCUaX4 Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 11:12:29 -0000 --B_3496806732_1940658 Content-type: multipart/alternative; boundary="B_3496806732_1943453" --B_3496806732_1943453 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable As I=E2=80=99m a proven HTTP-in-email idiot and I think I can get away with this, I=E2=80=99ll top post my answers. Comment 1 - I=E2=80=99m as happy with data begin singular as well as plural, so l= ong as it=E2=80=99s consistent. So, using the singular form is fine here. Comment 2 - Yes, =E2=80=98require=E2=80=99 works. For the rest - I agree with all of the offered fixes. From: Byron Ellacott Date: Tuesday, October 21, 2014 at 20:33 To: Edward Lewis , "ietf@ietf.org" = , "iesg@ietf.org" Cc: "weirds@ietf.org" , Andy Newton , "nkong@cnnic.cn" Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard > Responses inline... >=20 > On 18/10/2014 12:15 am, "Edward Lewis" wrote: >=20 >> Comment 1 >> --------- >>=20 >> Section 1. >>=20 >> ## The registration data expected to be presented by this service is >> ## Internet resource registration data - registration of domain names >> ## and Internet number resources. These data is typically provided b= y >>=20 >> Nit: ''These data is'': >> Perhaps - remove the =C2=8C=C2=B9The'' to start the paragraph and then ''Such da= ta >> are'' >> for the Nit. (Treat =C2=8C=C2=B9data'' consistently as singular or plural.) >=20 > Good catch. I suspect "These data is" was meant to be "This data is", > using "data" as a collective noun. I agree with removing 'The', but > personally prefer "This data is". >=20 >> Comment 2 >> --------- >>=20 >> Section 3. >>=20 >> Nit: ''meant to return only one path of execution'' - perhaps ''follow o= ne >> path''? >=20 > How would s/return/require/ work for you? The notion is that a protocol > matching this design intent would not lead to clients having branching or > tree searching operations, so for me "follow one path" describes a client > behaviour more than a protocol expectation. >=20 >> Comment 3 >> --------- >>=20 >>=20 >> Section 5.6. >>=20 >>=20 >> Nit: ''As the use of RDAP is for public resources'' is a judgement call. >> Suggest >> rewording as ''When RDAP is for public resources, a value of =C2=8C*=C2=B9. . .'= ' >=20 > I agree with the premise of this nit. The entire sentence then reads: >=20 > When RDAP is for public resources, a value of "*" is suitable for most > cases. >=20 > How about something a little less tortuous: >=20 > A value of "*" is suitable when RDAP is used for public resources. >=20 >> Comment 5 >> --------- >>=20 >> Section 7. >>=20 >> Nit: ''It does require the RDAP clients MUST support HTTPS.'' >> Nit: ''This document made'' should be ''This document makes'' >=20 > =3D> "It does require that RDAP clients MUST support HTTPS." >=20 > And agree on made =3D> makes. >=20 >> Comment 7 >>=20 >> --------- >>=20 >>=20 >> Appendix B >>=20 >> Nit: ''this is unlikely to have any known side effects'' - suggest ''thi= s >> will be[/ought to be] compatible with the RDAP definition.'' >=20 > How about we be more assertive: >=20 > "... this is compatible with the RDAP definition." >=20 > Thanks for looking over the doc closely! >=20 > --=20 > bje >=20 --B_3496806732_1943453 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
As I’m a proven HTTP-in= -email idiot and I think I can get away with this, I’ll top post my an= swers.

Comment 1 - I’m as happy with data beg= in singular as well as plural, so long as it’s consistent.  So, u= sing the singular form is fine here.
Comment 2 - Yes, ‘requi= re’ works.

For the rest - I agree with all of= the offered fixes.

From: Byron Ellacott <bje@apnic.net>= ;
Date: Tuesday, October 21, 2014 = at 20:33
To: Edward Lewis <edward.lewis@icann.org>, "ietf@ietf.org" <ietf@ietf.org>, "iesg@ietf.org" = <iesg@ietf.org>
Cc: "weirds@ietf.org= " <weirds@ietf.org>, Andy New= ton <andy@arin.net>, "nkong@cnnic.cn" <n= kong@cnnic.cn>
Subject: Re:= [weirds] Last Call: <draft-ietf-weirds-using-http-13.txt> (HTTP usage= in the Registration Data Access Protocol (RDAP)) to Proposed Standard

=
Responses inline...

On 18/10/2014 12:15 am, "E= dward Lewis" <edward.lewis@icann.= org> wrote:

Comment 1
---------

Sectio= n 1.

##    The registration dat= a expected to be presented by this service is
##   =  Internet resource registration data - registration of domain names
##    and Internet number resources.  T= hese data is typically provided by

Nit: ''These dat= a is'':
Perhaps - remove the =C2=8C=C2=B9The'' to start the paragraph and = then ''Such data
are''
for the Nit. (Treat =C2=8C=C2=B9data'' co= nsistently as singular or plural.)

Goo= d catch.  I suspect "These data is" was meant to be "This data is"= ,
using "data" as a collective noun.  I agree with remov= ing 'The', but
personally prefer "This data is".

Comment 2
-= --------

Section 3.

Nit: '= 'meant to return only one path of execution'' - perhaps ''follow one
path''?

How would s/return/require/= work for you?  The notion is that a protocol
matching t= his design intent would not lead to clients having branching or
tr= ee searching operations, so for me "follow one path" describes a client
behaviour more than a protocol expectation.

Comment 3
---------<= /div>


Section 5.6.


Nit: ''As the use of RDAP is for public resources'' is a ju= dgement call.
Suggest
rewording as ''When RDAP is for pu= blic resources, a value of =C2=8C*=C2=B9. . .''

I agree with the premise of this nit.  The entire sentence then = reads:

When RDAP is for public resources, a value o= f "*" is suitable for most
cases.

How abo= ut something a little less tortuous:

A value of "*"= is suitable when RDAP is used for public resources.

Comment 5
-------= --

Section 7.

Nit: ''It do= es require the RDAP clients MUST support HTTPS.''
Nit: ''This docu= ment made'' should be ''This document makes''

=3D> "It does require that RDAP clients MUST support HTTPS."
<= div>
And agree on made =3D> makes.

Comment 7

=
---------


Appendix B
=
Nit: ''this is unlikely to have any known side effects'' - su= ggest ''this
will be[/ought to be] compatible with the RDAP defini= tion.''

How about we be more assertive= :

"... this is compatible with the RDAP definition.= "

Thanks for looking over the doc closely!

--
bje

--B_3496806732_1943453-- --B_3496806732_1940658 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSHoDES5ryJ+wAd1HU8 xIOowIXJazAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MjIxMTEyMTJaMA0GCSqGSIb3DQEBAQUABIIBAMdmqVvRCq8F+kuJTp3xjn5REgS1SHpM3HUa sIf2hyyKgc+JBdwdbghPFTVpqx4a6PeFiJSfxEVIaV8SH0C917bXUCghWSK70mlk4argzrCZ e3oWe9Ps5YacJvV7MwNVC2PiKQKOLZvaif0INQcxItu0IeUKcWSr4jqgW9Rn6knc5FzTtikE E8YTzPQVf/TlymhDxrNwa6XCMqy93oiWwGb7J8kZVODAtNAUuu0j1kIPbZtCMHZy3XxyByCl jFWhS96M10lJVaJMT/fy15U1BgXipuPG1+S0p1DPeYgJiN4vYGhKbDEW6HkUQEeKdanxGzvQ 6bS3Me9Ec4sSt4bMVeY= --B_3496806732_1940658-- From nobody Wed Oct 22 06:47:18 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DF51ABD35; Wed, 22 Oct 2014 06:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da969gCBYMWU; Wed, 22 Oct 2014 06:47:11 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AB11A9239; Wed, 22 Oct 2014 06:46:59 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKVEe1UshHzT37Nzqqy4cmLAErYs8vX44D@postini.com; Wed, 22 Oct 2014 06:47:10 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9MDkvrU029266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 09:46:57 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 09:46:57 -0400 From: "Hollenbeck, Scott" To: Bert Greevenbosch , "draft-ietf-weirds-rdap-sec.all@tools.ietf.org" , "'iesg@ietf.org'" <'iesg@ietf.org'>, "apps-discuss@ietf.org" Thread-Topic: Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 Thread-Index: AQHP7dOraLlEMb/T9k2LS8+NEgKgD5w8Hmfw Date: Wed, 22 Oct 2014 13:46:56 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494F1417@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <46A1DF3F04371240B504290A071B4DB63E779CE3@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E779CE3@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/GSolpZJ-XSDMyLkQDxPu-AFWBu8 Cc: "weirds@ietf.org" Subject: Re: [weirds] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:47:12 -0000 > -----Original Message----- > From: Bert Greevenbosch [mailto:Bert.Greevenbosch@huawei.com] > Sent: Wednesday, October 22, 2014 4:39 AM > To: draft-ietf-weirds-rdap-sec.all@tools.ietf.org; 'iesg@ietf.org'; > apps-discuss@ietf.org > Subject: Applications Area Directorate Review of draft-ietf-weirds- > rdap-sec-09 >=20 > Document: draft-ietf-weirds-rdap-sec-09 > Title: Finding the Authoritative Registration Data (RDAP) Service > Reviewer: Bert Greevenbosch > Review Date: 22 October 2014 > IETF Last Call Date: 24 October 2014 > IESG Telechat Date: 30 October 2014 > Summary: May need an edit. >=20 > Major Issues: >=20 > None >=20 > Minor Issues: >=20 > None >=20 > Nits: >=20 > (n1) 3.3, it would be nice to replace "a 429 response code" by "a 429 > (Too many Requests) response code". Thanks for the feedback, Bert. You're probably right, but since this is a n= it I'd prefer to leave the text as-is to maintain consistency with other RD= AP documents that describe HTTP response codes without using parenthetical = text to describe the meaning of the code. We have normative references in t= he appropriate places to do that. Scott From nobody Wed Oct 22 06:51:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F301AC3A1; Wed, 22 Oct 2014 06:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTy5-rqtftYv; Wed, 22 Oct 2014 06:51:31 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id BCBE01ABD3C; Wed, 22 Oct 2014 06:51:31 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 66C76165190; Wed, 22 Oct 2014 09:51:31 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id A2329165196; Wed, 22 Oct 2014 09:51:30 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 22 Oct 2014 09:53:23 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Wed, 22 Oct 2014 09:51:30 -0400 From: Andy Newton To: Brian E Carpenter Thread-Topic: [weirds] Gen-ART Last Call review of draft-ietf-weirds-rdap-query-15 Thread-Index: AQHP7f9HNSROZyKYc02WW6AZV6KlBA== Date: Wed, 22 Oct 2014 13:51:28 +0000 Message-ID: <89CBD605-9A68-4683-9BEA-38F8CB6486F5@arin.net> References: <5446FCBD.60805@gmail.com> In-Reply-To: <5446FCBD.60805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: multipart/alternative; boundary="_000_89CBD6059A6846839BEA38F8CB6486F5arinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/QFvT28Y7IBCX737dvlTfKkBw9m8 Cc: General Area Review Team , "weirds@ietf.org" Subject: Re: [weirds] Gen-ART Last Call review of draft-ietf-weirds-rdap-query-15 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:51:33 -0000 --_000_89CBD6059A6846839BEA38F8CB6486F5arinnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 21, 2014, at 8:39 PM, Brian E Carpenter > wrote: 6874 slightly extends the syntax in 3986, but you want to explicitly exclude that extension. So I think this would cover it: OLD: The IPv4 and IPv6 address formats supported in this query are described in section 3.2.2 of [RFC3986], as IPv4address and IPv6address ABNF definitions. Any valid IPv6 text address format [RFC4291] can be used, compressed or not compressed. The restricted rules to write a text representation of an IPv6 address [RFC5952] are not mandatory. However, the zone id [RFC4007] is not appropriate in this context and therefore prohibited. NEW: The IPv4 and IPv6 address formats supported in this query are described in section 3.2.2 of [RFC3986], as IPv4address and IPv6address ABNF definitions. Any valid IPv6 text address format [RFC4291] can be used, compressed or not compressed. The rules to write a text representation of an IPv6 address [RFC5952] are RECOMMENDED. However, the zone id [RFC4007] is not appropriate in this context and therefore the corresponding syntax extension in [RFC6874] MUST NOT be used. Thanks. That=92s great. (I sort of feel obliged to apologise, since there has been confusion in this area since RFC 2732, although the root problem was the choice of the colon in both IPv6 address syntax and URI syntax.) :) It was collective oversight. Thanks for your review. This is good stuff. -andy --_000_89CBD6059A6846839BEA38F8CB6486F5arinnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 21, 2014, at 8:39 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

6874 slightly extends the syntax in 3986, but you want to explicitly
exclude that extension. So I think this would cover it:

OLD:

  The IPv4 and IPv6 address formats supported in this query are   described in section 3.2.2 of [RFC3986], as IPv4address and
  IPv6address ABNF definitions.  Any valid IPv6 text address= format
  [RFC4291] can be used, compressed or not compressed.  The = restricted
  rules to write a text representation of an IPv6 address [RFC595= 2] are
  not mandatory.  However, the zone id [RFC4007] is not appr= opriate in
  this context and therefore prohibited.

NEW:

  The IPv4 and IPv6 address formats supported in this query are   described in section 3.2.2 of [RFC3986], as IPv4address and
  IPv6address ABNF definitions.  Any valid IPv6 text address= format
  [RFC4291] can be used, compressed or not compressed.  The<= br>   rules to write a text representation of an IPv6 address [RFC595= 2] are
  RECOMMENDED.  However, the zone id [RFC4007] is not approp= riate in
  this context and therefore the corresponding syntax extension   in [RFC6874] MUST NOT be used.


Thanks. That=92s great.

(I sort of feel obliged to apologise, since there has been confusion
in this area since RFC 2732, although the root problem was the choice
of the colon in both IPv6 address syntax and URI syntax.)

:) It was collective oversight. Thanks for your review. This is good s= tuff.

-andy
--_000_89CBD6059A6846839BEA38F8CB6486F5arinnet_-- From nobody Wed Oct 22 06:55:51 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D0A1AC3A8; Wed, 22 Oct 2014 06:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fa_JKsXSjWe; Wed, 22 Oct 2014 06:55: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 3385D1AC3AE; Wed, 22 Oct 2014 06:55:42 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id E323F21378A; Wed, 22 Oct 2014 09:55:41 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 361B521378F; Wed, 22 Oct 2014 09:55:41 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 22 Oct 2014 09:57:34 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Wed, 22 Oct 2014 09:55:40 -0400 From: Andy Newton To: Scott Hollenbeck Thread-Topic: [weirds] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 Thread-Index: AQHP7dOraLlEMb/T9k2LS8+NEgKgD5w8HmfwgABIuIA= Date: Wed, 22 Oct 2014 13:55:39 +0000 Message-ID: <2FC7374A-6DF3-49F8-9FDD-8E8ADDCAA15A@arin.net> References: <46A1DF3F04371240B504290A071B4DB63E779CE3@SZXEMA510-MBX.china.huawei.com> <831693C2CDA2E849A7D7A712B24E257F494F1417@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494F1417@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: multipart/alternative; boundary="_000_2FC7374A6DF349F89FDD8E8ADDCAA15Aarinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/M2sWLnlokqj0T0i0uwdxRld6FfE Cc: "draft-ietf-weirds-rdap-sec.all@tools.ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:55:47 -0000 --_000_2FC7374A6DF349F89FDD8E8ADDCAA15Aarinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 22, 2014, at 9:46 AM, Hollenbeck, Scott > wrote: n1) 3.3, it would be nice to replace "a 429 response code" by "a 429 (Too many Requests) response code". Thanks for the feedback, Bert. You're probably right, but since this is a n= it I'd prefer to leave the text as-is to maintain consistency with other RD= AP documents that describe HTTP response codes without using parenthetical = text to describe the meaning of the code. We have normative references in t= he appropriate places to do that. Scott, Bert has made the same comment on using-http, so the parentheticals will ap= pear in our other documents. I view it as a readability thing, not necessar= ily a normative reference issue. -andy --_000_2FC7374A6DF349F89FDD8E8ADDCAA15Aarinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 22, 2014, at 9:46 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

n1) 3.3, it would be nice to replace "a 429 response code" by &qu= ot;a 429
(Too many Requests) response code".

Thanks for the feedback, Bert. You're probably right, but since this is a nit I'd= prefer to leave the text as-is to maintain consistency with other RDAP doc= uments that describe HTTP response codes without using parenthetical text t= o describe the meaning of the code. We have normative references in the appropriate places to do that.<= br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo= nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh= t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo= rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex= t-stroke-width: 0px;">

Scott,

Bert has made the same comment on using-http, so the parentheticals wi= ll appear in our other documents. I view it as a readability thing, not nec= essarily a normative reference issue.

-andy
--_000_2FC7374A6DF349F89FDD8E8ADDCAA15Aarinnet_-- From nobody Wed Oct 22 07:03:33 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866381AC3B5; Wed, 22 Oct 2014 07:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h66DrwAPHwrH; Wed, 22 Oct 2014 07:03:29 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FF91AC3B0; Wed, 22 Oct 2014 07:03:23 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKVEe5K1vcFP4MZkY0iekkMXbYos4mdqyD@postini.com; Wed, 22 Oct 2014 07:03:29 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9ME34Ja018825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 10:03:04 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 10:03:04 -0400 From: "Hollenbeck, Scott" To: Andy Newton Thread-Topic: [weirds] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 Thread-Index: AQHP7dOraLlEMb/T9k2LS8+NEgKgD5w8HmfwgABIuID//76wkA== Date: Wed, 22 Oct 2014 14:03:03 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494F1506@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <46A1DF3F04371240B504290A071B4DB63E779CE3@SZXEMA510-MBX.china.huawei.com> <831693C2CDA2E849A7D7A712B24E257F494F1417@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2FC7374A-6DF3-49F8-9FDD-8E8ADDCAA15A@arin.net> In-Reply-To: <2FC7374A-6DF3-49F8-9FDD-8E8ADDCAA15A@arin.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_831693C2CDA2E849A7D7A712B24E257F494F1506BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Qcdkl4DYcRIipxfwkLXVH_Tcx9Q Cc: "draft-ietf-weirds-rdap-sec.all@tools.ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:03:32 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F494F1506BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Andy Newton [mailto:andy@arin.net] Sent: Wednesday, October 22, 2014 9:56 AM To: Hollenbeck, Scott Cc: Bert Greevenbosch; draft-ietf-weirds-rdap-sec.all@tools.ietf.org; iesg@= ietf.org; apps-discuss@ietf.org; weirds@ietf.org Subject: Re: [weirds] Applications Area Directorate Review of draft-ietf-we= irds-rdap-sec-09 On Oct 22, 2014, at 9:46 AM, Hollenbeck, Scott > wrote: n1) 3.3, it would be nice to replace "a 429 response code" by "a 429 (Too many Requests) response code". Thanks for the feedback, Bert. You're probably right, but since this is a n= it I'd prefer to leave the text as-is to maintain consistency with other RD= AP documents that describe HTTP response codes without using parenthetical = text to describe the meaning of the code. We have normative references in t= he appropriate places to do that. Scott, Bert has made the same comment on using-http, so the parentheticals will ap= pear in our other documents. I view it as a readability thing, not necessar= ily a normative reference issue. [SAH] OK, well, if the other documents are going to change we should make t= he same change in rdap-sec. Scott --_000_831693C2CDA2E849A7D7A712B24E257F494F1506BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Andy New= ton [mailto:andy@arin.net]
Sent: Wednesday, October 22, 2014 9:56 AM
To: Hollenbeck, Scott
Cc: Bert Greevenbosch; draft-ietf-weirds-rdap-sec.all@tools.ietf.org= ; iesg@ietf.org; apps-discuss@ietf.org; weirds@ietf.org
Subject: Re: [weirds] Applications Area Directorate Review of draft-= ietf-weirds-rdap-sec-09

 

 

On Oct 22, 2014, at 9:46 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">shollenbeck@verisign.com>= wrote:



n1) 3.3, it would be nice to replace &= quot;a 429 response code" by "a 429
(Too many Requests) response code".


Thanks for the feedback, Bert. You're probably right, but since this is a n= it I'd prefer to leave the text as-is to maintain consistency with other RD= AP documents that describe HTTP response codes without using parenthetical = text to describe the meaning of the code. We have normative references in the appropriate places to do tha= t.

 

Scott,

 

Bert has made the same comment on using-http, so the= parentheticals will appear in our other documents. I view it as a readabil= ity thing, not necessarily a normative reference issue.

 

[SAH] OK, well, if the other documents are going to change we sh= ould make the same change in rdap-sec.

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F494F1506BRN1WNEXMBX01vc_-- From nobody Wed Oct 22 10:06:51 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C921ACE56 for ; Wed, 22 Oct 2014 10:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 845jCZaGv25J; Wed, 22 Oct 2014 10:06:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAB11ACE62; Wed, 22 Oct 2014 10:06:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022170632.26495.19698.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 10:06:32 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/unA1jXUkjoJhPzfN6s-6NTqNwX8 Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 17:06:46 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ From nobody Wed Oct 22 10:06:54 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CFD1ACE77 for ; Wed, 22 Oct 2014 10:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 825ZExxmezvk; Wed, 22 Oct 2014 10:06:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CF21ACE67; Wed, 22 Oct 2014 10:06:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022170633.26495.56203.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 10:06:33 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/JA7bm1Ji0pJgVsj789FhE0RHVy8 Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 17:06:48 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ From nobody Wed Oct 22 10:51:40 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87921ACE86 for ; Wed, 22 Oct 2014 10:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrOPA97WnWRg for ; Wed, 22 Oct 2014 10:51:34 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7A41ACEB5 for ; Wed, 22 Oct 2014 10:51:11 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKVEfujwWeqKQQC5t+8jn4Pb+4bbpXeP/f@postini.com; Wed, 22 Oct 2014 10:51:14 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9MHpAIk013249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 13:51:10 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 13:51:09 -0400 From: "Hollenbeck, Scott" To: "MORTON, ALFRED C (AL)" , "draft-ietf-weirds-rdap-sec.all@tools.ietf.org" Thread-Topic: draft-ietf-weirds-rdap-sec-09 Thread-Index: AQHP5uDcPsELcqXJ5UiVxA6l2ir9qpw8c3vQ Date: Wed, 22 Oct 2014 17:51:09 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494F1A0A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <4AF73AA205019A4C8A1DDD32C034631D797C6138@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D797C6138@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/F7Pvx31IV3HvvICgh9zD9SuX3QM Cc: "ops-ads@tools.ietf.org" , "ops-dir@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-rdap-sec-09 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 17:51:36 -0000 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acm@research.att.com] > Sent: Monday, October 13, 2014 8:26 AM > To: draft-ietf-weirds-rdap-sec.all@tools.ietf.org > Cc: ops-dir@tools.ietf.org; ops-ads@tools.ietf.org > Subject: draft-ietf-weirds-rdap-sec-09 >=20 > OPS-DIR review of draft-ietf-weirds-rdap-sec-09 >=20 > OPS-DIR reviews are primarily for the ops-area directors. > Authors should treat this review as they would any > LAST CALL comments. >=20 > Summary: Ready, one suggestion below, also see SEC-DIR review > when available. >=20 > regards, > Al >=20 > One goal of RDAP is to provide security services that > do not exist in the WHOIS protocol. RDAP itself > is described in multiple documents. > This document describes information security services for RDAP, > including authentication, authorization, > availability, data confidentiality, and data integrity. > It provides the requirements for selected security protocols > from among many choices. Where multiple choices are allowed, > interoperability has been considered and addressed (sec 3.1). >=20 > However, the sentence at the end of 3.1: > Work on HTTP authentication methods continues. RDAP ought to be > agile enough to support additional methods as they are defined. >=20 > cannot be a requirement, and it might be phrased more positively > as: > Work on HTTP authentication methods continues. RDAP is designed to > be > agile enough to support additional methods as they are defined. > (assuming others agree this is true) Thank you. I'll make this change. Scott From nobody Wed Oct 22 13:05:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7951A1A0E for ; Wed, 22 Oct 2014 13:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJq-TFNn57cK for ; Wed, 22 Oct 2014 13:05:16 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 969111A1A0A for ; Wed, 22 Oct 2014 13:05:16 -0700 (PDT) Received: from [IPv6:2620:0:230:c000:6e88:14ff:fe69:301c] (unknown [IPv6:2620:0:230:c000:6e88:14ff:fe69:301c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ACA25400A5 for ; Wed, 22 Oct 2014 16:05:15 -0400 (EDT) Message-ID: <54480DFB.6080508@viagenie.ca> Date: Wed, 22 Oct 2014 16:05:15 -0400 From: Audric Schiltknecht Organization: =?windows-1252?Q?Viag=E9nie?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: weirds@ietf.org References: <20141010222952.18899.38570.idtracker@ietfa.amsl.com> In-Reply-To: <20141010222952.18899.38570.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ntQn19a4TR44TdAEUuoRvJ8pAQo Subject: Re: [weirds] Last Call: (JSON Responses for the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 20:05:18 -0000 Hi, I think there is a minor nit in section 5.2 (The Nameserver Object Class), figure 17: { "objectClassName", "nameserver", should be { "objectClassName": "nameserver", Audric From nobody Wed Oct 22 15:07:13 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCE81AD0C3 for ; Wed, 22 Oct 2014 15:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYluXaHYciFT; Wed, 22 Oct 2014 15:07:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E75C1A7031; Wed, 22 Oct 2014 15:07:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022220709.16252.71810.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 15:07:09 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/wtZZ8L5C_E5QQ0ukkWcW9NPnQwE Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 22:07:11 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ From nobody Wed Oct 22 22:57:54 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C4B1A88D9; Wed, 22 Oct 2014 22:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAa7tJCHQKpR; Wed, 22 Oct 2014 22:57:43 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B44D1A88D7; Wed, 22 Oct 2014 22:57:43 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s9N5vgLY027889; Thu, 23 Oct 2014 14:57:42 +0900 X-AuditID: ac120820-b7fc78e000001dd0-38-544898d56c48 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id FE.40.07632.5D898445; Thu, 23 Oct 2014 14:57:41 +0900 (JST) Date: Thu, 23 Oct 2014 14:57:30 +0900 (JST) Message-Id: <20141023.145730.103194554.kambe@jprs.co.jp> To: ietf@ietf.org, iesg@ietf.org From: Naoki Kambe In-Reply-To: <20141010222952.18899.38570.idtracker@ietfa.amsl.com> References: <20141010222952.18899.38570.idtracker@ietfa.amsl.com> Organization: Japan Registry Services Co., Ltd. X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsWyRoiFT/fqDI8Qg9vfTSxm/JnIbPFs43wW i/ldx1kcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJXRuvsUa8Eq9oo701eyNDBeYu5i5OSQEDCR mLjzCxOELSZx4d56ti5GLg4hgZOMEmdnvGMFSbAIaEusOr6XEcTmFbCQWLyjH6xZREBB4v/U 32A2s4CwxI4XL8GahQWWMEo09D0DS7AJqEgsu7cZbAOngJPE0Tlv2UBsIQFHiWn9d4EWcHDw C+hLTG1KgTjCTqLp7zsWkDCvgKDE3x3CEOO1JHpmPGaHsOUltr+dwzyBUWAWQtUsJFWzkFQt YGRexSiTn5amW5yal1Kcm25gqFdSma+XVVBUrJcMojcxggOUQ2EH44xTBocYBTgYlXh4NTI8 QoRYE8uKK3MPMUpyMCmJ8j7rBQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4a21BsrxpiRWVqUW 5cOkpDlYlMR5mY17g4UE0hNLUrNTUwtSi2CyMhwcShK8stOBGgWLUtNTK9Iyc0oQ0kwcnCDD eYCGC4PU8BYXJOYWZ6ZD5E8xqnK0NL3tZRJiycvPS5US57UCKRIAKcoozYOb84pRHOgdYd7/ 04CyPMAkBDfhFdBwJqDhnze4gAwvSURISTUwtgmrWAkfFY+/N32du9xhkYXWZ40OBVsfrQpQ ndHC3yp8bnnYB+4F368nxr80bf2/belG4ZMJWjO3vntYtulcQp/VB8O3ccfyDn3Vb52/+9mp Jhe1r82KURU2v/sf5TBcEVQs+i+hkvdTu4SppEbUy26R45qpM/y+3bj821T30cKoo5v568OZ lFiKMxINtZiLihMB4Ay9Lv8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/8wQv9kz0BDRM5q1MiyHlSzQSrzY Cc: weirds@ietf.org Subject: Re: [weirds] Last Call: (JSON Responses for the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 05:57:44 -0000 Hello, Here is also a minor nit. I thinks we need an "objectClassName" element in each result object of the following "domainSearchResults" example in Section 8: OLD ... "domainSearchResults" : [ { "handle" : "1-XXXX", "ldhName" : "1.example.com", ... }, { "handle" : "2-XXXX", "ldhName" : "2.example.com", ... } ] NEW ... "domainSearchResults" : [ { "objectClassName" : "domain", "handle" : "1-XXXX", "ldhName" : "1.example.com", ... }, { "objectClassName" : "domain", "handle" : "2-XXXX", "ldhName" : "2.example.com", ... } ] Regards, Naoki Kambe From nobody Fri Oct 24 00:10:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43DF1AD6F7; Fri, 24 Oct 2014 00:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1tqT6_12-zL; Fri, 24 Oct 2014 00:10:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A43711AD6C8; Fri, 24 Oct 2014 00:10:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024071002.14659.45822.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 00:10:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/IMmb4vya-TxELY6ljWnN80dlHK8 Cc: iesg-secretary@ietf.org Subject: [weirds] Last Call Expired: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 07:10:13 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Fri Oct 24 00:10:46 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D731AD8D8; Fri, 24 Oct 2014 00:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzN3eW1HKLV8; Fri, 24 Oct 2014 00:10:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C26191AD6CD; Fri, 24 Oct 2014 00:10:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, weirds-chairs@tools.ietf.org, draft-ietf-weirds-using-http@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024071006.14659.85096.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 00:10:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/XqakQVx2NXxfg61jCWvJnAU_Dn8 Cc: iesg-secretary@ietf.org Subject: [weirds] Last Call Expired: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 07:10:29 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Fri Oct 24 00:11:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50801AD8EF; Fri, 24 Oct 2014 00:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7K8aj0c_1DT; Fri, 24 Oct 2014 00:10:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD6A1AD8E2; Fri, 24 Oct 2014 00:10:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, weirds-chairs@tools.ietf.org, draft-ietf-weirds-object-inventory@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024071018.14659.79490.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 00:10:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/mUsmlG2azD6_Wk8b4j56_DzOHeo Cc: iesg-secretary@ietf.org Subject: [weirds] Last Call Expired: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 07:10:53 -0000 X-List-Received-Date: Fri, 24 Oct 2014 07:10:53 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Fri Oct 24 00:11:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763821AD8E3; Fri, 24 Oct 2014 00:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oSSl5hjw-hu; Fri, 24 Oct 2014 00:11:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8779C1AD8E9; Fri, 24 Oct 2014 00:10:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024071029.14659.78218.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 00:10:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/FPGz3-h_AodzvRYCRRjBzMx3cnM Cc: iesg-secretary@ietf.org Subject: [weirds] Last Call Expired: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 07:11:16 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Fri Oct 24 00:11:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D431AD8D8; Fri, 24 Oct 2014 00:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiMSgqjjIKOG; Fri, 24 Oct 2014 00:11:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A96FC1AD6C8; Fri, 24 Oct 2014 00:10:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024071033.14659.19031.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 00:10:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/zX4ozgU-YRguQFiTr4ipsduR6RE Cc: iesg-secretary@ietf.org Subject: [weirds] Last Call Expired: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 07:11:20 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Fri Oct 24 05:43:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7C1A8923 for ; Fri, 24 Oct 2014 02:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo9utn59KSYz for ; Fri, 24 Oct 2014 02:29:11 -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 54F701A19E5 for ; Fri, 24 Oct 2014 02:29:11 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.110]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s9O9SxwS022232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Oct 2014 02:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1414142950; x=1414229350; bh=73uyKhvelKla1ARAZAWK9VlWNG9r+C2nZyEXlkhgWIU=; h=Date:To:From:Subject:In-Reply-To:References; b=KyzcpL1P17FnWCtX0ZYjSyXdymkZkYrZ0X2VrERNhVKh9tdmEQ3Cfe0lsrnxpLIru IgXZ4B647lf0D9ZWbznnTZ3lqxYw4KcXzrw5HwbUDMzSvGZm1EJBYfxjFVtovTfEGw 8ibSGGa/fw//gHMcrVbAgvkN1u3kICQb3bwgmkYQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1414142950; x=1414229350; i=@elandsys.com; bh=73uyKhvelKla1ARAZAWK9VlWNG9r+C2nZyEXlkhgWIU=; h=Date:To:From:Subject:In-Reply-To:References; b=pgVbJJ+emXhGBs2lM3xx0o7iSJAdZ6OyyBzR43xAoGp2kwrR2P7hgeiJeJMXxdRF2 D6Dk/Wv2McmsdrZlFLkYlo/dqZ3frWHLoN0CXx5OxScXLbWGPQZUFgzOnY9oOrCEVM ozxB/joqpXUmTqBo4t3HHRM90LLl4KlTkkN4ip1A= Message-Id: <6.2.5.6.2.20141023233125.0b618620@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Oct 2014 23:41:05 -0700 To: weirds@ietf.org From: S Moonesamy In-Reply-To: <20141010222207.8413.95671.idtracker@ietfa.amsl.com> References: <20141010222207.8413.95671.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/b7VDJid-h9YGc6bQtOK-nYrVujE X-Mailman-Approved-At: Fri, 24 Oct 2014 05:43:14 -0700 Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 09:29:12 -0000 At 15:22 10-10-2014, The IESG wrote: >The IESG has received a request from the Web Extensible Internet >Registration Data Service WG (weirds) to consider the following document: >- 'HTTP usage in the Registration Data Access Protocol (RDAP)' > as Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2014-10-24. Exceptionally, comments may be From Section 1: "This document describes the usage of the Hypertext Transfer Protocol (HTTP) [RFC7230] for registration data directory services." The title of the draft is "HTTP usage in the Registration Data Access Protocol (RDAP)". I suggest aligning the title of the draft with what the document describes. In Section 4.1: "Clients MUST support HTTPS as well as HTTP." Why is this an absolute requirement? Regards, S. Moonesamy From nobody Fri Oct 24 06:21:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D891A008A for ; Fri, 24 Oct 2014 06:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fANB8PXDJyPE for ; Fri, 24 Oct 2014 06:21:22 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6851A00F0 for ; Fri, 24 Oct 2014 06:19:09 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id D137B1650D7; Fri, 24 Oct 2014 09:19:08 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 3F1B71650D3; Fri, 24 Oct 2014 09:19:08 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Oct 2014 09:20:58 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 24 Oct 2014 09:19:07 -0400 From: Andy Newton To: S Moonesamy , "weirds@ietf.org" Thread-Topic: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard Thread-Index: AQHP5NimXwH0kXslL0utQFCRKbH1+5w/JFSAgAAsJAA= Date: Fri, 24 Oct 2014 13:19:06 +0000 Message-ID: In-Reply-To: <6.2.5.6.2.20141023233125.0b618620@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <783256209898054FA78071372C4B98A5@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/rDps9rtrwcGSpmk4aJy2AxfZ09c Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:21:27 -0000 On 10/24/14, 2:41 AM, "S Moonesamy" wrote: >In Section 4.1: > > "Clients MUST support HTTPS as well as HTTP." > >Why is this an absolute requirement? Security mafia, IETF religion, NSA. Take your pick. But the scope of why the IETF desires to have its protocols include security features is much larger than this draft or working group. From a practical standpoint, most client HTTP libraries support it so this does not seem burdensome to me. And it is a client requirement, not a service operator requirement. -andy From nobody Fri Oct 24 06:35:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF301A0097 for ; Fri, 24 Oct 2014 06:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK71cmQZgtvi for ; Fri, 24 Oct 2014 06:35:13 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172E81A0089 for ; Fri, 24 Oct 2014 06:35:08 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKVEpVitg5w4reQnNkQqFZougg7uoWh/RB@postini.com; Fri, 24 Oct 2014 06:35:12 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9ODZ4mp002332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 09:35:05 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 09:35:02 -0400 From: "Hollenbeck, Scott" To: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Thread-Topic: [weirds] Last Call Expired: Thread-Index: AQHP71m3FT/JtoW1lkeqHSJABjzUgJw/P41g Date: Fri, 24 Oct 2014 13:35:03 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4950050B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141024071029.14659.78218.idtracker@ietfa.amsl.com> In-Reply-To: <20141024071029.14659.78218.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/qS_zF9oqcVLO8m38h1aUjGzJLfc Subject: Re: [weirds] Last Call Expired: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:35:15 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of DraftTracker > Mail System > Sent: Friday, October 24, 2014 3:10 AM > To: iesg@ietf.org; weirds-chairs@tools.ietf.org; draft-ietf-weirds- > rdap-query@tools.ietf.org; weirds@ietf.org > Cc: iesg-secretary@ietf.org > Subject: [weirds] Last Call Expired: 15.txt> >=20 >=20 > Please DO NOT reply to this email. >=20 > I-D: > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap- > query/ >=20 > IETF Last Call has ended, and the state has been changed to > Waiting for Writeup. Do y'all want to see any document updates to address last call comments pri= or to the next round of review? Scott From nobody Fri Oct 24 06:43:47 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E021C1A008D for ; Fri, 24 Oct 2014 06:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4pXHJ0Vv_Te for ; Fri, 24 Oct 2014 06:43:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A54C91A0054 for ; Fri, 24 Oct 2014 06:43:44 -0700 (PDT) Received: from [IPv6:2620:0:230:c000:6e88:14ff:fe69:301c] (unknown [IPv6:2620:0:230:c000:6e88:14ff:fe69:301c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id F002941319 for ; Fri, 24 Oct 2014 09:43:43 -0400 (EDT) Message-ID: <544A578F.5070801@viagenie.ca> Date: Fri, 24 Oct 2014 09:43:43 -0400 From: Audric Schiltknecht Organization: =?UTF-8?B?VmlhZ8Opbmll?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: weirds@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/1CjgTwmkJzrFr5d8BIhYv3Kys1g Subject: [weirds] Required values in JSON responses X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:43:46 -0000 Hello, I have not followed all previous discussions about this, so I may be missing some information regarding this issue. In current JSON response draft (version 10): * Section 2.1: Clients processing JSON responses need to be prepared for values specified in this document to be absent from a response, as no JSON value listed is required to appear in a response. In other words, servers are free to not included values based on their own policies. I understand this statement as the fact that there is no REQUIRED values defined in all the document (and that in fact, even an empty JSON response is a valid response). (Also, there is a small nit: "servers are free to not included values" -> "servers are free to not include values"). However, * Section 4.9 An objectClassName is REQUIRED in all RDAP response objects so that the type of the object can be interpreted. This sections states that the 'objectClassName' JSON member is REQUIRED. Furthermore, * Section 4.2: The JSON name/values of "rel", "href", "hreflang", "title", "media", and "type" correspond to values found in Section 5 of [RFC5988]. The "value" JSON value is the context URI as described by [RFC5988]. The "href" JSON value MUST be specified. All other JSON values are OPTIONAL. Here, the 'href' value is a MUST for 'links' array. Long story short, sections 4.2 and 4.9 both specify required values for JSON objects whereas Section 2.1 states that there is no required value. Did I miss something about that? Thank you. Audric From nobody Fri Oct 24 07:03:27 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F451A016D for ; Fri, 24 Oct 2014 07:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AboSLDSEL6hS for ; Fri, 24 Oct 2014 07:03:17 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 19D091A01E7 for ; Fri, 24 Oct 2014 07:02:22 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id C7AA61650D5; Fri, 24 Oct 2014 10:02:21 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 1E16F1650AF; Fri, 24 Oct 2014 10:02:21 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Oct 2014 10:04:53 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 24 Oct 2014 10:02:20 -0400 From: Andy Newton To: Audric Schiltknecht , "weirds@ietf.org" Thread-Topic: [weirds] Required values in JSON responses Thread-Index: AQHP75CKaS8IjIzGwUKoETxvWBeEt5w/Rx6A Date: Fri, 24 Oct 2014 14:02:20 +0000 Message-ID: In-Reply-To: <544A578F.5070801@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <93F1F3CE66C88B4A9C2A8B1D9D613627@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/iHhFVSy4MEjjyxHnqsAizm85iMg Subject: Re: [weirds] Required values in JSON responses X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 14:03:19 -0000 On 10/24/14, 9:43 AM, "Audric Schiltknecht" wrote: >Hello, > >I have not followed all previous discussions about this, so I may be >missing some information regarding this issue. > >In current JSON response draft (version 10): > >* Section 2.1: > Clients processing JSON responses need to be prepared for values > specified in this document to be absent from a response, as no JSON > value listed is required to appear in a response. In other words, > servers are free to not included values based on their own policies. > >I understand this statement as the fact that there is no REQUIRED values >defined in all the document (and that in fact, even an empty JSON >response is a valid response). > >(Also, there is a small nit: "servers are free to not included values" -> >"servers are free to not include values"). > > >However, >* Section 4.9 > An objectClassName is REQUIRED in all RDAP > response objects so that the type of the object can be interpreted. > >This sections states that the 'objectClassName' JSON member is REQUIRED. > >Furthermore, >* Section 4.2: > > The JSON name/values of "rel", "href", "hreflang", "title", "media", > and "type" correspond to values found in Section 5 of [RFC5988]. The > "value" JSON value is the context URI as described by [RFC5988]. The > "href" JSON value MUST be specified. All other JSON values are > OPTIONAL. > >Here, the 'href' value is a MUST for 'links' array. > > >Long story short, sections 4.2 and 4.9 both specify required values for >JSON objects whereas Section 2.1 states that there is no required value. > >Did I miss something about that? No, I think you found a wording glitch. I propose the following change: OLD: Clients processing JSON responses need to be prepared for values specified in this document to be absent from a response, as no JSON value listed is required to appear in a response. In other words, servers are free to not included values based on their own policies. NEW: Clients processing JSON responses need to be prepared for values representing registration data specified in this document to be absent from a response. In other words, servers are free to not included JSON values containing registration data based on their own policies. -andy From nobody Fri Oct 24 08:12:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E5A1A1A58 for ; Fri, 24 Oct 2014 08:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DuApJCT7geR for ; Fri, 24 Oct 2014 08:12:16 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::719]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C1E1A1A5D for ; Fri, 24 Oct 2014 08:11:28 -0700 (PDT) Received: from AM3PR06MB115.eurprd06.prod.outlook.com (10.242.245.149) by AM3PR06MB114.eurprd06.prod.outlook.com (10.242.245.148) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 24 Oct 2014 15:11:04 +0000 Received: from AM3PR06MB115.eurprd06.prod.outlook.com ([169.254.11.49]) by AM3PR06MB115.eurprd06.prod.outlook.com ([169.254.11.49]) with mapi id 15.00.1054.004; Fri, 24 Oct 2014 15:11:05 +0000 From: Maarten Bosteels To: Andy Newton , Audric Schiltknecht , "weirds@ietf.org" Thread-Topic: [weirds] Required values in JSON responses Thread-Index: AQHP75CMyO+cT+Zb40GmjnVhaVZ+05w/Rx8AgAA0sAA= Date: Fri, 24 Oct 2014 15:11:05 +0000 Message-ID: References: <544A578F.5070801@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [77.67.63.234] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR06MB114; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(189002)(479174003)(199003)(51704005)(107886001)(92566001)(107046002)(31966008)(40100003)(122556002)(85852003)(50986999)(77096002)(21056001)(54356999)(86362001)(92726001)(36756003)(85306004)(99396003)(76176999)(106116001)(64706001)(4396001)(106356001)(87936001)(95666004)(97736003)(105586002)(66066001)(101416001)(120916001)(2501002)(19580395003)(46102003)(2656002)(76482002)(15975445006)(80022003)(20776003)(19580405001)(74482002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR06MB114; H:AM3PR06MB115.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: dnsbelgium.be Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/PjS67yTCEmehQs2KhPV0aWcM5wE Subject: Re: [weirds] Required values in JSON responses X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:12:20 -0000 On 24/10/14 16:02, "Andy Newton" wrote: >On 10/24/14, 9:43 AM, "Audric Schiltknecht" > wrote: > >>Hello, >> >>I have not followed all previous discussions about this, so I may be >>missing some information regarding this issue. >> >>In current JSON response draft (version 10): >> >>* Section 2.1: >> Clients processing JSON responses need to be prepared for values >> specified in this document to be absent from a response, as no JSON >> value listed is required to appear in a response. In other words, >> servers are free to not included values based on their own policies. >> >>I understand this statement as the fact that there is no REQUIRED values >>defined in all the document (and that in fact, even an empty JSON >>response is a valid response). >> >>(Also, there is a small nit: "servers are free to not included values" -> >>"servers are free to not include values"). >> >> >>However, >>* Section 4.9 >> An objectClassName is REQUIRED in all RDAP >> response objects so that the type of the object can be interpreted. >> >>This sections states that the 'objectClassName' JSON member is REQUIRED. >> >>Furthermore, >>* Section 4.2: >> >> The JSON name/values of "rel", "href", "hreflang", "title", "media", >> and "type" correspond to values found in Section 5 of [RFC5988]. The >> "value" JSON value is the context URI as described by [RFC5988]. The >> "href" JSON value MUST be specified. All other JSON values are >> OPTIONAL. >> >>Here, the 'href' value is a MUST for 'links' array. >> >> >>Long story short, sections 4.2 and 4.9 both specify required values for >>JSON objects whereas Section 2.1 states that there is no required value. >> >>Did I miss something about that? > >No, I think you found a wording glitch. I propose the following change: > >OLD: > > Clients processing JSON responses need to be prepared for values > specified in this document to be absent from a response, as no JSON > value listed is required to appear in a response. In other words, > servers are free to not included values based on their own policies. > >NEW: > > > Clients processing JSON responses need to be prepared for values > representing registration data specified in this document to be > absent from a response. In other words, servers are free to not > included JSON values containing registration data based on their > own policies. NEWER:=20 Clients processing JSON responses need to be prepared for values representing registration data specified in this document to be absent from a response. In other words, servers are free to not include JSON values containing registration data based on their own policies. Replaced "free to not included" by "free to not include" br Maarten > >-andy > > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From nobody Fri Oct 24 08:22:27 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2B61A1A1B for ; Fri, 24 Oct 2014 08:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxNm2vuojGWJ for ; Fri, 24 Oct 2014 08:22:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 364E91A1A1C for ; Fri, 24 Oct 2014 08:22:22 -0700 (PDT) Received: from [IPv6:2620:0:230:c000:6e88:14ff:fe69:301c] (unknown [IPv6:2620:0:230:c000:6e88:14ff:fe69:301c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3BDC7403D7; Fri, 24 Oct 2014 11:22:21 -0400 (EDT) Message-ID: <544A6EAD.20400@viagenie.ca> Date: Fri, 24 Oct 2014 11:22:21 -0400 From: Audric Schiltknecht Organization: =?windows-1252?Q?Viag=E9nie?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Maarten Bosteels , Andy Newton , "weirds@ietf.org" References: <544A578F.5070801@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2FqkW72-aK93RJaK1VcaukURPu8 Subject: Re: [weirds] Required values in JSON responses X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:22:24 -0000 Le 2014-10-24 11:11, Maarten Bosteels a écrit : > > > On 24/10/14 16:02, "Andy Newton" wrote: > >> On 10/24/14, 9:43 AM, "Audric Schiltknecht" >> wrote: >> >>> Hello, >>> >>> I have not followed all previous discussions about this, so I may be >>> missing some information regarding this issue. >>> >>> In current JSON response draft (version 10): >>> >>> * Section 2.1: >>> Clients processing JSON responses need to be prepared for values >>> specified in this document to be absent from a response, as no JSON >>> value listed is required to appear in a response. In other words, >>> servers are free to not included values based on their own policies. >>> >>> I understand this statement as the fact that there is no REQUIRED values >>> defined in all the document (and that in fact, even an empty JSON >>> response is a valid response). >>> >>> (Also, there is a small nit: "servers are free to not included values" -> >>> "servers are free to not include values"). >>> >>> >>> However, >>> * Section 4.9 >>> An objectClassName is REQUIRED in all RDAP >>> response objects so that the type of the object can be interpreted. >>> >>> This sections states that the 'objectClassName' JSON member is REQUIRED. >>> >>> Furthermore, >>> * Section 4.2: >>> >>> The JSON name/values of "rel", "href", "hreflang", "title", "media", >>> and "type" correspond to values found in Section 5 of [RFC5988]. The >>> "value" JSON value is the context URI as described by [RFC5988]. The >>> "href" JSON value MUST be specified. All other JSON values are >>> OPTIONAL. >>> >>> Here, the 'href' value is a MUST for 'links' array. >>> >>> >>> Long story short, sections 4.2 and 4.9 both specify required values for >>> JSON objects whereas Section 2.1 states that there is no required value. >>> >>> Did I miss something about that? >> >> No, I think you found a wording glitch. I propose the following change: >> >> OLD: >> >> Clients processing JSON responses need to be prepared for values >> specified in this document to be absent from a response, as no JSON >> value listed is required to appear in a response. In other words, >> servers are free to not included values based on their own policies. >> >> NEW: >> >> >> Clients processing JSON responses need to be prepared for values >> representing registration data specified in this document to be >> absent from a response. In other words, servers are free to not >> included JSON values containing registration data based on their >> own policies. > > NEWER: > > > Clients processing JSON responses need to be prepared for values > representing registration data specified in this document to be > absent from a response. In other words, servers are free to not > include JSON values containing registration data based on their > own policies. > > Replaced "free to not included" by "free to not include" That looks better, indeed. Related to the 'objectClassName' requirement, Section 5 may also need to be changed: In addition to the "links" array with a self link, servers SHOULD provide an "objectClassName" (see Section 4.9) string in each object. I think it is possible to completely remove this sentence, since it is already expressed in Section 4.9 (as a REQUIRED value). Regards, Audric From nobody Fri Oct 24 08:55:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B781A1A88 for ; Fri, 24 Oct 2014 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4evgYDyuhq56 for ; Fri, 24 Oct 2014 08:55:06 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id BA4051A1AD1 for ; Fri, 24 Oct 2014 08:55:05 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 74F8A1650CE; Fri, 24 Oct 2014 11:55:05 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id AE91C1650CB; Fri, 24 Oct 2014 11:55:04 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Oct 2014 11:56:54 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 24 Oct 2014 11:55:04 -0400 From: Andy Newton To: Maarten Bosteels , Audric Schiltknecht , "weirds@ietf.org" Thread-Topic: [weirds] Required values in JSON responses Thread-Index: AQHP75CKaS8IjIzGwUKoETxvWBeEt5w/Rx6AgABWRYD//8k4gA== Date: Fri, 24 Oct 2014 15:55:04 +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.3.7.130812 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/afYbmUY_PP86jBHDzBAeP-NvVB0 Subject: Re: [weirds] Required values in JSON responses X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:55:08 -0000 On 10/24/14, 11:11 AM, "Maarten Bosteels" wrote: > > >On 24/10/14 16:02, "Andy Newton" wrote: > >>On 10/24/14, 9:43 AM, "Audric Schiltknecht" >> wrote: >> >>>Hello, >>> >>>I have not followed all previous discussions about this, so I may be >>>missing some information regarding this issue. >>> >>>In current JSON response draft (version 10): >>> >>>* Section 2.1: >>> Clients processing JSON responses need to be prepared for values >>> specified in this document to be absent from a response, as no JSON >>> value listed is required to appear in a response. In other words, >>> servers are free to not included values based on their own policies. >>> >>>I understand this statement as the fact that there is no REQUIRED values >>>defined in all the document (and that in fact, even an empty JSON >>>response is a valid response). >>> >>>(Also, there is a small nit: "servers are free to not included values" >>>-> >>>"servers are free to not include values"). >>> >>> >>>However, >>>* Section 4.9 >>> An objectClassName is REQUIRED in all RDAP >>> response objects so that the type of the object can be interpreted. >>> >>>This sections states that the 'objectClassName' JSON member is REQUIRED. >>> >>>Furthermore, >>>* Section 4.2: >>> >>> The JSON name/values of "rel", "href", "hreflang", "title", "media", >>> and "type" correspond to values found in Section 5 of [RFC5988]. The >>> "value" JSON value is the context URI as described by [RFC5988]. The >>> "href" JSON value MUST be specified. All other JSON values are >>> OPTIONAL. >>> >>>Here, the 'href' value is a MUST for 'links' array. >>> >>> >>>Long story short, sections 4.2 and 4.9 both specify required values for >>>JSON objects whereas Section 2.1 states that there is no required value. >>> >>>Did I miss something about that? >> >>No, I think you found a wording glitch. I propose the following change: >> >>OLD: >> >> Clients processing JSON responses need to be prepared for values >> specified in this document to be absent from a response, as no JSON >> value listed is required to appear in a response. In other words, >> servers are free to not included values based on their own policies. >> >>NEW: >> >> >> Clients processing JSON responses need to be prepared for values >> representing registration data specified in this document to be >> absent from a response. In other words, servers are free to not >> included JSON values containing registration data based on their >> own policies. > >NEWER:=20 > > >Clients processing JSON responses need to be prepared for values > representing registration data specified in this document to be > absent from a response. In other words, servers are free to not > include JSON values containing registration data based on their > own policies. > >Replaced "free to not included" by "free to not include" > >br >Maarten Thanks. -andy From nobody Fri Oct 24 08:56:49 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9C1A1B3A for ; Fri, 24 Oct 2014 08:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03X-TVlsfNHx for ; Fri, 24 Oct 2014 08:56:36 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1682E1A1AA3 for ; Fri, 24 Oct 2014 08:56:36 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id BFB9821383F; Fri, 24 Oct 2014 11:56:35 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 1180721383C; Fri, 24 Oct 2014 11:56:35 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Oct 2014 11:59:07 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 24 Oct 2014 11:56:34 -0400 From: Andy Newton To: Audric Schiltknecht , Maarten Bosteels , "weirds@ietf.org" Thread-Topic: [weirds] Required values in JSON responses Thread-Index: AQHP75CKaS8IjIzGwUKoETxvWBeEt5w/Rx6AgAAYCp2AAAfdAA== Date: Fri, 24 Oct 2014 15:56:34 +0000 Message-ID: In-Reply-To: <544A6EAD.20400@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/jRMio8s3gQVCyP0FnUyKbtnqkTY Subject: Re: [weirds] Required values in JSON responses X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:56:44 -0000 On 10/24/14, 11:22 AM, "Audric Schiltknecht" wrote: >Le 2014-10-24 11:11, Maarten Bosteels a =E9crit : >>=20 >>=20 >> On 24/10/14 16:02, "Andy Newton" wrote: >>=20 >>> On 10/24/14, 9:43 AM, "Audric Schiltknecht" >>> wrote: >>> >>>> Hello, >>>> >>>> I have not followed all previous discussions about this, so I may be >>>> missing some information regarding this issue. >>>> >>>> In current JSON response draft (version 10): >>>> >>>> * Section 2.1: >>>> Clients processing JSON responses need to be prepared for values >>>> specified in this document to be absent from a response, as no JSON >>>> value listed is required to appear in a response. In other words, >>>> servers are free to not included values based on their own policies. >>>> >>>> I understand this statement as the fact that there is no REQUIRED >>>>values >>>> defined in all the document (and that in fact, even an empty JSON >>>> response is a valid response). >>>> >>>> (Also, there is a small nit: "servers are free to not included >>>>values" -> >>>> "servers are free to not include values"). >>>> >>>> >>>> However, >>>> * Section 4.9 >>>> An objectClassName is REQUIRED in all RDAP >>>> response objects so that the type of the object can be interpreted. >>>> >>>> This sections states that the 'objectClassName' JSON member is >>>>REQUIRED. >>>> >>>> Furthermore, >>>> * Section 4.2: >>>> >>>> The JSON name/values of "rel", "href", "hreflang", "title", "media", >>>> and "type" correspond to values found in Section 5 of [RFC5988]. >>>>The >>>> "value" JSON value is the context URI as described by [RFC5988]. >>>>The >>>> "href" JSON value MUST be specified. All other JSON values are >>>> OPTIONAL. >>>> >>>> Here, the 'href' value is a MUST for 'links' array. >>>> >>>> >>>> Long story short, sections 4.2 and 4.9 both specify required values >>>>for >>>> JSON objects whereas Section 2.1 states that there is no required >>>>value. >>>> >>>> Did I miss something about that? >>> >>> No, I think you found a wording glitch. I propose the following change: >>> >>> OLD: >>> >>> Clients processing JSON responses need to be prepared for values >>> specified in this document to be absent from a response, as no JSON >>> value listed is required to appear in a response. In other words, >>> servers are free to not included values based on their own policies. >>> >>> NEW: >>> >>> >>> Clients processing JSON responses need to be prepared for values >>> representing registration data specified in this document to be >>> absent from a response. In other words, servers are free to not >>> included JSON values containing registration data based on their >>> own policies. >>=20 >> NEWER:=20 >>=20 >>=20 >> Clients processing JSON responses need to be prepared for values >> representing registration data specified in this document to be >> absent from a response. In other words, servers are free to not >> include JSON values containing registration data based on their >> own policies. >>=20 >> Replaced "free to not included" by "free to not include" > >That looks better, indeed. > > >Related to the 'objectClassName' requirement, Section 5 may also need to >be changed: > > In addition to the "links" array with a self link, servers SHOULD > provide an "objectClassName" (see Section 4.9) string in each object. > >I think it is possible to completely remove this sentence, since it is >already expressed in Section 4.9 (as a REQUIRED value). I agree. -andy From nobody Fri Oct 24 08:58:46 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8D1A1B6B for ; Fri, 24 Oct 2014 08:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AotULsz3mbJP for ; Fri, 24 Oct 2014 08:58:39 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0A71A1B57 for ; Fri, 24 Oct 2014 08:58:25 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 16E7721383E; Fri, 24 Oct 2014 11:58:25 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 7B4BF21383E; Fri, 24 Oct 2014 11:58:24 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Oct 2014 12:00:14 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 24 Oct 2014 11:58:23 -0400 From: Andy Newton To: S Moonesamy , "weirds@ietf.org" Thread-Topic: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard Thread-Index: AQHP76AWR4xTrU7XkUq+cK87ftc6d5w/Z2qA Date: Fri, 24 Oct 2014 15:58:23 +0000 Message-ID: In-Reply-To: <6.2.5.6.2.20141024062448.0b2bb330@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/bW6GTr7u7pjqK2nyTs84GWNWuak Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:58:42 -0000 On 10/24/14, 9:28 AM, "S Moonesamy" wrote: >I don't have a strong opinion about this. I suggest having a short >explanation (it could be a few words) for the "MUST". What about a reference to the rdap-sec draft instead of a short explanation? -andy From nobody Fri Oct 24 11:00:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950F01A8A53; Fri, 24 Oct 2014 11:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzYnuWhw84Xo; Fri, 24 Oct 2014 11:00:25 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id BB0221A8A46; Fri, 24 Oct 2014 11:00:24 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 267B2213692; Fri, 24 Oct 2014 14:00:24 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id A59EA21364C; Fri, 24 Oct 2014 14:00:23 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Oct 2014 14:02:13 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 24 Oct 2014 14:00:23 -0400 From: Andy Newton To: Edward Lewis , "Hollenbeck, Scott" , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlit5w6fdGggABH2wCABM7MAA== Date: Fri, 24 Oct 2014 18:00:22 +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.3.7.130812 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NPP7_SxV6maZulRmIKhgjMRoA-U Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 18:00:26 -0000 I missed this due to all the HTML in the email... >> >>How about this? >> >>OLD: >>"Implementers need to consider the policy and privacy implications of >>returning information that was not explicitly requested." >> >>NEW: >>"Implementers need to consider the policy and privacy implications of >>returning information that was not explicitly requested. Clients should >>only receive information that they are explicitly authorized to receive." > >Almost=8A=B2Servers should only send information that clients are explicit= ly >authorized to receive.=B2 > >The way it is worded is impossible to "enforce." How does this work with anonymous access to public information, which is how this information is served today? How do I =B3explicitly" authorize an anonymous user? I think the old text above is good enough and find the next text (both versions) to be confusing. -andy From nobody Fri Oct 24 11:35:46 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3291A1A4F for ; Fri, 24 Oct 2014 08:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAvBWKS8wPCT for ; Fri, 24 Oct 2014 08:06:09 -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 6BAFB1A1A48 for ; Fri, 24 Oct 2014 08:06:09 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.110]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s9OF5g4g017443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2014 08:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1414163161; x=1414249561; bh=Cx1X4OS8F1RZDaDyjlBkRLn8xfs2G7yHBbPKb2B6Xrc=; h=Date:To:From:Subject:In-Reply-To:References; b=1HzCtrXi96lGzr+uaWchPoRbqaUqFK0fCbUPz3kjc+e6tVUVsJX6jzfEnv3h2UDUW bsRehGwMrXXyeZGigehRvofcpPK/lq5o0m7iB/xakEnsfploB+G+53wazj+7mZW0+m B9MGCFTpUE7kl5PukLo8cIS7dHSosFtctGvKpdp0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1414163161; x=1414249561; i=@elandsys.com; bh=Cx1X4OS8F1RZDaDyjlBkRLn8xfs2G7yHBbPKb2B6Xrc=; h=Date:To:From:Subject:In-Reply-To:References; b=hI/LSfQetHJv9rzIAhFahu2dxGjK/jjP7udDsD18l7T/lSLqG91j2Bc2O8HYEJbpN /so7KoiVi+bpEuYmC9OzcFaAdm93IUEziOMEehiBkDZ93o5mxTeF9hp3FL/e9/vvGs BZarDfkmebCQP+t5cIauMaJTx+SJLFRth9pFa3Ds= Message-Id: <6.2.5.6.2.20141024062448.0b2bb330@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Oct 2014 06:28:58 -0700 To: Andy Newton , weirds@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20141023233125.0b618620@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/jAymY0WX47zLFgH06mLEQnTzo_o X-Mailman-Approved-At: Fri, 24 Oct 2014 11:35:45 -0700 Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:06:10 -0000 Hi Andy, At 06:19 24-10-2014, Andy Newton wrote: >Security mafia, IETF religion, NSA. Take your pick. But the scope of why >the IETF desires to have its protocols include security features is much >larger than this draft or working group. From a practical standpoint, most >client HTTP libraries support it so this does not seem burdensome to me. >And it is a client requirement, not a service operator requirement. I don't have a strong opinion about this. I suggest having a short explanation (it could be a few words) for the "MUST". Regards, S. Moonesamy From nobody Fri Oct 24 15:24:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3939E1A1A4B for ; Fri, 24 Oct 2014 15:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8GGhaVgy4ue for ; Fri, 24 Oct 2014 15:15:52 -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 158AE1A1A18 for ; Fri, 24 Oct 2014 15:15:52 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.154.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s9OMFatT007620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2014 15:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1414188948; x=1414275348; bh=ZOUpfcIAZFWxs4ymPPT85xk4MxNnrPGXTXg+A6MIk7U=; h=Date:To:From:Subject:In-Reply-To:References; b=VfmCcHNImZIdNgQhtsudCi2OFVtUsX1xxmhR4DNlED0otlRdoH0uROm5n/gZqzJoH UrY+wQ29zMSmsaLk8AdNLiWTbdm7TWtjZ4k9Nb6C533yC3k4Zun8++AxUwJ4w+XzzJ CdCpVWINHaz02+qvlViXKVu/6y9e+NoE3goSFyLQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1414188948; x=1414275348; i=@elandsys.com; bh=ZOUpfcIAZFWxs4ymPPT85xk4MxNnrPGXTXg+A6MIk7U=; h=Date:To:From:Subject:In-Reply-To:References; b=2q7Z/Ktoi9GuPNEWHx3JWak4CHdARIAOB/dAr9GUgpVMsLDFHbe6IE45XQhf/gQyP QsBWjInIFnCn7N79QBy03rkqTQMeDn1MsMfBBLDgIr+jAKYRYkHIFTl6xkCkggZ9Dk plcQoXpzo8qcxwMPKFkDwi/5s0Iq4+U/X5kAQifU= Message-Id: <6.2.5.6.2.20141024145621.0bfb86e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Oct 2014 15:08:34 -0700 To: Andy Newton , weirds@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20141024062448.0b2bb330@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/yqrbrA1OcpNpERxq3fMeBu-lA8c X-Mailman-Approved-At: Fri, 24 Oct 2014 15:23:59 -0700 Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 22:15:53 -0000 Hi Andy, At 08:58 24-10-2014, Andy Newton wrote: >What about a reference to the rdap-sec draft instead of a short >explanation? There is the following in draft-ietf-weirds-rdap-sec-09: "HTTP Over TLS [RFC2818] can be used as needed to provide protection against man-in-the-middle attacks. and in Section 7 of this draft: "However, it does not restrict against the use of security mechanisms offered by the HTTP protocol. It does require the RDAP clients MUST support HTTPS." There is an inconsistency when I compare the two. I prefer not to argue about that as it is Friday. :-) I'll suggest the following: "Clients MUST implement HTTPS as well as HTTP to support security services." Please ask someone to review the suggestion as it is not that good. Regards, S. Moonesamy From nobody Fri Oct 24 16:03:40 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7421A1AE1; Fri, 24 Oct 2014 16:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-CRTi0-uG49; Fri, 24 Oct 2014 16:03:35 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136311A1B2D; Fri, 24 Oct 2014 16:03:35 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 24 Oct 2014 16:03:32 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Fri, 24 Oct 2014 16:03:31 -0700 From: Edward Lewis To: Andy Newton , "Hollenbeck, Scott" , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlit5w6fdGggABH2wCABM7MAIAAhvuA Date: Fri, 24 Oct 2014 23:03:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3497022207_4319855" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/GyM_4-mNBXZSW3o5tce60MvJ3vQ Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 23:03:38 -0000 --B_3497022207_4319855 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable As far as HTML in email, I just don=E2=80=99t care anymore. ;) If by =E2=80=9Cpublic information=E2=80=9D you mean information that anyone can access, then an anonymous user is explicitly permitted to be sent it. If by =E2=80=9Canonymous=E2=80=9D you mean a user without a proven identity, then any information deemed consumable by the general public is explicitly permitted to be sent. Just being pedantic. Perhaps the second sentence is redundant, but I do see a difference (which may be moot) in placing restrictions on what is sent vs. what can be received. From: Andy Newton Date: Friday, October 24, 2014 at 14:00 To: Edward Lewis , "Hollenbeck, Scott" , "ietf@ietf.org" , "iesg@ietf.org" Cc: "weirds@ietf.org" Subject: Re: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard >I missed this due to all the HTML in the email... > >>> >>>How about this? >>> >>>OLD: >>>"Implementers need to consider the policy and privacy implications of >>>returning information that was not explicitly requested." >>> >>>NEW: >>>"Implementers need to consider the policy and privacy implications of >>>returning information that was not explicitly requested. Clients should >>>only receive information that they are explicitly authorized to >>>receive." >> >>Almost=C5=A0=C2=B2Servers should only send information that clients are explicitl= y >>authorized to receive.=C2=B2 >> >>The way it is worded is impossible to "enforce." > >How does this work with anonymous access to public information, which is >how this information is served today? How do I =C2=B3explicitly" authorize an >anonymous user? I think the old text above is good enough and find the >next text (both versions) to be confusing. > >-andy --B_3497022207_4319855 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT32GYFRkWquom9MGrd P09Y8/NicDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MjQyMzAzMjdaMA0GCSqGSIb3DQEBAQUABIIBABXyjLJSyyvsmPGvC3s72G3AgwZjKDXEHKzL hZMdEoSdMrxw9m6bkD3d3V66wLs+tXSf5CP0lUDD+kF3ynrmjXVjfmH2VXHb9xDVZraTS3nA oBAiZAmIZZSCATZezMH6kBhid4pZ+XxGmMG2sBlnUG9ZBd2AYCVECLFEh9rnCjP6Vs0ir6wI FfvwjN1wARzRzF4KtwUHsqbl1/8K9pcJnd5L2l7MMQE/mkvJwKrQ3hNSE78O4JTnCAvMI8bg 5JsEEozDE73HhkkYXU11ENy/bdt6jxHIS362chlAhA8Ir7nqpIuqzCohaBHGz1vZn4jiRt/J pvlOWnqvcRjK2iB2Xto= --B_3497022207_4319855-- From nobody Sun Oct 26 21:38:13 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A554C1A1BBE for ; Sun, 26 Oct 2014 21:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTSO1hLQp4pA for ; Sun, 26 Oct 2014 21:38:11 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E141A1BB8 for ; Sun, 26 Oct 2014 21:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414384691; x=1445920691; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=QAfQl3L0qlpXe29U6QXPkXU2hwR0rHmHk9Cuevvp3N4=; b=XSf5V1vJxJH/eY/Z9ARFurG6GCibRFiDPqogZmiQVD2mjgs2IPWZx+7g Wm7rsy0OCoUhBIocMQVxajzT6BJACzvyFPTN9+Gr/iXD/5C/6tFv8vUzu KcdJk9sycRUGeijsKLMpOrkyv5GP720Kk4xQqDhY/JEfFkT5G9/yFI3pA M=; X-IronPort-AV: E=McAfee;i="5600,1067,7603"; a="76879171" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2014 21:38:10 -0700 X-IronPort-AV: E=Sophos;i="5.04,792,1406617200"; d="scan'208";a="737575428" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Oct 2014 21:38:10 -0700 Received: from NASANEXM01F.na.qualcomm.com (172.30.48.1) by nasanexhc06.na.qualcomm.com (172.30.48.21) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 26 Oct 2014 21:38:09 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 26 Oct 2014 21:38:09 -0700 Message-ID: <544DCC30.7000005@qti.qualcomm.com> Date: Sun, 26 Oct 2014 23:38:08 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.46.201.191) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/6dl9e2v-J8EO6IPvmM61wIpDbE4 Subject: [weirds] WEIRDS docs - "Go" or "No go" for IESG this week X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 04:38:12 -0000 I've been out of commission for several days due to a death in the family and I'm doing a bit of catch up. There have been quite a few Last Call/directorate review comments, but none of them seem to be showstoppers. So here's my question: Can the editors get out new versions Monday, 27 Aug, and I can ballot the documents with the new versions this week, or shall I push IESG Evaluation until right after Honolulu? I'd prefer the former if the editors can send out the new versions ASAP. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Oct 26 23:55:00 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376C91A1B97 for ; Sun, 26 Oct 2014 23:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPnfvX5j1ypO for ; Sun, 26 Oct 2014 23:54:58 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABDB1A1A39 for ; Sun, 26 Oct 2014 23:54:57 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x13so1188668wgg.32 for ; Sun, 26 Oct 2014 23:54:56 -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=vMbhaOk2j+ohPUAcMbOO68WybssGZun3guQlvMkMZkQ=; b=rjhgKxBaK489Hm2t7fA5oT8cwgOXYQa2wNZzLqxkFhsOHHkGtsMLBrnM3R7ec//TRU ZEB2OPJZiXa/XK/vz4/QX22u4nCdetLCmBfQCuU8qBkmsT61/0aKnpG8h/FMCM9iUYv+ lur4fRt5LOPjsiXdC9hF0O0jBHRzTvRmwQcBVYwjRe444D/NM6HBYRjWT6TwUbQHPwXO tf9gutrP6iji/VoBpA8E8pcITtkLLi8OeoJelaLLEq1WeRhz0kktRoDpaLdf3guaO18c 2ovO6WJWKYQ2tMFUKHL7WQNnkvzf/UwwTpvqzMLg9bR8xd7aazLQbcrlskIxLpjTbjlx 1Lpg== MIME-Version: 1.0 X-Received: by 10.194.90.210 with SMTP id by18mr21157562wjb.34.1414392896511; Sun, 26 Oct 2014 23:54:56 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Sun, 26 Oct 2014 23:54:56 -0700 (PDT) In-Reply-To: <544DCC30.7000005@qti.qualcomm.com> References: <544DCC30.7000005@qti.qualcomm.com> Date: Sun, 26 Oct 2014 23:54:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7bfcf6622b66ad050662027a Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/E_wOXYQhIRwrYPiDUhdjZWAomps Cc: "weirds@ietf.org" Subject: Re: [weirds] WEIRDS docs - "Go" or "No go" for IESG this week X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 06:54:59 -0000 --047d7bfcf6622b66ad050662027a Content-Type: text/plain; charset=UTF-8 On Sun, Oct 26, 2014 at 9:38 PM, Pete Resnick wrote: > I've been out of commission for several days due to a death in the family > and I'm doing a bit of catch up. There have been quite a few Last > Call/directorate review comments, but none of them seem to be showstoppers. > So here's my question: Can the editors get out new versions Monday, 27 Aug, > and I can ballot the documents with the new versions this week, or shall I > push IESG Evaluation until right after Honolulu? I'd prefer the former if > the editors can send out the new versions ASAP. s/Aug/Oct/ I agree, I didn't see anything that stopped us in our tracks or needs to go back to the WG for discussion. Does anyone disagree? Authors, are we ready to go? -MSK --047d7bfcf6622b66ad050662027a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Oct 26, 2014 at 9:38 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
I've been ou= t of commission for several days due to a death in the family and I'm d= oing a bit of catch up. There have been quite a few Last Call/directorate r= eview comments, but none of them seem to be showstoppers. So here's my = question: Can the editors get out new versions Monday, 27 Aug, and I can ba= llot the documents with the new versions this week, or shall I push IESG Ev= aluation until right after Honolulu? I'd prefer the former if the edito= rs can send out the new versions ASAP.

s/Aug/Oct/

=
I agree, I didn't see anything that stopped us in our tracks= or needs to go back to the WG for discussion.=C2=A0 Does anyone disagree?= =C2=A0 Authors, are we ready to go?

-MSK
--047d7bfcf6622b66ad050662027a-- From nobody Mon Oct 27 00:11:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07EB1A89E9; Mon, 27 Oct 2014 00:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnRvpB_dT7af; Mon, 27 Oct 2014 00:11:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B94861A89EF; Mon, 27 Oct 2014 00:10:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, mszucs@afilias.info, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027071024.14505.84783.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 00:10:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/gPc5UYeAuALEwR2A7vUzZRw7Ses Cc: iesg-secretary@ietf.org Subject: [weirds] Last Call Expired: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 07:11:09 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Mon Oct 27 03:44:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5CA1A1BD7 for ; Mon, 27 Oct 2014 03:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qoqvebjnzwO for ; Mon, 27 Oct 2014 03:44:26 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC0A1A9095 for ; Mon, 27 Oct 2014 03:44:14 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKVE4h/WOgjHF+Qc/ZpKk+e6QiECFXSQzE@postini.com; Mon, 27 Oct 2014 03:44:15 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9RAiDLB015700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 06:44:13 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 06:44:12 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , Pete Resnick Thread-Topic: [weirds] WEIRDS docs - "Go" or "No go" for IESG this week Thread-Index: AQHP8Z/TX7tJiBjAN0CVQS4RL155yZxDxaMA///81RA= Date: Mon, 27 Oct 2014 10:44:12 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49503C7F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <544DCC30.7000005@qti.qualcomm.com> 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_831693C2CDA2E849A7D7A712B24E257F49503C7FBRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/c-nyl_69afl6Tujp-0oBQHSbTo0 Cc: "weirds@ietf.org" Subject: Re: [weirds] WEIRDS docs - "Go" or "No go" for IESG this week X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:44:30 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F49503C7FBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbS4gSeKAmWxsIGhhdmUgbmV3IHZlcnNpb25zIG9mIHJkYXAtcXVlcnkgYW5kIHJkYXAtc2Vj IG91dCB0aGlzIG1vcm5pbmcuDQoNClNjb3R0DQoNCkZyb206IHdlaXJkcyBbbWFpbHRvOndlaXJk cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTXVycmF5IFMuIEt1Y2hlcmF3eQ0KU2Vu dDogTW9uZGF5LCBPY3RvYmVyIDI3LCAyMDE0IDI6NTUgQU0NClRvOiBQZXRlIFJlc25pY2sNCkNj OiB3ZWlyZHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbd2VpcmRzXSBXRUlSRFMgZG9jcyAtICJH byIgb3IgIk5vIGdvIiBmb3IgSUVTRyB0aGlzIHdlZWsNCg0KT24gU3VuLCBPY3QgMjYsIDIwMTQg YXQgOTozOCBQTSwgUGV0ZSBSZXNuaWNrIDxwcmVzbmlja0BxdGkucXVhbGNvbW0uY29tPG1haWx0 bzpwcmVzbmlja0BxdGkucXVhbGNvbW0uY29tPj4gd3JvdGU6DQpJJ3ZlIGJlZW4gb3V0IG9mIGNv bW1pc3Npb24gZm9yIHNldmVyYWwgZGF5cyBkdWUgdG8gYSBkZWF0aCBpbiB0aGUgZmFtaWx5IGFu ZCBJJ20gZG9pbmcgYSBiaXQgb2YgY2F0Y2ggdXAuIFRoZXJlIGhhdmUgYmVlbiBxdWl0ZSBhIGZl dyBMYXN0IENhbGwvZGlyZWN0b3JhdGUgcmV2aWV3IGNvbW1lbnRzLCBidXQgbm9uZSBvZiB0aGVt IHNlZW0gdG8gYmUgc2hvd3N0b3BwZXJzLiBTbyBoZXJlJ3MgbXkgcXVlc3Rpb246IENhbiB0aGUg ZWRpdG9ycyBnZXQgb3V0IG5ldyB2ZXJzaW9ucyBNb25kYXksIDI3IEF1ZywgYW5kIEkgY2FuIGJh bGxvdCB0aGUgZG9jdW1lbnRzIHdpdGggdGhlIG5ldyB2ZXJzaW9ucyB0aGlzIHdlZWssIG9yIHNo YWxsIEkgcHVzaCBJRVNHIEV2YWx1YXRpb24gdW50aWwgcmlnaHQgYWZ0ZXIgSG9ub2x1bHU/IEkn ZCBwcmVmZXIgdGhlIGZvcm1lciBpZiB0aGUgZWRpdG9ycyBjYW4gc2VuZCBvdXQgdGhlIG5ldyB2 ZXJzaW9ucyBBU0FQLg0KDQpzL0F1Zy9PY3QvDQpJIGFncmVlLCBJIGRpZG4ndCBzZWUgYW55dGhp bmcgdGhhdCBzdG9wcGVkIHVzIGluIG91ciB0cmFja3Mgb3IgbmVlZHMgdG8gZ28gYmFjayB0byB0 aGUgV0cgZm9yIGRpc2N1c3Npb24uICBEb2VzIGFueW9uZSBkaXNhZ3JlZT8gIEF1dGhvcnMsIGFy ZSB3ZSByZWFkeSB0byBnbz8NCg0KLU1TSw0K --_000_831693C2CDA2E849A7D7A712B24E257F49503C7FBRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbS4g SeKAmWxsIGhhdmUgbmV3IHZlcnNpb25zIG9mIHJkYXAtcXVlcnkgYW5kIHJkYXAtc2VjIG91dCB0 aGlzIG1vcm5pbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+U2NvdHQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IHdlaXJkcyBbbWFpbHRvOndlaXJkcy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5NdXJyYXkgUy4gS3VjaGVyYXd5PGJyPg0KPGI+U2VudDo8L2I+ IE1vbmRheSwgT2N0b2JlciAyNywgMjAxNCAyOjU1IEFNPGJyPg0KPGI+VG86PC9iPiBQZXRlIFJl c25pY2s8YnI+DQo8Yj5DYzo8L2I+IHdlaXJkc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3dlaXJkc10gV0VJUkRTIGRvY3MgLSAmcXVvdDtHbyZxdW90OyBvciAmcXVvdDtObyBn byZxdW90OyBmb3IgSUVTRyB0aGlzIHdlZWs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBPY3QgMjYsIDIwMTQgYXQgOTozOCBQTSwg UGV0ZSBSZXNuaWNrICZsdDs8YSBocmVmPSJtYWlsdG86cHJlc25pY2tAcXRpLnF1YWxjb21tLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnByZXNuaWNrQHF0aS5xdWFsY29tbS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkndmUgYmVlbiBvdXQgb2YgY29tbWlzc2lvbiBmb3Igc2V2ZXJhbCBkYXlzIGR1 ZSB0byBhIGRlYXRoIGluIHRoZSBmYW1pbHkgYW5kIEknbSBkb2luZyBhIGJpdCBvZiBjYXRjaCB1 cC4gVGhlcmUgaGF2ZSBiZWVuIHF1aXRlIGEgZmV3IExhc3QgQ2FsbC9kaXJlY3RvcmF0ZSByZXZp ZXcgY29tbWVudHMsIGJ1dCBub25lIG9mIHRoZW0gc2VlbSB0byBiZSBzaG93c3RvcHBlcnMuIFNv IGhlcmUncyBteSBxdWVzdGlvbjoNCiBDYW4gdGhlIGVkaXRvcnMgZ2V0IG91dCBuZXcgdmVyc2lv bnMgTW9uZGF5LCAyNyBBdWcsIGFuZCBJIGNhbiBiYWxsb3QgdGhlIGRvY3VtZW50cyB3aXRoIHRo ZSBuZXcgdmVyc2lvbnMgdGhpcyB3ZWVrLCBvciBzaGFsbCBJIHB1c2ggSUVTRyBFdmFsdWF0aW9u IHVudGlsIHJpZ2h0IGFmdGVyIEhvbm9sdWx1PyBJJ2QgcHJlZmVyIHRoZSBmb3JtZXIgaWYgdGhl IGVkaXRvcnMgY2FuIHNlbmQgb3V0IHRoZSBuZXcgdmVyc2lvbnMgQVNBUC48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+cy9BdWcvT2N0LzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSwgSSBkaWRuJ3Qgc2VlIGFueXRoaW5n IHRoYXQgc3RvcHBlZCB1cyBpbiBvdXIgdHJhY2tzIG9yIG5lZWRzIHRvIGdvIGJhY2sgdG8gdGhl IFdHIGZvciBkaXNjdXNzaW9uLiZuYnNwOyBEb2VzIGFueW9uZSBkaXNhZ3JlZT8mbmJzcDsgQXV0 aG9ycywgYXJlIHdlIHJlYWR5IHRvIGdvPzxicj4NCjxicj4NCi1NU0s8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_831693C2CDA2E849A7D7A712B24E257F49503C7FBRN1WNEXMBX01vc_-- From nobody Mon Oct 27 03:49:09 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A761A9067; Mon, 27 Oct 2014 03:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-5RxcWQZZdy; Mon, 27 Oct 2014 03:49:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A996B1A8A8F; Mon, 27 Oct 2014 03:49:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027104904.22451.16700.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 03:49:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/IVo2PT62LoxKIdaNShCyIZH-KX8 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-10.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:49:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Security Services for the Registration Data Access Protocol Authors : Scott Hollenbeck Ning Kong Filename : draft-ietf-weirds-rdap-sec-10.txt Pages : 11 Date : 2014-10-27 Abstract: The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services including authentication, authorization, availability, data confidentiality, and data integrity for RDAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-sec-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 03:49:11 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B1D1A1A9B for ; Mon, 27 Oct 2014 03:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGiuAb2XZy99; Mon, 27 Oct 2014 03:49:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E57C21A8FD5; Mon, 27 Oct 2014 03:49:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027104904.22451.72835.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 03:49:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/bQXhs7_vxsKouEZi8ydCIqrT82Q Subject: [weirds] New Version Notification - draft-ietf-weirds-rdap-sec-10.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:49:07 -0000 A new version (-10) has been submitted for draft-ietf-weirds-rdap-sec: http://www.ietf.org/internet-drafts/draft-ietf-weirds-rdap-sec-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-sec-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Oct 27 03:50:25 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A2C1A9035; Mon, 27 Oct 2014 03:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNlUdUCp4zYs; Mon, 27 Oct 2014 03:50:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 755361A907A; Mon, 27 Oct 2014 03:50:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027105015.23808.84193.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 03:50:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/3gbPdaKITeYV0eyb6MbVkQa6YKk Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-16.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:50:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Registration Data Access Protocol Query Format Authors : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-16.txt Pages : 20 Date : 2014-10-27 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. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-query-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 03:50:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41581A900B for ; Mon, 27 Oct 2014 03:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYWYD5CZlPz5; Mon, 27 Oct 2014 03:50:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B641A90A1; Mon, 27 Oct 2014 03:50:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027105015.23808.14830.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 03:50:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/mO-dhHo2TxqLH6lHxM0uOtxXeQ4 Subject: [weirds] New Version Notification - draft-ietf-weirds-rdap-query-16.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:50:22 -0000 A new version (-16) has been submitted for draft-ietf-weirds-rdap-query: http://www.ietf.org/internet-drafts/draft-ietf-weirds-rdap-query-16.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-query-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Oct 27 03:57:50 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA28F1A9092 for ; Mon, 27 Oct 2014 03:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQM9pnBX7Ntn for ; Mon, 27 Oct 2014 03:57:46 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D732D1A90C1 for ; Mon, 27 Oct 2014 03:57:44 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id u7so1224936qaz.39 for ; Mon, 27 Oct 2014 03:57:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=uzLtcsylRMtz0SHiHD7c7x/5mlcjkH1I/sR7FG1kh00=; b=QGgfGOZWmAExWSH2XDJLFy54Xv6xjd6fjNiDTzxvpgOmCSsf+3oW+2/RhjZYzFw9ha u/GwfGydHcJusYHPgyP6V2xbZtv9UYSih5bIz2TAsfMnmmIoET61zgv7Xpq7QeW4S7Cv 0Z618HJXNZFuQ/ns4aBqGa6Dh79qsl75qA6yOFZ/2S6ZPXDjwxLkOD6VA9QKbkST+1Xe WWG25i1ulk/aHLtwqLzMge40zPhIUd4/D1pV5uuH70mnUdXyvEd56+1TKjrbN9U7xVOg exnN3rMjCiXhLOexKLsssoXgwojpw6eCnMg+1F51fezlg5Owh0px7iXvZdX7+N2mwM03 XkQA== X-Gm-Message-State: ALoCoQmRrjleoeNnUcNwTYcQ3rLqP/6pp0gt8y0aC5S/0NzPwgwczdwItE4m/fxy1hYbTIynIzdV X-Received: by 10.140.101.120 with SMTP id t111mr30503267qge.6.1414407463976; Mon, 27 Oct 2014 03:57:43 -0700 (PDT) Received: from [10.232.199.64] (mobile-166-173-250-121.mycingular.net. [166.173.250.121]) by mx.google.com with ESMTPSA id 44sm4172045qgk.24.2014.10.27.03.57.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 03:57:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-77C2EBBD-1A23-4BEB-9DE8-024970CA8FBA Mime-Version: 1.0 (1.0) From: Andy Newton X-Mailer: iPhone Mail (12A405) In-Reply-To: Date: Mon, 27 Oct 2014 06:57:40 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <544DCC30.7000005@qti.qualcomm.com> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/hAZ0JpYnq5uB-rHcf1PRnipL-0c Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] WEIRDS docs - "Go" or "No go" for IESG this week X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:57:49 -0000 --Apple-Mail-77C2EBBD-1A23-4BEB-9DE8-024970CA8FBA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I am traveling today and won't be able to get anything out. But I can shoot f= or tomorrow if that works. -andy=20 Sent from my iPhone > On Oct 27, 2014, at 2:54 AM, Murray S. Kucherawy wro= te: >=20 >> On Sun, Oct 26, 2014 at 9:38 PM, Pete Resnick = wrote: >> I've been out of commission for several days due to a death in the family= and I'm doing a bit of catch up. There have been quite a few Last Call/dire= ctorate review comments, but none of them seem to be showstoppers. So here's= my question: Can the editors get out new versions Monday, 27 Aug, and I can= ballot the documents with the new versions this week, or shall I push IESG E= valuation until right after Honolulu? I'd prefer the former if the editors c= an send out the new versions ASAP. >=20 > s/Aug/Oct/ >=20 > I agree, I didn't see anything that stopped us in our tracks or needs to g= o back to the WG for discussion. Does anyone disagree? Authors, are we rea= dy to go? >=20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail-77C2EBBD-1A23-4BEB-9DE8-024970CA8FBA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I am traveling today and won't be able= to get anything out. But I can shoot for tomorrow if that works.
=
-andy 

Sent from my iPhone

On Oct 2= 7, 2014, at 2:54 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Sun, Oct 26, 2014 at 9:38 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
I've been ou= t of commission for several days due to a death in the family and I'm doing a= bit of catch up. There have been quite a few Last Call/directorate review c= omments, but none of them seem to be showstoppers. So here's my question: Ca= n the editors get out new versions Monday, 27 Aug, and I can ballot the docu= ments with the new versions this week, or shall I push IESG Evaluation until= right after Honolulu? I'd prefer the former if the editors can send out the= new versions ASAP.

s/Aug/Oct/

I agree, I= didn't see anything that stopped us in our tracks or needs to go back to th= e WG for discussion.  Does anyone disagree?  Authors, are we ready= to go?

-MSK
____________________= ___________________________
weirds mailing list
weirds@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/weirds">https://www.ietf.org= /mailman/listinfo/weirds
= --Apple-Mail-77C2EBBD-1A23-4BEB-9DE8-024970CA8FBA-- From nobody Mon Oct 27 06:56:00 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0B61ACC81; Mon, 27 Oct 2014 06:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b409qJSHJm-t; Mon, 27 Oct 2014 06:55:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 517841ACCE2; Mon, 27 Oct 2014 06:55:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027135536.22375.69158.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 06:55:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/kwhqfthJrdbmnXc9x2GhG0O7YwU Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-object-inventory-06.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 13:55:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Registration Data Access Protocol Object Inventory Analysis Authors : Linlin Zhou Ning Kong Sean Shen Arturo Servin Filename : draft-ietf-weirds-object-inventory-06.txt Pages : 32 Date : 2014-10-27 Abstract: WHOIS output objects from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) were collected and analyzed. This document describes the statistical analysis process and results of the analysis of existing WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-object-inventory-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-object-inventory-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 06:56:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238281ACCDE for ; Mon, 27 Oct 2014 06:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsUowCs473MU; Mon, 27 Oct 2014 06:55:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6A31ACC88; Mon, 27 Oct 2014 06:55:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-object-inventory@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027135536.22375.21308.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 06:55:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Tb-OmkJ0HDiehBex5dSR4LfyAg4 Subject: [weirds] New Version Notification - draft-ietf-weirds-object-inventory-06.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 13:55:49 -0000 A new version (-06) has been submitted for draft-ietf-weirds-object-inventory: http://www.ietf.org/internet-drafts/draft-ietf-weirds-object-inventory-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-object-inventory-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Oct 27 07:17:47 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20691A8740 for ; Mon, 27 Oct 2014 07:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu9ZSXIuhFUe for ; Mon, 27 Oct 2014 07:17:03 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD531A8739 for ; Mon, 27 Oct 2014 07:16:23 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so2974699wib.13 for ; Mon, 27 Oct 2014 07:16:21 -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=FPuTtvXmfjsbJiQAQD21Yxx4wUlotwAiHmi6MKkfP6o=; b=v+p2yZmMbyxcP2iSwlKwvSm1S9hnBKUGTazAQNqpetcA+EOEpkmu/1kNzZbvs+KzyT m13mp/R1suEuQOmuKsiBt1vH1utv75+8wPGcTks1hEDzETrcru1YIY0Sxa56UUyb+i8G 6uqoyEtAz10Td4mM4b0x8rRIHt39B1e/RbIjfb4/XpIfLuPQ4UlN/0NWngZ4doRrHLn9 xPWSGV9Hp3ckrxB2p0lr7QhUUck/V2Wx4GOExhipZyG7+jLoFaQc+3vRkgzF7J5MtIJb TX8ODr3iXA56cINXCghXhS2ZDQA9SCEJG57Nl8MkSN31henI9yhIab9/hYBRowKS6mkw geDw== MIME-Version: 1.0 X-Received: by 10.194.157.137 with SMTP id wm9mr23033300wjb.5.1414419381671; Mon, 27 Oct 2014 07:16:21 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 27 Oct 2014 07:16:21 -0700 (PDT) In-Reply-To: References: <544DCC30.7000005@qti.qualcomm.com> Date: Mon, 27 Oct 2014 07:16:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=089e013c6b68cedda70506682c08 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/-KfW-gmYnFcXP7L1xxCoOMTu9Fk Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] WEIRDS docs - "Go" or "No go" for IESG this week X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:17:05 -0000 --089e013c6b68cedda70506682c08 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 27, 2014 at 3:57 AM, Andy Newton wrote: > I am traveling today and won't be able to get anything out. But I can > shoot for tomorrow if that works. > > You won't be able to submit anything after 23:59 UTC today. -MSK --089e013c6b68cedda70506682c08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 27, 2014 at 3:57 AM, Andy Newton <andy@hxr.us&g= t; wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
I am traveling today a= nd won't be able to get anything out. But I can shoot for tomorrow if t= hat works.


You won't be= able to submit anything after 23:59 UTC today.

-MSK
=
--089e013c6b68cedda70506682c08-- From nobody Mon Oct 27 07:34:02 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEABD1A87AC for ; Mon, 27 Oct 2014 07:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SonkqcK9HwZ3; Mon, 27 Oct 2014 07:33:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6C11A87B3; Mon, 27 Oct 2014 07:33:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-object-inventory@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027143311.11631.55927.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 07:33:11 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Lv60P7-vEH5QHZNgCgzYSijTDE4 Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:33:18 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ From nobody Mon Oct 27 07:37:55 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048451ACDBD for ; Mon, 27 Oct 2014 07:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPj_Kcx8VLmt; Mon, 27 Oct 2014 07:37:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 890CF1A87AD; Mon, 27 Oct 2014 07:37:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027143727.21312.16090.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 07:37:27 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/KIhGOpe4LRNFLufYCjF9wbvQT1A Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:37:29 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ From nobody Mon Oct 27 07:59:14 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0561A878B for ; Mon, 27 Oct 2014 07:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.438 X-Spam-Level: ** X-Spam-Status: No, score=2.438 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n80AtwKvs6eU for ; Mon, 27 Oct 2014 07:58:18 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id C00C21A874D for ; Mon, 27 Oct 2014 07:58:17 -0700 (PDT) Received: from [192.168.1.106] (unknown [114.242.250.3]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QJB+XU5UBMLGAA--.31660S2; Mon, 27 Oct 2014 22:58:08 +0800 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8095B39C-2C51-4BFE-9008-52D629FAF7D2" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ning Kong In-Reply-To: Date: Mon, 27 Oct 2014 22:58:06 +0800 Message-Id: References: <544DCC30.7000005@qti.qualcomm.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1990.1) X-CM-TRANSID: AQAAf0A5QJB+XU5UBMLGAA--.31660S2 X-Coremail-Antispam: 1UD129KBjvdXoW7GF48GrykKr1kAw1xXr4fXwb_yoWDuFg_WF 1kJFy8Aw4UJw4Yqw4rAwnrCr43JFWFgry3t345XrnxX340y34kJF4kKasIv34fWry8Wr98 Gr1ftry8G3y7WjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbrAYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z2 80aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487McIj6xIIjxv20xvE 14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2 IYc2Ij64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxAIw28IcxkI7VAKI48JMxC20s026xCa FVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_Jr Wlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j 6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WF yUJVCq3wCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4U JbIYCTnIWIevJa73UjIFyTuYvjxUw6wZDUUUU X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Ck_zYq7HUdwHU2ljStLCcii5sUI Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] WEIRDS docs - "Go" or "No go" for IESG this week X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:58:20 -0000 --Apple-Mail=_8095B39C-2C51-4BFE-9008-52D629FAF7D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=gb2312 draft-ietf-weirds-object-inventory-06 was just posted. Cheers, Ning > =D4=DA 2014=C4=EA10=D4=C227=C8=D5=A3=AC=CF=C2=CE=E72:54=A3=ACMurray S. = Kucherawy =D0=B4=B5=C0=A3=BA >=20 > On Sun, Oct 26, 2014 at 9:38 PM, Pete Resnick = > wrote: > I've been out of commission for several days due to a death in the = family and I'm doing a bit of catch up. There have been quite a few Last = Call/directorate review comments, but none of them seem to be = showstoppers. So here's my question: Can the editors get out new = versions Monday, 27 Aug, and I can ballot the documents with the new = versions this week, or shall I push IESG Evaluation until right after = Honolulu? I'd prefer the former if the editors can send out the new = versions ASAP. >=20 > s/Aug/Oct/ >=20 > I agree, I didn't see anything that stopped us in our tracks or needs = to go back to the WG for discussion. Does anyone disagree? Authors, = are we ready to go? >=20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds = --Apple-Mail=_8095B39C-2C51-4BFE-9008-52D629FAF7D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=gb2312
draft-ietf-weirds-object-inventory-06 was = just posted.

Cheers,
Ning


=D4=DA 2014=C4=EA10=D4=C227=C8=D5=A3=AC=CF=C2=CE=E72:54=A3=ACMu= rray S. Kucherawy <superuser@gmail.com> =D0=B4=B5=C0=A3=BA

On Sun, Oct 26, 2014 at = 9:38 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
I've been out of = commission for several days due to a death in the family and I'm doing a = bit of catch up. There have been quite a few Last Call/directorate = review comments, but none of them seem to be showstoppers. So here's my = question: Can the editors get out new versions Monday, 27 Aug, and I can = ballot the documents with the new versions this week, or shall I push = IESG Evaluation until right after Honolulu? I'd prefer the former if the = editors can send out the new versions ASAP.

s/Aug/Oct/

I agree, I didn't see = anything that stopped us in our tracks or needs to go back to the WG for = discussion.  Does anyone disagree?  Authors, are we ready to = go?

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

= --Apple-Mail=_8095B39C-2C51-4BFE-9008-52D629FAF7D2-- From nobody Mon Oct 27 11:50:12 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DED51A916C; Mon, 27 Oct 2014 11:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqyXdJ11N-ne; Mon, 27 Oct 2014 11:49:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 129481ACE2A; Mon, 27 Oct 2014 11:49:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027184910.10489.21576.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 11:49:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/BrxAgAIzG0Rnil0xXAKZHKEOyPo Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-bootstrap-10.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:49:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Finding the Authoritative Registration Data (RDAP) Service Author : Marc Blanchet Filename : draft-ietf-weirds-bootstrap-10.txt Pages : 16 Date : 2014-10-27 Abstract: This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-bootstrap-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 11:50:29 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899321ACDF0 for ; Mon, 27 Oct 2014 11:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekhG172nyxdd; Mon, 27 Oct 2014 11:49:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A21741ACE8C; Mon, 27 Oct 2014 11:49:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, mszucs@afilias.info, weirds@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027184910.10489.99401.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 11:49:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/IC2fRhq9SS6rymZWyMrbhgJis1w Subject: [weirds] New Version Notification - draft-ietf-weirds-bootstrap-10.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:49:42 -0000 A new version (-10) has been submitted for draft-ietf-weirds-bootstrap: http://www.ietf.org/internet-drafts/draft-ietf-weirds-bootstrap-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-bootstrap-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Oct 27 11:54:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8CE1ACF10 for ; Mon, 27 Oct 2014 11:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j_AWEOPnFGv for ; Mon, 27 Oct 2014 11:54:25 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 866F31ACEFC for ; Mon, 27 Oct 2014 11:54:25 -0700 (PDT) Received: from h118.viagenie.ca (h118.viagenie.ca [206.123.31.118]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B237E403C8; Mon, 27 Oct 2014 14:54:24 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Marc Blanchet In-Reply-To: <20141027184910.10489.21576.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 14:54:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141027184910.10489.21576.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/rYfcxt-uMkh9LFpsOaJNoiV2HgI Cc: weirds-chairs@tools.ietf.org, Alessandro Vesely , Pete Resnick Subject: Re: [weirds] I-D Action: draft-ietf-weirds-bootstrap-10.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:54:27 -0000 This new version shall address the comments recevied during IETF LC = received by Alessandro and Bert (cced). to me, ready for next stage. Regards, Marc. > Le 2014-10-27 =C3=A0 14:49, internet-drafts@ietf.org a =C3=A9crit : >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Extensible Internet Registration = Data Service Working Group of the IETF. >=20 > Title : Finding the Authoritative Registration Data = (RDAP) Service > Author : Marc Blanchet > Filename : draft-ietf-weirds-bootstrap-10.txt > Pages : 16 > Date : 2014-10-27 >=20 > Abstract: > This document specifies a method to find which Registration Data > Access Protocol (RDAP) server is authoritative to answer queries for > a requested scope, such as domain names, IP addresses or Autonomous > System numbers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-bootstrap-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Oct 27 12:08:36 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BECF1AD034 for ; Mon, 27 Oct 2014 12:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT6yL-_hhgnj; Mon, 27 Oct 2014 12:08:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 132FB1AD033; Mon, 27 Oct 2014 12:07:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-object-inventory@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027190758.29873.46554.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 12:07:58 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/WyQeduKnRMZx9Vq1FOYtcu8-W1Y Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 19:08:08 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ From nobody Mon Oct 27 15:43:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE71A1BAD for ; Mon, 27 Oct 2014 15:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgtIlyuiSm4c; Mon, 27 Oct 2014 15:43:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4781A1B32; Mon, 27 Oct 2014 15:43:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, mszucs@afilias.info, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027224317.27909.85396.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 15:43:17 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/HQivXGUrxEVNHCTNAwXtcu1YxIE Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:43:29 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ From nobody Mon Oct 27 15:52:14 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D231A1BF2 for ; Mon, 27 Oct 2014 15:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymoOJ1k-jXcp; Mon, 27 Oct 2014 15:52:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53ABD1A1BFC; Mon, 27 Oct 2014 15:51:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027225140.25395.27181.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 15:51:40 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ioevQy818rLCTOLAEg9Ht3axBpI Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:52:10 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ From nobody Mon Oct 27 15:59:05 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B02B1A212A for ; Mon, 27 Oct 2014 15:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCEtAVvpMonh; Mon, 27 Oct 2014 15:58:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E5C1A6EF1; Mon, 27 Oct 2014 15:57:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027225759.29220.56584.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 15:57:59 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/kzhNst_cdA5LwqJ2l01OTAIfsIc Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:58:58 -0000 IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ From nobody Mon Oct 27 22:07:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394D21A1B24 for ; Mon, 27 Oct 2014 22:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSOblAGa7VW2; Mon, 27 Oct 2014 22:07:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E75581A19F0; Mon, 27 Oct 2014 22:07:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, mszucs@afilias.info, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028050724.24558.73445.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 22:07:24 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/6dSzf2861g4N0PLU91WVl5pUcko Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 05:07:28 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ From nobody Tue Oct 28 06:31:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E354A1A885E; Tue, 28 Oct 2014 06:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KLd0w3SIyov; Tue, 28 Oct 2014 06:31:19 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 256BB1A882C; Tue, 28 Oct 2014 06:31:19 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id D522916505A; Tue, 28 Oct 2014 09:31:18 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 2184A16502D; Tue, 28 Oct 2014 09:31:18 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 28 Oct 2014 09:33:43 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Tue, 28 Oct 2014 09:31:17 -0400 From: Andy Newton To: Edward Lewis Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlit5w6fdGggABH2wCABM7MAIAAhvuAgAW6OQA= Date: Tue, 28 Oct 2014 13:31:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6094DE52EA8163428F0656D5DA6988D1@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/SfcwFFwwQFNM1mwkq-XHij7TdRU Cc: "weirds@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 13:31:21 -0000 On Oct 24, 2014, at 7:03 PM, Edward Lewis wrote: > As far as HTML in email, I just don=92t care anymore. ;) >=20 > If by =93public information=94 you mean information that anyone can acces= s, > then an anonymous user is explicitly permitted to be sent it. If by > =93anonymous=94 you mean a user without a proven identity, then any > information deemed consumable by the general public is explicitly > permitted to be sent. >=20 It=92s the word =93explicitly=94 which is confusing me. How is it =93explic= it=94 that they are permitted access to the information? Are you assuming a= specific authorization scheme or security service? Are you assuming/imposi= ng some sort of public notification? > Just being pedantic. >=20 > Perhaps the second sentence is redundant, but I do see a difference (whic= h > may be moot) in placing restrictions on what is sent vs. what can be > received. I agree. There is a difference and that the sentence is redundant. As it st= ands I find it adds more confusion and does not really add a useful benefit= . -andy > From: Andy Newton > Date: Friday, October 24, 2014 at 14:00 > To: Edward Lewis , "Hollenbeck, Scott" > , "ietf@ietf.org" , > "iesg@ietf.org" > Cc: "weirds@ietf.org" > Subject: Re: Last Call: > (Registration Data Access Protocol Query Format) to Proposed Standard >=20 >=20 >> I missed this due to all the HTML in the email... >>=20 >>>>=20 >>>> How about this? >>>>=20 >>>> OLD: >>>> "Implementers need to consider the policy and privacy implications of >>>> returning information that was not explicitly requested." >>>>=20 >>>> NEW: >>>> "Implementers need to consider the policy and privacy implications of >>>> returning information that was not explicitly requested. Clients shoul= d >>>> only receive information that they are explicitly authorized to >>>> receive." >>>=20 >>> Almost=8A=B2Servers should only send information that clients are expli= citly >>> authorized to receive.=B2 >>>=20 >>> The way it is worded is impossible to "enforce." >>=20 >> How does this work with anonymous access to public information, which is >> how this information is served today? How do I =B3explicitly" authorize = an >> anonymous user? I think the old text above is good enough and find the >> next text (both versions) to be confusing. >>=20 >> -andy From nobody Tue Oct 28 06:47:04 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BED1A88E7; Tue, 28 Oct 2014 06:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq1CDR7W4ukV; Tue, 28 Oct 2014 06:46:48 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF5D1A88EB; Tue, 28 Oct 2014 06:46:48 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 28 Oct 2014 06:46:45 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 28 Oct 2014 06:46:45 -0700 From: Edward Lewis To: Andy Newton Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlit5w6fdGggABH2wCABM7MAIAAhvuAgAW6OQD///OOgA== Date: Tue, 28 Oct 2014 13:46:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3497334403_6832519" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/vVyw_JyCRcKPePdgeudx3VReTGQ Cc: "weirds@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 13:46:56 -0000 --B_3497334403_6832519 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable (I hope HTML is off=E2=80=A6) Here=E2=80=99s my concern. Most RFCs assume the target audience is the implementer and this sentence makes it explicit. (Not being said pejorative sense, and, um, no pun intended.) For a large part of the deployment, the code will be pulled off the git-shelf by operators and put into service. The operators will be at the mercy of the developer=E2=80=99s inclusion or exclusion of knobs and meters t= o configure the code to do the right thing. The idea stuck in the back of my head is ensuring that implementers knowingly include a way for a authorization-to-send policy to be specified (made explicit), even if the policy is =E2=80=9Call can see anything.=E2=80=9D How about this then: Implementers need to consider the policy and privacy implications of returning information that was not explicitly requested. Servers ought to support means to ensure that any information sent is done in accordance with local policy, including what is found in a search. This is meant to be a reminder within the scope of =E2=80=9Cother things found while searching.=E2=80=9D Local policy is the catch-all used in DNSSEC RFCs to cover anything an operator may elect to do. From: Andy Newton Date: Tuesday, October 28, 2014 at 9:31 To: Edward Lewis Cc: Scott Hollenbeck , "ietf@ietf.org" , "iesg@ietf.org" , "weirds@ietf.org" Subject: Re: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard > >On Oct 24, 2014, at 7:03 PM, Edward Lewis wrote: > >> As far as HTML in email, I just don=E2=80=99t care anymore. ;) >>=20 >> If by =E2=80=9Cpublic information=E2=80=9D you mean information that anyone can acce= ss, >> then an anonymous user is explicitly permitted to be sent it. If by >> =E2=80=9Canonymous=E2=80=9D you mean a user without a proven identity, then any >> information deemed consumable by the general public is explicitly >> permitted to be sent. >>=20 > >It=E2=80=99s the word =E2=80=9Cexplicitly=E2=80=9D which is confusing me. How is it =E2=80=9Cexpli= cit=E2=80=9D >that they are permitted access to the information? Are you assuming a >specific authorization scheme or security service? Are you >assuming/imposing some sort of public notification? > >> Just being pedantic. >>=20 >> Perhaps the second sentence is redundant, but I do see a difference >>(which >> may be moot) in placing restrictions on what is sent vs. what can be >> received. > >I agree. There is a difference and that the sentence is redundant. As it >stands I find it adds more confusion and does not really add a useful >benefit. > >-andy > > >> From: Andy Newton >> Date: Friday, October 24, 2014 at 14:00 >> To: Edward Lewis , "Hollenbeck, Scott" >> , "ietf@ietf.org" , >> "iesg@ietf.org" >> Cc: "weirds@ietf.org" >> Subject: Re: Last Call: >> (Registration Data Access Protocol Query Format) to Proposed Standard >>=20 >>=20 >>> I missed this due to all the HTML in the email... >>>=20 >>>>>=20 >>>>> How about this? >>>>>=20 >>>>> OLD: >>>>> "Implementers need to consider the policy and privacy implications of >>>>> returning information that was not explicitly requested." >>>>>=20 >>>>> NEW: >>>>> "Implementers need to consider the policy and privacy implications of >>>>> returning information that was not explicitly requested. Clients >>>>>should >>>>> only receive information that they are explicitly authorized to >>>>> receive." >>>>=20 >>>> Almost=C5=A0=C2=B2Servers should only send information that clients are >>>>explicitly >>>> authorized to receive.=C2=B2 >>>>=20 >>>> The way it is worded is impossible to "enforce." >>>=20 >>> How does this work with anonymous access to public information, which >>>is >>> how this information is served today? How do I =C2=B3explicitly" authorize >>>an >>> anonymous user? I think the old text above is good enough and find the >>> next text (both versions) to be confusing. >>>=20 >>> -andy --B_3497334403_6832519 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQvykrMGtkTnG1dKGeW ZWkD1adqXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MjgxMzQ2NDNaMA0GCSqGSIb3DQEBAQUABIIBACcCy/KVc2c7xm11zFZICwP8nLuck1+M3Mkd EHYM+VwhKwWtPlwR/64UFkSUBL/wtYufTX5IJRVNdM/EQQmmXfcIOUx0MLboO7YueBqdtgSc 1h2OgvGj9KhiPhtAsaBb0qO8x7eD+mYzzfDc4UX8WIvtfGDaO8IqjhbOdMy4s0GKeyuRy32Z fxRUVm58nnhYB28htshGFf+QRtD4Y1oluvcMVlkV94q1mUKXS1kaUXEw+BI+GNI+UOaZSU+7 MK+tJcrGrxzgczwl5vTdGTpzl/mfOGxT4RvzmvnO5gH0AfZ9lAkHywmUwDURC0OR9RGGF7dh T+6+L7GUAUNkwcdinWs= --B_3497334403_6832519-- From nobody Tue Oct 28 07:02:24 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A559F1A8905; Tue, 28 Oct 2014 07:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzLW3jRCTsCx; Tue, 28 Oct 2014 07:02:16 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 45A411A8903; Tue, 28 Oct 2014 07:02:16 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id DF581213741; Tue, 28 Oct 2014 10:02:15 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id BF536213748; Tue, 28 Oct 2014 10:02:14 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 28 Oct 2014 10:04:40 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Tue, 28 Oct 2014 10:02:14 -0400 From: Andy Newton To: Edward Lewis Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlit5w6fdGggABH2wCABM7MAIAAhvuAgAW6OQD///OOgIAAFRiA Date: Tue, 28 Oct 2014 14:02:14 +0000 Message-ID: <8DE4FAF1-B8D9-4BA8-A840-0A7DF3C7E768@arin.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <22416930613C81489BD7484E2DFAFB90@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/VCWie5qSO4lvcSNeH1q0HqBvrDI Cc: "weirds@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 14:02:17 -0000 On Oct 28, 2014, at 9:46 AM, Edward Lewis wrote: > How about this then: >=20 > Implementers need to consider the policy and privacy implications of > returning information that was not explicitly requested. Servers ought > to support means to ensure that any information sent is done in accordanc= e > with local policy, including what is found in a search. I find this much easier to understand, and it works for me. -andy From nobody Tue Oct 28 07:20:13 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801311A8919; Tue, 28 Oct 2014 07:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv7ag4nfYbFn; Tue, 28 Oct 2014 07:19:48 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61E01A891F; Tue, 28 Oct 2014 07:18:03 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKVE+lm8RcRi+83tVBozIUY7GLeu8bOpUu@postini.com; Tue, 28 Oct 2014 07:18:25 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9SEI2TB013696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 10:18:02 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 10:17:54 -0400 From: "Hollenbeck, Scott" To: Andy Newton , Edward Lewis Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlit5w6fdGggABH2wCABM7MAIAAhvuAgAW6OQD///OOgIAAFRiA///BMcA= Date: Tue, 28 Oct 2014 14:18:01 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49507306@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <8DE4FAF1-B8D9-4BA8-A840-0A7DF3C7E768@arin.net> In-Reply-To: <8DE4FAF1-B8D9-4BA8-A840-0A7DF3C7E768@arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2x2jxNEwPXSPwE38HpBvCauamrg Cc: "weirds@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 14:19:56 -0000 > -----Original Message----- > From: Andy Newton [mailto:andy@arin.net] > Sent: Tuesday, October 28, 2014 10:02 AM > To: Edward Lewis > Cc: Hollenbeck, Scott; ietf@ietf.org; iesg@ietf.org; weirds@ietf.org > Subject: Re: Last Call: > (Registration Data Access Protocol Query Format) to Proposed Standard >=20 >=20 > On Oct 28, 2014, at 9:46 AM, Edward Lewis > wrote: >=20 > > How about this then: > > > > Implementers need to consider the policy and privacy implications of > > returning information that was not explicitly requested. Servers > ought > > to support means to ensure that any information sent is done in > accordance > > with local policy, including what is found in a search. >=20 > I find this much easier to understand, and it works for me. Same here. I'll see if I can add it after the IESG does their thing. Scott From nobody Tue Oct 28 08:45:23 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C16B1A8AAF; Tue, 28 Oct 2014 08:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLqOIOuG_59B; Tue, 28 Oct 2014 08:45:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 351D01A8944; Tue, 28 Oct 2014 08:45:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028154519.16974.28657.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 08:45:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ZmWug-IWQP5QwaEFO45h-tkuPSQ Cc: weirds@ietf.org Subject: [weirds] I-D ACTION:draft-ietf-weirds-using-http-14.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 15:45:20 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : HTTP usage in the Registration Data Access Protocol (RDAP) Author(s) : A. Newton, et al Filename : draft-ietf-weirds-using-http Pages : 19 Date : 2014-10-28 This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-weirds-using-http-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-weirds-using-http"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-10-28084519.I-D@ietf.org> --NextPart-- From nobody Tue Oct 28 08:48:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDECC1A8AEE; Tue, 28 Oct 2014 08:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP7r5LrdFR6n; Tue, 28 Oct 2014 08:47:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 232261A8AEA; Tue, 28 Oct 2014 08:47:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028154756.26393.96249.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 08:47:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/PgOZKk7guZyEhlLkmEEGXR7eVFM Cc: weirds@ietf.org Subject: [weirds] I-D ACTION:draft-ietf-weirds-json-response-11.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 15:47:58 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : JSON Responses for the Registration Data Access Protocol (RDAP) Author(s) : A. Newton, et al Filename : draft-ietf-weirds-json-response Pages : 91 Date : 2014-10-28 This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-weirds-json-response-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-weirds-json-response"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-10-28084756.I-D@ietf.org> --NextPart-- From nobody Tue Oct 28 09:02:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA521A9026 for ; Tue, 28 Oct 2014 09:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq3w2eC9F_e5; Tue, 28 Oct 2014 09:02:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A4D1A8BC5; Tue, 28 Oct 2014 09:01:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-using-http@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028160141.26369.64488.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 09:01:41 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/UrL40-95shgZs5_YB3ZZGuvIHnw Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:02:20 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ From nobody Tue Oct 28 10:07:17 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1041A9025 for ; Tue, 28 Oct 2014 10:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITcLdmh7RbrH; Tue, 28 Oct 2014 10:07:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0741A9040; Tue, 28 Oct 2014 10:07:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028170714.5223.16353.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 10:07:14 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/e7WPJxe9_T_3yKJ8nGaRT3DruNY Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 17:07:16 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ From nobody Tue Oct 28 10:12:57 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0471A8F3A for ; Tue, 28 Oct 2014 10:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhq3Tzum_Odj; Tue, 28 Oct 2014 10:12:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AA01A9078; Tue, 28 Oct 2014 10:12:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028171251.3247.25937.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 10:12:51 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/IOIhRrik62B4qWRnwgWEaVjffz4 Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 17:12:55 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ From nobody Tue Oct 28 10:23:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714091A90A7 for ; Tue, 28 Oct 2014 10:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twV_ZwEtVtgt for ; Tue, 28 Oct 2014 10:22:53 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDB41A90C1 for ; Tue, 28 Oct 2014 10:22:52 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id a1so1424625wgh.30 for ; Tue, 28 Oct 2014 10:22:51 -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=NDZ9wXGFGuyxrBJHnRTmKNaa7TJ/YiZVYsSbhYIYAT4=; b=JGYteg1rjJCNsFai/AUw+wqCr6zy7mN1TFD7aqB/mnJMuqBvbVubOCVi17mqOs6Nbr OFp18MtjJtULlTxIVlhmA8bA0u98Y4Z9RxLGGw/sx2F11IHGQ66laIuyUfnDOHoryKeW ix3xAo9A2ZKa1BtsoQV8pkg0V2Zp0QMA8dbwg/7RrdwdZWEfxqawnIFqHWV4lNtA1Uzl vAz9c08W8evsKVDFNbCh3agGc0v/PXKJUwbr+6jaq9ZVChwzYTM2vWkNmdZ/j6HIFpdu 8d/6RhIU4bdHs+RbvwwDjKYPSOXwTI+Hf2EhOiiDmr3yatWXrvuJmspSX80mgnPXzov3 1Xdg== MIME-Version: 1.0 X-Received: by 10.180.9.65 with SMTP id x1mr6415972wia.30.1414516969947; Tue, 28 Oct 2014 10:22:49 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 28 Oct 2014 10:22:49 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49507306@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <8DE4FAF1-B8D9-4BA8-A840-0A7DF3C7E768@arin.net> <831693C2CDA2E849A7D7A712B24E257F49507306@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Tue, 28 Oct 2014 10:22:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=001a11c245ca85ca7405067ee5b3 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/4pvWX0reK2AN3u5tmk3qS_vFhco Cc: Edward Lewis , "weirds@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 17:22:57 -0000 --001a11c245ca85ca7405067ee5b3 Content-Type: text/plain; charset=UTF-8 [trimming] Pete, could you do this as an RFC Editor note, make it a YES comment, or do a "Point raised" so we have a chance to fix it before it goes to the RFC Editor? -MSK On Tue, Oct 28, 2014 at 7:18 AM, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: Andy Newton [mailto:andy@arin.net] > > Sent: Tuesday, October 28, 2014 10:02 AM > > To: Edward Lewis > > Cc: Hollenbeck, Scott; ietf@ietf.org; iesg@ietf.org; weirds@ietf.org > > Subject: Re: Last Call: > > (Registration Data Access Protocol Query Format) to Proposed Standard > > > > > > On Oct 28, 2014, at 9:46 AM, Edward Lewis > > wrote: > > > > > How about this then: > > > > > > Implementers need to consider the policy and privacy implications of > > > returning information that was not explicitly requested. Servers > > ought > > > to support means to ensure that any information sent is done in > > accordance > > > with local policy, including what is found in a search. > > > > I find this much easier to understand, and it works for me. > > Same here. I'll see if I can add it after the IESG does their thing. > > Scott > > --001a11c245ca85ca7405067ee5b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[trimming]

Pete, could you do this as an RFC E= ditor note, make it a YES comment, or do a "Point raised" so we h= ave a chance to fix it before it goes to the RFC Editor?

-MSK<= br>

On T= ue, Oct 28, 2014 at 7:18 AM, Hollenbeck, Scott <shollenbeck@verisig= n.com> wrote:
> -----Original Message-----
> From: Andy Newton [mailto:andy@arin.n= et]
> Sent: Tuesday, October 28, 2014 10:02 AM
> To: Edward Lewis
> Cc: Hollenbeck, Scott; ietf@ietf.org<= /a>; iesg@ietf.org; weirds@ietf.org
> Subject: Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt> > (Registration Data Access Protocol Query Format) to Proposed Standard<= br> >
>
> On Oct 28, 2014, at 9:46 AM, Edward Lewis <= edward.lewis@icann.org> > wrote:
>
> > How about this then:
> >
> > Implementers need to consider the policy and privacy implications= of
> > returning information that was not explicitly requested.=C2=A0 Se= rvers
> ought
> > to support means to ensure that any information sent is done in > accordance
> > with local policy, including what is found in a search.
>
> I find this much easier to understand, and it works for me.

Same here. I'll see if I can add it after the IESG does their th= ing.

Scott


--001a11c245ca85ca7405067ee5b3-- From nobody Tue Oct 28 10:24:41 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868F71A90A5 for ; Tue, 28 Oct 2014 10:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI877DsB03zc for ; Tue, 28 Oct 2014 10:24:37 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597461A90A8 for ; Tue, 28 Oct 2014 10:24:27 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so1408969wgg.28 for ; Tue, 28 Oct 2014 10:24:25 -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=u8jATY7X852aij9syxCNqg/AXGJMMQlz5odC/cHMe2s=; b=XbryWnPI6hIWFkDHKu1CnK4qYAqWmirNbpeMQw1bIZYS019WJa7AVzWecTtf2zVy1j c/8W+7kxG7SXF+GvXbdme5jYckgjILzUdJoiEJ+gp89JnR6/gC2J3HpJuxpjrUOZ4LGo VfUV6NCk/Vg0iMmnnURy5p5QMe/saIMWNdqerV5qiaeB84VwGQe3vQwIojknXmyYpcJQ CpQXIPooaJTVtbnt7yubNb1nax2fnAn0An2e/9dVbauIuUDowFpjCUZbpeFvebBGsSel cizCBBy/5k88EsQLbSbUHyuFBfW0yIE002LeiIrMVgZHjdC0FpZXbrxtlycDn1kf3tBS doTw== MIME-Version: 1.0 X-Received: by 10.194.157.137 with SMTP id wm9mr6100042wjb.5.1414517065522; Tue, 28 Oct 2014 10:24:25 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 28 Oct 2014 10:24:25 -0700 (PDT) Date: Tue, 28 Oct 2014 10:24:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e013c6b6838244805067eeb4e Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/GXtHUFFZKb3EiOh8MS7nYQ9mRiw Subject: [weirds] Keeping score X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 17:24:39 -0000 --089e013c6b6838244805067eeb4e Content-Type: text/plain; charset=UTF-8 Colleagues, IESG Evaluation of the WEIRDS documents has begun. The telechat occurs Thursday morning, but some ADs are already balloting. You can view the current state of things here: https://datatracker.ietf.org/wg/weirds/documents/ For those unfamiliar, every document needs at least 10 green votes ("Yes" or "No Objection") with no red votes ("Discuss") to get approved for publication as an RFC. -MSK --089e013c6b6838244805067eeb4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

IESG Evaluation of the WEIRDS= documents has begun.=C2=A0 The telechat occurs Thursday morning, but some = ADs are already balloting.=C2=A0 You can view the current state of things h= ere:

h= ttps://datatracker.ietf.org/wg/weirds/documents/

For those= unfamiliar, every document needs at least 10 green votes ("Yes" = or "No Objection") with no red votes ("Discuss") to get= approved for publication as an RFC.

-MSK
--089e013c6b6838244805067eeb4e-- From nobody Tue Oct 28 10:36:24 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA0F1A914A for ; Tue, 28 Oct 2014 10:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qcm61v9ubB5i for ; Tue, 28 Oct 2014 10:36:16 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345D61A9136 for ; Tue, 28 Oct 2014 10:34:07 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVE/TjsJ7L9FEPn3E/eRgWG420UOInWQn@postini.com; Tue, 28 Oct 2014 10:34:29 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9SHY59C004080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 13:34:06 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 13:33:58 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP6iOh+ufVYqwER0OTXIBMYRlit5w6fdGggABH2wCABM7MAIAAhvuAgAW6OQD///OOgIAAFRiA///BMcCAAHbbgP//vyjw Date: Tue, 28 Oct 2014 17:34:05 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49507704@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <8DE4FAF1-B8D9-4BA8-A840-0A7DF3C7E768@arin.net> <831693C2CDA2E849A7D7A712B24E257F49507306@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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_831693C2CDA2E849A7D7A712B24E257F49507704BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/qwstbelGKzyz3po8Xde84qJtVYU Cc: Edward Lewis , "weirds@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 17:36:19 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F49507704BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWZ0ZXIgcmUtcmVhZGluZyB0aGUgc3VnZ2VzdGVkIHRleHQgSeKAmWQgYWN0dWFsbHkgbGlrZSB0 byBjaGFuZ2UgaXQuIFBsZWFzZSBkb27igJl0IGRvIGFueXRoaW5nIHRvIGNvbW1pdCBpdCBhcy1p cy4NCg0KT0xEOg0KSW1wbGVtZW50ZXJzIG5lZWQgdG8gY29uc2lkZXIgdGhlIHBvbGljeSBhbmQg cHJpdmFjeSBpbXBsaWNhdGlvbnMgb2YgcmV0dXJuaW5nIGluZm9ybWF0aW9uIHRoYXQgd2FzIG5v dCBleHBsaWNpdGx5IHJlcXVlc3RlZC4gIFNlcnZlcnMgb3VnaHQgdG8gc3VwcG9ydCBtZWFucyB0 byBlbnN1cmUgdGhhdCBhbnkgaW5mb3JtYXRpb24gc2VudCBpcyBkb25lIGluIGFjY29yZGFuY2Ug d2l0aCBsb2NhbCBwb2xpY3ksIGluY2x1ZGluZyB3aGF0IGlzIGZvdW5kIGluIGEgc2VhcmNoLg0K DQpORVc6DQpJbXBsZW1lbnRlcnMgbmVlZCB0byBjb25zaWRlciB0aGUgcG9saWN5IGFuZCBwcml2 YWN5IGltcGxpY2F0aW9ucyBvZiByZXR1cm5pbmcgaW5mb3JtYXRpb24gdGhhdCB3YXMgbm90IGV4 cGxpY2l0bHkgcmVxdWVzdGVkLiAgU2VydmVycyBuZWVkIHRvIGVuc3VyZSB0aGF0IGFueSBpbmZv cm1hdGlvbiBzZW50LCBpbmNsdWRpbmcgc2VhcmNoIHJlc3VsdHMsIGlzIHJldHVybmVkIGluIGFj Y29yZGFuY2Ugd2l0aCBsb2NhbCBwb2xpY3kuDQoNClNjb3R0DQoNCkZyb206IE11cnJheSBTLiBL dWNoZXJhd3kgW21haWx0bzpzdXBlcnVzZXJAZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgT2N0 b2JlciAyOCwgMjAxNCAxOjIzIFBNDQpUbzogSG9sbGVuYmVjaywgU2NvdHQNCkNjOiBBbmR5IE5l d3RvbjsgRWR3YXJkIExld2lzOyB3ZWlyZHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBMYXN0IENh bGw6IDxkcmFmdC1pZXRmLXdlaXJkcy1yZGFwLXF1ZXJ5LTE1LnR4dD4gKFJlZ2lzdHJhdGlvbiBE YXRhIEFjY2VzcyBQcm90b2NvbCBRdWVyeSBGb3JtYXQpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoN Clt0cmltbWluZ10NCg0KUGV0ZSwgY291bGQgeW91IGRvIHRoaXMgYXMgYW4gUkZDIEVkaXRvciBu b3RlLCBtYWtlIGl0IGEgWUVTIGNvbW1lbnQsIG9yIGRvIGEgIlBvaW50IHJhaXNlZCIgc28gd2Ug aGF2ZSBhIGNoYW5jZSB0byBmaXggaXQgYmVmb3JlIGl0IGdvZXMgdG8gdGhlIFJGQyBFZGl0b3I/ DQotTVNLDQoNCk9uIFR1ZSwgT2N0IDI4LCAyMDE0IGF0IDc6MTggQU0sIEhvbGxlbmJlY2ssIFNj b3R0IDxzaG9sbGVuYmVja0B2ZXJpc2lnbi5jb208bWFpbHRvOnNob2xsZW5iZWNrQHZlcmlzaWdu LmNvbT4+IHdyb3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmR5 IE5ld3RvbiBbbWFpbHRvOmFuZHlAYXJpbi5uZXQ8bWFpbHRvOmFuZHlAYXJpbi5uZXQ+XQ0KPiBT ZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI4LCAyMDE0IDEwOjAyIEFNDQo+IFRvOiBFZHdhcmQgTGV3 aXMNCj4gQ2M6IEhvbGxlbmJlY2ssIFNjb3R0OyBpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGll dGYub3JnPjsgaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz47IHdlaXJkc0BpZXRm Lm9yZzxtYWlsdG86d2VpcmRzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogTGFzdCBDYWxsOiA8 ZHJhZnQtaWV0Zi13ZWlyZHMtcmRhcC1xdWVyeS0xNS50eHQ+DQo+IChSZWdpc3RyYXRpb24gRGF0 YSBBY2Nlc3MgUHJvdG9jb2wgUXVlcnkgRm9ybWF0KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPg0K Pg0KPiBPbiBPY3QgMjgsIDIwMTQsIGF0IDk6NDYgQU0sIEVkd2FyZCBMZXdpcyA8ZWR3YXJkLmxl d2lzQGljYW5uLm9yZzxtYWlsdG86ZWR3YXJkLmxld2lzQGljYW5uLm9yZz4+DQo+IHdyb3RlOg0K Pg0KPiA+IEhvdyBhYm91dCB0aGlzIHRoZW46DQo+ID4NCj4gPiBJbXBsZW1lbnRlcnMgbmVlZCB0 byBjb25zaWRlciB0aGUgcG9saWN5IGFuZCBwcml2YWN5IGltcGxpY2F0aW9ucyBvZg0KPiA+IHJl dHVybmluZyBpbmZvcm1hdGlvbiB0aGF0IHdhcyBub3QgZXhwbGljaXRseSByZXF1ZXN0ZWQuICBT ZXJ2ZXJzDQo+IG91Z2h0DQo+ID4gdG8gc3VwcG9ydCBtZWFucyB0byBlbnN1cmUgdGhhdCBhbnkg aW5mb3JtYXRpb24gc2VudCBpcyBkb25lIGluDQo+IGFjY29yZGFuY2UNCj4gPiB3aXRoIGxvY2Fs IHBvbGljeSwgaW5jbHVkaW5nIHdoYXQgaXMgZm91bmQgaW4gYSBzZWFyY2guDQo+DQo+IEkgZmlu ZCB0aGlzIG11Y2ggZWFzaWVyIHRvIHVuZGVyc3RhbmQsIGFuZCBpdCB3b3JrcyBmb3IgbWUuDQoN ClNhbWUgaGVyZS4gSSdsbCBzZWUgaWYgSSBjYW4gYWRkIGl0IGFmdGVyIHRoZSBJRVNHIGRvZXMg dGhlaXIgdGhpbmcuDQoNClNjb3R0DQoNCg== --_000_831693C2CDA2E849A7D7A712B24E257F49507704BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWZ0ZXIg cmUtcmVhZGluZyB0aGUgc3VnZ2VzdGVkIHRleHQgSeKAmWQgYWN0dWFsbHkgbGlrZSB0byBjaGFu Z2UgaXQuIFBsZWFzZSBkb27igJl0IGRvIGFueXRoaW5nIHRvIGNvbW1pdCBpdCBhcy1pcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0xEOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW1wbGVtZW50 ZXJzIG5lZWQgdG8gY29uc2lkZXIgdGhlIHBvbGljeSBhbmQgcHJpdmFjeSBpbXBsaWNhdGlvbnMg b2YgcmV0dXJuaW5nIGluZm9ybWF0aW9uIHRoYXQgd2FzIG5vdCBleHBsaWNpdGx5IHJlcXVlc3Rl ZC4mbmJzcDsgU2VydmVycyBvdWdodCB0byBzdXBwb3J0IG1lYW5zIHRvIGVuc3VyZSB0aGF0DQog YW55IGluZm9ybWF0aW9uIHNlbnQgaXMgZG9uZSBpbiBhY2NvcmRhbmNlIHdpdGggbG9jYWwgcG9s aWN5LCBpbmNsdWRpbmcgd2hhdCBpcyBmb3VuZCBpbiBhIHNlYXJjaC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+TkVXOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbXBsZW1lbnRlcnMgbmVlZCB0 byBjb25zaWRlciB0aGUgcG9saWN5IGFuZCBwcml2YWN5IGltcGxpY2F0aW9ucyBvZiByZXR1cm5p bmcgaW5mb3JtYXRpb24gdGhhdCB3YXMgbm90IGV4cGxpY2l0bHkgcmVxdWVzdGVkLiZuYnNwOyBT ZXJ2ZXJzIG5lZWQgdG8gZW5zdXJlIHRoYXQgYW55IGluZm9ybWF0aW9uIHNlbnQsDQogaW5jbHVk aW5nIHNlYXJjaCByZXN1bHRzLCBpcyByZXR1cm5lZCBpbiBhY2NvcmRhbmNlIHdpdGggbG9jYWwg cG9saWN5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNjb3R0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBNdXJyYXkgUy4gS3VjaGVyYXd5IFttYWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDI4LCAyMDE0IDE6MjMgUE08 YnI+DQo8Yj5Ubzo8L2I+IEhvbGxlbmJlY2ssIFNjb3R0PGJyPg0KPGI+Q2M6PC9iPiBBbmR5IE5l d3RvbjsgRWR3YXJkIExld2lzOyB3ZWlyZHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtd2VpcmRzLXJkYXAtcXVlcnktMTUudHh0Jmd0 OyAoUmVnaXN0cmF0aW9uIERhdGEgQWNjZXNzIFByb3RvY29sIFF1ZXJ5IEZvcm1hdCkgdG8gUHJv cG9zZWQgU3RhbmRhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+W3RyaW1taW5n XTxicj4NCjxicj4NClBldGUsIGNvdWxkIHlvdSBkbyB0aGlzIGFzIGFuIFJGQyBFZGl0b3Igbm90 ZSwgbWFrZSBpdCBhIFlFUyBjb21tZW50LCBvciBkbyBhICZxdW90O1BvaW50IHJhaXNlZCZxdW90 OyBzbyB3ZSBoYXZlIGEgY2hhbmNlIHRvIGZpeCBpdCBiZWZvcmUgaXQgZ29lcyB0byB0aGUgUkZD IEVkaXRvcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4tTVNLPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE9jdCAyOCwgMjAxNCBhdCA3OjE4IEFNLCBIb2xs ZW5iZWNrLCBTY290dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNob2xsZW5iZWNrQHZlcmlzaWduLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnNob2xsZW5iZWNrQHZlcmlzaWduLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9t OiBBbmR5IE5ld3RvbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphbmR5QGFyaW4ubmV0Ij5hbmR5 QGFyaW4ubmV0PC9hPl08YnI+DQomZ3Q7IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjgsIDIwMTQg MTA6MDIgQU08YnI+DQomZ3Q7IFRvOiBFZHdhcmQgTGV3aXM8YnI+DQomZ3Q7IENjOiBIb2xsZW5i ZWNrLCBTY290dDsgPGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8 L2E+OyA8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+DQppZXNnQGlldGYub3JnPC9hPjsg PGEgaHJlZj0ibWFpbHRvOndlaXJkc0BpZXRmLm9yZyI+d2VpcmRzQGlldGYub3JnPC9hPjxicj4N CiZndDsgU3ViamVjdDogUmU6IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtd2VpcmRzLXJkYXAt cXVlcnktMTUudHh0Jmd0Ozxicj4NCiZndDsgKFJlZ2lzdHJhdGlvbiBEYXRhIEFjY2VzcyBQcm90 b2NvbCBRdWVyeSBGb3JtYXQpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IE9uIE9jdCAyOCwgMjAxNCwgYXQgOTo0NiBBTSwgRWR3YXJkIExld2lzICZs dDs8YSBocmVmPSJtYWlsdG86ZWR3YXJkLmxld2lzQGljYW5uLm9yZyI+ZWR3YXJkLmxld2lzQGlj YW5uLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IEhvdyBhYm91dCB0aGlzIHRoZW46PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEltcGxl bWVudGVycyBuZWVkIHRvIGNvbnNpZGVyIHRoZSBwb2xpY3kgYW5kIHByaXZhY3kgaW1wbGljYXRp b25zIG9mPGJyPg0KJmd0OyAmZ3Q7IHJldHVybmluZyBpbmZvcm1hdGlvbiB0aGF0IHdhcyBub3Qg ZXhwbGljaXRseSByZXF1ZXN0ZWQuJm5ic3A7IFNlcnZlcnM8YnI+DQomZ3Q7IG91Z2h0PGJyPg0K Jmd0OyAmZ3Q7IHRvIHN1cHBvcnQgbWVhbnMgdG8gZW5zdXJlIHRoYXQgYW55IGluZm9ybWF0aW9u IHNlbnQgaXMgZG9uZSBpbjxicj4NCiZndDsgYWNjb3JkYW5jZTxicj4NCiZndDsgJmd0OyB3aXRo IGxvY2FsIHBvbGljeSwgaW5jbHVkaW5nIHdoYXQgaXMgZm91bmQgaW4gYSBzZWFyY2guPGJyPg0K Jmd0Ozxicj4NCiZndDsgSSBmaW5kIHRoaXMgbXVjaCBlYXNpZXIgdG8gdW5kZXJzdGFuZCwgYW5k IGl0IHdvcmtzIGZvciBtZS48YnI+DQo8YnI+DQpTYW1lIGhlcmUuIEknbGwgc2VlIGlmIEkgY2Fu IGFkZCBpdCBhZnRlciB0aGUgSUVTRyBkb2VzIHRoZWlyIHRoaW5nLjxicj4NCjxzcGFuIHN0eWxl PSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5TY290dDwvc3Bhbj48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_831693C2CDA2E849A7D7A712B24E257F49507704BRN1WNEXMBX01vc_-- From nobody Tue Oct 28 12:36:28 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94491ACCEB for ; Tue, 28 Oct 2014 12:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A37H177Pzczi for ; Tue, 28 Oct 2014 12:36:14 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665BD1ACCE1 for ; Tue, 28 Oct 2014 12:36:11 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 28 Oct 2014 12:36:07 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 28 Oct 2014 12:36:07 -0700 From: Edward Lewis To: "Hollenbeck, Scott" , "Murray S. Kucherawy" Thread-Topic: Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard Thread-Index: AQHP8tVwkHicvWE52kKxVnzSHrUIx5xGGXGA Date: Tue, 28 Oct 2014 19:36:07 +0000 Message-ID: References: <8DE4FAF1-B8D9-4BA8-A840-0A7DF3C7E768@arin.net> <831693C2CDA2E849A7D7A712B24E257F49507306@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49507704@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49507704@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3497355363_8084531" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/jlyE83oceFoU4lHeThIhnkRaKBM Cc: "weirds@ietf.org" Subject: Re: [weirds] Last Call: (Registration Data Access Protocol Query Format) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:36:25 -0000 --B_3497355363_8084531 Content-type: multipart/alternative; boundary="B_3497355363_8089278" --B_3497355363_8089278 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable FWIW, I=E2=80=99m fine with the change. From: , Scott Date: Tuesday, October 28, 2014 at 13:34 To: "Murray S. Kucherawy" Cc: Andy Newton , Edward Lewis , "weirds@ietf.org" Subject: RE: Last Call: (Registratio= n Data Access Protocol Query Format) to Proposed Standard > After re-reading the suggested text I=E2=80=99d actually like to change it. Ple= ase > don=E2=80=99t do anything to commit it as-is. > =20 > OLD: > Implementers need to consider the policy and privacy implications of retu= rning > information that was not explicitly requested. Servers ought to support = means > to ensure that any information sent is done in accordance with local poli= cy, > including what is found in a search. > =20 > NEW:=20 > Implementers need to consider the policy and privacy implications of retu= rning > information that was not explicitly requested. Servers need to ensure th= at > any information sent, including search results, is returned in accordance= with > local policy. > =20 > Scott > =20 >=20 > From: Murray S. Kucherawy [mailto:superuser@gmail.com] > Sent: Tuesday, October 28, 2014 1:23 PM > To: Hollenbeck, Scott > Cc: Andy Newton; Edward Lewis; weirds@ietf.org > Subject: Re: Last Call: (Registrati= on > Data Access Protocol Query Format) to Proposed Standard > =20 >=20 > [trimming] >=20 > Pete, could you do this as an RFC Editor note, make it a YES comment, or = do a > "Point raised" so we have a chance to fix it before it goes to the RFC Ed= itor? > -MSK >=20 > =20 >=20 > On Tue, Oct 28, 2014 at 7:18 AM, Hollenbeck, Scott > wrote: >> > -----Original Message----- >> > From: Andy Newton [mailto:andy@arin.net] >> > Sent: Tuesday, October 28, 2014 10:02 AM >> > To: Edward Lewis >> > Cc: Hollenbeck, Scott; ietf@ietf.org; iesg@ietf.org; weirds@ietf.org >> > Subject: Re: Last Call: >> > (Registration Data Access Protocol Query Format) to Proposed Standard >> > >> > >> > On Oct 28, 2014, at 9:46 AM, Edward Lewis >> > wrote: >> > >>> > > How about this then: >>> > > >>> > > Implementers need to consider the policy and privacy implications o= f >>> > > returning information that was not explicitly requested. Servers >> > ought >>> > > to support means to ensure that any information sent is done in >> > accordance >>> > > with local policy, including what is found in a search. >> > >> > I find this much easier to understand, and it works for me. >=20 > Same here. I'll see if I can add it after the IESG does their thing. >=20 > Scott > =20 --B_3497355363_8089278 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
FWIW, I’m fine with the= change.

From: <H= ollenbeck>, Scott <shollenbe= ck@verisign.com>
Date: Tues= day, October 28, 2014 at 13:34
To: = "Murray S. Kucherawy" <superuser@gm= ail.com>
Cc: Andy Newton &l= t;andy@arin.net>, Edward Lewis <edward.lewis@icann.org>, "weirds@ietf.org" <weirds@ietf.org>
Subject: = RE: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registra= tion Data Access Protocol Query Format) to Proposed Standard
<= br>

After re-reading the suggest= ed text I’d actually like to change it. Please don’t do anything= to commit it as-is.

 

OLD:

Im= plementers need to consider the policy and privacy implications of returning= information that was not explicitly requested.  Servers ought to suppo= rt means to ensure that any information sent is done in accordance with local policy, including wh= at is found in a search.

 <= /o:p>

NEW:

Implementers need to consider the p= olicy and privacy implications of returning information that was not explici= tly requested.  Servers need to ensure that any information sent, including search results, is returned in accordance with local policy.

 

Scott

<= span style=3D"font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"> 

From: Murray S. Kucherawy = [mailto:superuser@gmail.com]
Sent: Tuesday, October 28, 2014 1:23 PM
To: Hollenbeck= , Scott
Cc: Andy Newton; Edward Lewis; weirds@ietf.org
Subject: Re: Last Call: <draft-ietf-w= eirds-rdap-query-15.txt> (Registration Data Access Protocol Query Format)= to Proposed Standard

=  

[trimming]

Pete, could you do this as an RFC Editor note, make it a YES comment, or do= a "Point raised" so we have a chance to fix it before it goes to the RFC Ed= itor?

= -MSK

 

On Tue, Oct 28, 2014 at 7:18 AM, Hollenbeck, Scott <= ;shollenbeck@veris= ign.com> wrote:

> -----Original Message-----
> From: Andy Newton [mailto:andy@arin.net= ]
> Sent: Tuesday, October 28, 2014 10:02 AM
> To: Edward Lewis
> Cc: Hollenbeck, Scott; ietf@ietf.org; iesg@ietf.org; weirds@ietf.org
= > Subject: Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt> > (Registration Data Access Protocol Query Format) to Proposed Standard<= br> >
>
> On Oct 28, 2014, at 9:46 AM, Edward Lewis <edward.lewis@icann.org>
> wrote:
>
> > How about this then:
> >
> > Implementers need to consider the policy and privacy implications= of
> > returning information that was not explicitly requested.  Se= rvers
> ought
> > to support means to ensure that any information sent is done in > accordance
> > with local policy, including what is found in a search.
>
> I find this much easier to understand, and it works for me.

Same here. I'll see if I can add it after the IESG does their thing.

Scott

 

 --B_3497355363_8089278-- --B_3497355363_8084531 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSaG+sDWoXBDonXdn4T Q/R9/05ZAjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MjgxOTM2MDNaMA0GCSqGSIb3DQEBAQUABIIBAEgrgOxfkgcCvoX8wJtU+vCBPCbDN5UBpwVJ K6qknbAXHGptx009U7fMKfAndX6Ldd4OLVMNlSJlRXp4nYjHdbnz0yh90+xM6wj6fAqgDnx4 6cDO2dvjKOfuEC0PagyWOK7joFkr/bIZBQEsNBy0mj+hrtE43ChR80ACuLinBiXSSmPO4Eht FuDbUTXzpLllQPPrKx9I+Sb0HLPhgv7s4VO2JPpsu0vAqSLFbL0lCJYkAhhGJyFpn8ktoMfJ o3RNT4CSVuzUl+t2p/pTyCh/tqSzz2qoK3hK8DPUeMmHUenXqEE4iHov65VA7fu7vD++GeJW j/bE4ErTWQjSci7tk6Q= --B_3497355363_8084531-- From nobody Tue Oct 28 16:14:11 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBDB1A1AFD; Tue, 28 Oct 2014 16:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXqjNMwkTg67; Tue, 28 Oct 2014 16:14:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CA01A1AE3; Tue, 28 Oct 2014 16:14:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 16:14:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/UGz2NGLyR5M6351KceY7HA8yNDs Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 23:14:05 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-weirds-rdap-query-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- = Section 3.2.3 = If I'm reading the document correctly, when searching for an entity, the search pattern is expected to represent an entity using the syntax specified in Section 6.1 of draft-ietf-weirds-json-response. But when the path segment is provided, rather than a search, Section 3.1.5 says this: The parameter represents an entity (such as a contact, registrant, or registrar) identifier whose syntax is specific to the registration provider. For example, for some DNRs contact identifiers are specified in RFC 5730 [RFC5730] and RFC 5733 [RFC5733]. This makes it seem as if an entity in a path segment uses different syntax (actually, non-standard syntax that is up to the registration provider) than an entity that someone might search for. Is there some specific field in the entity definition in draft-ietf-weirds-json-response that is supposed to correspond to? Aren't HTTP GETs for both path segments and searches meant to provide responses based on the same underlying data? If so, I don't understand why there is a specified syntax for entities in one but not the other. This also seems inconsistent with the following text in Section 6.1 of draft-ietf-weirds-json-response: The entity object class appears throughout this document and is an appropriate response for the /entity/XXXX query defined in Registration Data Access Protocol Lookup Format [I-D.ietf-weirds-rdap-query] ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 3 = "The query URL is constructed by concatenating the base URL to the help path segment specified in either Section 3.1.6." The "either" is extraneous, or there is some other section missing at the end of this sentence. = Section 4.2 and Section 8: I think it would be helpful here to point out that the identity/authorization of the searcher may be a relevant factor in determining how broad the response set should be for any particular query (and not just a single static policy that applies to all searchers equally). From nobody Tue Oct 28 16:14:57 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259FE1A1B03; Tue, 28 Oct 2014 16:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBwukjVr1D9n; Tue, 28 Oct 2014 16:14:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0FB1A1A64; Tue, 28 Oct 2014 16:14:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028231454.16979.8007.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 16:14:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/R8VWgndlZ6XAZM_fTcYJFZzkwAg Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-json-response@tools.ietf.org Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 23:14:55 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-weirds-json-response-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think this document is missing a discussion of the fact that while jCard was selected as the format for entity representation because it can flexibly accommodate the spectrum of the kinds of entities that require representation in RDAP, the full jCard specification includes many fields that are unrelated to the uses of the RDAP protocol and therefore not expected to be stored or made available by servers. This is a different point than the point made in Appendix A.1 (which should really be in Section 14 IMO) about the use of status values, which implies that the fields exist in the server-side database but are not shared in certain circumstances. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 3.2 = I love an idiom as much as the next person, but it would be better to use names in examples that are not culturally specific. = Section 4 = The reference to I-D.ietf-jcardcal-jcard should be replaced with RFC 7095, I think. = Section 6.1 = Following on from my DISCUSS, I know the example in this section is just an example, but it includes all kinds of information about Joe User that no registry should be asking for and no registrant should willingly provide (gender? anniversary? really?!). It would be nice for the example to reflect what reality might/should actually be like. From nobody Tue Oct 28 16:15:52 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F4B1A1B0B; Tue, 28 Oct 2014 16:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gph01ZeysvFi; Tue, 28 Oct 2014 16:15:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AE61A1A64; Tue, 28 Oct 2014 16:15:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 16:15:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/X3UeXTRQyayVHZZo4nZfKHofU7c Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 23:15:49 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-weirds-rdap-sec-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- = General comment = I'm not exactly sure which document this remark is directed at, but I'm putting it in a DISCUSS here and we can figure that out later. I feel like the RDAP document suite is missing an overall explanation of the privacy threat model associated with registration data, the policy choices that are left up to registry providers, and the mechanisms included in RDAP to help protect registrant and client/user privacy and facilitate those policy choices. There are mentions of some of this here and there, but even those are not necessarily consistent with each other (see my DISCUSS on draft-ietf-weirds-using-http). So I think it would be beneficial to capture this in one place and articulate it explicitly, rather than implicitly across the documents. Some of the salient points for starters: * WHOIS data has historically included personal information about registrants, has been made public, and has not had the benefit of authentication or access control mechanisms to gate access to it. In part as a result of this, proxy and privacy services have arisen to shield the identities of registrants. * The standardization of RDAP does not change or impact the data that registries may require to be collected from registrants. However, RDAP data structures allow servers to indicate when data returned to clients has been made private, redacted, obscured, or shielded by a proxy. * RDAP uses the jCard standard format for entity representation, but many of the jCard fields are irrelevant for registry operation purposes and their use should be minimized. * RDAP includes mechanisms that can be used to authenticate clients, allowing servers to support tiered access based on local policy. This means that all registration data need no longer be public, and personal data or data that may be considered more sensitive can have its access restricted to specifically privileged clients. * [Something about confidentiality of requests and responses ... see my other DISCUSS point below.] * etc. = Section 3.4 = "If the policy of the server operator requires encryption to protect client-server data exchanges (such as to protect non-public data that can not be accessed without client identification and authentication), HTTP Over TLS MUST be used to protect those exchanges." It is unclear to me that a server policy that allows unencrypted access should be allowed, particularly in the cases of entity-related requests, but perhaps also in the case of other requests. The fact that the registry data may be public is orthogonal to the question of whether a particular query for that data should have confidentiality protection. I'd like to understand why RDAP does not require HTTP over TLS to be used in all cases and instead allows unsuspecting client users to send their queries in the clear in cases where server policy does not mandate use of TLS. I'm especially curious about this since clients are required to support HTTPS anyway. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 3.1 = "RDAP's authentication framework needs to accommodate anonymous access as well as verification of identities" I would suggest s/anonymous access/unauthenticated access/ since generally it can be pretty difficult to remain anonymous when accessing anything over IP. Similar comment for 3.2, I would delete "or anonymous." From nobody Tue Oct 28 16:17:02 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1D61A1B07; Tue, 28 Oct 2014 16:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22IKCALt7c-1; Tue, 28 Oct 2014 16:17:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9FD1A1B0B; Tue, 28 Oct 2014 16:17:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028231700.11097.11887.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 16:17:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/0GDUAKhDm19z_CZEyjM4FMwfvSo Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-using-http@tools.ietf.org Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-using-http-14: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 23:17:01 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-weirds-using-http-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- = Section 5.6 = "When responding to queries, it is RECOMMENDED that servers use the Access-Control-Allow-Origin header field, as specified by [W3C.CR-cors-20130129]. As the use of RDAP is for public resources, a value of "*" is suitable for most cases." What is the use case for cross-site RDAP queries? Also, I am confused by the claim in the second sentence. The message that I got from draft-ietf-weirds-rdap-sec and draft-ietf-weirds-json-response is that one of the motivations for using HTTP for RDAP was that its authentication features could be leveraged to provide tiered access to data on the server, such that some of the data would not be public but would be restricted to specific users (from draft-ietf-weirds-json-response, Appendix A.1: "In many use cases, it is necessary to hide or obscure the information of a registrant or contact due to policy or other operational matters."). So it seems like if cross-site requests are justified at all, there should be some text here explaining when that might be the case and when not. From nobody Tue Oct 28 23:33:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A151A19EB; Tue, 28 Oct 2014 23:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxPfUbyfq5Wm; Tue, 28 Oct 2014 23:33:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0746C1A0861; Tue, 28 Oct 2014 23:33:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029063322.10888.60928.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 23:33:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/D394ZePVL3f8fKlV9EL1GwqiQyI Cc: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, weirds@ietf.org Subject: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-bootstrap-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 06:33:24 -0000 Barry Leiba has entered the following ballot position for draft-ietf-weirds-bootstrap-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- DISCUSS point 1, on the clarity of the text about matching: -- Section 4 -- The matching is of labels from right to left... You and I know that, but will every reader understand that? With gTLDs upon us, will it always be clear to everyone that a registry entry of "nyc" matches "coffee.nyc", but does not match "nyc.com"? Will everyone understand that a registry entry of "example.com" matches "good.example.com", but does not match "goodexample.com"? There's also nothing said about what happens if there are multiple matches at the same specificity. What if there are two Entry Arrays that both contain "example.com"? More likely, what if someone makes an error in specifying AS numbers, we get one entry for 10000-12000 and another for 12000-14000... and then we query for 12000? It might be good to be clearer about exactly what matching is intended, and what doesn't match. Feel free to use my examples above, if that helps. ----- DISCUSS point 2: the scope of what we're asking IANA to do, and the question of whether it's really clear both to us and to them what it is, what it will entail, and what it will cost: -- Section 8 -- Clients SHOULD cache the registry, but use underlying protocol signalling, such as the HTTP Expires header field [RFC7234], to identify when it is time to refresh the cached registry. Now you're putting another requirement on IANA, which I'm not sure has been part of the discussion: they have to present the registries in the right format AND manage the TTL of the queries with the Expires header. Please, please make sure that IANA is very clear about the entire scope of what we're asking, and signs off on it. -- Section 12 -- IANA is expected to generate the RDAP Bootstrap Services Registries data from these above mentioned registries, according to their own registration policies. I presume "their" refers to the registries, not to IANA, but that's ambiguous, and should be fixed. The above-mentioned registries do not have RDAP URLs, do they? Whence is IANA meant to get that information, in order to generate these new registries? If IANA generates these by periodically re-processing the source registries to pick up changes, how current are the RDAP registries expected to be? Is it OK for them to be updated once a week? Once a month? Are we setting up any SLAs for the timeliness and reliability of these registries? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 1 -- This document requests IANA to make an augmented version of the existing registries available for the specific purpose of RDAP use I presume that IANA has agreed to do that. Where will the URIs for those augmented registries be published. That is, how will a bootstrapping application know where to find them for the bootstrapping? -- Section 3 -- The JSON object for each registry will start with a series of members that contain metadata "Start with" implies ordering, but members within JSON objects are explicitly unordered. Do you actually care about the ordering, or should you just change "start with" to "contain" (and similarly change the subsequent "Following that")? Each item of the array contains a second-level array, with two elements, each of them being a third-level array. The first third-level array, named 'Entry array', contains all entries that have the same set of base RDAP URLs. The second third- level array, named 'Service URL array', contains the list of base RDAP URLs usable for the entries found in the 'Entry array'. There is no assumption of sorting except that the two arrays found in each second-level array MUST appear in the correct order: The entries array are followed by the service URL array. This is just an editorial comment, but this description seems unnecessarily complicated, and the "no sorting, but certain things have to be in the right order" is just odd. May I make a suggestion that gets rid of the "third-level array" awkwardness (and also corrects some wording errors)?: NEW Each element of the Services array is a second-level array with two elements: in order, an Entry Array and a Service URL Array. The Entry Array contains all entries that have the same set of base RDAP URLs. The Service URL Array contains the list of base RDAP URLs usable for the entries found in the Entry Array. Elements within these two arrays are not sorted in any way. END Any unknown or unspecified JSON object properties or values should be ignored by implementers. 1. Implementers don't ignore the unrecognized things; implementations do. 2. What does it mean to ignore an unspecified thing? It's not there to be ignored. 3. The "should be" makes people wonder whether it's supposed to be a 2119 key word, and why it's not. I suggest just using "are" -- that's simply the way it is. So, maybe: Any unrecognized JSON object properties or values are ignored by implementations. -- Section 4 -- The domain names authoritative registration data service is found by doing the label-wise longest match of the target domain name with the domain values in the arrays in the IANA Domain Name RDAP Bootstrap Service Registry. The values contained in the second element of the array are the valid base RDAP URLs as described in [I-D.ietf-weirds-rdap-query]. You have names for these arrays in Section 3; why don't you use them? NEW The domain names authoritative registration data service is found by doing the label-wise longest match of the target domain name with the domain values in the Entry Arrays in the IANA Domain Name RDAP Bootstrap Service Registry. The values contained in the Service URL Array of the matching second-level array are the valid base RDAP URLs as described in [I-D.ietf-weirds-rdap-query]. END And similarly for other times when you say "first element" or "second element". I'm also thinking more and more that "longest match" should instead be "most specific match", especially for the IP address numbers. -- Section 5.1 -- Doesn't "CIDR format" need a reference? -- Section 7 -- The registries may not contain the requested value or the base RDAP URL value may be empty. Nothing up in Section 3 said that a Service URL Array could be empty. If that's legal, that fact should be specified up there. -- Section 10.2 -- In the definition of "rdap-bootstrap-registry" you should note that the "description" member is optional, probably by saying, "and an optional MEMBER description and...". From nobody Tue Oct 28 23:37:27 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6EA1A1B05; Tue, 28 Oct 2014 23:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jf7rH3aocZy; Tue, 28 Oct 2014 23:37:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D63B1A1A1C; Tue, 28 Oct 2014 23:37:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029063708.10884.33832.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 23:37:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/S-OZtG1rm-47f6XM4qDiIUVWfuo Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org Subject: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 06:37:10 -0000 Barry Leiba has entered the following ballot position for draft-ietf-weirds-rdap-query-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- -- Section 3.2.1 -- None of the syntaxes begin with "/", and then you have a examples that do. Probably should take the "/" off the examples, no? But I see that the json-response document also uses the leading slash. But but, the bootstrapping document says that the URLs MUST end with slashes, because query specifications are appended to them (therefore the query specifications don't begin with slashes). This all seems somewhat inconsistent. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 1.1 -- You have some repetition repetition in the definition of REST. I suggest adding a little to the definition of IDNA, to make it clear that it's not just a handy abbreviation, but a pointer to something specific: "Internationalized Domain Names in Applications, a protocol for the handling of IDNs." Also, some of these terms (such as NFC and NFKC) have references where they're used down below. It wouldn't be a bad idea to cite those references up here as well. -- Section 3 -- Queries are formed by retrieving the appropriate base URL from the registry This may seem picayune, but I think it should be "an appropriate base URL", not "the". There may be more than one, and the bootstrap doc says that if one doesn't work, try another. It also doesn't give any guidance on selecting from among multiple https URLs, or multiple http ones. -- Section 3.1.3 -- IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, all internationalized labels in an IDN SHOULD be either A-labels or U-labels. You think the bit after the "that is" clarifies, but I don't. I suggest that this does: NEW IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, internationalized labels in an IDN SHOULD be either all A-labels or all U-labels. END -- Section 4.1 -- Partial matching is not feasible across combinations of Unicode characters because Unicode characters can be combined with another Unicode character or characters. Servers SHOULD NOT partially match combinations of Unicode characters where a Unicode character may be legally combined with another Unicode character or characters. It should be noted, though, that it may not always be possible to detect possible cases where a character could have been combined with another character, but was not, because of the way combining characters can be combined with many other characters. I'm not going to try to re-write that myself (don't try this at home!), and I did understand it... but I have to say that it's a truly convoluted paragraph. Please see if you can say this and the subsequent paragraph in a different way without the "combined combining character characters with combined character combinations" feel to it. From nobody Tue Oct 28 23:38:31 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4921A0673; Tue, 28 Oct 2014 23:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz7IhPOMMxno; Tue, 28 Oct 2014 23:38:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F6D1A19F8; Tue, 28 Oct 2014 23:38:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029063827.10865.74501.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 23:38:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/hTK9DlRzz9D4TFCw-0DQSRVEF2Q Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Barry Leiba's No Objection on draft-ietf-weirds-rdap-sec-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 06:38:29 -0000 Barry Leiba has entered the following ballot position for draft-ietf-weirds-rdap-sec-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 3.1 -- This section describes security authentication mechanisms and their need for implementation by authorization policies. It took me a few readings to get what I think you mean. I think you mean this: NEW This section describes security authentication mechanisms and the need for authorization policies to include them. END From nobody Tue Oct 28 23:40:41 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDA21A1B17; Tue, 28 Oct 2014 23:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgqWqzeU-D-M; Tue, 28 Oct 2014 23:40:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA9B1A1AED; Tue, 28 Oct 2014 23:40:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029064038.10876.63312.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 23:40:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/J_LhsMS1MrkmFs5xEVsH-EvNFAE Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-using-http@tools.ietf.org Subject: [weirds] Barry Leiba's No Objection on draft-ietf-weirds-using-http-14: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 06:40:39 -0000 Barry Leiba has entered the following ballot position for draft-ietf-weirds-using-http-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 1 -- 2. A client issues an HTTP (or HTTPS) query using GET [RFC7231]. As an example, a query for the network registration 192.0.2.0 might be http://example.com/rdap/ip/192.0.2.0 A small point, but, strictly speaking, that is not a query: it's a query URL. The query is the full HTTP GET protocol. So either put in the HTTP query, or make it "As an example, a query URL for...". (The rdap-query document actually is careful to call them URLs every time.) Another small point: in bullet 4 you expand the abbreviation "URL". Good, but you've used "URL" twice, earlier in the document. You should expand it the first time it's used. -- Section 2 -- Yet another small point: I see that someone asked you to expand "SSAC". Cool, but that now screams out for noting that it's a committee of ICANN (which then raises the question of whether ICANN should be expanded). I'm going to duck and cover now, and just let you do what you think best here. -- Section 3 -- First, each query is meant to require only one path of execution to obtain an answer. A response may contain an answer, no answer, or a redirect, and clients are not expected to fork multiple paths of execution to satisfy a query. Do clients "satisfy" queries? I thought that clients make them, and servers satisfy them. -- Section 5.2 -- For example, if the client sends http://serv1.example.com/weirds/domain/example.com Again: strictly speaking, the client doesn't "send" that. You could say, "if the client uses". -- Section 5.3 -- Clients MAY retry the query based on the respective response code. What you probably want to say here is NEW A client MAY retry the query if that is appropriate for the respective response code. END -- Section 9.1 -- Thank you! It's always been my contention that IRIs are not part of wire protocol, and should never be sent around as IRIs. From nobody Tue Oct 28 23:42:50 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436571A1AF5; Tue, 28 Oct 2014 23:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keIEZc8dkU8d; Tue, 28 Oct 2014 23:42:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B591A1AED; Tue, 28 Oct 2014 23:42:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029064244.10900.50891.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 23:42:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/7icmz_W8_JYtqh2afPAp8m-PSuY Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-json-response@tools.ietf.org Subject: [weirds] Barry Leiba's No Objection on draft-ietf-weirds-json-response-11: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 06:42:46 -0000 Barry Leiba has entered the following ballot position for draft-ietf-weirds-json-response-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In section 9 it might be worth saying a few more words about how responses can be truncated. Until I saw the example, I was thinking that the JSON itself might be incomplete. The example made me realise that you're talking about limiting what is returned, not actually truncating what used to be a complete response. I'm OK with referring to it as "truncated", but I'd like to see just a little explanation of the situations you're talking about, so it's clear you don't just mean snipping it in the middle. From nobody Wed Oct 29 05:24:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF45E1A00A9; Wed, 29 Oct 2014 05:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62t6Q7dhp3zE; Wed, 29 Oct 2014 05:23:51 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A121A00A6; Wed, 29 Oct 2014 05:23:46 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKVFDcUW7c1m8uWOmTgTl+Rd/L5hZZxyLS@postini.com; Wed, 29 Oct 2014 05:23:50 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9TCNifQ003878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 08:23:44 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 08:23:35 -0400 From: "Hollenbeck, Scott" To: Barry Leiba , The IESG Thread-Topic: [weirds] Barry Leiba's No Objection on draft-ietf-weirds-rdap-sec-10: (with COMMENT) Thread-Index: AQHP80L1yHKJoD5CC0GzGN27WLykB5xG/33w Date: Wed, 29 Oct 2014 12:23:42 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49507F91@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141029063827.10865.74501.idtracker@ietfa.amsl.com> In-Reply-To: <20141029063827.10865.74501.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/1uTwTVh8EpkuuIv-f3ZkbfL6MIQ Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Barry Leiba's No Objection on draft-ietf-weirds-rdap-sec-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 12:23:53 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Wednesday, October 29, 2014 2:38 AM > To: The IESG > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > chairs@tools.ietf.org; weirds@ietf.org > Subject: [weirds] Barry Leiba's No Objection on draft-ietf-weirds-rdap- > sec-10: (with COMMENT) >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-weirds-rdap-sec-10: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > -- Section 3.1 -- >=20 > This section describes security authentication mechanisms and their > need for implementation by authorization policies. >=20 > It took me a few readings to get what I think you mean. I think you > mean > this: > NEW > This section describes security authentication mechanisms and the > need for authorization policies to include them. > END Agreed, your text is clearer. Thanks. Scott From nobody Wed Oct 29 05:39:43 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376071A00A9; Wed, 29 Oct 2014 05:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX7gt7cTkXKZ; Wed, 29 Oct 2014 05:39:37 -0700 (PDT) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27EE1A0076; Wed, 29 Oct 2014 05:39:32 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKVFDgBHpIElqztIPOkSedJBIgOMLpBciz@postini.com; Wed, 29 Oct 2014 05:39:36 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9TCdVjh004082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 08:39:31 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 08:39:30 -0400 From: "Hollenbeck, Scott" To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) Thread-Index: AQHP80LK4DGMzkwCmU6uwmQT25fa9ZxHAKWA Date: Wed, 29 Oct 2014 12:39:30 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49507FFD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141029063708.10884.33832.idtracker@ietfa.amsl.com> In-Reply-To: <20141029063708.10884.33832.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/BSFU8a87cQw70IJU1AhC79JpTJU Cc: "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" Subject: Re: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 12:39:39 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCYXJyeSBMZWliYSBbbWFpbHRv OmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnXQ0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjks IDIwMTQgMjozNyBBTQ0KPiBUbzogVGhlIElFU0cNCj4gQ2M6IHdlaXJkcy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc7IGRyYWZ0LWlldGYtd2VpcmRzLXJkYXAtDQo+IHF1ZXJ5QHRvb2xzLmlldGYub3Jn OyB3ZWlyZHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogQmFycnkgTGVpYmEncyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYtd2VpcmRzLXJkYXAtcXVlcnktMTY6DQo+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1F TlQpDQo+IA0KPiBCYXJyeSBMZWliYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBw b3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi13ZWlyZHMtcmRhcC1xdWVyeS0xNjogRGlzY3Vzcw0K PiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj dCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8g YW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJh Z3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwOi8vd3d3Lmll dGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtDQo+IGNyaXRlcmlhLmh0bWwNCj4gZm9yIG1v cmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4N Cj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9u cywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi13ZWlyZHMtcmRhcC1xdWVyeS8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAtLSBTZWN0aW9uIDMuMi4xIC0t DQo+IE5vbmUgb2YgdGhlIHN5bnRheGVzIGJlZ2luIHdpdGggIi8iLCBhbmQgdGhlbiB5b3UgaGF2 ZSBhIGV4YW1wbGVzIHRoYXQNCj4gZG8uICBQcm9iYWJseSBzaG91bGQgdGFrZSB0aGUgIi8iIG9m ZiB0aGUgZXhhbXBsZXMsIG5vPyAgQnV0IEkgc2VlIHRoYXQNCj4gdGhlIGpzb24tcmVzcG9uc2Ug ZG9jdW1lbnQgYWxzbyB1c2VzIHRoZSBsZWFkaW5nIHNsYXNoLiAgQnV0IGJ1dCwgdGhlDQo+IGJv b3RzdHJhcHBpbmcgZG9jdW1lbnQgc2F5cyB0aGF0IHRoZSBVUkxzIE1VU1QgZW5kIHdpdGggc2xh c2hlcywNCj4gYmVjYXVzZQ0KPiBxdWVyeSBzcGVjaWZpY2F0aW9ucyBhcmUgYXBwZW5kZWQgdG8g dGhlbSAodGhlcmVmb3JlIHRoZSBxdWVyeQ0KPiBzcGVjaWZpY2F0aW9ucyBkb24ndCBiZWdpbiB3 aXRoIHNsYXNoZXMpLiAgVGhpcyBhbGwgc2VlbXMgc29tZXdoYXQNCj4gaW5jb25zaXN0ZW50Lg0K DQpHaXZlbiB0aGUgdGV4dCBpbiBTZWN0aW9uIDMgKFBhdGggU2VnbWVudCBTcGVjaWZpY2F0aW9u KSBhbmQgdGhlIGJvb3RzdHJhcCBkb2N1bWVudCwgeWVzLCBJIHNob3VsZCByZW1vdmUgdGhlIGxl YWRpbmcgIi8iIGZyb20gdGhlIGV4YW1wbGVzLiBBbmR5IGFuZCBJIGNhbiBtYWtlIHN1cmUgdGhh dCByZGFwLXF1ZXJ5IGFuZCBqc29uLXJlc3BvbnNlIGRvIHRoaXMgY29uc2lzdGVudGx5Lg0KDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gLS0gU2Vj dGlvbiAxLjEgLS0NCj4gWW91IGhhdmUgc29tZSByZXBldGl0aW9uIHJlcGV0aXRpb24gaW4gdGhl IGRlZmluaXRpb24gb2YgUkVTVC4NCg0KT29wcywgeWVzLCB0aGF0IHNob3VsZCBiZSBmaXhlZC4N Cg0KPiBJIHN1Z2dlc3QgYWRkaW5nIGEgbGl0dGxlIHRvIHRoZSBkZWZpbml0aW9uIG9mIElETkEs IHRvIG1ha2UgaXQgY2xlYXINCj4gdGhhdCBpdCdzIG5vdCBqdXN0IGEgaGFuZHkgYWJicmV2aWF0 aW9uLCBidXQgYSBwb2ludGVyIHRvIHNvbWV0aGluZw0KPiBzcGVjaWZpYzogIkludGVybmF0aW9u YWxpemVkIERvbWFpbiBOYW1lcyBpbiBBcHBsaWNhdGlvbnMsIGEgcHJvdG9jb2wNCj4gZm9yDQo+ IHRoZSBoYW5kbGluZyBvZiBJRE5zLiINCj4gDQo+IEFsc28sIHNvbWUgb2YgdGhlc2UgdGVybXMg KHN1Y2ggYXMgTkZDIGFuZCBORktDKSBoYXZlIHJlZmVyZW5jZXMgd2hlcmUNCj4gdGhleSdyZSB1 c2VkIGRvd24gYmVsb3cuICBJdCB3b3VsZG4ndCBiZSBhIGJhZCBpZGVhIHRvIGNpdGUgdGhvc2UN Cj4gcmVmZXJlbmNlcyB1cCBoZXJlIGFzIHdlbGwuDQoNCkFncmVlZCBvbiBib3RoIHBvaW50cy4N Cg0KPiAtLSBTZWN0aW9uIDMgLS0NCj4gDQo+ICAgIFF1ZXJpZXMgYXJlDQo+ICAgIGZvcm1lZCBi eSByZXRyaWV2aW5nIHRoZSBhcHByb3ByaWF0ZSBiYXNlIFVSTCBmcm9tIHRoZSByZWdpc3RyeQ0K PiANCj4gVGhpcyBtYXkgc2VlbSBwaWNheXVuZSwgYnV0IEkgdGhpbmsgaXQgc2hvdWxkIGJlICJh biBhcHByb3ByaWF0ZSBiYXNlDQo+IFVSTCIsIG5vdCAidGhlIi4gIFRoZXJlIG1heSBiZSBtb3Jl IHRoYW4gb25lLCBhbmQgdGhlIGJvb3RzdHJhcCBkb2MNCj4gc2F5cw0KPiB0aGF0IGlmIG9uZSBk b2Vzbid0IHdvcmssIHRyeSBhbm90aGVyLiAgSXQgYWxzbyBkb2Vzbid0IGdpdmUgYW55DQo+IGd1 aWRhbmNlDQo+IG9uIHNlbGVjdGluZyBmcm9tIGFtb25nIG11bHRpcGxlIGh0dHBzIFVSTHMsIG9y IG11bHRpcGxlIGh0dHAgb25lcy4NCg0KQWdyZWVkLCAiYW4iLg0KDQo+IC0tIFNlY3Rpb24gMy4x LjMgLS0NCj4gDQo+ICAgIElETnMgU0hPVUxEIE5PVCBiZSByZXByZXNlbnRlZCBhcyBhIG1peHR1 cmUgb2YgQS1sYWJlbHMgYW5kIFUtDQo+IGxhYmVsczsNCj4gICAgdGhhdCBpcywgYWxsIGludGVy bmF0aW9uYWxpemVkIGxhYmVscyBpbiBhbiBJRE4gU0hPVUxEIGJlIGVpdGhlcg0KPiAgICBBLWxh YmVscyBvciBVLWxhYmVscy4NCj4gDQo+IFlvdSB0aGluayB0aGUgYml0IGFmdGVyIHRoZSAidGhh dCBpcyIgY2xhcmlmaWVzLCBidXQgSSBkb24ndC4gIEkNCj4gc3VnZ2VzdA0KPiB0aGF0IHRoaXMg ZG9lczoNCj4gTkVXDQo+ICAgIElETnMgU0hPVUxEIE5PVCBiZSByZXByZXNlbnRlZCBhcyBhIG1p eHR1cmUgb2YgQS1sYWJlbHMgYW5kIFUtDQo+IGxhYmVsczsNCj4gICAgdGhhdCBpcywgaW50ZXJu YXRpb25hbGl6ZWQgbGFiZWxzIGluIGFuIElETiBTSE9VTEQgYmUgZWl0aGVyIGFsbA0KPiAgICBB LWxhYmVscyBvciBhbGwgVS1sYWJlbHMuDQo+IEVORA0KDQpBZ3JlZWQuDQoNCj4gLS0gU2VjdGlv biA0LjEgLS0NCj4gDQo+ICAgIFBhcnRpYWwgbWF0Y2hpbmcgaXMgbm90IGZlYXNpYmxlIGFjcm9z cyBjb21iaW5hdGlvbnMgb2YgVW5pY29kZQ0KPiAgICBjaGFyYWN0ZXJzIGJlY2F1c2UgVW5pY29k ZSBjaGFyYWN0ZXJzIGNhbiBiZSBjb21iaW5lZCB3aXRoIGFub3RoZXINCj4gICAgVW5pY29kZSBj aGFyYWN0ZXIgb3IgY2hhcmFjdGVycy4gIFNlcnZlcnMgU0hPVUxEIE5PVCBwYXJ0aWFsbHkgbWF0 Y2gNCj4gICAgY29tYmluYXRpb25zIG9mIFVuaWNvZGUgY2hhcmFjdGVycyB3aGVyZSBhIFVuaWNv ZGUgY2hhcmFjdGVyIG1heSBiZQ0KPiAgICBsZWdhbGx5IGNvbWJpbmVkIHdpdGggYW5vdGhlciBV bmljb2RlIGNoYXJhY3RlciBvciBjaGFyYWN0ZXJzLiAgSXQNCj4gICAgc2hvdWxkIGJlIG5vdGVk LCB0aG91Z2gsIHRoYXQgaXQgbWF5IG5vdCBhbHdheXMgYmUgcG9zc2libGUgdG8NCj4gZGV0ZWN0 DQo+ICAgIHBvc3NpYmxlIGNhc2VzIHdoZXJlIGEgY2hhcmFjdGVyIGNvdWxkIGhhdmUgYmVlbiBj b21iaW5lZCB3aXRoDQo+ICAgIGFub3RoZXIgY2hhcmFjdGVyLCBidXQgd2FzIG5vdCwgYmVjYXVz ZSBvZiB0aGUgd2F5IGNvbWJpbmluZw0KPiAgICBjaGFyYWN0ZXJzIGNhbiBiZSBjb21iaW5lZCB3 aXRoIG1hbnkgb3RoZXIgY2hhcmFjdGVycy4NCj4gDQo+IEknbSBub3QgZ29pbmcgdG8gdHJ5IHRv IHJlLXdyaXRlIHRoYXQgbXlzZWxmIChkb24ndCB0cnkgdGhpcyBhdCBob21lISksDQo+IGFuZCBJ IGRpZCB1bmRlcnN0YW5kIGl0Li4uIGJ1dCBJIGhhdmUgdG8gc2F5IHRoYXQgaXQncyBhIHRydWx5 DQo+IGNvbnZvbHV0ZWQNCj4gcGFyYWdyYXBoLiAgUGxlYXNlIHNlZSBpZiB5b3UgY2FuIHNheSB0 aGlzIGFuZCB0aGUgc3Vic2VxdWVudCBwYXJhZ3JhcGgNCj4gaW4gYSBkaWZmZXJlbnQgd2F5IHdp dGhvdXQgdGhlICJjb21iaW5lZCBjb21iaW5pbmcgY2hhcmFjdGVyIGNoYXJhY3RlcnMNCj4gd2l0 aCBjb21iaW5lZCBjaGFyYWN0ZXIgY29tYmluYXRpb25zIiBmZWVsIHRvIGl0Lg0KDQpIb3cgaXMg dGhpcz8NCg0KTkVXDQpQYXJ0aWFsIG1hdGNoaW5nIGlzIG5vdCBmZWFzaWJsZSBhY3Jvc3MgY29t YmluYXRpb25zIG9mIFVuaWNvZGUgY2hhcmFjdGVycyBiZWNhdXNlIFVuaWNvZGUgY2hhcmFjdGVy cyBjYW4gYmUgY29tYmluZWQgd2l0aCBlYWNoIG90aGVyLiBTZXJ2ZXJzIFNIT1VMRCBOT1QgcGFy dGlhbGx5IG1hdGNoIGNvbWJpbmF0aW9ucyBvZiBVbmljb2RlIGNoYXJhY3RlcnMgd2hlcmUgYSBs ZWdhbCBjb21iaW5hdGlvbiBpcyBwb3NzaWJsZS4gSXQgc2hvdWxkIGJlIG5vdGVkLCB0aG91Z2gs IHRoYXQgaXQgbWF5IG5vdCBhbHdheXMgYmUgcG9zc2libGUgdG8gZGV0ZWN0IGNhc2VzIHdoZXJl IGEgY2hhcmFjdGVyIGNvdWxkIGhhdmUgYmVlbiBjb21iaW5lZCB3aXRoIGFub3RoZXIgY2hhcmFj dGVyLCBidXQgd2FzIG5vdCwgYmVjYXVzZSBjaGFyYWN0ZXJzIGNhbiBiZSBjb21iaW5lZCBpbiBt YW55IGRpZmZlcmVudCB3YXlzLg0KRU5EDQoNClNjb3R0DQo= From nobody Wed Oct 29 06:05:14 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDA31A00A6; Wed, 29 Oct 2014 06:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxnQRJUUV8TF; Wed, 29 Oct 2014 06:05:03 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3697B1A009E; Wed, 29 Oct 2014 06:05:00 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKVFDl+E9KG2o3KpV5cTSB4OJx0lN1Hvaz@postini.com; Wed, 29 Oct 2014 06:05:02 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9TD4tJw008623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 09:04:55 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 09:04:46 -0400 From: "Hollenbeck, Scott" To: Alissa Cooper , The IESG Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) Thread-Index: AQHP8wThqQazUPVAGEi2/UP5B6hs2JxHBZLg Date: Wed, 29 Oct 2014 13:04:54 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> In-Reply-To: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/LtGzw2bhtjzs2HVaT3-wJZ8aN-U Cc: "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:05:06 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Alissa > Cooper > Sent: Tuesday, October 28, 2014 7:14 PM > To: The IESG > Cc: weirds-chairs@tools.ietf.org; weirds@ietf.org; draft-ietf-weirds- > rdap-query@tools.ietf.org > Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap- > query-16: (with DISCUSS and COMMENT) >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-weirds-rdap-query-16: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > =3D Section 3.2.3 =3D > If I'm reading the document correctly, when searching for an entity, > the > search pattern is expected to represent an entity using the syntax > specified in Section 6.1 of draft-ietf-weirds-json-response. But when > the > path segment is provided, rather than a search, Section 3.1.5 says > this: >=20 > The parameter represents an entity (such as a contact, > registrant, or registrar) identifier whose syntax is specific to the > registration provider. For example, for some DNRs contact > identifiers are specified in RFC 5730 [RFC5730] and RFC 5733 > [RFC5733]. >=20 > This makes it seem as if an entity in a path segment uses different > syntax (actually, non-standard syntax that is up to the registration > provider) than an entity that someone might search for. Is there some > specific field in the entity definition in > draft-ietf-weirds-json-response that is supposed to correspond > to? Aren't HTTP GETs for both path segments and searches meant to > provide > responses based on the same underlying data? If so, I don't understand > why there is a specified syntax for entities in one but not the other. > This also seems inconsistent with the following text in Section 6.1 of > draft-ietf-weirds-json-response: >=20 > The entity object class appears throughout this document and is an > appropriate response for the /entity/XXXX query defined in > Registration Data Access Protocol Lookup Format > [I-D.ietf-weirds-rdap-query] It's actually Section 5.1 of json-response. That section reference is incor= rect (and could be removed as suggested below). If only xml2rfc made it pos= sible to tag cross-document section references... The json-response document doesn't actually provide a syntax specification = for entity handles. The closest it comes is "a string representing an regis= try unique identifier of the entity" (we need to change "an registry" to "a= registry"). The text in 3.2.3 (Entity Search) should be consistent with 3.= 1.5 (Entity Path Segment Specification) and json-response. 3.1.5 says this: "The parameter represents an entity (such as a contact, registrant= , or registrar) identifier whose syntax is specific to the registration pro= vider." This is consistent with json-response. Would this change in 3.2.3 address y= our concern? OLD "where XXXX is a search pattern representing an entity name as specified in= Section 6.1 of [I-D.ietf-weirds-json-response]" NEW "where XXXX is a search pattern representing an entity (such as a contact, = registrant, or registrar) identifier whose syntax is specific to the regist= ration provider" > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =3D Section 3 =3D > "The query URL is > constructed by concatenating the base URL to the help path segment > specified in either Section 3.1.6." >=20 > The "either" is extraneous, or there is some other section missing at > the > end of this sentence. "either" should be removed. Thanks for that catch. > =3D Section 4.2 and Section 8: > I think it would be helpful here to point out that the > identity/authorization of the searcher may be a relevant factor in > determining how broad the response set should be for any particular > query > (and not just a single static policy that applies to all searchers > equally). I can add this to both sections: "Note that there might not be a single, static information return policy th= at applies to all clients equally. Client identity and associated authoriza= tions can be a relevant factor in determining how broad the response set wi= ll be for any particular query." Does that work? Scott From nobody Wed Oct 29 06:25:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524BD1A00E0; Wed, 29 Oct 2014 06:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFFKUFnxo-Ey; Wed, 29 Oct 2014 06:25:00 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A80DA1A00B5; Wed, 29 Oct 2014 06:25:00 -0700 (PDT) Received: from h118.viagenie.ca (h118.viagenie.ca [206.123.31.118]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C8124403B1; Wed, 29 Oct 2014 09:24:59 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Marc Blanchet In-Reply-To: <20141029063322.10888.60928.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 09:24:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141029063322.10888.60928.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/K5TNYXElV-ATs6fkSK9VNNqUTTI Cc: weirds@ietf.org, weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, The IESG Subject: Re: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-bootstrap-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:25:04 -0000 > Le 2014-10-29 =C3=A0 02:33, Barry Leiba a = =C3=A9crit : thanks for your review. >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > DISCUSS point 1, on the clarity of the text about matching: >=20 > -- Section 4 -- > The matching is of labels from right to left... You and I know that, = but > will every reader understand that? With gTLDs upon us, will it always = be > clear to everyone that a registry entry of "nyc" matches "coffee.nyc", > but does not match "nyc.com"? Will everyone understand that a = registry > entry of "example.com" matches "good.example.com", but does not match > "goodexample.com"? >=20 > There's also nothing said about what happens if there are multiple > matches at the same specificity. What if there are two Entry Arrays = that > both contain "example.com"? More likely, what if someone makes an = error > in specifying AS numbers, we get one entry for 10000-12000 and another > for 12000-14000... and then we query for 12000? >=20 > It might be good to be clearer about exactly what matching is = intended, > and what doesn't match. Feel free to use my examples above, if that > helps. this has been a recurring comment. I=E2=80=99ll add more text and = examples.=20 >=20 > ----- >=20 > DISCUSS point 2: the scope of what we're asking IANA to do, and the > question of whether it's really clear both to us and to them what it = is, > what it will entail, and what it will cost: >=20 > -- Section 8 -- >=20 > Clients SHOULD cache the > registry, but use underlying protocol signalling, such as the HTTP > Expires header field [RFC7234], to identify when it is time to > refresh the cached registry. >=20 > Now you're putting another requirement on IANA, which I'm not sure has > been part of the discussion: they have to present the registries in = the > right format AND manage the TTL of the queries with the Expires = header.=20 > Please, please make sure that IANA is very clear about the entire = scope > of what we're asking, and signs off on it. IANA, both regular staff and technical staff, has reviewed the whole = text, and were fine. >=20 > -- Section 12 -- >=20 > IANA is expected to generate the RDAP Bootstrap > Services Registries data from these above mentioned registries, > according to their own registration policies. >=20 > I presume "their" refers to the registries, not to IANA, but that's > ambiguous, and should be fixed. The above-mentioned registries do not > have RDAP URLs, do they? no. > Whence is IANA meant to get that information, > in order to generate these new registries? currently, for names, the registration process includes a =C2=AB whois = server domain name =C2=BB entry. IANA will add a new entry for =C2=AB = rdap server url =C2=BB to the process, so that registrie can send their = rdap server url entry through the normal process.=20 >=20 > If IANA generates these by periodically re-processing the source > registries to pick up changes, how current are the RDAP registries > expected to be? Is it OK for them to be updated once a week? Once a > month? Are we setting up any SLAs for the timeliness and reliability = of > these registries? they would not be regenerated from the source. The rdap registries will = be updated whenever there is a change submitted by the registries for an = rdap entry. For example, say =C2=AB.ontario =C2=BB has a whois server = but no rdap server. .ontario will not be in the rdap registry. When = .ontario has his rdap server and running, they will request IANA = (through the updated process described above) to add their entry = (.ontario) in the rdap registry for their rdap server. Then when IANA = process the request, the rdap registry will be updated. No synching or = else. There have been multiple comments and iterations of this section. = Usually, I added those as is in the document, but maybe it became more = convoluted than necessary and hence bring questions. I=E2=80=99ll reread = it with a more fresh start and see if it could be clearer.=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > -- Section 1 -- >=20 > This document requests IANA to make an augmented version of > the existing registries available for the specific purpose of > RDAP use >=20 > I presume that IANA has agreed to do that. Where will the URIs for = those > augmented registries be published. as typical, the URI of these registries will not be in the RFC. = Moreover, IANA specifically requested to not have the URI in the RFC, = because of the requirements for =C2=AB high volume =C2=BB which may = require some specific URL. > That is, how will a bootstrapping > application know where to find them for the bootstrapping? the developer will have to look at IANA site once to find the url of the = bootstrap registries. Not sure what is my action item here. >=20 > -- Section 3 -- >=20 > The JSON object for each > registry will start with a series of members that contain metadata >=20 > "Start with" implies ordering, but members within JSON objects are > explicitly unordered. Do you actually care about the ordering, or = should > you just change "start with" to "contain" (and similarly change the > subsequent "Following that =C2=BB) ok. > ? >=20 > Each item of the array contains a second-level array, > with two elements, each of them being a third-level array. >=20 > The first third-level array, named 'Entry array', contains all > entries that have the same set of base RDAP URLs. The second third- > level array, named 'Service URL array', contains the list of base > RDAP URLs usable for the entries found in the 'Entry array'. There > is no assumption of sorting except that the two arrays found in each > second-level array MUST appear in the correct order: The entries > array are followed by the service URL array. >=20 > This is just an editorial comment, but this description seems > unnecessarily complicated, and the "no sorting, but certain things = have > to be in the right order" is just odd. >=20 > May I make a suggestion that gets rid of the "third-level array" > awkwardness (and also corrects some wording errors)?: >=20 > NEW > Each element of the Services array is a second-level array with > two elements: in order, an Entry Array and a Service URL Array. >=20 > The Entry Array contains all entries that have the same set of > base RDAP URLs. The Service URL Array contains the list of base > RDAP URLs usable for the entries found in the Entry Array. Elements > within these two arrays are not sorted in any way. > END ok.=20 >=20 > Any unknown or unspecified JSON object > properties or values should be ignored by implementers. >=20 > 1. Implementers don't ignore the unrecognized things; implementations > do. >=20 > 2. What does it mean to ignore an unspecified thing? It's not there = to > be ignored. >=20 > 3. The "should be" makes people wonder whether it's supposed to be a = 2119 > key word, and why it's not. I suggest just using "are" -- that's = simply > the way it is. >=20 > So, maybe: > Any unrecognized JSON object properties or values are > ignored by implementations. ok. >=20 > -- Section 4 -- >=20 > The domain names authoritative registration data service is found by > doing the label-wise longest match of the target domain name with = the > domain values in the arrays in the IANA Domain Name RDAP Bootstrap > Service Registry. The values contained in the second element of the > array are the valid base RDAP URLs as described in > [I-D.ietf-weirds-rdap-query]. >=20 > You have names for these arrays in Section 3; why don't you use them? >=20 > NEW > The domain names authoritative registration data service is found by > doing the label-wise longest match of the target domain name with = the > domain values in the Entry Arrays in the IANA Domain Name RDAP > Bootstrap Service Registry. The values contained in the Service URL > Array of the matching second-level array are the valid base RDAP = URLs > as described in [I-D.ietf-weirds-rdap-query]. > END ok. >=20 > And similarly for other times when you say "first element" or "second > element". >=20 > I'm also thinking more and more that "longest match" should instead be > "most specific match", especially for the IP address numbers. in network operations environment, longest match for IP addresses is = pretty common use. But I=E2=80=99m fine if people prefer most specific = match.=20 >=20 > -- Section 5.1 -- > Doesn't "CIDR format" need a reference? will look into it. >=20 > -- Section 7 -- >=20 > The registries may not contain the requested value or the base RDAP > URL value may be empty. >=20 > Nothing up in Section 3 said that a Service URL Array could be empty. = If > that's legal, that fact should be specified up there. ok >=20 > -- Section 10.2 -- > In the definition of "rdap-bootstrap-registry" you should note that = the > "description" member is optional, probably by saying, "and an optional > MEMBER description and=E2=80=A6 =C2=BB ok. > . From nobody Wed Oct 29 06:32:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC81A00E8; Wed, 29 Oct 2014 06:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRKdPhH-weAB; Wed, 29 Oct 2014 06:32:27 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C5C1A00D4; Wed, 29 Oct 2014 06:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414589547; x=1446125547; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VNMuIIsskNYbKf9QLmq958gL3Nl+dAnOzgwtJ7qqE2Y=; b=GSRlmrnlXZKvuX/1xlanM7eTb862RyGPQXybw/Ygkl9TVBGm9AQB7vxv wfmrFbdhKceoVXUvVqsGsoYXY+F9oIh8ycYeTX1P1+oK+hZBlzg51gUJx t3zaw4ciY647wzP5ZHD0KczqBKxJGaR+D3uUda1Lb7xALWCKwzw7Rm4Ax Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7605"; a="79581927" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2014 06:32:27 -0700 X-IronPort-AV: E=Sophos;i="5.04,810,1406617200"; d="scan'208";a="739248988" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Oct 2014 06:32:26 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 29 Oct 2014 06:32:26 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 29 Oct 2014 06:32:25 -0700 Message-ID: <5450EC62.40000@qti.qualcomm.com> Date: Wed, 29 Oct 2014 08:32:18 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (129.46.53.226) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/fM4x3e-zoVqXSw7A-oLINxYtSeA Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:32:29 -0000 On 10/29/14 8:04 AM, Hollenbeck, Scott wrote: > If only xml2rfc made it possible to tag cross-document section references... > Actually, it does. Make sure there's an "anchor" on the section, and then use an where you want the reference. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Oct 29 06:36:12 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260581A00EB; Wed, 29 Oct 2014 06:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRzYhVOrLW2T; Wed, 29 Oct 2014 06:36:07 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CB3A1A00EF; Wed, 29 Oct 2014 06:36:06 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id l4so2488580lbv.28 for ; Wed, 29 Oct 2014 06:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kG+TmvAHuJ9aWHquCw0djw4c1jeNjAPFC+ng1HE20rQ=; b=vDmgz6jrMLXShsyHc/VWrBzrBtSOiLANPywM3oQKooxY9t9sQNQJ+AsKqazDYf8/N7 A+AYzNoDjQGg4WSygJEFbrf7AboCIWTx4QG3mlHGhQTsh1ooJyfWYfzLFHRqFT3e2cnv kKjuCCuPugZG+i44ZH8mu8TZtBOEva3A2iqYlCZGToXkRCCaRnDqqh2T+A2kGMeSlutP cAAAEdhSHx8V8SyzV6AQcXRlcXZ+3prU3wkyfo8cRQ9BAv+bICJZt4bKeYvqfb20uq4w 7SnyVD/LmAkrkR/JfY/h0HXpzrLWj0eGFmia5yg2qGkKQ3dKNV9xsH4ojU6dx2syTK9E Ir/A== MIME-Version: 1.0 X-Received: by 10.152.4.132 with SMTP id k4mr2018357lak.1.1414589764513; Wed, 29 Oct 2014 06:36:04 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Wed, 29 Oct 2014 06:36:04 -0700 (PDT) In-Reply-To: <5450EC62.40000@qti.qualcomm.com> References: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5450EC62.40000@qti.qualcomm.com> Date: Wed, 29 Oct 2014 09:36:04 -0400 X-Google-Sender-Auth: iFwE0u0mu4iNIhPEJ192nqshxoI Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/4VHHQ-1APvAxTdbWm_h6Yju3MnQ Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" , The IESG Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:36:08 -0000 \>> If only xml2rfc made it possible to tag cross-document section >> references... > > Actually, it does. Make sure there's an "anchor" on the section, and then > use an where you want the reference. That doesn't work if the section you're citing is in another document. Barry From nobody Wed Oct 29 06:37:54 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03B31A00E9; Wed, 29 Oct 2014 06:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt59re09guP7; Wed, 29 Oct 2014 06:37:49 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA32C1A009E; Wed, 29 Oct 2014 06:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414589869; x=1446125869; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Gu1yDDi3j5iqR17nSaL261OeXAPShO9WOTQPlUPOvYs=; b=lxr96G194FG7JHwisHMteNsYIFAX8510ObVcUOXMTd/E2D6QaUH/n2ir RcyhgY0vDgPd92FUuWcNBlWNPJVZ6klhKYxoDpAbqp3w9FiLdzDM9AbI7 jIKabx1WNM01Wopn0TXWXporxbGQWWlWHKFvl6a0Mn1dAOiXRrsqkDSle U=; X-IronPort-AV: E=McAfee;i="5600,1067,7605"; a="77054481" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2014 06:37:30 -0700 X-IronPort-AV: E=Sophos;i="5.04,810,1406617200"; d="scan'208";a="779315708" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Oct 2014 06:37:30 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 29 Oct 2014 06:37:29 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 29 Oct 2014 06:37:29 -0700 Message-ID: <5450ED92.5030908@qti.qualcomm.com> Date: Wed, 29 Oct 2014 08:37:22 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5450EC62.40000@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (129.46.53.226) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Yma9vUJyGnLkwSy7Gc6wuoy7SLU Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:37:51 -0000 On 10/29/14 8:36 AM, Barry Leiba wrote: > \>> If only xml2rfc made it possible to tag cross-document section > >>> references... >>> >> Actually, it does. Make sure there's an "anchor" on the section, and then >> use an where you want the reference. >> > That doesn't work if the section you're citing is in another document. > Darn it. "Cross-document". Reading...not my strong suit. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Oct 29 06:39:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42241A0100; Wed, 29 Oct 2014 06:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSd0pXgWPAf8; Wed, 29 Oct 2014 06:39:25 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815971A00FA; Wed, 29 Oct 2014 06:39:24 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z11so514584lbi.35 for ; Wed, 29 Oct 2014 06:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=mt+hGBD/+HGu7YfgGpx0PwClS0vS+qqNHheVawsgLTU=; b=1GQrwqcxg2fF/4NBTgdHnSQZWzbgRF426UEDm9p7HCEGbbJh0Eih3BO0lOl/RAI1iu RjLu042MVOamD3TY5k0j2qA/fWJJbWkM2eBjjhTHmbwzmVustK1tzR58HcR88QAnT9wC YJiTCdp7H+35iHoOnQmqFdjDDmJXkfSQCZn2qAaklL0LElbhpf89UFhj+7SOC65N3YFt 0vLyik+ND5MTLQLhMbsa83AKd4GSUKw7HLQG78d7l0Crr0vibAEHLlcUDzz8E6H7ex6A rg9WwsY+eBxeHLCsYLhgWLtdEiLvGrtzUChW44YMTZkqAsRdKBWiDSE+VGYtexriupLM GIJw== MIME-Version: 1.0 X-Received: by 10.152.170.131 with SMTP id am3mr11349790lac.15.1414589962461; Wed, 29 Oct 2014 06:39:22 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Wed, 29 Oct 2014 06:39:22 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49507FFD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141029063708.10884.33832.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F49507FFD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 29 Oct 2014 09:39:22 -0400 X-Google-Sender-Auth: 5s4XrMy31CBDCiIS_HYtCC_dwTc Message-ID: From: Barry Leiba To: "Hollenbeck, Scott" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/BQOnZk_wKmthIyi7R4yugAq-AaE Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:39:26 -0000 > Given the text in Section 3 (Path Segment Specification) and the bootstra= p > document, yes, I should remove the leading "/" from the examples. Andy > and I can make sure that rdap-query and json-response do this consistentl= y. Thanks! >> I'm not going to try to re-write that myself (don't try this at home!), >> and I did understand it... but I have to say that it's a truly convolute= d >> paragraph. Please see if you can say this and the subsequent paragraph >> in a different way without the "combined combining character characters >> with combined character combinations" feel to it. > > How is this? > > NEW > Partial matching is not feasible across combinations of Unicode character= s because Unicode characters can be combined with each other. Servers SHOUL= D NOT partially match combinations of Unicode characters where a legal comb= ination is possible. It should be noted, though, that it may not always be = possible to detect cases where a character could have been combined with an= other character, but was not, because characters can be combined in many di= fferent ways. > END Ahhhhh... that seems smoother; thanks for that. Barry From nobody Wed Oct 29 07:19:39 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264CE1A0140; Wed, 29 Oct 2014 07:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0eGGdVrkvmL; Wed, 29 Oct 2014 07:19:33 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061431A00E5; Wed, 29 Oct 2014 07:19:28 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKVFD3bWJ64SxthioxvuKxU5rSL6eH2e33@postini.com; Wed, 29 Oct 2014 07:19:32 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9TEJNui015884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 10:19:23 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 10:19:22 -0400 From: "Hollenbeck, Scott" To: Pete Resnick Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) Thread-Index: AQHP8wThqQazUPVAGEi2/UP5B6hs2JxHBZLggABQ9wD//8m/MA== Date: Wed, 29 Oct 2014 14:19:22 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F495082F5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5450EC62.40000@qti.qualcomm.com> In-Reply-To: <5450EC62.40000@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/_Vwmpic4bnjtlyhWH_8sB0DGJ3A Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:19:35 -0000 > -----Original Message----- > From: Pete Resnick [mailto:presnick@qti.qualcomm.com] > Sent: Wednesday, October 29, 2014 9:32 AM > To: Hollenbeck, Scott > Cc: Alissa Cooper; The IESG; weirds-chairs@tools.ietf.org; > weirds@ietf.org; draft-ietf-weirds-rdap-query@tools.ietf.org > Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds- > rdap-query-16: (with DISCUSS and COMMENT) >=20 > On 10/29/14 8:04 AM, Hollenbeck, Scott wrote: > > If only xml2rfc made it possible to tag cross-document section > references... > > >=20 > Actually, it does. Make sure there's an "anchor" on the section, and > then use an where you want the reference. That works *within* the document, not in a second document. Scott From nobody Wed Oct 29 08:04:38 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888A91A0242; Wed, 29 Oct 2014 08:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsnsiSAqlcqI; Wed, 29 Oct 2014 08:04:19 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1C71A038E; Wed, 29 Oct 2014 08:03:38 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKVFEByQCbn6fdMdJ2AxOVYo04A2MzAuTf@postini.com; Wed, 29 Oct 2014 08:04:08 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9TF3aKv021088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 11:03:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 11:03:35 -0400 From: "Hollenbeck, Scott" To: Alissa Cooper , The IESG Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) Thread-Index: AQHP8wUfEIZLGkYoKkacqpPaBIZ0W5xHIoBg Date: Wed, 29 Oct 2014 15:03:34 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F495084BA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> In-Reply-To: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/hWdZ14CdapzUOuamaWwF9u18Vfs Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:04:29 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Alissa > Cooper > Sent: Tuesday, October 28, 2014 7:16 PM > To: The IESG > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > chairs@tools.ietf.org; weirds@ietf.org > Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap- > sec-10: (with DISCUSS and COMMENT) >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-weirds-rdap-sec-10: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > =3D General comment =3D > I'm not exactly sure which document this remark is directed at, but I'm > putting it in a DISCUSS here and we can figure that out later. >=20 > I feel like the RDAP document suite is missing an overall explanation > of > the privacy threat model associated with registration data, the policy > choices that are left up to registry providers, and the mechanisms > included in RDAP to help protect registrant and client/user privacy > and > facilitate those policy choices. There are mentions of some of this > here > and there, but even those are not necessarily consistent with each > other > (see my DISCUSS on draft-ietf-weirds-using-http). So I think it would > be > beneficial to capture this in one place and articulate it explicitly, > rather than implicitly across the documents. Some of the salient points > for starters: >=20 > * WHOIS data has historically included personal information about > registrants, has been made public, and has not had the benefit of > authentication or access control mechanisms to gate access to it. In > part > as a result of this, proxy and privacy services have arisen to shield > the > identities of registrants. >=20 > * The standardization of RDAP does not change or impact the data that > registries may require to be collected from registrants. However, RDAP > data structures allow servers to indicate when data returned to clients > has been made private, redacted, obscured, or shielded by a proxy. >=20 > * RDAP uses the jCard standard format for entity representation, but > many > of the jCard fields are irrelevant for registry operation purposes and > their use should be minimized. >=20 > * RDAP includes mechanisms that can be used to authenticate clients, > allowing servers to support tiered access based on local policy. This > means that all registration data need no longer be public, and personal > data or data that may be considered more sensitive can have its access > restricted to specifically privileged clients. >=20 > * [Something about confidentiality of requests and responses ... see my > other DISCUSS point below.] >=20 > * etc. I could see adding a good bit of what you wrote above to a new section titl= ed "Privacy Threats Associated with Registration Data" that appears as a ne= w section in the Introduction or perhaps between the existing sections 2 an= d 3. Would one of those options work? > =3D Section 3.4 =3D > "If the policy of the server operator > requires encryption to protect client-server data exchanges (such as > to protect non-public data that can not be accessed without client > identification and authentication), HTTP Over TLS MUST be used to > protect those exchanges." >=20 > It is unclear to me that a server policy that allows unencrypted access > should be allowed, particularly in the cases of entity-related > requests, > but perhaps also in the case of other requests. The fact that the > registry data may be public is orthogonal to the question of whether a > particular query for that data should have confidentiality protection. > I'd like to understand why RDAP does not require HTTP over TLS to be > used > in all cases and instead allows unsuspecting client users to send their > queries in the clear in cases where server policy does not mandate use > of > TLS. I'm especially curious about this since clients are required to > support HTTPS anyway. The current text is a reflection of operational possibilities in which the = server operator does not support queries that could return PII. I don't bel= ieve we had WG support for requiring HTTPS in such situations. Do we need t= o mandate TLS for all servers? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =3D Section 3.1 =3D > "RDAP's authentication framework needs to accommodate anonymous access > as well as verification of identities" >=20 > I would suggest s/anonymous access/unauthenticated access/ since > generally it can be pretty difficult to remain anonymous when accessing > anything over IP. >=20 > Similar comment for 3.2, I would delete "or anonymous." Agreed. "unauthenticated" is appropriate. Scott From nobody Wed Oct 29 08:32:04 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC461A01F0; Wed, 29 Oct 2014 08:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTef-vExUVXu; Wed, 29 Oct 2014 08:31:59 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069CD1A017D; Wed, 29 Oct 2014 08:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414596720; x=1446132720; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xAOBL9VdNXcuQcJPgx2hR0wg5SDUncIIIm5HpBbLHWg=; b=zmBjI7f5yRnhLLtZfabYukvsImVB9JNF7WxVxkF5jv1iXx8wKLV4XSOw OIh4pAN29lpoYvWQuynOZ/PhirnH1WK3ux+cFL+1CEYBZOc3nVOVQ/PzB B0GFWT9GdB2XRIDrIwHm059J+KVdc8zTHxzcmMOWnThJJH0aiJO1/lK/M A=; X-IronPort-AV: E=McAfee;i="5600,1067,7605"; a="77061130" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2014 08:31:59 -0700 X-IronPort-AV: E=Sophos;i="5.04,810,1406617200"; d="scan'208";a="739312357" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Oct 2014 08:31:57 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 29 Oct 2014 08:31:56 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 29 Oct 2014 08:31:55 -0700 Message-ID: <54510863.8020906@qti.qualcomm.com> Date: Wed, 29 Oct 2014 08:31:47 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Alissa Cooper References: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> In-Reply-To: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/FQD51nTI8r65woYkszX4S93_4Rc Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, The IESG , weirds@ietf.org Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:32:01 -0000 On 10/28/14 4:15 PM, Alissa Cooper wrote: > I feel like the RDAP document suite is missing an overall explanation of > the privacy threat model associated with registration data, the policy > choices that are left up to registry providers, and the mechanisms > included in RDAP to help protect registrant and client/user privacy and > facilitate those policy choices. So this is the first time I've had any serious discussion of privacy issues in one of my WGs, so please be patient with me as I try to get my head around the issue. I would expect that questions of *policy*, i.e., what registries/registrars desire or are required to give out, is something that the protocol documents should not discuss at all. What we want to talk about in the document is how the protocol is able to provide whatever protections on privacy the supplier of the information desires or is required to provide, right? Because when you say: > * RDAP uses the jCard standard format for entity representation, but many > of the jCard fields are irrelevant for registry operation purposes and > their use should be minimized. > A general statement that says, "The server should minimize the amount of info it sends back" I get, but the existence of fields in the jCard spec doesn't seem like something that we should be talking in terms of. If you are sending back the data, you should send it in the appropriate jCard field. If for some particular registry, there is a policy that involves publicly producing the date of birth of a registrant, insofar as we think that absurd, we're talking about the policy, not the existence of the jCard field. If that assessment is correct, then I've got real worries about saying anything more than handwavy about data privacy policies given the politics of the entities involved. That said, other things you've got like: > * RDAP includes mechanisms that can be used to authenticate clients, > allowing servers to support tiered access based on local policy. This > means that all registration data need no longer be public, and personal > data or data that may be considered more sensitive can have its access > restricted to specifically privileged clients. > seem sufficiently high-level to work in a Privacy Considerations section (somewhere). But when you get to: > It is unclear to me that a server policy that allows unencrypted access > should be allowed, particularly in the cases of entity-related requests, > but perhaps also in the case of other requests. That gets me a bit more nervous, as I'm not sure we should be commenting on any particular policy like this. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Oct 29 09:23:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3B81A1B6F; Wed, 29 Oct 2014 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNVjz7AZI2ki; Wed, 29 Oct 2014 09:23:35 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D28D1A1B79; Wed, 29 Oct 2014 09:23:30 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id hz20so296771lab.37 for ; Wed, 29 Oct 2014 09:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pnib+k/EiqTPFcPolrcsjlETho49ROpotB+ELWbfoos=; b=m7a+qq3Do8HxKfqyOpWlfG+iMaDEnmki2c1MnUVJY1LeuSTvgjvAnX+//fe/eE4T6j zl4gCvPhNLPBGxA1x1m5CmVSKzHLFUyODF5bGDwUmdR2Q/K48u3pDRLgVSvmPqOYQ3Ae E6qe+AILg3G9hQfcjFQ9irHSidlerqB8rXuYC+oifDO/y5p+UsowelJnVfVjqBvgNcm9 bkFlF9tJ8Gsupw1iXmq2YvptPjTxn6QWps8D7r/1Sh5SC8drsNfLf2UlQXid882mbRsj j9Xcep8RDu850Up/tUlx3ebmD7D07LUoAO6B52KhjROiqZ7ryVxMQG7xACTjRMeLl4LR BOtA== MIME-Version: 1.0 X-Received: by 10.112.170.131 with SMTP id am3mr4112139lbc.97.1414599809013; Wed, 29 Oct 2014 09:23:29 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Wed, 29 Oct 2014 09:23:28 -0700 (PDT) In-Reply-To: References: <20141029063322.10888.60928.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 12:23:28 -0400 X-Google-Sender-Auth: ggJu8tfRsSH3MeGPxQNmfvf-InU Message-ID: From: Barry Leiba To: Marc Blanchet Content-Type: multipart/alternative; boundary=001a11c36af01d9dad0506922fef Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/M-Ol6a5N_BAZQHIvs45rgRnV4bU Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-bootstrap@tools.ietf.org" , "weirds@ietf.org" , The IESG Subject: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-bootstrap-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:23:39 -0000 --001a11c36af01d9dad0506922fef Content-Type: text/plain; charset=ISO-8859-1 Thanks for the quick response, Marc. We're ok on almost everything... Just the IANA bit to iron out, but that should be easy. > It might be good to be clearer about exactly what matching is intended, > > and what doesn't match. Feel free to use my examples above, if that > > helps. > > this has been a recurring comment. I'll add more text and examples. Great; thanks. > > DISCUSS point 2: the scope of what we're asking IANA to do, and the > > question of whether it's really clear both to us and to them what it is, > > what it will entail, and what it will cost ... > > IANA is expected to generate the RDAP Bootstrap > > Services Registries data from these above mentioned registries, > > according to their own registration policies. > > > > I presume "their" refers to the registries, not to IANA, but that's > > ambiguous, and should be fixed. The above-mentioned registries do not > > have RDAP URLs, do they? > > no. > > > Whence is IANA meant to get that information, > > in order to generate these new registries? > > currently, for names, the registration process includes a << whois server > domain name >> entry. IANA will add a new entry for << rdap server url >> to > the process, so that registrie can send their rdap server url entry through > the normal process. I don't see that the document tells IANA they need to do that. Each of the four registries needs to have a new field, and that has to be made clear in the IANA Considerations. > > If IANA generates these by periodically re-processing the source > > registries to pick up changes, how current are the RDAP registries > > expected to be? Is it OK for them to be updated once a week? Once a > > month? Are we setting up any SLAs for the timeliness and reliability of > > these registries? > > they would not be regenerated from the source. The rdap registries will be > updated whenever there is a change submitted by the registries for an rdap > entry. For example, say <<.ontario >> has a whois server but no rdap server. > .ontario will not be in the rdap registry. When .ontario has his rdap > server and running, they will request IANA (through the updated process > described above) to add their entry (.ontario) in the rdap registry for > their rdap server. Then when IANA process the request, the rdap registry > will be updated. No synching or else. Again, that's not mentioned. The document says that these RDAP registries aren't updated as usual with registries, but are generated from the source registries. If that's just how they get started, and IANA is expected to keep them current in real time to coincide with all updates to the source registries, the document has to say that in the IANA Considerations. > There have been multiple comments and iterations of this section. Usually, > I added those as is in the document, but maybe it became more convoluted > than necessary and hence bring questions. I'll reread it with a more fresh > start and see if it could be clearer. ... > This document requests IANA to make an augmented version of > > the existing registries available for the specific purpose of > > RDAP use > > > > I presume that IANA has agreed to do that. Where will the URIs for those > > augmented registries be published. > > as typical, the URI of these registries will not be in the RFC. Moreover, > IANA specifically requested to not have the URI in the RFC, because of the > requirements for << high volume >> which may require some specific URL. > > > That is, how will a bootstrapping > > application know where to find them for the bootstrapping? > > the developer will have to look at IANA site once to find the url of the > bootstrap registries. > > Not sure what is my action item here. How will the developer know where to look? If developers are expected to look someplace, and then hard-code the URL(s) into their products, then (1) they have to be told that, and told where to look to find the URL(s) and (2) IANA has to be told that the URLs have to be published in the place we tell the developers to look, and they have to be told that those URL MUST be persistent (because they will be hard-coded in software). That stuff has to be in the IANA Considerations. In general, the point here is that *everything* that IANA has to know and do must be in one place, in the IANA Considerations. We can't make them look through and analyze the whole document, and we can't make them guess about anything. I will be happy when we have an IANA Considerations section that lays it all out, and we have a review from IANA that shows they understand it and are OK with it. > I'm also thinking more and more that "longest match" should instead be > > "most specific match", especially for the IP address numbers. > > in network operations environment, longest match for IP addresses is > pretty common use. But I'm fine if people prefer most specific match. No... "Most specific" sounds nicer to me, but if "longest" is a recognised term of art, don't change it for me. > Doesn't "CIDR format" need a reference? > > will look into it. One of the other docs (rdap-query, maybe) has one. Barry --001a11c36af01d9dad0506922fef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the quick response, Marc.  We're ok on almost everythin= g... Just the IANA bit to iron out, but that should be easy.

> It might be good to be clearer about exactly w= hat matching is intended,
> and what doesn't match.  Feel free to use my examples above, = if that
> helps.

this has been a recurring comment. I’ll add more text and examples.

Great; thanks.
 
> DISCUSS point 2: the scope of what we're a= sking IANA to do, and the
> question of whether it's really clear both to us and to them what = it is,
> what it will entail, and what it will cost
 
...

=
>   IANA is expected to generat= e the RDAP Bootstrap
>   Services Registries data from these above mentioned regist= ries,
>   according to their own registration policies.
>
> I presume "their" refers to the registries, not to IANA, but= that's
> ambiguous, and should be fixed.  The above-mentioned registries d= o not
> have RDAP URLs, do they?

no.

>  Whence is IANA meant to get that information,
> in order to generate these new registries?

currently, for names, the registration process includes a « whois ser= ver domain name » entry. IANA will add a new entry for « rdap s= erver url » to the process, so that registrie can send their rdap ser= ver url entry through the normal process.

I= don't see that the document tells IANA they need to do that.  Eac= h of the four registries needs to have a new field, and that has to be made= clear in the IANA Considerations.
 
> If IANA generates these by periodically re-processing th= e source
> registries to pick up changes, how current are the RDAP registries
> expected to be? Is it OK for them to be updated once a week?  Onc= e a
> month?  Are we setting up any SLAs for the timeliness and reliabi= lity of
> these registries?

they would not be regenerated from the source. The rdap registries will be = updated whenever there is a change submitted by the registries for an rdap = entry.  For example, say «.ontario » has a whois server bu= t no rdap server. .ontario will not be in the rdap registry. When .ontario = has his rdap server and running, they will request IANA (through the update= d process described above) to add their entry (.ontario)  in the rdap = registry for their rdap server. Then when IANA process the request, the rda= p registry will be updated.  No synching or else.
Again, that's not mentioned. The document says that these R= DAP registries aren't updated as usual with registries, but are ge= nerated from the source registries.  If that's just how they get s= tarted, and IANA is expected to keep them current in real time to coincide = with all updates to the source registries, the document has to say that in = the IANA Considerations.
 
There have been multiple comments and iterations of this section. Usuall= y, I added those as is in the document, but maybe it became more convoluted= than necessary and hence bring questions. I’ll reread it with a more= fresh start and see if it could be clearer.

...

>   T= his document requests IANA to make an augmented version of
>   the existing registries available for the specific purpose= of
>   RDAP use
>
> I presume that IANA has agreed to do that.  Where will the URIs f= or those
> augmented registries be published.

as typical, the URI of these registries will not be in the RFC. Moreover, I= ANA specifically requested to not have the URI in the RFC, because of the r= equirements for « high volume » which may require some specific= URL.

> That is, how will a bootstrapping
> application know where to find them for the bootstrapping?

the developer will have to look at IANA site once to find the url of the bo= otstrap registries.

Not sure what is my action item here.

How w= ill the developer know where to look?  If developers are expected to l= ook someplace, and then hard-code the URL(s) into their products, then (1) = they have to be told that, and told where to look to find the URL(s) and (2= ) IANA has to be told that the URLs have to be published in the place we te= ll the developers to look, and they have to be told that those URL MUST be = persistent (because they will be hard-coded in software).  That stuff = has to be in the IANA Considerations.

In general, = the point here is that *everything* that IANA has to know and do must be in= one place, in the IANA Considerations.  We can't make them look t= hrough and analyze the whole document, and we can't make them guess abo= ut anything.

I will be happy when we have an IANA = Considerations section that lays it all out, and we have a review from IANA= that shows they understand it and are OK with it.

> I'm also thinking more and more that &q= uot;longest match" should instead be
> "most specific match", especially for the IP address numbers= .

in network operations environment, longest match for IP addresses is pretty= common use. But I’m fine if people prefer most specific match.

No... "Most specific" sounds nicer to = me, but if "longest" is a recognised term of art, don't chang= e it for me.

> Doesn&= #39;t "CIDR format" need a reference?

will look into it.

One of the other docs (r= dap-query, maybe) has one.

Barry

--001a11c36af01d9dad0506922fef-- From nobody Wed Oct 29 09:31:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AD81A1B0C; Wed, 29 Oct 2014 09:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLajCs8g2jo0; Wed, 29 Oct 2014 09:31:05 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id AB14B1A1B19; Wed, 29 Oct 2014 09:31:05 -0700 (PDT) Received: from h118.viagenie.ca (h118.viagenie.ca [206.123.31.118]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A6C5941319; Wed, 29 Oct 2014 12:31:04 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9B1022A7-B40E-41F8-B8F9-51E7A0DE7B67" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Marc Blanchet In-Reply-To: Date: Wed, 29 Oct 2014 12:31:04 -0400 Message-Id: <6B5169E9-465A-4FFE-8FD3-C939FC309A21@viagenie.ca> References: <20141029063322.10888.60928.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/oHoEfzUWVuGThxfEx4H0qn65b-s Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-bootstrap@tools.ietf.org" , "weirds@ietf.org" , The IESG Subject: Re: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-bootstrap-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:31:11 -0000 --Apple-Mail=_9B1022A7-B40E-41F8-B8F9-51E7A0DE7B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Le 2014-10-29 =E0 12:23, Barry Leiba a =E9crit= : >=20 > Thanks for the quick response, Marc. We're ok on almost everything... = Just the IANA bit to iron out, but that should be easy. >=20 > > It might be good to be clearer about exactly what matching is = intended, > > and what doesn't match. Feel free to use my examples above, if that > > helps. >=20 > this has been a recurring comment. I=92ll add more text and examples. >=20 > Great; thanks. > =20 > > DISCUSS point 2: the scope of what we're asking IANA to do, and the > > question of whether it's really clear both to us and to them what it = is, > > what it will entail, and what it will cost > =20 > ... >=20 > > IANA is expected to generate the RDAP Bootstrap > > Services Registries data from these above mentioned registries, > > according to their own registration policies. > > > > I presume "their" refers to the registries, not to IANA, but that's > > ambiguous, and should be fixed. The above-mentioned registries do = not > > have RDAP URLs, do they? >=20 > no. >=20 > > Whence is IANA meant to get that information, > > in order to generate these new registries? >=20 > currently, for names, the registration process includes a =AB whois = server domain name =BB entry. IANA will add a new entry for =AB rdap = server url =BB to the process, so that registrie can send their rdap = server url entry through the normal process. >=20 > I don't see that the document tells IANA they need to do that. Each = of the four registries needs to have a new field, and that has to be = made clear in the IANA Considerations. well, I=92ve been told _many_ times to let IANA do their own stuff on = their side and we should not intervene/require/write text on this. I=92m = all fine in saying those things (it was actually in the very first = versions of the draft and in some presentations).=20 > =20 > > If IANA generates these by periodically re-processing the source > > registries to pick up changes, how current are the RDAP registries > > expected to be? Is it OK for them to be updated once a week? Once a > > month? Are we setting up any SLAs for the timeliness and = reliability of > > these registries? >=20 > they would not be regenerated from the source. The rdap registries = will be updated whenever there is a change submitted by the registries = for an rdap entry. For example, say =AB.ontario =BB has a whois server = but no rdap server. .ontario will not be in the rdap registry. When = .ontario has his rdap server and running, they will request IANA = (through the updated process described above) to add their entry = (.ontario) in the rdap registry for their rdap server. Then when IANA = process the request, the rdap registry will be updated. No synching or = else. >=20 > Again, that's not mentioned. same reasoning as above. > The document says that these RDAP registries aren't updated as usual = with registries, but are generated from the source registries. If = that's just how they get started, and IANA is expected to keep them = current in real time to coincide with all updates to the source = registries, the document has to say that in the IANA Considerations. Again, I=92ll make another pass to it to see if I can find some common = ground. > =20 > There have been multiple comments and iterations of this section. = Usually, I added those as is in the document, but maybe it became more = convoluted than necessary and hence bring questions. I=92ll reread it = with a more fresh start and see if it could be clearer. >=20 > ... >=20 > > This document requests IANA to make an augmented version of > > the existing registries available for the specific purpose of > > RDAP use > > > > I presume that IANA has agreed to do that. Where will the URIs for = those > > augmented registries be published. >=20 > as typical, the URI of these registries will not be in the RFC. = Moreover, IANA specifically requested to not have the URI in the RFC, = because of the requirements for =AB high volume =BB which may require = some specific URL. >=20 > > That is, how will a bootstrapping > > application know where to find them for the bootstrapping? >=20 > the developer will have to look at IANA site once to find the url of = the bootstrap registries. >=20 > Not sure what is my action item here. >=20 > How will the developer know where to look? If developers are expected = to look someplace, and then hard-code the URL(s) into their products, = then (1) they have to be told that, and told where to look to find the = URL(s) and (2) IANA has to be told that the URLs have to be published in = the place we tell the developers to look, and they have to be told that = those URL MUST be persistent (because they will be hard-coded in = software). That stuff has to be in the IANA Considerations. again, I=92m full agreement with your point. I=92ll raised it with IANA = to see if we can do something.=20 >=20 > In general, the point here is that *everything* that IANA has to know = and do must be in one place, in the IANA Considerations. We can't make = them look through and analyze the whole document, and we can't make them = guess about anything. >=20 > I will be happy when we have an IANA Considerations section that lays = it all out, and we have a review from IANA that shows they understand it = and are OK with it. >=20 > > I'm also thinking more and more that "longest match" should instead = be > > "most specific match", especially for the IP address numbers. >=20 > in network operations environment, longest match for IP addresses is = pretty common use. But I=92m fine if people prefer most specific match. >=20 > No... "Most specific" sounds nicer to me, but if "longest" is a = recognised term of art, don't change it for me. >=20 > > Doesn't "CIDR format" need a reference? >=20 > will look into it. >=20 > One of the other docs (rdap-query, maybe) has one. >=20 > Barry >=20 --Apple-Mail=_9B1022A7-B40E-41F8-B8F9-51E7A0DE7B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Le 2014-10-29 =E0 12:23, Barry Leiba <barryleiba@computer.org> a =E9crit :

Thanks for the quick = response, Marc.  We're ok on almost everything... Just the IANA bit = to iron out, but that should be easy.

> It might be good = to be clearer about exactly what matching is intended,
> and what doesn't match.  Feel free to use my examples above, = if that
> helps.

this has been a recurring comment. I=92ll add more text and = examples.

Great; thanks.
 
> DISCUSS point 2: the scope of what we're = asking IANA to do, and the
> question of whether it's really clear both to us and to them what = it is,
> what it will entail, and what it will cost
 
...

>   IANA = is expected to generate the RDAP Bootstrap
>   Services Registries data from these above mentioned = registries,
>   according to their own registration policies.
>
> I presume "their" refers to the registries, not to IANA, but = that's
> ambiguous, and should be fixed.  The above-mentioned = registries do not
> have RDAP URLs, do they?

no.

>  Whence is IANA meant to get that information,
> in order to generate these new registries?

currently, for names, the registration process includes a =AB whois = server domain name =BB entry. IANA will add a new entry for =AB rdap = server url =BB to the process, so that registrie can send their rdap = server url entry through the normal process.

I don't see that the = document tells IANA they need to do that.  Each of the four = registries needs to have a new field, and that has to be made clear in = the IANA Considerations.

well, I=92ve been told _many_ times to let IANA do = their own stuff on their side and we should not intervene/require/write = text on this. I=92m all fine in saying those things (it was actually in = the very first versions of the draft and in some = presentations). 

 
> If IANA = generates these by periodically re-processing the source
> registries to pick up changes, how current are the RDAP = registries
> expected to be? Is it OK for them to be updated once a week?  = Once a
> month?  Are we setting up any SLAs for the timeliness and = reliability of
> these registries?

they would not be regenerated from the source. The rdap registries will = be updated whenever there is a change submitted by the registries for an = rdap entry.  For example, say =AB.ontario =BB has a whois server = but no rdap server. .ontario will not be in the rdap registry. When = .ontario has his rdap server and running, they will request IANA = (through the updated process described above) to add their entry = (.ontario)  in the rdap registry for their rdap server. Then when = IANA process the request, the rdap registry will be updated.  No = synching or else.

Again, that's not mentioned. =

same reasoning = as above.

The document says that these = RDAP registries aren't updated as usual with registries, but are = generated from the source registries.  If that's just how they get = started, and IANA is expected to keep them current in real time to = coincide with all updates to the source registries, the document has to = say that in the IANA Considerations.

Again, I=92ll make another pass to it to see if I = can find some common ground.

 
There have been multiple comments and iterations = of this section. Usually, I added those as is in the document, but maybe = it became more convoluted than necessary and hence bring questions. I=92ll= reread it with a more fresh start and see if it could be = clearer.



...

>   This document requests IANA to = make an augmented version of
>   the existing registries available for the specific = purpose of
>   RDAP use
>
> I presume that IANA has agreed to do that.  Where will the = URIs for those
> augmented registries be published.

as typical, the URI of these registries will not be in the RFC. = Moreover, IANA specifically requested to not have the URI in the RFC, = because of the requirements for =AB high volume =BB which may require = some specific URL.

> That is, how will a bootstrapping
> application know where to find them for the bootstrapping?

the developer will have to look at IANA site once to find the url of the = bootstrap registries.

Not sure what is my action item here.

How will the developer know where to = look?  If developers are expected to look someplace, and then = hard-code the URL(s) into their products, then (1) they have to be told = that, and told where to look to find the URL(s) and (2) IANA has to be = told that the URLs have to be published in the place we tell the = developers to look, and they have to be told that those URL MUST be = persistent (because they will be hard-coded in software).  That = stuff has to be in the IANA = Considerations.

again, I=92m full agreement with your point. I=92ll = raised it with IANA to see if we can do something. 


In general, the point = here is that *everything* that IANA has to know and do must be in one = place, in the IANA Considerations.  We can't make them look through = and analyze the whole document, and we can't make them guess about = anything.

I = will be happy when we have an IANA Considerations section that lays it = all out, and we have a review from IANA that shows they understand it = and are OK with it.

> I'm also thinking more and more that = "longest match" should instead be
> "most specific match", especially for the IP address numbers.

in network operations environment, longest match for IP addresses is = pretty common use. But I=92m fine if people prefer most specific = match.

No... "Most specific" sounds nicer to me, but if "longest" is = a recognised term of art, don't change it for me.
> Doesn't "CIDR = format" need a reference?

will look into it.

One of the other docs (rdap-query, maybe) has one.

Barry


= --Apple-Mail=_9B1022A7-B40E-41F8-B8F9-51E7A0DE7B67-- From nobody Wed Oct 29 09:50:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DB61A1B4D; Wed, 29 Oct 2014 09:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlR10YTdhgcv; Wed, 29 Oct 2014 09:50:16 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FE21A1B1A; Wed, 29 Oct 2014 09:50:15 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id gm9so2876528lab.4 for ; Wed, 29 Oct 2014 09:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vLdE7SVQNxRrssE5EftNeUvOAwZuTe9G0SmyFb2thA8=; b=rE8bFZB+2MO47jmOLudtZ+joSRyoZBC2wHLceezoeMeGJ3NmCyqqPN9rX4T3QIlyKL W1nvG/YRmI3FwOEsrrptOh0bQ4oZR8uRV25zvVu9TRxZxdtuGsSCaC6EVJFNsgPUBI+f ZROf8JG8BGge1cfAYp2r3hl6JxijGqzqN88uoO/lsy3yMesLoRY+m/vQpEcH45gMvi89 rgrFOn+jDtFxdRomqL9mzogxBDqX0frBRwIpTTeuaZQBj3UxpkTL/bexoFquPbtXO4ix eRS7g/t0PBIQnenDtkwNoueZE4Es9Fsn2kGCbmQY3/bd+L05OyroeR30tQtTz0Sa6K/2 tWlQ== MIME-Version: 1.0 X-Received: by 10.153.7.170 with SMTP id dd10mr12704295lad.45.1414601413078; Wed, 29 Oct 2014 09:50:13 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Wed, 29 Oct 2014 09:50:13 -0700 (PDT) In-Reply-To: <6B5169E9-465A-4FFE-8FD3-C939FC309A21@viagenie.ca> References: <20141029063322.10888.60928.idtracker@ietfa.amsl.com> <6B5169E9-465A-4FFE-8FD3-C939FC309A21@viagenie.ca> Date: Wed, 29 Oct 2014 12:50:13 -0400 X-Google-Sender-Auth: OVLs92nTdTP75MJwx3xMNH7nlOE Message-ID: From: Barry Leiba To: Marc Blanchet Content-Type: multipart/alternative; boundary=001a113483aeb9b4550506928ec5 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ToL9uIxeaApYtMJorxbEk60SVkQ Cc: The IESG , "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-bootstrap@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-bootstrap-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:50:17 -0000 --001a113483aeb9b4550506928ec5 Content-Type: text/plain; charset=ISO-8859-1 > > well, I've been told _many_ times to let IANA do their own stuff on their > side and we should not intervene/require/write text on this. I'm all fine > in saying those things (it was actually in the very first versions of the > draft and in some presentations). > Understood. We need to make sure we make the *requirements* clear, without trying to dictate *how*. > Again, I'll make another pass to it to see if I can find some common > ground. > I'll happily work with you (and Michelle) off list to make sure we get something that works. Barry --001a113483aeb9b4550506928ec5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
well, I’ve been told _many_ times to let IANA do their own stuff on= their side and we should not intervene/require/write text on this. I&rsquo= ;m all fine in saying those things (it was actually in the very first versi= ons of the draft and in some presentations). 

Understood.  We need to make sure we mak= e the *requirements* clear, without trying to dictate *how*.
&nbs= p;
=
Again, I’ll make another pass to it to see if I can find so= me common ground.

I'l= l happily work with you (and Michelle) off list to make sure we get somethi= ng that works.

Barry
 
--001a113483aeb9b4550506928ec5-- From nobody Wed Oct 29 09:54:49 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7430B1A1B55; Wed, 29 Oct 2014 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzxlLnW_yrLi; Wed, 29 Oct 2014 09:54:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E23B1A1B46; Wed, 29 Oct 2014 09:54:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029165443.6647.29382.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 09:54:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NvF0eVc4QpsxFqmTp-3yFyK6zo0 Cc: draft-ietf-weirds-object-inventory@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Barry Leiba's Abstain on draft-ietf-weirds-object-inventory-06: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:54:44 -0000 Barry Leiba has entered the following ballot position for draft-ietf-weirds-object-inventory-06: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I see no value in publishing this document as an RFC. I think it would be great to keep the information in the wiki for all to peruse, but I don't think anyone will want to read the RFC a year from now, much less several years from now. But I understand that this has been discussed and decided, so I will accept that I'm in the rough, and will abstain. From nobody Wed Oct 29 10:22:29 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0021A6FD4; Wed, 29 Oct 2014 10:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5wCzKGVKPrz; Wed, 29 Oct 2014 10:22:24 -0700 (PDT) Received: from office.denic.de (office.denic.de [81.91.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B59C1A01A8; Wed, 29 Oct 2014 10:22:24 -0700 (PDT) Received: from office.denic.de (mailout1.denic.de [10.122.34.3]) by office.denic.de (Postfix) with ESMTPS id 36247240244; Wed, 29 Oct 2014 18:22:16 +0100 (CET) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtps (TLSv1:AES256-SHA:256) id 1XjWwq-00074y-0w; Wed, 29 Oct 2014 18:22:16 +0100 Received: from localhost by x27.adm.denic.de with local id 1XjWwp-000227-RR; Wed, 29 Oct 2014 18:22:15 +0100 Date: Wed, 29 Oct 2014 18:22:15 +0100 From: Peter Koch To: Barry Leiba Message-ID: <20141029172215.GW21403@x28.adm.denic.de> Mail-Followup-To: Barry Leiba , Marc Blanchet , "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-bootstrap@tools.ietf.org" , "weirds@ietf.org" , The IESG References: <20141029063322.10888.60928.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/VUvCmB9JBZWWKddbuftK_8EY9tQ Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-bootstrap@tools.ietf.org" , "weirds@ietf.org" , The IESG Subject: Re: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-bootstrap-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:22:26 -0000 On Wed, Oct 29, 2014 at 12:23:28PM -0400, Barry Leiba wrote: > Again, that's not mentioned. The document says that these RDAP registries > aren't updated as usual with registries, but are generated from the source > registries. If that's just how they get started, and IANA is expected to > keep them current in real time to coincide with all updates to the source > registries, the document has to say that in the IANA Considerations. in the light of the current discussion about "IANA transition" that lets us all look a bit closer at the IETF/IANA relations I wonder whether it is appropriate to tell the "IETF-IANA" that a "registry" shall be a copy of (or, essentially a processed combination of) registries maintained on behalf of/under the auspices of other policy setting bodies. For the _protocol_ to work, a registry (in the IETF sense) is simply not necessary. For the _service_ to work, a bootstrapping is nice to have, but IMHO it's not the IETF to define that service. Instead of describing the seeding and maintenance (rather than the syntax/format) of this "registry" in an IETF standards track document, it would be cleaner policy wise for ICANN (sic) to publish, say, an independent stream RFC that states how the "registry" (and the misnomer can be dealt with by then) is maintained and how and where it can be accessed. -Peter From nobody Wed Oct 29 10:29:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1786E1A7016; Wed, 29 Oct 2014 10:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n75yoBN2eFuy; Wed, 29 Oct 2014 10:29:24 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023EF1A700D; Wed, 29 Oct 2014 10:29:23 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so3864366wgg.4 for ; Wed, 29 Oct 2014 10:29:22 -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=dKe26F3M3wNaSeG5zzZ2zornebz+/zOJVBlYpVhSeGg=; b=koNLe69VxQaD7Nh+ESBPfWtWEqlSdeTm19L5qfe2LpXklFSJqyDTMdDIShcgsPFViq S2fKysMGvNNwPFwICA/WBREfGtD+Kw8jaUnG4DSVlEwtKBmEOOZZGIhYtpbZZ4tzF2Fw +guxp4ReOMvPxCclJ6Ss6HtuFEtUenSDbXmmYxfhZA65mdEXbfvUkPYFyM0agwqdeyBk 3XY6Jnvul0JmuXL3Jagw2bRf20izzzEF8Y/f9UV/Kad+2FO+8ERRpwN6sdsMWRfbbTq5 rHmkrpEhmcnoqBA3aMdEXm4n8zHrF5xM4KiTAzwMpHZSx58ZOC/wM7nzILh+s4YPe1Ls 5FpA== MIME-Version: 1.0 X-Received: by 10.194.3.2 with SMTP id 2mr14251635wjy.89.1414603762350; Wed, 29 Oct 2014 10:29:22 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Wed, 29 Oct 2014 10:29:22 -0700 (PDT) In-Reply-To: <6B5169E9-465A-4FFE-8FD3-C939FC309A21@viagenie.ca> References: <20141029063322.10888.60928.idtracker@ietfa.amsl.com> <6B5169E9-465A-4FFE-8FD3-C939FC309A21@viagenie.ca> Date: Wed, 29 Oct 2014 10:29:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: Marc Blanchet Content-Type: multipart/alternative; boundary=047d7b343c18c0c8f60506931a5e Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ZQWEL_usgojbWeSDt0HdAwdwxLc Cc: The IESG , "weirds-chairs@tools.ietf.org" , Barry Leiba , "draft-ietf-weirds-bootstrap@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-bootstrap-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:29:29 -0000 --047d7b343c18c0c8f60506931a5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 9:31 AM, Marc Blanchet wrote: > > currently, for names, the registration process includes a =C2=AB whois se= rver >> domain name =C2=BB entry. IANA will add a new entry for =C2=AB rdap serv= er url =C2=BB to >> the process, so that registrie can send their rdap server url entry thro= ugh >> the normal process. > > > I don't see that the document tells IANA they need to do that. Each of > the four registries needs to have a new field, and that has to be made > clear in the IANA Considerations. > > well, I=E2=80=99ve been told _many_ times to let IANA do their own stuff = on their > side and we should not intervene/require/write text on this. I=E2=80=99m = all fine > in saying those things (it was actually in the very first versions of the > draft and in some presentations). > An example of the sort of thing we can't tell IANA is to "create a registry in the JSON format". The way that's worded, we'd be telling IANA that they have to store it in JSON. In fact, we don't care how they store it; we care how they export it. That's the kind of precision and observation of boundaries that IANA Considerations needs. On the other hand, what Barry's talking about is exactly the kind of thing we _do_ need to include. Now, for Barry: The first paragraph of Section 12 is our attempt to do what you're asking, namely an instruction to augment the existing registries with the fields we need to produce the RDAP bootstrap information. Are you just looking for something like this? ADD TO FIRST PARAGRAPH OF SECTION 12: Specifically, each entry in the existing IANA registries needs a new field that contains a list of RDAP server URIs where RDAP service for the corresponding entity/entities will be available. This field needs to be populated as these URIs are provided to IANA. > > >> > If IANA generates these by periodically re-processing the source >> > registries to pick up changes, how current are the RDAP registries >> > expected to be? Is it OK for them to be updated once a week? Once a >> > month? Are we setting up any SLAs for the timeliness and reliability = of >> > these registries? >> >> they would not be regenerated from the source. The rdap registries will >> be updated whenever there is a change submitted by the registries for an >> rdap entry. For example, say =C2=AB.ontario =C2=BB has a whois server b= ut no rdap >> server. .ontario will not be in the rdap registry. When .ontario has his >> rdap server and running, they will request IANA (through the updated >> process described above) to add their entry (.ontario) in the rdap >> registry for their rdap server. Then when IANA process the request, the >> rdap registry will be updated. No synching or else. > > > Again, that's not mentioned. > > same reasoning as above. > I agree that this is also something we do need to document. I do think we tried in the second paragraph of Section 12 to say that, but we're possibly too close to the material to say it with the right amount of detail. Does the above suggestion cover it? > > The document says that these RDAP registries aren't updated as usual with > registries, but are generated from the source registries. If that's just > how they get started, and IANA is expected to keep them current in real > time to coincide with all updates to the source registries, the document > has to say that in the IANA Considerations. > > > Again, I=E2=80=99ll make another pass to it to see if I can find some com= mon > ground. > Does the above help at all? > ... > > > This document requests IANA to make an augmented version of >> > the existing registries available for the specific purpose of >> > RDAP use >> > >> > I presume that IANA has agreed to do that. Where will the URIs for >> those >> > augmented registries be published. >> >> as typical, the URI of these registries will not be in the RFC. Moreover= , >> IANA specifically requested to not have the URI in the RFC, because of t= he >> requirements for =C2=AB high volume =C2=BB which may require some specif= ic URL. >> >> > That is, how will a bootstrapping >> > application know where to find them for the bootstrapping? >> >> the developer will have to look at IANA site once to find the url of the >> bootstrap registries. >> >> Not sure what is my action item here. > > > How will the developer know where to look? If developers are expected to > look someplace, and then hard-code the URL(s) into their products, then (= 1) > they have to be told that, and told where to look to find the URL(s) and > (2) IANA has to be told that the URLs have to be published in the place w= e > tell the developers to look, and they have to be told that those URL MUST > be persistent (because they will be hard-coded in software). That stuff > has to be in the IANA Considerations. > > > again, I=E2=80=99m full agreement with your point. I=E2=80=99ll raised it= with IANA to see > if we can do something. > We have a bit of a chicken-and-egg problem here. I guess we can just leave a placeholder URL for IANA to fill in when it makes that decision. I hadn't pushed us to do so because the root cache for DNS is understood to exist for download at some known locations, but I don't think that appears in any RFCs; it's just something IANA does, and people figure out out-of-band how to find it. -MSK --047d7b343c18c0c8f60506931a5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 29, 2014 at 9:31 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

=
currently, for names, the registration process includes a =C2=AB whois serv= er domain name =C2=BB entry. IANA will add a new entry for =C2=AB rdap serv= er url =C2=BB to the process, so that registrie can send their rdap server = url entry through the normal process.

I don= 't see that the document tells IANA they need to do that.=C2=A0 Each of= the four registries needs to have a new field, and that has to be made cle= ar in the IANA Considerations.
well, I= =E2=80=99ve been told _many_ times to let IANA do their own stuff on their = side and we should not intervene/require/write text on this. I=E2=80=99m al= l fine in saying those things (it was actually in the very first versions o= f the draft and in some presentations).=C2=A0

An example of the sort of thing we can't tell IANA= is to "create a registry in the JSON format".=C2=A0 The way that= 's worded, we'd be telling IANA that they have to store it in JSON.= =C2=A0 In fact, we don't care how they store it; we care how they expor= t it.=C2=A0 That's the kind of precision and observation of boundaries = that IANA Considerations needs.

On the other hand, what B= arry's talking about is exactly the kind of thing we _do_ need to inclu= de.=C2=A0 Now, for Barry: The first paragraph of Section 12 is our attempt = to do what you're asking, namely an instruction to augment the existing= registries with the fields we need to produce the RDAP bootstrap informati= on. Are you just looking for something like this?

ADD TO = FIRST PARAGRAPH OF SECTION 12:

Specifically, each entry i= n the existing IANA registries needs a new field that contains a list of RD= AP server URIs where RDAP service for the corresponding entity/entities wil= l be available.=C2=A0 This field needs to be populated as these URIs are pr= ovided to IANA.


=C2=A0
&g= t; If IANA generates these by periodically re-processing the source
> registries to pick up changes, how current are the RDAP registries
> expected to be? Is it OK for them to be updated once a week?=C2=A0 Onc= e a
> month?=C2=A0 Are we setting up any SLAs for the timeliness and reliabi= lity of
> these registries?

they would not be regenerated from the source. The rdap registries will be = updated whenever there is a change submitted by the registries for an rdap = entry.=C2=A0 For example, say =C2=AB.ontario =C2=BB has a whois server but = no rdap server. .ontario will not be in the rdap registry. When .ontario ha= s his rdap server and running, they will request IANA (through the updated = process described above) to add their entry (.ontario)=C2=A0 in the rdap re= gistry for their rdap server. Then when IANA process the request, the rdap = registry will be updated.=C2=A0 No synching or else.

<= /div>
Again, that's not mentioned.
=
same reasoning as above.

=
I agree that this is also something we do need to document.=C2=A0 I do= think we tried in the second paragraph of Section 12 to say that, but we&#= 39;re possibly too close to the material to say it with the right amount of= detail.=C2=A0 Does the above suggestion cover it?
=C2=A0
<= span class=3D"">
The document says t= hat these RDAP=C2=A0registries aren't updated as usual with registries,= but are generated from the source registries.=C2=A0 If that's just how= they get started, and IANA is expected to keep them current in real time t= o coincide with all updates to the source registries, the document has to s= ay that in the IANA Considerations.

=
Again, I=E2=80=99ll make another pass to it to see if I can fin= d some common ground.

Doe= s the above help at all?
...

>=C2= =A0 =C2=A0This document requests IANA to make an augmented version of
>=C2=A0 =C2=A0the existing registries available for the specific purpose= of
>=C2=A0 =C2=A0RDAP use
>
> I presume that IANA has agreed to do that.=C2=A0 Where will the URIs f= or those
> augmented registries be published.

as typical, the URI of these registries will not be in the RFC. Moreover, I= ANA specifically requested to not have the URI in the RFC, because of the r= equirements for =C2=AB high volume =C2=BB which may require some specific U= RL.

> That is, how will a bootstrapping
> application know where to find them for the bootstrapping?

the developer will have to look at IANA site once to find the url of the bo= otstrap registries.

Not sure what is my action item here.

How w= ill the developer know where to look?=C2=A0 If developers are expected to l= ook someplace, and then hard-code the URL(s) into their products, then (1) = they have to be told that, and told where to look to find the URL(s) and (2= ) IANA has to be told that the URLs have to be published in the place we te= ll the developers to look, and they have to be told that those URL MUST be = persistent (because they will be hard-coded in software).=C2=A0 That stuff = has to be in the IANA Considerations.

again, I=E2=80=99m full agreement with your point. I=E2=80=99= ll raised it with IANA to see if we can do something.=C2=A0

We have a bit of a chicken-and-egg probl= em here.=C2=A0 I guess we can just leave a placeholder URL for IANA to fill= in when it makes that decision.=C2=A0 I hadn't pushed us to do so beca= use the root cache for DNS is understood to exist for download at some know= n locations, but I don't think that appears in any RFCs; it's just = something IANA does, and people figure out out-of-band how to find it.
<= br>
-MSK
--047d7b343c18c0c8f60506931a5e-- From nobody Wed Oct 29 10:30:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96611A7014; Wed, 29 Oct 2014 10:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI5qioLHa3i4; Wed, 29 Oct 2014 10:30:01 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B281A7016; Wed, 29 Oct 2014 10:30:00 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id a1so2422455wgh.34 for ; Wed, 29 Oct 2014 10:29:59 -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=6iI4NDhK62i+T05uO90VCRfZNTGBsn2isI8TJb/FLM4=; b=vRB7xwmFN/iG230kfod48LcbuTha6Yd/ozaSQ78RreptmcSdC1r6eS//B+PrfvNWwY CnpdlTACP+CxRpmTQ96BS5hEr9obfFKmFeyP7LWQ333zKfJZdBS4GxDLYz3O12b+6tI7 sKkhV5nMB61SNtRen3yfn/IArI7XCKrthrUAmHR0NcEzKF6xxceBCLxk9uXnfC8YRP+X dRInsjkxIL3QsWNHYzBjvMX+DutXj6E/0RGUzdU2QLnt01qmNXhkzFObSJAC5aU/gX3V ocfW4u1AxCszJghYBEPbcm05rkmpe0Tu3yL2p21vnGUAEcbofUJTufrnjdCaIlhL7A/o T5dw== MIME-Version: 1.0 X-Received: by 10.180.91.49 with SMTP id cb17mr13617210wib.30.1414603799250; Wed, 29 Oct 2014 10:29:59 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Wed, 29 Oct 2014 10:29:59 -0700 (PDT) In-Reply-To: References: <20141029063322.10888.60928.idtracker@ietfa.amsl.com> <6B5169E9-465A-4FFE-8FD3-C939FC309A21@viagenie.ca> Date: Wed, 29 Oct 2014 10:29:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d043c7b2af3cf0a0506931c84 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/bSKZ8CaCqAP_-GljaW7_bPotazo Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-bootstrap@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-bootstrap-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:30:05 -0000 --f46d043c7b2af3cf0a0506931c84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 9:50 AM, Barry Leiba wrote: > well, I=E2=80=99ve been told _many_ times to let IANA do their own stuff = on their >> side and we should not intervene/require/write text on this. I=E2=80=99m= all fine >> in saying those things (it was actually in the very first versions of th= e >> draft and in some presentations). >> > > Understood. We need to make sure we make the *requirements* clear, > without trying to dictate *how*. > Yes, that's been the basis of my guidance throughout the process. > > >> Again, I=E2=80=99ll make another pass to it to see if I can find some co= mmon >> ground. >> > > I'll happily work with you (and Michelle) off list to make sure we get > something that works. > Count me in as well. -MSK --f46d043c7b2af3cf0a0506931c84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 29, 2014 at 9:50 AM, Barry Leiba <barry= leiba@computer.org> wrote:
we= ll, I=E2=80=99ve been told _many_ times to let IANA do their own stuff on t= heir side and we should not intervene/require/write text on this. I=E2=80= =99m all fine in saying those things (it was actually in the very first ver= sions of the draft and in some presentations).=C2=A0
<= /blockquote>

Understood.=C2=A0 We need to make su= re we make the *requirements* clear, without trying to dictate *how*.
=

Yes, that's been the basis of my guida= nce throughout the process.
=C2=A0
=C2=A0
Again, I=E2=80=99ll make another pas= s to it to see if I can find some common ground.

I'll happily work with you (and Michelle= ) off list to make sure we get something that works.

Count me in as well.

-MSK
= --f46d043c7b2af3cf0a0506931c84-- From nobody Wed Oct 29 11:21:11 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B973B1A877F for ; Wed, 29 Oct 2014 11:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqAShIjU208S for ; Wed, 29 Oct 2014 11:20:58 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938311A8795 for ; Wed, 29 Oct 2014 11:20:56 -0700 (PDT) Received: (qmail 85022 invoked from network); 29 Oct 2014 18:20:54 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 29 Oct 2014 18:20:54 -0000 Date: 29 Oct 2014 18:20:32 -0000 Message-ID: <20141029182032.56782.qmail@ary.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F495084BA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/nlKUNjYCnCYJ3zM-Ejvf6z8KFVI Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:21:00 -0000 >> TLS. I'm especially curious about this since clients are required to >> support HTTPS anyway. > >The current text is a reflection of operational possibilities in >which the server operator does not support queries that could return >PII. I don't believe we had WG support for requiring HTTPS in such >situations. Do we need to mandate TLS for all servers? One of my early bootstrap proposals was https only, and people said no, don't do that. Even though everyone supports https, the wide variation in CAs and ciphers makes interop failures surprisingly common. For example, imagine a ccTLD that uses a cert signed by an authority that is widely used in its own country, and unknown elsewhere. Also keep in mind that not all URLS start with http or https. For a small provider handling what would currently be SWIPs, it might well be easier to use ftp. R's, John From nobody Wed Oct 29 11:47:54 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DE11A884D; Wed, 29 Oct 2014 11:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2zbd7wVsirg; Wed, 29 Oct 2014 11:47:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C78E1A87A6; Wed, 29 Oct 2014 11:47:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 11:47:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/uFSrXBux5wDfSmWGpmq44Uak49o Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org Subject: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:47:52 -0000 Ted Lemon has entered the following ballot position for draft-ietf-weirds-rdap-query-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Point 1: In section 3.1.1, it's not clear which of three alternative things you may have been specifying: (1) the ASCII representation of the IP address is intended to be converted to binary before use, (2) the ASCII representation is intended to be used directly, or (3) whether the IP address is converted to binary prior to use is an implementation choice. If (1) is what's intended, you should say so explicitly. If either (2) or (3) is intended, then the representation that's used needs to be in some canonical form, and the text as written does not ensure that it will be. So to address this discuss, you should either update the text to say that (1) is what's intended, and it won't work otherwise, or you need to require, not suggest, a canonical representation. If you go with the second option, your reference to RFC 5952 isn't adequate: you need to specifically reference section 4, and specifically exclude section 5. I have no preference as to how you resolve this. Point 2: In 3.1.3, the instructions as given don't really guide implementations toward interoperability. Why not just say that servers SHOULD either convert a-labels to u-labels, or u-labels to a-labels, and be done with it? It's not like it's a difficult conversion, and they have to do the conversion to do the comparison, unless for some reason they store both A- and U-labels as keys in their database, which seems really unlikely. The recommendations are written are so vague that I would expect interoperability to only be likely in the case of queries that contain no IDN labels. I wouldn't mind this in an Informational document, but it's pretty sketchy in a standards-track document. It's particularly weird that in one place you say "An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup" and then in the next paragraph you say "The server MAY perform the match using either the A-label or U-label form. Using one consistent form for matching every label is likely to be more reliable." I'm not sure how to resolve this. I think there's some underlying decision the working group has made that led to this language, but the lack of consistency I mention above leads me to wonder if either that decision wasn't very clear, or the document failed to reflect it. Interestingly, 3.1.4 is written as if 3.1.3 gives clear guidance as to how IDNs are represented. In 3.2.1 and 3.2.2, the main use cases I can see for nameserver searches are for spammers to identify related domains, and for eavesdroppers to do the same. What's the motivation for including these capabilities? At a minimum, the privacy considerations for this search ought to be discussed in a privacy considerations section or in the security considerations section. Point 3: In 4.1, you don't actually specify the syntax for partial string matches. I think I can intuit what you mean, but you should be explicit, and you shouldn't suggest using POSIX regex searches unless that's what you really mean; if that's what you really mean, then you need to do a lot more work than you've done. I _think_ what you intend is to simply say that if one or more asterisks appear in a label, then when the search is done, any label that contains the non-asterisk characters in sequence plus zero or more characters in sequence in place of each asterisk would match. But you don't actually say that, so I'm not sure what you actually intended. The text could be read to mean that any arbitrary search mechanism is allowed, but if that's the case then you need to go into a lot more detail about the caveats, such as the '.' character in posix regexps and the start and end markers. The text on partial matches for unicode also seems unnecessarily complicated, and likely not implementable without massive knowledge of all the various unicode character sets, which I would not expect an implementation to bother with. It seems relatively harmless to allow searches on combining characters, particularly since it would be a lot of work to prevent it. For example, a search for *ཀ་ would not find all instances of a syllable that starts with the sound "ka" because ka can be either a head letter or subjoined, but a user might search first using the head letter and then the subjoined letter if (as is not unlikely) he or she were unsure of the correct spelling. It would be a shame if such a search were rendered impossible by an overly-thorough implementation of the current text. As I say, I don't really know what was intended here, so I can't make a definite suggestion as to what the right thing to do is to fix this; I think we just need to discuss it, hence the discuss point. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Point A: In 3.1.2: For example, the following URL would be used to find information describing autonomous system number 12 (a number within a range of registered blocks): http://example.com/rdap/autnum/12 The following URL would be used to find information describing 4-byte autonomous system number 65538: http://example.com/rdap/autnum/65538 The examples don't really seem to illustrate what is said in the text. The syntax for both examples is the same, and we don't see any return results. So to say that one example is an example of a number within a range of registered blocks, while the other is a 4-byte number, doesn't make sense because the query formats are identical. The preceding text is clear, if I understand it correctly: a number in the path element following 'autnum' is an autonomous system number, which references a block of one or more numbers. If there are additional semantics, e.g., byte size boundaries for AS numbers, that are also encoded in the query, those should be described explicitly. But IMHO that doesn't make sense: in _this_ context, these are just decimal numbers of arbitrary precision, and how many bytes they are, or whether any particular number references a block or just a single number, is not something that should be mentioned in the examples. Point B: Section 6 appears to be confusing presentation and representation. A client might well present a UI that shows U-labels, but use A-labels on the back end. The text as written here really doesn't make sense. What are you trying to say? I think that you shouldn't confuse what's presented to the user with what's sent on the wire. Possibly this is related to the confusion over A-labels and U-labels that I called out in Point 2 of the discuss. From nobody Wed Oct 29 12:40:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778781A89FD; Wed, 29 Oct 2014 12:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMlj0U8JASkN; Wed, 29 Oct 2014 12:40:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E95141A89FC; Wed, 29 Oct 2014 12:40:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029194033.25541.89324.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 12:40:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/PgzLMV4Yr_qMpcP5m68p01a6JVk Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-json-response@tools.ietf.org Subject: [weirds] Ted Lemon's No Objection on draft-ietf-weirds-json-response-11: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 19:40:35 -0000 Ted Lemon has entered the following ballot position for draft-ietf-weirds-json-response-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Point 1: In 4.3: It is the job of the clients to determine line breaks, spacing and display issues for sentences within the character strings of the "description" array. Each string in the "description" array contains a single complete division of human readable text indicating to clients where there are semantic breaks. What do you mean by "semantic breaks"? Paragraph breaks? Sentence breaks? Dependent clause breaks? This doesn't make sense. I'm not going to raise a discuss on it because I don't think it affects interoperability, but I have no idea how to implement a client to display this in a way that will make sense to the user. Point 2: A general question that occurred to me in reading 5.5, which also applies to 5.4: should you have some text talking about how the link member of a network or autnum object is generated? Both networks and autnum objects, as I understand it, can be gotten by querying any number in the range they enclose. But of course the link member isn't going to enumerate all the possible queries that could return the particular object containing that link member. So how is the value that's returned chosen? Is it the lowest number in the range? The number that was used in the query that returned the object? Some other number? I don't think you need to change anything, but it might be worth discussing this in sections 5.4 and 5.5. From nobody Wed Oct 29 13:22:34 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE71D1A88AF; Wed, 29 Oct 2014 13:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwpiBCaP-ZY1; Wed, 29 Oct 2014 13:22:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CCA1A88A0; Wed, 29 Oct 2014 13:22:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029202207.28303.43283.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 13:22:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/fQwXAca_wyYcN9nsj12GGK-wdfI Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Stephen Farrell's No Record on draft-ietf-weirds-rdap-sec-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:22:23 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-weirds-rdap-sec-10: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've yet to read the weirds docs but in the meantime am fully supportive of Alissa's privacy related points. From nobody Wed Oct 29 15:12:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE1B1A90EB; Wed, 29 Oct 2014 14:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po_fIMKR5di9; Wed, 29 Oct 2014 14:43:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A081A8766; Wed, 29 Oct 2014 14:43:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029214342.30884.77333.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 14:43:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/JeuJInym5Ylln0Ge0KIkVcBkyr4 X-Mailman-Approved-At: Wed, 29 Oct 2014 15:12:15 -0700 Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-json-response@tools.ietf.org Subject: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 21:43:45 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-weirds-json-response-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft and including options for privacy protections. I do support Alissa's discuss on the -sec draft and as such, my discuss here is specific to this draft and values set forth in it for privacy. The general security and privacy considerations would be good to reference from one place. I think it would help to have the explicit guidance or recommendations for privacy included directly in the privacy section. While the example in the appendix is good, I'd prefer to see explicit recommendations for each of the relevant status codes from section 10.2.2. How about something along the lines of the following: Current Privacy Considerations section: This specification suggests status values to denote contact and registrant information that has been marked as private and/or has been redacted or obscured. See Section 10.2.2 for the list of status values. See Appendix A.1 on guidance to apply those values to contacts and registrants. Suggested Privacy Considerations section: This specification suggests status values to denote contact and registrant information that has been marked as private and/or has been redacted or obscured. See Section 10.2.2 for the complete list of status values. A few of the status values indicate that there are privacy concerns associated with the object instance. For the following status codes, the RECOMMENDED actions include: 7. private - The object is not be shared in query responses, unless the user is authorized to view this information. 8. redacted - The data has already been redacted, and may be returned in a response in the data redacted form. This is a safer option to choose to prevent unauthorized access to associated object instances than marking them as private. 9. obscured - The data has already been obscured, and may be returned in a response in the obscured form. This option may reveal privacy sensitive information and should only be used when data sensitivity does not require a more protective option like "private" or "redacted". See Appendix A.1 or an example applying those values to contacts and registrants. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing the SecDir review and including information on a possible cache poisoning attack. http://www.ietf.org/mail-archive/web/secdir/current/msg05183.html Some nits were included as well that might be helpful. From nobody Wed Oct 29 15:45:50 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476CC1AC3F2; Wed, 29 Oct 2014 15:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0N8UPL9AtkH; Wed, 29 Oct 2014 15:45:41 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 297A31AC3F0; Wed, 29 Oct 2014 15:45:41 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 95328165001; Wed, 29 Oct 2014 18:45:40 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 9255E164FDE; Wed, 29 Oct 2014 18:45:39 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 29 Oct 2014 18:47:55 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Wed, 29 Oct 2014 18:45:31 -0400 From: Andy Newton To: Ted Lemon Thread-Topic: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) Thread-Index: AQHP86jbPycVGSxOaEags5rtlyoB6ZxH79KA Date: Wed, 29 Oct 2014 22:45:30 +0000 Message-ID: <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> In-Reply-To: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0012178D06C77F4AA756F400B662EF9C@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/GeNbuUVXgmxSaxOETd99sB3sn4g Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 22:45:43 -0000 On Oct 29, 2014, at 2:47 PM, Ted Lemon wrote: > Point 1: >=20 > In section 3.1.1, it's not clear which of three alternative things you > may have been specifying: (1) the ASCII representation of the IP address > is intended to be converted to binary before use, (2) the ASCII > representation is intended to be used directly, or (3) whether the IP > address is converted to binary prior to use is an implementation choice.= =20 > If (1) is what's intended, you should say so explicitly. If either (2) > or (3) is intended, then the representation that's used needs to be in > some canonical form, and the text as written does not ensure that it will > be. >=20 > So to address this discuss, you should either update the text to say that > (1) is what's intended, and it won't work otherwise, or you need to > require, not suggest, a canonical representation. If you go with the > second option, your reference to RFC 5952 isn't adequate: you need to > specifically reference section 4, and specifically exclude section 5. I > have no preference as to how you resolve this. It is option 3. However, the implementer wishes to construct a database is = up to the implementer. They need to be able to parse IPv6 addresses and use= them to construct whatever key their database uses, be it textual or binar= y. Having implemented both forms, you cannot simply take the textual repres= entation and use that as a key. All that being said, I don=92t understand the suggested fix. Section 5 of R= FC 5952 is about IPv4 embedded addresses in IPv6 addresses. But they are di= fferent addresses. There is no collision so the need for canonicalization i= sn=92t obvious. Cutting embedded-IPv4 addresses does make implementation ea= sier, and I don=92t think anybody would actually care if they were explicit= ly forbidden. > In 3.2.1 and 3.2.2, the main use cases I can see for nameserver searches > are for spammers to identify related domains, and for eavesdroppers to do > the same. What's the motivation for including these capabilities? At > a minimum, the privacy considerations for this search ought to be > discussed in a privacy considerations section or in the security > considerations section. Nameserver searches return nameserver objects. I don=92t know how useful th= at would be a to a spammer, but to a nameserver operator trying to determin= e which registrations are pointing to their nameserver, that seems useful. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Point A: >=20 > In 3.1.2: >=20 > For example, the following URL would be used to find information > describing autonomous system number 12 (a number within a range of > registered blocks): >=20 > http://example.com/rdap/autnum/12 >=20 > The following URL would be used to find information describing 4-byte > autonomous system number 65538: >=20 > http://example.com/rdap/autnum/65538 >=20 > The examples don't really seem to illustrate what is said in the text. =20 > The syntax for both examples is the same, and we don't see any return > results. So to say that one example is an example of a number within a > range of registered blocks, while the other is a 4-byte number, doesn't > make sense because the query formats are identical. The preceding text > is clear, if I understand it correctly: a number in the path element > following 'autnum' is an autonomous system number, which references a > block of one or more numbers. If there are additional semantics, e.g., > byte size boundaries for AS numbers, that are also encoded in the query, > those should be described explicitly. But IMHO that doesn't make sense: > in _this_ context, these are just decimal numbers of arbitrary precision, > and how many bytes they are, or whether any particular number references > a block or just a single number, is not something that should be > mentioned in the examples. Those examples seem far away from that reference to ASPLAIN and RFC 5396. T= he point is: don=92t do ASDOT=85 which is an issue for 4-byte as numbers. W= e should probably actually say that, and split apart the first paragraph to= put the examples closer to it. -andy= From nobody Wed Oct 29 16:00:34 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14E81ACCF0; Wed, 29 Oct 2014 16:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSwXJHV1PBp9; Wed, 29 Oct 2014 16:00:30 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5431AC3FB; Wed, 29 Oct 2014 16:00:30 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id E23A7DA0223; Wed, 29 Oct 2014 23:03:44 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id EC19253E084; Wed, 29 Oct 2014 15:59:59 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 15:59:59 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> Date: Wed, 29 Oct 2014 18:59:46 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <18AD51DF-27E5-4E8E-85A2-FAB95A5B8EA2@nominum.com> References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/5PqyGKeAet4nE-gYdFOvwgrOQCA Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 23:00:32 -0000 On Oct 29, 2014, at 6:45 PM, Andy Newton wrote: > It is option 3. However, the implementer wishes to construct a = database is up to the implementer. They need to be able to parse IPv6 = addresses and use them to construct whatever key their database uses, be = it textual or binary. Having implemented both forms, you cannot simply = take the textual representation and use that as a key. You seem to be saying it's option 1, then, not option 3. > All that being said, I don=92t understand the suggested fix. Section 5 = of RFC 5952 is about IPv4 embedded addresses in IPv6 addresses. But they = are different addresses. There is no collision so the need for = canonicalization isn=92t obvious. Cutting embedded-IPv4 addresses does = make implementation easier, and I don=92t think anybody would actually = care if they were explicitly forbidden. It should be the case that there isn't more than one way to represent = the IP address. Or else it should be the case that the server is = required to accept the IP address no whether it is canonicalized or not. = You have to tell the client what to expect. If it's okay for the = client to send any old syntactically valid IP address, that's fine, but = the document doesn't currently say that, and so a server implementor = might _assume_ that you mean that only addresses canonicalized according = to section 4 of RFC 5952 are permitted. The point of normative = language is to make sure that we don't rely on the implementor to make = the same assumptions we made. > Nameserver searches return nameserver objects. I don=92t know how = useful that would be a to a spammer, but to a nameserver operator trying = to determine which registrations are pointing to their nameserver, that = seems useful. Wouldn't they already know, since they configured the name server? From nobody Wed Oct 29 16:24:34 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3A81ACD05; Wed, 29 Oct 2014 16:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJcw-YvMMxdC; Wed, 29 Oct 2014 16:24:31 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id E960A1A6F93; Wed, 29 Oct 2014 16:24:30 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 695F7165005; Wed, 29 Oct 2014 19:24:30 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id D2CF6164FF8; Wed, 29 Oct 2014 19:24:29 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 29 Oct 2014 19:26:52 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Wed, 29 Oct 2014 19:24:29 -0400 From: Andy Newton To: Ted Lemon Thread-Topic: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) Thread-Index: AQHP86jbPycVGSxOaEags5rtlyoB6ZxH79KAgAAD+wCAAAbogA== Date: Wed, 29 Oct 2014 23:24:28 +0000 Message-ID: <7EEC5E39-E7B7-4407-9634-9D13F4EE8075@arin.net> References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> <18AD51DF-27E5-4E8E-85A2-FAB95A5B8EA2@nominum.com> In-Reply-To: <18AD51DF-27E5-4E8E-85A2-FAB95A5B8EA2@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8C083EEFB43D004788D40A8AB2EB938B@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NOrKjiQCvLEPeELsRJIWWGtrl1Y Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 23:24:32 -0000 On Oct 29, 2014, at 6:59 PM, Ted Lemon wrote: > It should be the case that there isn't more than one way to represent the= IP address. Or else it should be the case that the server is required to= accept the IP address no whether it is canonicalized or not. You have to = tell the client what to expect. If it's okay for the client to send any o= ld syntactically valid IP address, that's fine, but the document doesn't cu= rrently say that, and so a server implementor might _assume_ that you mean = that only addresses canonicalized according to section 4 of RFC 5952 are pe= rmitted. The point of normative language is to make sure that we don't re= ly on the implementor to make the same assumptions we made. Now I understand. Thanks. >> Nameserver searches return nameserver objects. I don=92t know how useful= that would be a to a spammer, but to a nameserver operator trying to deter= mine which registrations are pointing to their nameserver, that seems usefu= l. >=20 > Wouldn't they already know, since they configured the name server? Not necessarily. How a nameserver object is mapped in a registry is not a d= etail needed to configure a nameserver to accept queries for a domain. -andy= From nobody Wed Oct 29 16:29:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F681ACD16; Wed, 29 Oct 2014 16:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEAD7yEG4eln; Wed, 29 Oct 2014 16:29:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 676771ACD14; Wed, 29 Oct 2014 16:29:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029232910.320.95416.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 16:29:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/WcCiluQsh1fhZPS1MdnnJdNZEcM Cc: draft-ietf-weirds-object-inventory@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Alissa Cooper's Abstain on draft-ietf-weirds-object-inventory-06: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 23:29:12 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-weirds-object-inventory-06: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm with Barry -- this seems like it would have made more sense if published on a wiki, as a research paper, or in a slide deck. If the choices made in the protocol documents actually linked back to these findings for justification, I might see it differently, but at present there does not seem to be much connection between these findings and some of the design decisions made in the protocol. The data formats in the protocol don't seem to support every field that was discovered in this study, nor does there seem to be any consistent metric that was used for deciding whether to include a particular field based on its prevalence in these findings. From nobody Wed Oct 29 16:50:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBEC1ACD49; Wed, 29 Oct 2014 16:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G800fbZz-zi9; Wed, 29 Oct 2014 16:50:30 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FD01ACD50; Wed, 29 Oct 2014 16:50:30 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id F1BB0DA021E; Wed, 29 Oct 2014 23:53:44 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id AA4CE53E084; Wed, 29 Oct 2014 16:49:59 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 16:49:59 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <7EEC5E39-E7B7-4407-9634-9D13F4EE8075@arin.net> Date: Wed, 29 Oct 2014 19:49:44 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <83C9269A-D476-4C64-ACFE-7D20DAE2BD25@nominum.com> References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> <18AD51DF-27E5-4E8E-85A2-FAB95A5B8EA2@nominum.com> <7EEC5E39-E7B7-4407-9634-9D13F4EE8075@arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/FdiAGJSKdJpuY3r0qjzE57v4Gdc Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 23:50:31 -0000 On Oct 29, 2014, at 7:24 PM, Andy Newton wrote: > Not necessarily. How a nameserver object is mapped in a registry is = not a detail needed to configure a nameserver to accept queries for a = domain. OK, that use case does make some sense. My concern is that it will be = used for data mining by people other than owners of nameservers. I = don't think there's much that can be done to mitigate this, though, so = I'll take it out of the DISCUSS. It wouldn't hurt to mention it = specifically in the security considerations section, but I'll leave that = up to you. From nobody Wed Oct 29 16:53:45 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911911ACD63; Wed, 29 Oct 2014 16:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecQM5Y_igNAN; Wed, 29 Oct 2014 16:53:41 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17ABE1ACCFB; Wed, 29 Oct 2014 16:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414626821; x=1446162821; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=X/O+K4ZyfAub/E5VgRLiPKuChahafsoayISdUqx5Ks4=; b=nYR3f/tyel/mqGdFzPRNQ7wkmoxnNgUgsAL+WZgNX3yFmTJvEMNnSmxw W952chH6qMkIJ/8gfHVOf7/FBmWiShYNFKUtU1pZrNv7AfMWseHI7xO2Z 9S3v+N0fLNPr3gIZciBoZ9eD1eUZP99hnlmF85DOxyy6ga/b1nYANqilP w=; X-IronPort-AV: E=McAfee;i="5600,1067,7606"; a="77093776" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2014 16:53:40 -0700 X-IronPort-AV: E=Sophos;i="5.07,280,1413270000"; d="scan'208";a="765597195" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Oct 2014 16:53:40 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 29 Oct 2014 16:53:39 -0700 Received: from apc-qrc004-rpdu-k02-lf.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 29 Oct 2014 16:53:39 -0700 Message-ID: <54517E02.6020501@qti.qualcomm.com> Date: Wed, 29 Oct 2014 16:53:38 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ted Lemon References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> In-Reply-To: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (129.46.53.226) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/SSM_EJUdFy4BjFFvGcpDxhwgcS0 Cc: weirds-chairs@tools.ietf.org, The IESG , draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 23:53:43 -0000 On just point 2: On 10/29/14 11:47 AM, Ted Lemon wrote: > Point 2: > > In 3.1.3, the instructions as given don't really guide implementations > toward interoperability. Why not just say that servers SHOULD either > convert a-labels to u-labels, or u-labels to a-labels, and be done with > it? > See the discussion in section 6.1, referred to in 3.1.3. Converting to u-labels or a-labels can change the search semantics because of case-mapping. Remember, the server is trying to do its best in the face of clients that might be handing it some pretty dicey stuff. A client that does the right thing and only queries all-a-label or all-u-label strings is going to get consistent results, because it is taking responsibility to do the appropriate mappings. But if the client is blindly handing over labels it got from somewhere else (which is why you would get mixed stuff), the server is going to do what it can to get things right (or decide that it doesn't want to try). So the most interoperable thing is to say, "Clients: Query reasonable things. Servers: You can choose to be helpful or not on unreasonable things." At least that's my understanding of the consensus of the WG and the IDN experts consulted; the IDN experts on the list can pipe up if I've gotten this wrong. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Oct 29 17:10:45 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3B01ACDDD; Wed, 29 Oct 2014 17:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YssKKoZaPxby; Wed, 29 Oct 2014 17:10:35 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0191ACDEF; Wed, 29 Oct 2014 17:10:35 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 05D96DA0224; Thu, 30 Oct 2014 00:13:51 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B34D953E080; Wed, 29 Oct 2014 17:10:05 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 17:10:05 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54517E02.6020501@qti.qualcomm.com> Date: Wed, 29 Oct 2014 20:09:50 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <54517E02.6020501@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ru7lBnj9VKgbPtVWepRrrdmXBTQ Cc: weirds-chairs@tools.ietf.org, The IESG , draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 00:10:37 -0000 On Oct 29, 2014, at 7:53 PM, Pete Resnick = wrote: > A client that does the right thing and only queries all-a-label or = all-u-label strings is going to get consistent results, because it is = taking responsibility to do the appropriate mappings. But if the client = is blindly handing over labels it got from somewhere else (which is why = you would get mixed stuff), Why would the client do that? Why not specify what the right thing is = for the client to do as a SHOULD, and _then_ explain what might break if = it doesn't, rather than just sort of talking about it and hoping for the = best? Also, U-labels are case-sensitive. So the semantic difference you're = describing doesn't actually exist. A-labels are just encoded U-labels. = So if you take an A-label and turn it into a U-label, you can do a = comparison between it and another U-label without case folding, and = indeed you aren't _allowed_ to do case folding. And similarly, if you = take a U-label and encode it as an A-label, then you can just compare it = to other A-labels, because A-label comparisons are case-insensitive with = respect to the A-label representation: case-folding does not change the = meaning of an A-label. This is explained in RFC 5891 section 3 bullet = point 2. (BTW, what I just explained in the above paragraph gives me a headache = and tells me we should _never_ use IDN for any writing system that has = case, because it will be insanely easy to spoof. But you probably = already knew that.) From nobody Wed Oct 29 17:32:50 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA61ACE70; Wed, 29 Oct 2014 17:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN_NUeBLFByK; Wed, 29 Oct 2014 17:32:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0338F1ACE71; Wed, 29 Oct 2014 17:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414629163; x=1446165163; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QVmPevajKZTwi5aVRTqs2kKm0pDnN3ojl/hPSfFSNEQ=; b=VdkLcmeJA9CQPuaOTFqw2mJI28OkPei142XE4xmFOaSoYGtkrbQ/TOAU WTrEnYshC+VJItdbYC6zJW04tVWBxGmpY50zA958hMGaICRLnpEz0ttIm GwS0CIvzvnoBrmbd4AOnFOl7RJIIh+TrB39vCur7q1Vq2uHCR2MoJeZmt c=; X-IronPort-AV: E=McAfee;i="5600,1067,7606"; a="171510490" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2014 17:32:42 -0700 X-IronPort-AV: E=Sophos;i="5.07,281,1413270000"; d="scan'208";a="765615286" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Oct 2014 17:32:42 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc11.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 29 Oct 2014 17:32:41 -0700 Received: from apc-qrc004-rpdu-k02-lf.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 29 Oct 2014 17:32:35 -0700 Message-ID: <54518722.2040005@qti.qualcomm.com> Date: Wed, 29 Oct 2014 17:32:34 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ted Lemon References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <54517E02.6020501@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (129.46.53.226) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/-xdpk9Vy7X2rI6QHJN88TS3Q4Og Cc: weirds-chairs@tools.ietf.org, The IESG , draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 00:32:45 -0000 On 10/29/14 5:09 PM, Ted Lemon wrote: > On Oct 29, 2014, at 7:53 PM, Pete Resnick wrote: > >> A client that does the right thing and only queries all-a-label or all-u-label strings is going to get consistent results, because it is taking responsibility to do the appropriate mappings. But if the client is blindly handing over labels it got from somewhere else (which is why you would get mixed stuff), >> > Why would the client do that? Because clients get their input from all sorts of weird places, and some not-so-smart clients do not have the machinery to do the right thing. They SHOULD, but they don't. > Why not specify what the right thing is for the client to do as a SHOULD, and _then_ explain what might break if it doesn't, rather than just sort of talking about it and hoping for the best? > But that's exactly what the second full paragraph of 3.1.3 says now: SHOULD be either U-Labels or A-Labels, might break if not (see section 6.1), here are reasons you might see brokenness, and servers can do what they will to make things right. > Also, U-labels are case-sensitive. So the semantic difference you're describing doesn't actually exist. If servers could count on only getting real U-labels, of course. And if servers could simply reject crappy input out of hand, life would be much simpler. But AFAIU this is a case in which some servers (which serve particular constituencies) have to be a bit liberal in what they accept. So I think we have to give some information in the document about what to do when you get "interesting" input. > (BTW, what I just explained in the above paragraph gives me a headache and tells me we should _never_ use IDN for any writing system that has case, because it will be insanely easy to spoof. But you probably already knew that.) > :-) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Oct 29 18:18:11 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D511AC407; Wed, 29 Oct 2014 18:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W05wxE-TaiP; Wed, 29 Oct 2014 18:18:01 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9074C1ACEE4; Wed, 29 Oct 2014 18:18:01 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id DA0F4DA0227; Thu, 30 Oct 2014 01:21:16 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3B18353E083; Wed, 29 Oct 2014 18:17:31 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 18:17:31 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54518722.2040005@qti.qualcomm.com> Date: Wed, 29 Oct 2014 21:17:15 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3866CF36-5E95-486F-B953-A0C981A3666C@nominum.com> References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <54517E02.6020501@qti.qualcomm.com> <54518722.2040005@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/J2icaN9Ez3h6jYvNejr0Y2A1s3M Cc: weirds-chairs@tools.ietf.org, The IESG , draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 01:18:03 -0000 On Oct 29, 2014, at 8:32 PM, Pete Resnick = wrote: > On 10/29/14 5:09 PM, Ted Lemon wrote: >> Why not specify what the right thing is for the client to do as a = SHOULD, and _then_ explain what might break if it doesn't, rather than = just sort of talking about it and hoping for the best? >> =20 >=20 > But that's exactly what the second full paragraph of 3.1.3 says now: = SHOULD be either U-Labels or A-Labels, might break if not (see section = 6.1), here are reasons you might see brokenness, and servers can do what = they will to make things right. Right, fair enough. But what's bothering me is the text that follows = that. Why isn't it a SHOULD that the server should convert U-labels to = A-labels? >> Also, U-labels are case-sensitive. So the semantic difference = you're describing doesn't actually exist. >=20 > If servers could count on only getting real U-labels, of course. And = if servers could simply reject crappy input out of hand, life would be = much simpler. But AFAIU this is a case in which some servers (which = serve particular constituencies) have to be a bit liberal in what they = accept. So I think we have to give some information in the document = about what to do when you get "interesting" input. What's a "real U-label?" If it's unicode, it's a U-label, or else it's = garbage. There is no third alternative. If it's garbage, just reject = it. When would garbage be something that it would make sense to = attempt to use, rather than rejecting? I think never. From nobody Wed Oct 29 18:59:53 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ED71ACFB9; Wed, 29 Oct 2014 18:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muN-fmdtypBj; Wed, 29 Oct 2014 18:59:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE511ACFB5; Wed, 29 Oct 2014 18:59:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 18:59:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/036PAUctr_ApW6lXeRadsrleXMU Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 01:59:47 -0000 Ted Lemon has entered the following ballot position for draft-ietf-weirds-rdap-sec-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As far as I can tell, this specification effectively relies on HTTP authentication as its sole MTI mechanism, and leaves things like OAuth as sort of "you could do this, but we aren't saying how." I am deeply uncomfortable with this, because HTTP authentication really sucks when you are trying to make it work in a context where authentication is optional. I think if you want to rely on this mechanism, you need to give the reader more guidance on how to make this work. What I mean is that in order to trigger the client to send authentication, you have to send back a 401 Unauthorized HTTP response. But that assumes that authentication _is_ required, and it's not. So how does the server know to send back the HTTP unauthorized response? The answer is that it does not, and so you need to somehow signal to the client that it should send more authentication info if it wants better information, while still returning information in case the client has no credentials to offer. This is probably doable, but simply relying on RFC 7235 without explaining how to make it work isn't sufficient. From nobody Wed Oct 29 19:53:14 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4861ACD28; Wed, 29 Oct 2014 16:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVRH6tfD2VIX; Wed, 29 Oct 2014 16:43:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AD71ACCFB; Wed, 29 Oct 2014 16:43:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029234348.3341.6266.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 16:43:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/WNNVFNvgD2qur_rAtv2mKKZoGQQ X-Mailman-Approved-At: Wed, 29 Oct 2014 19:53:08 -0700 Cc: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, weirds@ietf.org Subject: [weirds] Kathleen Moriarty's No Objection on draft-ietf-weirds-bootstrap-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 23:43:49 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-weirds-bootstrap-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This draft looks fine and adds the appropriate set of security considerations for what it does, however, shouldn't there be a reference to the draft-ietf-weirds-rdap-sec draft to say where everything else should be covered? Thanks From nobody Wed Oct 29 19:53:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7671ACE9C; Wed, 29 Oct 2014 18:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsDefiltijHx; Wed, 29 Oct 2014 18:00:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C05461ACE9A; Wed, 29 Oct 2014 18:00:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030010044.24345.22556.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 18:00:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/9L6No0vnvHWRrJrfv3h4C11UPhs X-Mailman-Approved-At: Wed, 29 Oct 2014 19:53:12 -0700 Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 01:00:47 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-weirds-rdap-sec-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft and improving security for the whois function in weirds. There are a lot of options now and the work is appreciated. I have a lot of comments and suggestions that should be pretty easy to resolve. You may find a discuss and comment on the same section, so I've tried to label the start of each item with the draft section numbers. Section 3.1 Could you also include a reference to RFC5280? If the use of PKI and CAs is listed, a pointer to the security considerations would be very helpful to the reader. The pointer should be to the full draft, not just the security consideration section as it covers important things like the need for path validation. Path validation includes checking the certificate validity, the path/chain (root is trusted), etc. I'm not looking for you to add much text, just to punt off to the existing documents if people are interested in the security behind these recommendations for federation, authentication, authorization, etc. Section 3.2 Could you expand on the details here a bit? Between this draft and the response draft, I don't see enough information or guidance on how one might leverage value settings on objects and what are the right actions to take based on those values. My discuss on the response draft is specific to that draft, but the same concept applies here. If the guidance belongs in the response draft, then recommended actions or a list of options if it varies from administrator to administrator would be helpful at the start of the sections that provide the lists of values that can be set on objects. This section of the sec draft should then reference the response draft letting the reader know where to look for authorization and access control options and guidelines. Section 3.4 Since the protocol allows for the use of values to mark objects as private, obscured, redacted, this should be mentioned in this section with a pointer to the response draft section 10.2.2 and the recommended actions in the (hopefully) updated Privacy Considerations section of that draft. For confidentially, leaving out the data with the "redacted" value set if possible will do a lot more than trying to protect it with TLS, so I think it's important to note that in this section. The "private" value should limit access (I'd like to see some mention of how that is accomplished, but probably in the Response draft). The "obscured" value is interesting, but since it is only obscured, it may to be the best option for confidentially protection. Possible new section for Access Controls - Since user based access is possible, I'd like to see a section added to cover that as well. Is access tied to the roles designated in 10.2.4 of the Response draft? Should it be? Having the combination of user roles and data object values gives a lot of flexibility, but that is talked about enough in the drafts (IMO). Security consideration section: It's good that you are recommending against use of the Null cipher, but could you add a reference to the UTA TLS best practices draft here as well? That will cover quite a few bases with out having to repeat stuff here. https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Alissa's discuss for a privacy threat model. Section 3.1 As an FYI (not asking for anything to be done here except to participate in HTTPAuth last calls) - HTTP Digest and Basic just went through a revision and are just about done. There are a few minor updates and the security considerations in the updated documents spell out the remaining issues. Although these are the solutions for HTTP Auth, most people don't rely on it and use other methods, so we don't have implementations of better options. There are a few other options in the HTTPAuth WG about to go to IETF last call or are WG drafts. If you are going to rely on HTTPAuth methods, maybe there should be a push for the improved options from the WEIRDS WG - at least pitching in to review during last calls. https://datatracker.ietf.org/wg/httpauth/documents/ Section 3.1 I'm a little uneasy with just having a pointer to TLS to fix everything in OAuth and OpenID. Could you put in pointers to main framework documents like RFC6749 with a statement that says security considerations are included in those drafts? The security considerations differ between token types (bearer vs. Holder of Key) and that is out-of scope for this draft, so punting to the OAuth drafts would be very helpful instead of just pointing to TLS (but please do leave that in). This is just a comment the references do appear at end of the Security considerations section, & I'd recommend you move those up to section 3.1 as it will be a lot easier for the reader. Section 3.1 Just a question, should SAML 2.0 be listed as an option since this is a RESTful interface and we are talking about client authentication via a federated identity scheme or is that not an option? Thanks. From nobody Wed Oct 29 23:29:40 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5751E1AD022; Wed, 29 Oct 2014 23:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yG4buiEt6MS; Wed, 29 Oct 2014 23:29:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C89BA1A6FB1; Wed, 29 Oct 2014 23:29:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030062925.11472.79559.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 23:29:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/RENiOazIuoZaoEyUlHxM5k92m3I Cc: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, weirds@ietf.org Subject: [weirds] Richard Barnes' No Objection on draft-ietf-weirds-bootstrap-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 06:29:27 -0000 Richard Barnes has entered the following ballot position for draft-ietf-weirds-bootstrap-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The use of JSON in this syntax is slightly disappointing. Generally, using JSON arrays to contain items of different types is not a great idea. It seems like the "services" entries should actually be objects, with entries indicating the semantics of the inner arrays, e.g.: OLD: [ ["1.0.0.0/8", "192.0.0.0/8"], ["https://rir1.example.com/myrdap/"] ] NEW: { "resources": ["1.0.0.0/8", "192.0.0.0/8"], "urls": ["https://rir1.example.com/myrdap/"] } This should not be hard to describe in the notation of Section 10.2, and it only uses a few more bytes on the wire. From nobody Wed Oct 29 23:50:14 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBE31AD028; Wed, 29 Oct 2014 23:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VizKn_dWaYm8; Wed, 29 Oct 2014 23:50:11 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D8F1AD029; Wed, 29 Oct 2014 23:50:11 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id b13so3424379wgh.26 for ; Wed, 29 Oct 2014 23:50:10 -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=HyzI+qTQ8D7iFcpm9FDYwpeGnhUlNnO24yeghr9inVk=; b=qbIx+4NejKJaN6btWfXiF9d4OgkCEWw+GalCuBVaFnxbtgz2RZS0o59Li2icHbjglr lyFXvW6Zj2KTg0gYlBR1NwVG4knuI/fH7ixwHqSE+i1H0wVh6HE3yC42Hk0/FzI4kMO2 5eJZlDi9t+/hbPpaliuM0jOAR3ADNVYLSRC4I6ZLrVKkQmJLFnkPDrwkBu2Qb2yKQ1EF gVON+euY7Ssopvp+RUapRxC7f2mqvOXjOsf4671yQVJC3z3eXVha5GgBxnzIJ07HY91D 4aX6Y9sEfUxZgsEP7tIS907FSbUJ6D5bZU867snNO1h+BrPTRcqE6kfWCz44s70v3d5h m8+Q== MIME-Version: 1.0 X-Received: by 10.194.91.176 with SMTP id cf16mr17775895wjb.60.1414651809938; Wed, 29 Oct 2014 23:50:09 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Wed, 29 Oct 2014 23:50:09 -0700 (PDT) In-Reply-To: <20141029232910.320.95416.idtracker@ietfa.amsl.com> References: <20141029232910.320.95416.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 23:50:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alissa Cooper Content-Type: multipart/alternative; boundary=047d7bfcef269cc48c05069e4a49 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/jBO6m4Arh6wikxGoQEdsNcdgzwU Cc: draft-ietf-weirds-object-inventory@tools.ietf.org, "weirds-chairs@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Abstain on draft-ietf-weirds-object-inventory-06: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 06:50:13 -0000 --047d7bfcef269cc48c05069e4a49 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 29, 2014 at 4:29 PM, Alissa Cooper wrote: > I'm with Barry -- this seems like it would have made more sense if > published on a wiki, as a research paper, or in a slide deck. If the > choices made in the protocol documents actually linked back to these > findings for justification, I might see it differently, but at present > there does not seem to be much connection between these findings and some > of the design decisions made in the protocol. The data formats in the > protocol don't seem to support every field that was discovered in this > study, nor does there seem to be any consistent metric that was used for > deciding whether to include a particular field based on its prevalence in > these findings. > We discussed this a few times in the WG when deciding whether to adopt and ultimately publish this document. In the end the WG reached consensus that it was worth publishing because the research described in it led directly to the fields registered by the json-response draft. The detail you described in that last sentence are probably things we should consider adding either to this document or to json-response. -MSK --047d7bfcef269cc48c05069e4a49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 29, 2014 at 4:29 PM, Alissa Cooper <alissa@= cooperw.in> wrote:
I'm with Barry -- this = seems like it would have made more sense if
published on a wiki, as a research paper, or in a slide deck. If the
choices made in the protocol documents actually linked back to these
findings for justification, I might see it differently, but at present
there does not seem to be much connection between these findings and some of the design decisions made in the protocol. The data formats in the
protocol don't seem to support every field that was discovered in this<= br> study, nor does there seem to be any consistent metric that was used for deciding whether to include a particular field based on its prevalence in these findings.

We discussed this a few= times in the WG when deciding whether to adopt and ultimately publish this= document.=C2=A0 In the end the WG reached consensus that it was worth publ= ishing because the research described in it led directly to the fields regi= stered by the json-response draft.

The detail you describ= ed in that last sentence are probably things we should consider adding eith= er to this document or to json-response.

-MSK
--047d7bfcef269cc48c05069e4a49-- From nobody Wed Oct 29 23:52:46 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04241AD02D for ; Wed, 29 Oct 2014 23:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0htbUCbl02F for ; Wed, 29 Oct 2014 23:52:43 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91EE61AD02C for ; Wed, 29 Oct 2014 23:52:43 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hy10so2374150vcb.40 for ; Wed, 29 Oct 2014 23:52:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=q7P8rLtUr7dYASsYKDKpcsmr9OIGYs/y2yV++htNddU=; b=jFKaEE5pSE5iUQPXKKdFlzSyN2LLw+lUj9/C9vwz24wX68OTmN+qo/8DZQuyxPZF2V KUiILhsaD3SyAiu4VVggzYFeO0Q4ypWytbFd8BPhmE9sJnkDunFBW5VpNQ7HJ8Nh+APT Crx6T4QFbzKsH6ayTEa8XgKzGjh/eHqBo41T5HS6KZ9GkSOwBJUPQ+omvzkejAy7E6aw 2tOpG0PJQ/wyB1zpqx2ayxcZsCrEipUbfMe9nhS+bPCHIhDPybYBEenhUrIxWW/eI1E4 C6XSI3vXevpQu9mz2I0btVriYwpJZ3zVW57KSq6EFdAIqGNSc8K5veyXBILEC9MVhDzg wAdw== X-Gm-Message-State: ALoCoQmXdRLzJhaLANOxsWT+rL6hxt9HW16JHd5XPrjMbWz8FrXfVN7lO/KLNDzTibaPKXksHkGb MIME-Version: 1.0 X-Received: by 10.221.51.71 with SMTP id vh7mr11610376vcb.27.1414651962516; Wed, 29 Oct 2014 23:52:42 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Wed, 29 Oct 2014 23:52:42 -0700 (PDT) In-Reply-To: <20141028231700.11097.11887.idtracker@ietfa.amsl.com> References: <20141028231700.11097.11887.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 23:52:42 -0700 Message-ID: From: Richard Barnes To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a11331564b4fe1305069e5396 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/s89MqtoD8KoYutWxWGt4TUnrauU Cc: "weirds-chairs@tools.ietf.org" , draft-ietf-weirds-using-http@tools.ietf.org, The IESG , weirds@ietf.org Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-using-http-14: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 06:52:45 -0000 --001a11331564b4fe1305069e5396 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 4:17 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-weirds-using-http-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > = Section 5.6 = > "When responding to queries, it is RECOMMENDED that servers use the > Access-Control-Allow-Origin header field, as specified by > [W3C.CR-cors-20130129]. As the use of RDAP is for public resources, > a value of "*" is suitable for most cases." > > What is the use case for cross-site RDAP queries? > This seems pretty obvious to me; see, e.g., https://who.is/ Also, I am confused by the claim in the second sentence. The message that > I got from draft-ietf-weirds-rdap-sec and draft-ietf-weirds-json-response > is that one of the motivations for using HTTP for RDAP was that its > authentication features could be leveraged to provide tiered access to > data on the server, such that some of the data would not be public but > would be restricted to specific users (from > draft-ietf-weirds-json-response, Appendix A.1: "In many use cases, it is > necessary to hide or obscure the information of a registrant or contact > due to policy or other operational matters."). So it seems like if > cross-site requests are justified at all, there should be some text here > explaining when that might be the case and when not. > I agree that some clarification could be useful, in light of the fact that not *all* RDAP data will be public. In particular, I note that cross-origin requests (if authorized) will be sent with the user's cookies. So RDAP server operators should keep in mind that if they allow cross-origin requests, then they might expose access-controlled information to origins that might not be authorized. The right mitigation is probably to suggest checking the Origin header and using that as a secondary control. --Richard --001a11331564b4fe1305069e5396 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 28, 2014 at 4:17 PM, Alissa Cooper <alissa@cooperw.in&= gt; wrote:
Alis= sa Cooper has entered the following ballot position for
draft-ietf-weirds-using-http-14: Discuss

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


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


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

=3D Section 5.6 =3D
"When responding to queries, it is RECOMMENDED that servers use the =C2=A0 =C2=A0Access-Control-Allow-Origin header field, as specified by
=C2=A0 =C2=A0[W3C.CR-cors-20130129].=C2=A0 As the use of RDAP is for public= resources,
=C2=A0 =C2=A0a value of "*" is suitable for most cases."

What is the use case for cross-site RDAP queries?

=
This seems pretty obvious to me; see, e.g., https://who.is/
=C2=A0

Also, I am confused by the claim in the second sentence. The message that I got from draft-ietf-weirds-rdap-sec and draft-ietf-weirds-json-response is that one of the motivations for using HTTP for RDAP was that its
authentication features could be leveraged to provide tiered access to
data on the server, such that some of the data would not be public but
would be restricted to specific users (from
draft-ietf-weirds-json-response, Appendix A.1: "In many use cases, it = is
necessary to hide or obscure the information of a registrant or contact
due to policy or other operational matters."). So it seems like if
cross-site requests are justified at all, there should be some text here explaining when that might be the case and when not.
<= br>
I agree that some clarification could be useful, in light of = the fact that not *all* RDAP data will be public.

In part= icular, I note that cross-origin requests (if authorized) will be sent with= the user's cookies.=C2=A0 So RDAP server operators should keep in mind= that if they allow cross-origin requests, then they might expose access-co= ntrolled information to origins that might not be authorized.=C2=A0 The rig= ht mitigation is probably to suggest checking the Origin header and using t= hat as a secondary control.

--Richard
=C2= =A0
--001a11331564b4fe1305069e5396-- From nobody Wed Oct 29 23:56:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30FC1AD029; Wed, 29 Oct 2014 23:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFylYiKzeged; Wed, 29 Oct 2014 23:56:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A58F11A0382; Wed, 29 Oct 2014 23:56:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030065634.11484.73249.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 23:56:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/fxBHmzywkt1mvOIHvcQQSFaHY7I Cc: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, weirds@ietf.org Subject: [weirds] Richard Barnes' No Objection on draft-ietf-weirds-bootstrap-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 06:56:36 -0000 Richard Barnes has entered the following ballot position for draft-ietf-weirds-bootstrap-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a little unclear as to why this document is necessary. It seems like given the use of 30X redirects in -using-http, you could just start with an IANA root server and redirect your way down the tree. It may appear that this bootstrap mechanism saves queries to the root, but you could achieve the same effect or better using 301 redirects with appropriate caching. The use of JSON in this syntax is slightly disappointing. Generally, using JSON arrays to contain items of different types is not a great idea. It seems like the "services" entries should actually be objects, with entries indicating the semantics of the inner arrays, e.g.: OLD: [ ["1.0.0.0/8", "192.0.0.0/8"], ["https://rir1.example.com/myrdap/"] ] NEW: { "resources": ["1.0.0.0/8", "192.0.0.0/8"], "urls": ["https://rir1.example.com/myrdap/"] } This should not be hard to describe in the notation of Section 10.2, and it only uses a few more bytes on the wire. From nobody Thu Oct 30 00:10:50 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD83A1AD03B; Thu, 30 Oct 2014 00:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANWOVXDxr1K3; Thu, 30 Oct 2014 00:10:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 073461AD029; Thu, 30 Oct 2014 00:10:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030071038.27588.21716.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 00:10:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/tKjRrNQRKxkS1IjfWk6VcB4ssDc Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org Subject: [weirds] Richard Barnes' No Objection on draft-ietf-weirds-rdap-query-16: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 07:10:42 -0000 Richard Barnes has entered the following ballot position for draft-ietf-weirds-rdap-query-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "Servers MUST return an HTTP 501 (Not Implemented) [RFC7231] response to inform clients of unsupported queries." Shouldn't this go in -using-http? Also, the wording here could use tightening. It seems like you want to use 501 for query *types* that you don't support, vs. 404 for things where you just don't have an answer. So sending a query for "bbc.co.uk" to the ".youtube" server would result in 404, but sending it to the ARIN server might result in 501. From nobody Thu Oct 30 00:39:40 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFF21AD03D for ; Thu, 30 Oct 2014 00:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ROAXQyWrBwH for ; Thu, 30 Oct 2014 00:39:36 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810901AD03B for ; Thu, 30 Oct 2014 00:39:36 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hq12so2390298vcb.23 for ; Thu, 30 Oct 2014 00:39:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=thPRkKgcNEtC/rHSN0YsqoGDMf2Xzp8uE0h2ru+RwRg=; b=VPQt8xKMM1GyDuxd5foeN/CEws1GxPHlWvwgALtjvHqTIeFQ1IWke6ewO8GLCt8egA 1xydtG7+3LzgsFmQsiq1++5EAVOscbsEO3ozd8sH51jCAK3nmYJaZPyutg4hlmYUFgon 1lVH+IRUh6ob/hYAtLSqi7goVlqDlcE80+dhcnDMwp87Aur1aO7CdWJMswBrISDYvt27 Z5bTmiW9OV24vyS5rUZsCdtE4LrDRn3XY6iBG/NXFrh+9Fpc/FMNZAauMxIhc7Sgy6l3 qSYgdxACEKpCPsVTXlfE1V3SsXHiQTvIXwF6L4ugUIThsQobFVNNy6TniWWJZNhZYLs6 tQVQ== X-Gm-Message-State: ALoCoQlfCT80mwHLXMa+WbCctXBa0acMmhEVASYONpgXdOh4Pl3kRbtc+4PcgIzD14SRQ9/m7XiZ MIME-Version: 1.0 X-Received: by 10.220.97.72 with SMTP id k8mr11797667vcn.5.1414654775403; Thu, 30 Oct 2014 00:39:35 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Thu, 30 Oct 2014 00:39:35 -0700 (PDT) In-Reply-To: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 00:39:35 -0700 Message-ID: From: Richard Barnes To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c2d7b85e417b05069efb47 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/744QacmmvDlUWQ39c8_f-pm18l0 Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , weirds@ietf.org Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 07:39:38 -0000 --001a11c2d7b85e417b05069efb47 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 29, 2014 at 6:59 PM, Ted Lemon wrote: > Ted Lemon has entered the following ballot position for > draft-ietf-weirds-rdap-sec-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > As far as I can tell, this specification effectively relies on HTTP > authentication as its sole MTI mechanism, and leaves things like OAuth as > sort of "you could do this, but we aren't saying how." I am deeply > uncomfortable with this, because HTTP authentication really sucks when > you are trying to make it work in a context where authentication is > optional. > > I think if you want to rely on this mechanism, you need to give the > reader more guidance on how to make this work. What I mean is that in > order to trigger the client to send authentication, you have to send back > a 401 Unauthorized HTTP response. But that assumes that authentication > _is_ required, and it's not. So how does the server know to send back > the HTTP unauthorized response? The answer is that it does not, and so > you need to somehow signal to the client that it should send more > authentication info if it wants better information, while still returning > information in case the client has no credentials to offer. > > This is probably doable, but simply relying on RFC 7235 without > explaining how to make it work isn't sufficient. > This is a feature request, not a DISCUSS. There are bazillions of HTTP servers out there today that get by just fine with a binary, per-resource distinction between authorized and unauthorized. And I can see situations where that would make sense here too. For example, a server might not grant access to entity records without authorization. That said, I do expect that "add more fields to the JSON object if authenticated" will be a common pattern here, so it might be useful to have a standard mechanism for the server to hint that more data might be available. (Or it might not be useful -- if the client has credentials, why didn't it use them the first time?) It's also worth considering that the hint itself might be privacy sensitive, in that it reveals that there is more information than is being provided. The point is that you're asking for a feature which is clearly non-essential, and likely of negligible utility. This is not an interop problem. --Richard --001a11c2d7b85e417b05069efb47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 29, 2014 at 6:59 PM, Ted Lemon <ted.lemon@nominum.com<= /a>> wrote:
Ted Lemon has enter= ed the following ballot position for
draft-ietf-weirds-rdap-sec-10: Discuss

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


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


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As far as I can tell, this specification effectively relies on HTTP
authentication as its sole MTI mechanism, and leaves things like OAuth as sort of "you could do this, but we aren't saying how."=C2=A0 = =C2=A0I am deeply
uncomfortable with this, because HTTP authentication really sucks when
you are trying to make it work in a context where authentication is
optional.

I think if you want to rely on this mechanism, you need to give the
reader more guidance on how to make this work.=C2=A0 =C2=A0What I mean is t= hat in
order to trigger the client to send authentication, you have to send back a 401 Unauthorized HTTP response.=C2=A0 =C2=A0But that assumes that authent= ication
_is_ required, and it's not.=C2=A0 =C2=A0So how does the server know to= send back
the HTTP unauthorized response?=C2=A0 =C2=A0The answer is that it does not,= and so
you need to somehow signal to the client that it should send more
authentication info if it wants better information, while still returning information in case the client has no credentials to offer.

This is probably doable, but simply relying on RFC 7235 without
explaining how to make it work isn't sufficient.
This is a feature request, not a DISCUSS.

There are bazilli= ons of HTTP servers out there today that get by just fine with a binary, pe= r-resource distinction between authorized and unauthorized.=C2=A0 And I can= see situations where that would make sense here too.=C2=A0 For example, a = server might not grant access to entity records without authorization.
<= br>
That said, I do expect that "add m= ore fields to the JSON object if authenticated" will be a common patte= rn here, so it might be useful to have a standard mechanism for the server = to hint that more data might be available.=C2=A0 (Or it might not be useful= -- if the client has credentials, why didn't it use them the first tim= e?)=C2=A0 It's also worth considering that the hint itself might be pri= vacy sensitive, in that it reveals that there is more information than is b= eing provided.

The point is that yo= u're asking for a feature which is clearly non-essential, and likely of= negligible utility.=C2=A0 This is not an interop problem.

--Richard

<= br>
--001a11c2d7b85e417b05069efb47-- From nobody Thu Oct 30 04:09:23 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FF41AD0C7; Thu, 30 Oct 2014 04:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNxqr5D-Vrtg; Thu, 30 Oct 2014 04:09:14 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1421B1AD0C4; Thu, 30 Oct 2014 04:09:14 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id C24942137B1; Thu, 30 Oct 2014 07:09:13 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 1AC2E21379E; Thu, 30 Oct 2014 07:09:13 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 07:11:45 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Thu, 30 Oct 2014 07:09:05 -0400 From: Andy Newton To: Alissa Cooper Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) Thread-Index: AQHP8wT+VvAo7jjE6k+C7Xa31Tup25xIwNgA Date: Thu, 30 Oct 2014 11:09:03 +0000 Message-ID: <23FB3A98-8047-4505-B91F-FB9ABCAC8407@arin.net> References: <20141028231454.16979.8007.idtracker@ietfa.amsl.com> In-Reply-To: <20141028231454.16979.8007.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <250B3B83826BBA4CB40C47F5FAE6286A@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/bArlLdONq7ySkYDz_DMNpKwO52w Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 11:09:16 -0000 On Oct 28, 2014, at 7:14 PM, Alissa Cooper wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I think this document is missing a discussion of the fact that while > jCard was selected as the format for entity representation because it can > flexibly accommodate the spectrum of the kinds of entities that require > representation in RDAP, the full jCard specification includes many fields > that are unrelated to the uses of the RDAP protocol and therefore not > expected to be stored or made available by servers. This is a different > point than the point made in Appendix A.1 (which should really be in > Section 14 IMO) about the use of status values, which implies that the > fields exist in the server-side database but are not shared in certain > circumstances. This is a good point. Does inserting the following paragraph after the fir= st paragraph in Section 5.1 address this? The entity object class uses jCard [RFC7095] to represent contact informa= tion, such as postal addresses, email addresses, phone numbers and names of=20 organizations and individuals. Many of the types of information that can = be represented with jCard are unlikely to be used in RDAP, such as birthdays= , anniversaries, and gender. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =3D Section 3.2 =3D > I love an idiom as much as the next person, but it would be better to use > names in examples that are not culturally specific. >=20 > =3D Section 4 =3D > The reference to I-D.ietf-jcardcal-jcard should be replaced with RFC > 7095, I think. >=20 > =3D Section 6.1 =3D > Following on from my DISCUSS, I know the example in this section is just > an example, but it includes all kinds of information about Joe User that > no registry should be asking for and no registrant should willingly > provide (gender? anniversary? really?!). It would be nice for the example > to reflect what reality might/should actually be like. Agreed (though your section numbers are off). Thanks. -andy= From nobody Thu Oct 30 04:24:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363C51AD0BA; Thu, 30 Oct 2014 04:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUA_2mSxQfkS; Thu, 30 Oct 2014 04:24:27 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id EAB791AD0B8; Thu, 30 Oct 2014 04:24:26 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 906F7164FB5; Thu, 30 Oct 2014 07:24:26 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id CB2CA164F9E; Thu, 30 Oct 2014 07:24:25 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 07:26:42 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Thu, 30 Oct 2014 07:24:19 -0400 From: Andy Newton To: Kathleen Moriarty Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) Thread-Index: AQHP88F1J3B5CvDFWkm1ep9SfJAe4pxIw6KA Date: Thu, 30 Oct 2014 11:24:19 +0000 Message-ID: <07C08197-D2E1-4B37-9560-65090C3E57A6@arin.net> References: <20141029214342.30884.77333.idtracker@ietfa.amsl.com> In-Reply-To: <20141029214342.30884.77333.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/kX_h7Cw2YHmwsgFNRLZ8gj605Fk Cc: "weirds@ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 11:24:29 -0000 On Oct 29, 2014, at 5:43 PM, Kathleen Moriarty wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for your work on this draft and including options for privacy > protections. I do support Alissa's discuss on the -sec draft and as > such, my discuss here is specific to this draft and values set forth in > it for privacy. The general security and privacy considerations would be > good to reference from one place. >=20 > I think it would help to have the explicit guidance or recommendations > for privacy included directly in the privacy section. While the example > in the appendix is good, I'd prefer to see explicit recommendations for > each of the relevant status codes from section 10.2.2. How about > something along the lines of the following: >=20 > Current Privacy Considerations section: > This specification suggests status values to denote contact and > registrant information that has been marked as private and/or has > been redacted or obscured. See Section 10.2.2 for the list of status > values. See Appendix A.1 on guidance to apply those values to > contacts and registrants. >=20 > Suggested Privacy Considerations section: > This specification suggests status values to denote contact and > registrant information that has been marked as private and/or has > been redacted or obscured. See Section 10.2.2 for the complete list > of status > values. A few of the status values indicate that there are privacy > concerns associated with the object instance. For the following > status > codes, the RECOMMENDED actions include: > 7. private - The object is not be shared in query responses, unless > the > user is authorized to view this information. > 8. redacted - The data has already been redacted, and may be > returned > in a response in the data redacted form. This is a safer > option to choose > to prevent unauthorized access to associated object instances > than marking > them as private. > 9. obscured - The data has already been obscured, and may be > returned in a > response in the obscured form. This option may reveal privacy > sensitive > information and should only be used when data sensitivity does > not require > a more protective option like "private" or "redacted". >=20 > See Appendix A.1 or an example applying those values to > contacts and registrants. This sounds like a good idea to me. Thanks for the text. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for addressing the SecDir review and including information on a > possible cache poisoning attack. > http://www.ietf.org/mail-archive/web/secdir/current/msg05183.html > Some nits were included as well that might be helpful. I thought I included them. But I=92ll circle back to that review for the ni= ts. Thanks. -andy= From nobody Thu Oct 30 04:44:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585441AD0A2; Thu, 30 Oct 2014 04:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F8-OnFZABrl; Thu, 30 Oct 2014 04:44: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 E176D1AD0B7; Thu, 30 Oct 2014 04:44:37 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 98FF62137AB; Thu, 30 Oct 2014 07:44:37 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id A6433213799; Thu, 30 Oct 2014 07:44:36 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 07:47:09 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Thu, 30 Oct 2014 07:44:28 -0400 From: Andy Newton To: Scott Hollenbeck , Alissa Cooper Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) Thread-Index: AQHP8wTl04TaTfEJpEevEZPfqIUblJxHTuEAgAF72oA= Date: Thu, 30 Oct 2014 11:44:27 +0000 Message-ID: <395E6D17-B800-4589-8A23-249BAE6711BD@arin.net> References: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: multipart/alternative; boundary="_000_395E6D17B80045898A23249BAE6711BDarinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ruv6htpLJ6Vw10nklv2FOUgijhc Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 11:44:40 -0000 --_000_395E6D17B80045898A23249BAE6711BDarinnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 29, 2014, at 9:04 AM, Hollenbeck, Scott > wrote: ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =3D Section 3.2.3 =3D If I'm reading the document correctly, when searching for an entity, the search pattern is expected to represent an entity using the syntax specified in Section 6.1 of draft-ietf-weirds-json-response. But when the path segment is provided, rather than a search, Section 3.1.5 says this: The parameter represents an entity (such as a contact, registrant, or registrar) identifier whose syntax is specific to the registration provider. For example, for some DNRs contact identifiers are specified in RFC 5730 [RFC5730] and RFC 5733 [RFC5733]. This makes it seem as if an entity in a path segment uses different syntax (actually, non-standard syntax that is up to the registration provider) than an entity that someone might search for. Is there some specific field in the entity definition in draft-ietf-weirds-json-response that is supposed to correspond to? Aren't HTTP GETs for both path segments and searches meant to provide responses based on the same underlying data? If so, I don't understand why there is a specified syntax for entities in one but not the other. This also seems inconsistent with the following text in Section 6.1 of draft-ietf-weirds-json-response: The entity object class appears throughout this document and is an appropriate response for the /entity/XXXX query defined in Registration Data Access Protocol Lookup Format [I-D.ietf-weirds-rdap-query] Alissa, I do not fully comprehend this issue. To answer your question: yes = the HTTP GETs for both lookups and searches of entities are suppose to retu= rn the same underlying data. Would it be helpful for the text in json-respo= nse above to also state they are applicable for searches? OLD "where XXXX is a search pattern representing an entity name as specified in= Section 6.1 of [I-D.ietf-weirds-json-response]" NEW "where XXXX is a search pattern representing an entity (such as a contact, = registrant, or registrar) identifier whose syntax is specific to the regist= ration provider" Scott, I am confused. One is a search by handle and the other a search by a= person or organization=92s name. Doesn=92t this eliminate the name search? -andy --_000_395E6D17B80045898A23249BAE6711BDarinnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <66B61DEA2D93AB48B18FF2CC0B629ADD@corp.arin.net> Content-Transfer-Encoding: quoted-printable

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

=3D Section 3.2.3 =3D
If I'm reading the document correctly, when searching for an entity,
the
search pattern is expected to represent an entity using the syntax
specified in Section 6.1 of draft-ietf-weirds-json-response. But when
the
path segment is provided, rather than a search, Section 3.1.5 says
this:

  The <handle> parameter represents an entity (such as a co= ntact,
  registrant, or registrar) identifier whose syntax is specific t= o the
  registration provider.  For example, for some DNRs contact=
  identifiers are specified in RFC 5730 [RFC5730] and RFC 5733   [RFC5733].

This makes it seem as if an entity in a path segment uses different
syntax (actually, non-standard syntax that is up to the registration
provider) than an entity that someone might search for. Is there some
specific field in the entity definition in
draft-ietf-weirds-json-response that <handle> is supposed to correspo= nd
to? Aren't HTTP GETs for both path segments and searches meant to
provide
responses based on the same underlying data? If so, I don't understand
why there is a specified syntax for entities in one but not the other.
This also seems inconsistent with the following text in Section 6.1 of
draft-ietf-weirds-json-response:

  The entity object class appears throughout this document and is= an
  appropriate response for the /entity/XXXX query defined in
  Registration Data Access Protocol Lookup Format
  [I-D.ietf-weirds-rdap-query]

Alissa, I do not fully comprehend this issue. To answer your question:= yes the HTTP GETs for both lookups and searches of entities are suppose to= return the same underlying data. Would it be helpful for the text in json-= response above to also state they are applicable for searches?

OLD
"where XXXX is a search pattern representing an entity name as specifi= ed in Section 6.1 of [I-D.ietf-weirds-json-response]"

NEW
"where XXXX is a search pattern representing an entity (such as a cont= act, registrant, or registrar) identifier whose syntax is specific to the r= egistration provider"

Scott, I am confused. One is a search by handle and the other a search= by a person or organization=92s name. Doesn=92t this eliminate the name se= arch?

-andy
--_000_395E6D17B80045898A23249BAE6711BDarinnet_-- From nobody Thu Oct 30 04:58:11 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF96A1AD0C7; Thu, 30 Oct 2014 04:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE1uKc-2WkcV; Thu, 30 Oct 2014 04:58:08 -0700 (PDT) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3061A0007; Thu, 30 Oct 2014 04:58:05 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKVFInzFbnbwpSnde/GHYCMhBSoqBtROoe@postini.com; Thu, 30 Oct 2014 04:58:07 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9UBw2lK001870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 07:58:02 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 07:58:02 -0400 From: "Hollenbeck, Scott" To: Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) Thread-Index: AQHP89z4cLdpc7IQ5UeqNBsgSlTrYpxIgcvQ Date: Thu, 30 Oct 2014 11:58:02 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4950954D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141030010044.24345.22556.idtracker@ietfa.amsl.com> In-Reply-To: <20141030010044.24345.22556.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/k7yYDkaTvgUbb3eYZ8exjmMX19g Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 11:58:11 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBb bWFpbHRvOkthdGhsZWVuLk1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNk YXksIE9jdG9iZXIgMjksIDIwMTQgOTowMSBQTQ0KPiBUbzogVGhlIElFU0cNCj4gQ2M6IHdlaXJk cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtd2VpcmRzLXJkYXAtDQo+IHNlY0B0 b29scy5pZXRmLm9yZzsgd2VpcmRzQGlldGYub3JnDQo+IFN1YmplY3Q6IEthdGhsZWVuIE1vcmlh cnR5J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXdlaXJkcy1yZGFwLXNlYy0xMDoNCj4gKHdpdGgg RElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEthdGhsZWVuIE1vcmlhcnR5IGhhcyBlbnRlcmVk IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLXdlaXJkcy1y ZGFwLXNlYy0xMDogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0 aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlz DQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSBy ZWZlciB0byBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtDQo+IGNy aXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFu ZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi13ZWlyZHMtcmRhcC1zZWMvDQo+IA0KPiAN Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4g VGhhbmtzIGZvciB5b3VyIHdvcmsgb24gdGhpcyBkcmFmdCBhbmQgaW1wcm92aW5nIHNlY3VyaXR5 IGZvciB0aGUgd2hvaXMNCj4gZnVuY3Rpb24gaW4gd2VpcmRzLiAgVGhlcmUgYXJlIGEgbG90IG9m IG9wdGlvbnMgbm93IGFuZCB0aGUgd29yayBpcw0KPiBhcHByZWNpYXRlZC4gIEkgaGF2ZSBhIGxv dCBvZiBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgdGhhdCBzaG91bGQgYmUNCj4gcHJldHR5IGVh c3kgdG8gcmVzb2x2ZS4gIFlvdSBtYXkgZmluZCBhIGRpc2N1c3MgYW5kIGNvbW1lbnQgb24gdGhl IHNhbWUNCj4gc2VjdGlvbiwgc28gSSd2ZSB0cmllZCB0byBsYWJlbCB0aGUgc3RhcnQgb2YgZWFj aCBpdGVtIHdpdGggdGhlIGRyYWZ0DQo+IHNlY3Rpb24gbnVtYmVycy4NCj4gDQo+IFNlY3Rpb24g My4xDQo+IENvdWxkIHlvdSBhbHNvIGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gUkZDNTI4MD8gIElm IHRoZSB1c2Ugb2YgUEtJIGFuZA0KPiBDQXMNCj4gaXMgbGlzdGVkLCBhIHBvaW50ZXIgdG8gdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdvdWxkIGJlIHZlcnkNCj4gaGVscGZ1bA0KPiB0byB0 aGUgcmVhZGVyLiAgVGhlIHBvaW50ZXIgc2hvdWxkIGJlIHRvIHRoZSBmdWxsIGRyYWZ0LCBub3Qg anVzdCB0aGUNCj4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGFzIGl0IGNvdmVycyBp bXBvcnRhbnQgdGhpbmdzIGxpa2UgdGhlDQo+IG5lZWQgZm9yIHBhdGggdmFsaWRhdGlvbi4gIFBh dGggdmFsaWRhdGlvbiBpbmNsdWRlcyBjaGVja2luZyB0aGUNCj4gY2VydGlmaWNhdGUgdmFsaWRp dHksIHRoZSBwYXRoL2NoYWluIChyb290IGlzIHRydXN0ZWQpLCBldGMuICBJJ20gbm90DQo+IGxv b2tpbmcgZm9yIHlvdSB0byBhZGQgbXVjaCB0ZXh0LCBqdXN0IHRvIHB1bnQgb2ZmIHRvIHRoZSBl eGlzdGluZw0KPiBkb2N1bWVudHMgaWYgcGVvcGxlIGFyZSBpbnRlcmVzdGVkIGluIHRoZSBzZWN1 cml0eSBiZWhpbmQgdGhlc2UNCj4gcmVjb21tZW5kYXRpb25zIGZvciBmZWRlcmF0aW9uLCBhdXRo ZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiwgZXRjLg0KDQpBIHJlZmVyZW5jZSB0byBSRkMgNTI4 MCBpcyBhbHJlYWR5IGluY2x1ZGVkIGluIHRoZSA2dGggcGFyYWdyYXBoIChwYWdlIDQsIDNyZCBw YXJhZ3JhcGggZG93biBmcm9tIHRoZSB0b3ApLg0KDQo+IFNlY3Rpb24gMy4yDQo+IENvdWxkIHlv dSBleHBhbmQgb24gdGhlIGRldGFpbHMgaGVyZSBhIGJpdD8gIEJldHdlZW4gdGhpcyBkcmFmdCBh bmQgdGhlDQo+IHJlc3BvbnNlIGRyYWZ0LCBJIGRvbid0IHNlZSBlbm91Z2ggaW5mb3JtYXRpb24g b3IgZ3VpZGFuY2Ugb24gaG93IG9uZQ0KPiBtaWdodCBsZXZlcmFnZSB2YWx1ZSBzZXR0aW5ncyBv biBvYmplY3RzIGFuZCB3aGF0IGFyZSB0aGUgcmlnaHQgYWN0aW9ucw0KPiB0byB0YWtlIGJhc2Vk IG9uIHRob3NlIHZhbHVlcy4gICBNeSBkaXNjdXNzIG9uIHRoZSByZXNwb25zZSBkcmFmdCBpcw0K PiBzcGVjaWZpYyB0byB0aGF0IGRyYWZ0LCBidXQgdGhlIHNhbWUgY29uY2VwdCBhcHBsaWVzIGhl cmUuICBJZiB0aGUNCj4gZ3VpZGFuY2UgYmVsb25ncyBpbiB0aGUgcmVzcG9uc2UgZHJhZnQsIHRo ZW4gcmVjb21tZW5kZWQgYWN0aW9ucyBvciBhDQo+IGxpc3Qgb2Ygb3B0aW9ucyBpZiBpdCB2YXJp ZXMgZnJvbSBhZG1pbmlzdHJhdG9yIHRvIGFkbWluaXN0cmF0b3Igd291bGQNCj4gYmUNCj4gaGVs cGZ1bCBhdCB0aGUgc3RhcnQgb2YgdGhlIHNlY3Rpb25zIHRoYXQgcHJvdmlkZSB0aGUgbGlzdHMg b2YgdmFsdWVzDQo+IHRoYXQgY2FuIGJlIHNldCBvbiBvYmplY3RzLg0KPiANCj4gVGhpcyBzZWN0 aW9uIG9mIHRoZSBzZWMgZHJhZnQgc2hvdWxkIHRoZW4gcmVmZXJlbmNlIHRoZSByZXNwb25zZSBk cmFmdA0KPiBsZXR0aW5nIHRoZSByZWFkZXIga25vdyB3aGVyZSB0byBsb29rIGZvciBhdXRob3Jp emF0aW9uIGFuZCBhY2Nlc3MNCj4gY29udHJvbCBvcHRpb25zIGFuZCBndWlkZWxpbmVzLg0KDQpJ J20gbm90IHN1cmUgd2hhdCBlbHNlIEkgY2FuIGFkZCB0byB0aGlzIHNlY3Rpb24uIFJlc3BvbnNl LW9iamVjdC1zcGVjaWZpYyBndWlkYW5jZSBiZWxvbmdzIGluIHRoZSByZXNwb25zZSBkb2N1bWVu dC4gQXNzdW1pbmcgQW5keSBhbmQgSSBtYWtlIHRob3NlIG1vZHMgdG8gdGhlIHJlc3BvbnNlIGRy YWZ0LCB3b3VsZCBhIHJlZmVyZW5jZSBhdCB0aGUgZW5kIG9mIFNlY3Rpb24gMy4yIGJlIHN1ZmZp Y2llbnQ/DQoNCj4gU2VjdGlvbiAzLjQNCj4gU2luY2UgdGhlIHByb3RvY29sIGFsbG93cyBmb3Ig dGhlIHVzZSBvZiB2YWx1ZXMgdG8gbWFyayBvYmplY3RzIGFzDQo+IHByaXZhdGUsIG9ic2N1cmVk LCByZWRhY3RlZCwgdGhpcyBzaG91bGQgYmUgbWVudGlvbmVkIGluIHRoaXMgc2VjdGlvbg0KPiB3 aXRoIGEgcG9pbnRlciB0byB0aGUgcmVzcG9uc2UgZHJhZnQgc2VjdGlvbiAxMC4yLjIgYW5kIHRo ZSByZWNvbW1lbmRlZA0KPiBhY3Rpb25zIGluIHRoZSAoaG9wZWZ1bGx5KSB1cGRhdGVkIFByaXZh Y3kgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZg0KPiB0aGF0DQo+IGRyYWZ0LiAgRm9yIGNvbmZp ZGVudGlhbGx5LCBsZWF2aW5nIG91dCB0aGUgZGF0YSB3aXRoIHRoZSAicmVkYWN0ZWQiDQo+IHZh bHVlIHNldCBpZiBwb3NzaWJsZSB3aWxsIGRvIGEgbG90IG1vcmUgdGhhbiB0cnlpbmcgdG8gcHJv dGVjdCBpdCB3aXRoDQo+IFRMUywgc28gSSB0aGluayBpdCdzIGltcG9ydGFudCB0byBub3RlIHRo YXQgaW4gdGhpcyBzZWN0aW9uLiAgVGhlDQo+ICJwcml2YXRlIiB2YWx1ZSBzaG91bGQgbGltaXQg YWNjZXNzIChJJ2QgbGlrZSB0byBzZWUgc29tZSBtZW50aW9uIG9mDQo+IGhvdw0KPiB0aGF0IGlz IGFjY29tcGxpc2hlZCwgYnV0IHByb2JhYmx5IGluIHRoZSBSZXNwb25zZSBkcmFmdCkuICBUaGUN Cj4gIm9ic2N1cmVkIiB2YWx1ZSBpcyBpbnRlcmVzdGluZywgYnV0IHNpbmNlIGl0IGlzIG9ubHkg b2JzY3VyZWQsIGl0IG1heQ0KPiB0bw0KPiBiZSB0aGUgYmVzdCBvcHRpb24gZm9yIGNvbmZpZGVu dGlhbGx5IHByb3RlY3Rpb24uDQoNCkZpbmUuDQoNCj4gUG9zc2libGUgbmV3IHNlY3Rpb24gZm9y IEFjY2VzcyBDb250cm9scyAtDQo+IFNpbmNlIHVzZXIgYmFzZWQgYWNjZXNzIGlzIHBvc3NpYmxl LCBJJ2QgbGlrZSB0byBzZWUgYSBzZWN0aW9uIGFkZGVkIHRvDQo+IGNvdmVyIHRoYXQgYXMgd2Vs bC4gIElzIGFjY2VzcyB0aWVkIHRvIHRoZSByb2xlcyBkZXNpZ25hdGVkIGluIDEwLjIuNA0KPiBv Zg0KPiB0aGUgUmVzcG9uc2UgZHJhZnQ/ICBTaG91bGQgaXQgYmU/ICBIYXZpbmcgdGhlIGNvbWJp bmF0aW9uIG9mIHVzZXINCj4gcm9sZXMNCj4gYW5kIGRhdGEgb2JqZWN0IHZhbHVlcyBnaXZlcyBh IGxvdCBvZiBmbGV4aWJpbGl0eSwgYnV0IHRoYXQgaXMgdGFsa2VkDQo+IGFib3V0IGVub3VnaCBp biB0aGUgZHJhZnRzIChJTU8pLg0KDQpGaW5lLiBBY2Nlc3MgdG8gaW5mb3JtYXRpb24gaXMgdGll ZCB0byB0aGUgaWRlbnRpdHkgb2YgdGhlIGNsaWVudCBhbmQgYXNzb2NpYXRlZCBhdXRob3JpemF0 aW9ucywgbm90IHRoZSByb2xlcyBpZGVudGlmaWVkIGluIHRoZSByZXNwb25zZSBkYXRhIHJlY29y ZHMuDQogDQo+IFNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbjoNCj4gSXQncyBnb29kIHRo YXQgeW91IGFyZSByZWNvbW1lbmRpbmcgYWdhaW5zdCB1c2Ugb2YgdGhlIE51bGwgY2lwaGVyLCBi dXQNCj4gY291bGQgeW91IGFkZCBhIHJlZmVyZW5jZSB0byB0aGUgVVRBIFRMUyBiZXN0IHByYWN0 aWNlcyBkcmFmdCBoZXJlIGFzDQo+IHdlbGw/ICBUaGF0IHdpbGwgY292ZXIgcXVpdGUgYSBmZXcg YmFzZXMgd2l0aCBvdXQgaGF2aW5nIHRvIHJlcGVhdA0KPiBzdHVmZg0KPiBoZXJlLg0KPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXV0YS10bHMtYmNwLw0KDQpG aW5lLCBpdCdzIGluIFdHIGxhc3QgY2FsbC4gSSdsbCBhZGQgYW4gaW5mb3JtYXRpdmUgcmVmZXJl bmNlLg0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAN Cj4gSSBzdXBwb3J0IEFsaXNzYSdzIGRpc2N1c3MgZm9yIGEgcHJpdmFjeSB0aHJlYXQgbW9kZWwu DQo+IA0KPiBTZWN0aW9uIDMuMQ0KPiBBcyBhbiBGWUkgKG5vdCBhc2tpbmcgZm9yIGFueXRoaW5n IHRvIGJlIGRvbmUgaGVyZSBleGNlcHQgdG8NCj4gcGFydGljaXBhdGUNCj4gaW4gSFRUUEF1dGgg bGFzdCBjYWxscykgLSBIVFRQIERpZ2VzdCBhbmQgQmFzaWMganVzdCB3ZW50IHRocm91Z2ggYQ0K PiByZXZpc2lvbiBhbmQgYXJlIGp1c3QgYWJvdXQgZG9uZS4gIFRoZXJlIGFyZSBhIGZldyBtaW5v ciB1cGRhdGVzIGFuZA0KPiB0aGUNCj4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gdGhlIHVw ZGF0ZWQgZG9jdW1lbnRzIHNwZWxsIG91dCB0aGUNCj4gcmVtYWluaW5nDQo+IGlzc3Vlcy4gIEFs dGhvdWdoIHRoZXNlIGFyZSB0aGUgc29sdXRpb25zIGZvciBIVFRQIEF1dGgsIG1vc3QgcGVvcGxl DQo+IGRvbid0IHJlbHkgb24gaXQgYW5kIHVzZSBvdGhlciBtZXRob2RzLCBzbyB3ZSBkb24ndCBo YXZlDQo+IGltcGxlbWVudGF0aW9ucw0KPiBvZiBiZXR0ZXIgb3B0aW9ucy4gIFRoZXJlIGFyZSBh IGZldyBvdGhlciBvcHRpb25zIGluIHRoZSBIVFRQQXV0aCBXRw0KPiBhYm91dCB0byBnbyB0byBJ RVRGIGxhc3QgY2FsbCBvciBhcmUgV0cgZHJhZnRzLiAgSWYgeW91IGFyZSBnb2luZyB0bw0KPiBy ZWx5DQo+IG9uIEhUVFBBdXRoIG1ldGhvZHMsIG1heWJlIHRoZXJlIHNob3VsZCBiZSBhIHB1c2gg Zm9yIHRoZSBpbXByb3ZlZA0KPiBvcHRpb25zIGZyb20gdGhlIFdFSVJEUyBXRyAtIGF0IGxlYXN0 IHBpdGNoaW5nIGluIHRvIHJldmlldyBkdXJpbmcgbGFzdA0KPiBjYWxscy4NCj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy93Zy9odHRwYXV0aC9kb2N1bWVudHMvDQo+IA0KPiBTZWN0aW9u IDMuMQ0KPiBJJ20gYSBsaXR0bGUgdW5lYXN5IHdpdGgganVzdCBoYXZpbmcgYSBwb2ludGVyIHRv IFRMUyB0byBmaXggZXZlcnl0aGluZw0KPiBpbiBPQXV0aCBhbmQgT3BlbklELiAgQ291bGQgeW91 IHB1dCBpbiBwb2ludGVycyB0byBtYWluIGZyYW1ld29yaw0KPiBkb2N1bWVudHMgbGlrZSBSRkM2 NzQ5IHdpdGggYSBzdGF0ZW1lbnQgdGhhdCBzYXlzIHNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb25z DQo+IGFyZSBpbmNsdWRlZCBpbiB0aG9zZSBkcmFmdHM/ICBUaGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgZGlmZmVyDQo+IGJldHdlZW4NCj4gdG9rZW4gdHlwZXMgKGJlYXJlciB2cy4gSG9sZGVy IG9mIEtleSkgYW5kIHRoYXQgaXMgb3V0LW9mIHNjb3BlIGZvcg0KPiB0aGlzDQo+IGRyYWZ0LCBz byBwdW50aW5nIHRvIHRoZSBPQXV0aCBkcmFmdHMgd291bGQgYmUgdmVyeSBoZWxwZnVsIGluc3Rl YWQgb2YNCj4ganVzdCBwb2ludGluZyB0byBUTFMgKGJ1dCBwbGVhc2UgZG8gbGVhdmUgdGhhdCBp bikuDQo+IA0KPiBUaGlzIGlzIGp1c3QgYSBjb21tZW50IHRoZSByZWZlcmVuY2VzIGRvIGFwcGVh ciBhdCBlbmQgb2YgdGhlIFNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24sICYgSSdk IHJlY29tbWVuZCB5b3UgbW92ZSB0aG9zZSB1cCB0byBzZWN0aW9uDQo+IDMuMQ0KPiBhcyBpdCB3 aWxsIGJlIGEgbG90IGVhc2llciBmb3IgdGhlIHJlYWRlci4NCg0KVGhlcmUncyBhbHJlYWR5IGEg cmVmZXJlbmNlIHRvIFJGQyA2NzQ5IGluIFNlY3Rpb24gMy4xLjEsIHdoZXJlIHdlIHRhbGsgc3Bl Y2lmaWNhbGx5IGFib3V0IGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbi4gV291bGQgYWRkaW5nIGEg c2VudGVuY2UgdGhlcmUgdG8gc3BlY2lmaWNhbGx5IHJlZmVyIHRvIHRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBiZSBzdWZmaWNpZW50Pw0KDQo+IFNlY3Rpb24gMy4xDQo+IEp1c3QgYSBxdWVz dGlvbiwgc2hvdWxkIFNBTUwgMi4wIGJlIGxpc3RlZCBhcyBhbiBvcHRpb24gc2luY2UgdGhpcyBp cyBhDQo+IFJFU1RmdWwgaW50ZXJmYWNlIGFuZCB3ZSBhcmUgdGFsa2luZyBhYm91dCBjbGllbnQg YXV0aGVudGljYXRpb24gdmlhIGENCj4gZmVkZXJhdGVkIGlkZW50aXR5IHNjaGVtZSBvciBpcyB0 aGF0IG5vdCBhbiBvcHRpb24/ICBUaGFua3MuDQoNCkl0IHdvdWxkIGJlIGEgbW9yZSBhcHByb3By aWF0ZSBhZGRpdGlvbiB0byBTZWN0aW9uIDMuMS4xLiBUaGUgZG9jdW1lbnQgY3VycmVudGx5IHNh eXM6DQoNCiJGZWRlcmF0ZWQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyB1c2VkIGJ5IFJEQVAg TVVTVCBiZSBmdWxseSBzdXBwb3J0ZWQgYnkgSFRUUC4gT0F1dGgsIE9wZW5JRCwgYW5kIENBLWJh c2VkIG1lY2hhbmlzbXMgYXJlIHRocmVlIHBvc3NpYmxlIGFwcHJvYWNoZXMgdG8gcHJvdmlkZSBm ZWRlcmF0ZWQgYXV0aGVudGljYXRpb24uIiBJIGNvdWxkIGFkZCBTQU1MIHRvIHRoZSBsaXN0IHNp bmNlIHdlJ3JlIG5vdCBtYW5kYXRpbmcgYW55dGhpbmcuDQoNClNjb3R0DQoNCg== From nobody Thu Oct 30 05:03:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3051AD0A2; Thu, 30 Oct 2014 05:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdhdKplsAQVA; Thu, 30 Oct 2014 05:03:21 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3322C1A000F; Thu, 30 Oct 2014 05:03:18 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKVFIpBT7iWK3g8MHSv9jF7Bh5XTAzutYY@postini.com; Thu, 30 Oct 2014 05:03:21 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9UC3GHu002477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 08:03:16 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 08:03:05 -0400 From: "Hollenbeck, Scott" To: Andy Newton , Alissa Cooper Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) Thread-Index: AQHP8wThqQazUPVAGEi2/UP5B6hs2JxHBZLggAHFKYD//8EhUA== Date: Thu, 30 Oct 2014 12:03:14 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49509564@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <395E6D17-B800-4589-8A23-249BAE6711BD@arin.net> In-Reply-To: <395E6D17-B800-4589-8A23-249BAE6711BD@arin.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_831693C2CDA2E849A7D7A712B24E257F49509564BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/QZkiJ-uT8pttBGBk5eJvW_GKqVM Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:03:29 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F49509564BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Andy Newton [mailto:andy@arin.net] Sent: Thursday, October 30, 2014 7:44 AM To: Hollenbeck, Scott; Alissa Cooper Cc: The IESG; weirds-chairs@tools.ietf.org; weirds@ietf.org; draft-ietf-wei= rds-rdap-query@tools.ietf.org Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-que= ry-16: (with DISCUSS and COMMENT) On Oct 29, 2014, at 9:04 AM, Hollenbeck, Scott > wrote: ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =3D Section 3.2.3 =3D If I'm reading the document correctly, when searching for an entity, the search pattern is expected to represent an entity using the syntax specified in Section 6.1 of draft-ietf-weirds-json-response. But when the path segment is provided, rather than a search, Section 3.1.5 says this: The parameter represents an entity (such as a contact, registrant, or registrar) identifier whose syntax is specific to the registration provider. For example, for some DNRs contact identifiers are specified in RFC 5730 [RFC5730] and RFC 5733 [RFC5733]. This makes it seem as if an entity in a path segment uses different syntax (actually, non-standard syntax that is up to the registration provider) than an entity that someone might search for. Is there some specific field in the entity definition in draft-ietf-weirds-json-response that is supposed to correspond to? Aren't HTTP GETs for both path segments and searches meant to provide responses based on the same underlying data? If so, I don't understand why there is a specified syntax for entities in one but not the other. This also seems inconsistent with the following text in Section 6.1 of draft-ietf-weirds-json-response: The entity object class appears throughout this document and is an appropriate response for the /entity/XXXX query defined in Registration Data Access Protocol Lookup Format [I-D.ietf-weirds-rdap-query] Alissa, I do not fully comprehend this issue. To answer your question: yes = the HTTP GETs for both lookups and searches of entities are suppose to retu= rn the same underlying data. Would it be helpful for the text in json-respo= nse above to also state they are applicable for searches? OLD "where XXXX is a search pattern representing an entity name as specified in= Section 6.1 of [I-D.ietf-weirds-json-response]" NEW "where XXXX is a search pattern representing an entity (such as a contact, = registrant, or registrar) identifier whose syntax is specific to the regist= ration provider" Scott, I am confused. One is a search by handle and the other a search by a= person or organization's name. Doesn't this eliminate the name search? [SAH] I thought the comment had to do with lookups by entity handle (3.1.5)= and searches by entity handle (3.2.3). The text in the two sections descri= bes handle syntax inconsistently. That's what I attempted to correct. Scott --_000_831693C2CDA2E849A7D7A712B24E257F49509564BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Andy New= ton [mailto:andy@arin.net]
Sent: Thursday, October 30, 2014 7:44 AM
To: Hollenbeck, Scott; Alissa Cooper
Cc: The IESG; weirds-chairs@tools.ietf.org; weirds@ietf.org; draft-i= etf-weirds-rdap-query@tools.ietf.org
Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-r= dap-query-16: (with DISCUSS and COMMENT)

 

 

On Oct 29, 2014, at 9:04 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">shollenbeck@verisign.com>= wrote:



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

=3D Section 3.2.3 =3D
If I'm reading the document correctly, when searching for an entity,
the
search pattern is expected to represent an entity using the syntax
specified in Section 6.1 of draft-ietf-weirds-json-response. But when
the
path segment is provided, rather than a search, Section 3.1.5 says
this:

  The <handle> parameter represents an entity (such as a co= ntact,
  registrant, or registrar) identifier whose syntax is specific t= o the
  registration provider.  For example, for some DNRs contact=
  identifiers are specified in RFC 5730 [RFC5730] and RFC 5733   [RFC5733].

This makes it seem as if an entity in a path segment uses different
syntax (actually, non-standard syntax that is up to the registration
provider) than an entity that someone might search for. Is there some
specific field in the entity definition in
draft-ietf-weirds-json-response that <handle> is supposed to correspo= nd
to? Aren't HTTP GETs for both path segments and searches meant to
provide
responses based on the same underlying data? If so, I don't understand
why there is a specified syntax for entities in one but not the other.
This also seems inconsistent with the following text in Section 6.1 of
draft-ietf-weirds-json-response:

  The entity object class appears throughout this document and is= an
  appropriate response for the /entity/XXXX query defined in
  Registration Data Access Protocol Lookup Format
  [I-D.ietf-weirds-rdap-query]

 

Alissa, I do not fully comprehend this issue. To ans= wer your question: yes the HTTP GETs for both lookups and searches of entit= ies are suppose to return the same underlying data. Would it be helpful for= the text in json-response above to also state they are applicable for searches?



OLD
"where XXXX is a search pattern representing an entity name as specifi= ed in Section 6.1 of [I-D.ietf-weirds-json-response]"

NEW
"where XXXX is a search pattern representing an entity (such as a cont= act, registrant, or registrar) identifier whose syntax is specific to the r= egistration provider"

 

Scott, I am confused. One is a search by handle and = the other a search by a person or organization’s name. Doesn’t = this eliminate the name search?

 

[SAH] I thought the comment had to do with= lookups by entity handle (3.1.5) and searches by entity handle (3.2.3). Th= e text in the two sections describes handle syntax inconsistently. That’s what I attempted to correct.

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F49509564BRN1WNEXMBX01vc_-- From nobody Thu Oct 30 05:33:45 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BA91A003B; Thu, 30 Oct 2014 05:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xgXdQaya5PF; Thu, 30 Oct 2014 05:33:39 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06671A003A; Thu, 30 Oct 2014 05:33:39 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id D0895DA021F; Thu, 30 Oct 2014 12:36:57 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7728353E084; Thu, 30 Oct 2014 05:33:09 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 30 Oct 2014 05:33:09 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 30 Oct 2014 08:33:02 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <107E1EEF-9EAA-4A81-9DDE-C6CBB3C6E6E6@nominum.com> References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NvgJxd54M5O0avJB-aKryTprHM8 Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , weirds@ietf.org Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:33:41 -0000 On Oct 30, 2014, at 3:39 AM, Richard Barnes wrote: > This is a feature request, not a DISCUSS. >=20 > There are bazillions of HTTP servers out there today that get by just = fine with a binary, per-resource distinction between authorized and = unauthorized. And I can see situations where that would make sense here = too. For example, a server might not grant access to entity records = without authorization. No, this isn't correct. If you look at the base spec, it's clear that = some queries may get one answer if authenticated, and a different answer = if not authenticated. That's not something that HTTP authentication = supports without tweaks, so the security document needs to describe = those tweaks. The security document currently appears to be claiming = to address this use case, but it clearly doesn't. Hence the DISCUSS. One way to address the DISCUSS would be to say "this security model does = not support one of the use cases described in the base spec: returning = different answers depending on whether or not the client has = authenticated. A mechanism for addressing this is left as future = work." I think that would be unfortunate, but it would resolve the = DISCUSS. From nobody Thu Oct 30 06:43:50 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DB81AD255; Thu, 30 Oct 2014 06:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLMMGAp3vCCm; Thu, 30 Oct 2014 06:43:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B427F1AD0BC; Thu, 30 Oct 2014 06:43:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030134347.12462.94883.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 06:43:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/p7p2k4B5Q7V9Hnsy6O_4_WwDn_o Cc: draft-ietf-weirds-object-inventory@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-object-inventory-06: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:43:49 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-weirds-object-inventory-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think there is no harm at all in this being an RFC and using abstain to nitpick doesn't seem right (or at least, I don't understand why the stated abstains aren't nitpicking). From nobody Thu Oct 30 06:47:58 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8633F1AD26E; Thu, 30 Oct 2014 06:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qjNatF4HFIE; Thu, 30 Oct 2014 06:47:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88ACD1AD37C; Thu, 30 Oct 2014 06:47:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030134742.16217.19224.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 06:47:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/o6V5eG0zHYUs0El4SqQyHmzodw4 Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-json-response@tools.ietf.org Subject: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-json-response-11: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:47:50 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-weirds-json-response-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I support Alissa's discuss point that jCard is too rich a syntax and the specific jCard members intended to be used here ought be specified and the spec should say to not use others. The example on p18, with gender, dob, and other privacy sensitive fields should be adjusted to not include such. - I think it would have been a fine thing had the WG decided to do a more comprehensive privacy analysis of RDAP but I don't see that in this document set at least. I do like Kathleen's suggested text better than that currently in the privacy considerations section though. - Figure numbers are used inconsisently, some examples have them and, for no apparent reason, some don't. That needs fixing. There's also a lack of clarity about the specification style here - you need to be clearer as to what is just and example and what is not. - p21, the list following the example contains items that were not in the example - this is unclear writing. Are you saying that the list is normative or not? If so, you need to say so. If not, why go beyond the example? The same point applies to the lots of other examples that follow. - 10.2.X: there's a lot of stuff here that wasn't described. I wouldn't be surprised if that causes interop problems. From nobody Thu Oct 30 06:48:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E971AD35C; Thu, 30 Oct 2014 06:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qbFF7-Z8hS5; Thu, 30 Oct 2014 06:48:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 255641AD210; Thu, 30 Oct 2014 06:48:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030134831.10266.39819.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 06:48:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/MxeKW1eqe4PvmoZM2VonqV7J7yM Cc: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, weirds@ietf.org Subject: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-bootstrap-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:48:32 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-weirds-bootstrap-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - p4, where does it say what time is the publication time? Is it when the record is created/sent to IANA or when IANA get it or what? - section 9, 1st para: I'm not clear what cache expiry expectations we're setting here for IANA and dislike that that is essentially a form of dynamic data intended to be related to registry content that I don't believe IANA has previously been asked to serve up. I think that's a bad plan. - section 11 - this ought call for TLS as a MUST From nobody Thu Oct 30 06:50:00 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2199F1A0126; Thu, 30 Oct 2014 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjIMd56gXQxw; Thu, 30 Oct 2014 06:49:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5471AD372; Thu, 30 Oct 2014 06:49:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030134956.5440.23247.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 06:49:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/rMvaRdQuLg_iG76L-bxRr6d2w1o Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org Subject: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-rdap-query-16: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:49:58 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-weirds-rdap-query-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Using https schemed URIs in the examples would be better. Mind you, https://example.com does get you a fairly odd certificate, so I can see why you might push back on that;-) - I think the privacy considerations from the json response draft might be better here. From nobody Thu Oct 30 06:50:45 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D671AD0BC; Thu, 30 Oct 2014 06:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uDq1pYTT1Ja; Thu, 30 Oct 2014 06:50:14 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840701A0126; Thu, 30 Oct 2014 06:50:11 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKVFJCE/ttIipcegCjif50sMssGAhxlkf2@postini.com; Thu, 30 Oct 2014 06:50:14 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9UDo9xd015367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 09:50:10 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 09:50:09 -0400 From: "Hollenbeck, Scott" To: Ted Lemon , The IESG Thread-Topic: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) Thread-Index: AQHP8+UzLw/108KMGkWvbe99kamx05xIorPg Date: Thu, 30 Oct 2014 13:50:08 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4950987F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> In-Reply-To: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/car__2i9eOIcIj7xV9qpm0rT48s Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:50:22 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Wednesday, October 29, 2014 10:00 PM > To: The IESG > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > chairs@tools.ietf.org; weirds@ietf.org > Subject: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: > (with DISCUSS) >=20 > Ted Lemon has entered the following ballot position for > draft-ietf-weirds-rdap-sec-10: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > As far as I can tell, this specification effectively relies on HTTP > authentication as its sole MTI mechanism, and leaves things like OAuth > as > sort of "you could do this, but we aren't saying how." I am deeply > uncomfortable with this, because HTTP authentication really sucks when > you are trying to make it work in a context where authentication is > optional. >=20 > I think if you want to rely on this mechanism, you need to give the > reader more guidance on how to make this work. What I mean is that in > order to trigger the client to send authentication, you have to send > back > a 401 Unauthorized HTTP response. But that assumes that > authentication > _is_ required, and it's not. So how does the server know to send back > the HTTP unauthorized response? The answer is that it does not, and > so > you need to somehow signal to the client that it should send more > authentication info if it wants better information, while still > returning > information in case the client has no credentials to offer. >=20 > This is probably doable, but simply relying on RFC 7235 without > explaining how to make it work isn't sufficient. Would adding something like this suffice? "A client typically does not know in advance if a server requires client au= thentication to process a query. If a client sends a request for a query th= at can be processed without authentication information, a server can return= an RDAP response consistent with local policies for unauthenticated access= . If authentication is required, a server MUST return an HTTP 401 (Unauthor= ized) response to challenge the authorization of a user agent. The authenti= cation process can then proceed as described in Section 2 of RFC 7235 [RFC7= 235]." FWIW I noticed that I need to change the title of RFC 7235 where it's curre= ntly referenced. It should be "Hypertext Transfer Protocol (HTTP/1.1): Auth= entication". Scott From nobody Thu Oct 30 06:51:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234BA1AD372; Thu, 30 Oct 2014 06:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0knR_p7jTGI9; Thu, 30 Oct 2014 06:51:12 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1353B1A0126; Thu, 30 Oct 2014 06:51:05 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKVFJCSDvLpqk186QJcnDbLJLcAU9RdwNW@postini.com; Thu, 30 Oct 2014 06:51:08 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9UDp3mB015467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 09:51:03 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 09:50:52 -0400 From: "Hollenbeck, Scott" To: Ted Lemon , Richard Barnes Thread-Topic: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) Thread-Index: AQHP9BSsIj2l7Q9rj0i31Duli2V+6ZxI1i8A///CaZA= Date: Thu, 30 Oct 2014 13:51:02 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49509892@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> <107E1EEF-9EAA-4A81-9DDE-C6CBB3C6E6E6@nominum.com> In-Reply-To: <107E1EEF-9EAA-4A81-9DDE-C6CBB3C6E6E6@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/IJ_FEVEXrfbD2oQewIQbj5AWZm4 Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:51:16 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Thursday, October 30, 2014 8:33 AM > To: Richard Barnes > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > chairs@tools.ietf.org; The IESG; weirds@ietf.org > Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap- > sec-10: (with DISCUSS) >=20 > On Oct 30, 2014, at 3:39 AM, Richard Barnes wrote: > > This is a feature request, not a DISCUSS. > > > > There are bazillions of HTTP servers out there today that get by just > fine with a binary, per-resource distinction between authorized and > unauthorized. And I can see situations where that would make sense > here too. For example, a server might not grant access to entity > records without authorization. >=20 > No, this isn't correct. If you look at the base spec, it's clear that > some queries may get one answer if authenticated, and a different > answer if not authenticated. That's not something that HTTP > authentication supports without tweaks, so the security document needs > to describe those tweaks. The security document currently appears to > be claiming to address this use case, but it clearly doesn't. Hence > the DISCUSS. I disagree with the "clearly doesn't" statement, so yes, let's have a discu= ssion. In Section 3.2 we have text that explicitly acknowledges the use case ("Ser= ver operators MAY offer varying degrees of access depending on policy and n= eed in conjunction with the authentication methods described in Section 3.1= "). There is no way I can describe the server-side response-building tweaks= that might be made by every single server operator because there is no "on= e size fits all" approach in this space. Operators will provide service in = accordance with local laws, local policies, and whatever agreements they ha= ppen to have in place with entities like ICANN. The document reflects that = reality. The answers that can be returned are described in json-response. Perhaps we= need to add text there. I do not know what I can add to address this parti= cular concern, which leads to: > One way to address the DISCUSS would be to say "this security model > does not support one of the use cases described in the base spec: > returning different answers depending on whether or not the client has > authenticated. A mechanism for addressing this is left as future > work." I think that would be unfortunate, but it would resolve the > DISCUSS. I am open to adding text, but I do not agree with adding *this* text. The m= odel described in rdap-sec acknowledges the use case. Could you be more spe= cific about the additional detail that you think is missing? I don't see it= described in the DISCUSS text. That's focused on authentication. I sent a = suggestion for that comment a moment ago. Scott Scott From nobody Thu Oct 30 06:53:03 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D14A1AD381; Thu, 30 Oct 2014 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7I7XIpv5OtC; Thu, 30 Oct 2014 06:52:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BEF1AD36E; Thu, 30 Oct 2014 06:52:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030135248.15698.53754.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 06:52:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/zT7biu7WzFDchgnZIVB2GxEihR0 Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-rdap-sec-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:52:54 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-weirds-rdap-sec-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I strongly support Aliss's discuss on privacy. That would be even more important should registrars/registries in future require that personally identifying information be available for all registrants, which I believe is a policy that at least some are arguing for. - Isn't it sad that HTTP basic and digest still have to be the MTIs here for client auth. (I would suggest HOBA [1] but that's not quite done, being just finished WGLC, and would be self-serving, though it would be far better than basic or digest;-) [1] https://tools.ietf.org/html/draft-ietf-httpauth-hoba-05 - Why not just say "TLS MUST be used" in all cases? Is there a real need to not use TLS for weirds ever? - TLS client auth - I think you could easily make this MTI (to implement, not to use) as its basically there in most codebases. From nobody Thu Oct 30 06:53:50 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7761A0103; Thu, 30 Oct 2014 06:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNFJnt9ko6lU; Thu, 30 Oct 2014 06:53:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 018D01AD381; Thu, 30 Oct 2014 06:53:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030135343.10266.64338.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 06:53:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/YiAtEusb552pbvyAE6cwIL-tQlo Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-using-http@tools.ietf.org Subject: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-using-http-14: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:53:46 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-weirds-using-http-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - As I said on the sec draft, I see no reason why RDAP could not only be defined for use with https URIs. - 5.5 seems to conflict a bit with one of the notices defined in the json-response draft where you say to do the same thing in the payload. I don't think it's a big problem but could be better to say which to use when. - I'm also not sure the CORS thing is quite right if cookies might get sent to the wrong places. From nobody Thu Oct 30 06:57:08 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3641A00E4; Thu, 30 Oct 2014 06:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1ge51h1L_Fj; Thu, 30 Oct 2014 06:57:06 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123B51A0171; Thu, 30 Oct 2014 06:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414677426; x=1446213426; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=U/ycxz+ZxhYs1DMJ9p4/tswdvQZY2Au45VXkPEri0rs=; b=zprTQvkETsAfsQTDaNwZO1Jg7ulDSpAPTV+OhLhmeuR7lmd1yWAPNWJN RdPVMrZ8sBQzBHGJDao5FV3F7SSTLx4+tMnZyT9tFDknJ30SDgMP/Gu0n kVW6aWrNF6gqn3IebXezB5wZkvE8PXxq0obHGeHB8JtyibAUtP6pKjpo0 c=; X-IronPort-AV: E=McAfee;i="5600,1067,7606"; a="79962129" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Oct 2014 06:57:04 -0700 X-IronPort-AV: E=Sophos;i="5.07,285,1413270000"; d="scan'208";a="739971533" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Oct 2014 06:57:05 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 06:57:03 -0700 Received: from apc-qrc004-rpdu-k02-lf.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 30 Oct 2014 06:57:03 -0700 Message-ID: <545243AE.7090101@qti.qualcomm.com> Date: Thu, 30 Oct 2014 06:57:02 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20141029165443.6647.29382.idtracker@ietfa.amsl.com> In-Reply-To: <20141029165443.6647.29382.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/COZyvlkR8xQ1FKvG0jW4JgcJAyk Cc: draft-ietf-weirds-object-inventory@tools.ietf.org, weirds-chairs@tools.ietf.org, The IESG , weirds@ietf.org Subject: Re: [weirds] Barry Leiba's Abstain on draft-ietf-weirds-object-inventory-06: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:57:08 -0000 [Cc'ing Alissa directly as well] On 10/29/14 9:54 AM, Barry Leiba wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I see no value in publishing this document as an RFC. I think it would > be great to keep the information in the wiki for all to peruse, but I > don't think anyone will want to read the RFC a year from now, much less > several years from now. But I understand that this has been discussed > and decided, so I will accept that I'm in the rough, and will abstain. > I do want to point out the text in the ballot: Early discussion of the document centered around whether to publish it at all. Consensus of the WG is that this is useful work to record as it draws a line from WHOIS to RDAP explaining some of the choices found in other documents. It may also be referenced by ICANN work as their policies transition from WHOIS to RDAP. which is itself a slight modification of the shepherd writeup: Early discussion of the document centered around whether to publish it at all. After discussion with our Area Director who really forced the WG to consider that question, consensus of the WG is that this is useful work to record as it draws a line from WHOIS to RDAP explaining some of the choices found in other documents. It may also be referenced by ICANN work as their policies transition from WHOIS to RDAP. It is the last sentence that convinced me not to hold up the document. Would adding such information to the top of the document change either of your ballots? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Oct 30 06:59:28 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAD31A00E4; Thu, 30 Oct 2014 06:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-su6w0lZVPF; Thu, 30 Oct 2014 06:59:17 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B8B1AD0BC; Thu, 30 Oct 2014 06:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414677557; x=1446213557; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=D+MmYxUGqLkjhQUCLkeDs8ZVGWCFJj15mHQCnNp23JM=; b=BNPiF4yXHbVcMalg7h/9Jk0vAu/EBJersO3CxwuScVJ9h4QQA+As1mT4 63RqxyZIUXeAnbpzweNgmL2jGrbmhculpaTqz0iMtQlnm3U+LOWbQfQTW hHPKksBbYyIXopQQOS3glLsfHU3ermZSIDQUytBe9j+/cGEhCi5RYivFg s=; X-IronPort-AV: E=McAfee;i="5600,1067,7606"; a="171740892" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine02.qualcomm.com with ESMTP; 30 Oct 2014 06:59:16 -0700 X-IronPort-AV: E=Sophos;i="5.07,286,1413270000"; d="scan'208";a="31646415" Received: from nasanexhc03.na.qualcomm.com ([10.46.200.142]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Oct 2014 06:59:16 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by NASANEXHC03.na.qualcomm.com (10.46.200.142) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 06:59:15 -0700 Received: from apc-qrc004-rpdu-k02-lf.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 30 Oct 2014 06:59:09 -0700 Message-ID: <5452442D.50901@qti.qualcomm.com> Date: Thu, 30 Oct 2014 06:59:09 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Richard Barnes References: <20141030062925.11472.79559.idtracker@ietfa.amsl.com> In-Reply-To: <20141030062925.11472.79559.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (129.46.53.236) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/qGtxtY4KaOTEMEtzzaBxHcHrojM Cc: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, The IESG , weirds@ietf.org Subject: Re: [weirds] Richard Barnes' No Objection on draft-ietf-weirds-bootstrap-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:59:19 -0000 On 10/29/14 11:29 PM, Richard Barnes wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The use of JSON in this syntax is slightly disappointing. Generally, > using JSON arrays to contain items of different types is not a great > idea. It seems like the "services" entries should actually be objects, > with entries indicating the semantics of the inner arrays, e.g.: > > OLD: [ ["1.0.0.0/8", "192.0.0.0/8"], ["https://rir1.example.com/myrdap/"] > ] > NEW: { "resources": ["1.0.0.0/8", "192.0.0.0/8"], "urls": > ["https://rir1.example.com/myrdap/"] } > > This should not be hard to describe in the notation of Section 10.2, and > it only uses a few more bytes on the wire. > Your faithful Responsible AD made the almost identical comment during AD Evaluation. The implementation ship had apparently sailed, with interoperable implementations, and so I decided that rough consensus and running code outweighed prettiness. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Oct 30 07:00:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55CC1AD255; Thu, 30 Oct 2014 06:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJyg2oPjZ-Q7; Thu, 30 Oct 2014 06:59:57 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AEB61AD37A; Thu, 30 Oct 2014 06:59:54 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id mc6so4396891lab.26 for ; Thu, 30 Oct 2014 06:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kQtN9J9elx6UubhbxDc80oPcImTRVRbA0pqDtnX+16A=; b=wVBIZzuk0+YS771Lriby6w1T8r22AI7rAZGJ1P36IJmXl2h7HL3neqWooyze7Wsu20 rPP4h3+hc0StnAPIbk4aHE7Ln4HcyA1m2EgNLCRHBVLkT9GKC4Zoo9NrLBmudZEOV8ll /FO28budUjePwk6l2UysiqIvdlFWcpthywceXDg8nYuIYyRubmadcnJVWgKffi58/OtF EaD04q0iKSE009TPGTNcOqjnosxvzau5LY1WVWRbmT/hp6wHGnM3759W/CeNdJ9VoV75 5a4DMER6SBmHEMvdvvoPArj3PrhuWb/+Xo87naFK433ulxvckplxecwVWwxpd/3hveX8 Ol9Q== MIME-Version: 1.0 X-Received: by 10.112.162.41 with SMTP id xx9mr18907782lbb.21.1414677590272; Thu, 30 Oct 2014 06:59:50 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Thu, 30 Oct 2014 06:59:50 -0700 (PDT) In-Reply-To: <545243AE.7090101@qti.qualcomm.com> References: <20141029165443.6647.29382.idtracker@ietfa.amsl.com> <545243AE.7090101@qti.qualcomm.com> Date: Thu, 30 Oct 2014 09:59:50 -0400 X-Google-Sender-Auth: eopdB0vNBHaaTaA7TMU5vacWQak Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/642r4TJX46lqBmQIRT93v1ZNCYM Cc: draft-ietf-weirds-object-inventory@tools.ietf.org, "weirds-chairs@tools.ietf.org" , The IESG , "weirds@ietf.org Group" Subject: Re: [weirds] Barry Leiba's Abstain on draft-ietf-weirds-object-inventory-06: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:59:59 -0000 > Early discussion of the document centered around whether to publish > it at all. After discussion with our Area Director who really forced > the WG to consider that question, consensus of the WG is that this is > useful work to record as it draws a line from WHOIS to RDAP > explaining some of the choices found in other documents. It may also > be referenced by ICANN work as their policies transition from WHOIS > to RDAP. > > It is the last sentence that convinced me not to hold up the document. Would > adding such information to the top of the document change either of your > ballots? It might, indeed. But it doesn't matter, unless you just don't like having any ABSTAIN ballots on principle. Barry From nobody Thu Oct 30 07:16:53 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060671AD3B4 for ; Thu, 30 Oct 2014 07:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qOaFnugkQXm for ; Thu, 30 Oct 2014 07:16:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8A91AD3A0 for ; Thu, 30 Oct 2014 07:16:42 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 4BD3120BF1 for ; Thu, 30 Oct 2014 10:16:42 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 30 Oct 2014 10:16:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=mesmtp; bh=c6H3rpI5AXflQ26Z HkbLUnDRgCo=; b=NRRM9ykJMHQgdw4SLIFsmBXAwIfKMAWcdW1ZFtBoYozbytqg m4urVf5bucOos/BSNVEqXoZRcZRedtCfdeUy2Vo9l4DffBBSr6li8wHtqeL/A2TA LGIr+NAxuw2duoV+j5oFTlFPOBGmQK67mEiR1iCfHE6s1aaPJDHgu0psB54= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:message-id:references:to; s= smtpout; bh=c6H3rpI5AXflQ26ZHkbLUnDRgCo=; b=SHZ1WJ28CVIlIEnzhJRK hHl4kD4pw9zuQ2MaIkFFoJgqKIvs4EJs/L7/QSnUlQkaK+4PbewQCRrECQK36TeP L9AzbNNaBX/PN/IVweVL+vYouksv66hgcjb1tUz7R32lNvQHezMNAr7l2EBEiY86 A9phhrxyJoXnWchRCiro5sE= X-Sasl-enc: EkxRzHbZRKMfyXD2iHPASPZqniUw0JLrtMGldKSwbG7T 1414678602 Received: from sjc-vpn6-1922.cisco.com (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 7BB7E6800F5; Thu, 30 Oct 2014 10:16:41 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_858D528D-8A17-4E53-BE0D-55F8CCFC06F4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Thu, 30 Oct 2014 07:16:41 -0700 Message-Id: <027A5923-CEE2-45AB-BD85-EB2B0EB76E50@cooperw.in> References: <20141029232910.320.95416.idtracker@ietfa.amsl.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/qi5AIlSYeKngVjANHElgdEtp8BE Cc: draft-ietf-weirds-object-inventory@tools.ietf.org, "weirds-chairs@tools.ietf.org" , IESG , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Abstain on draft-ietf-weirds-object-inventory-06: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:16:51 -0000 --Apple-Mail=_858D528D-8A17-4E53-BE0D-55F8CCFC06F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 29, 2014, at 11:50 PM, Murray S. Kucherawy = wrote: > On Wed, Oct 29, 2014 at 4:29 PM, Alissa Cooper = wrote: > I'm with Barry -- this seems like it would have made more sense if > published on a wiki, as a research paper, or in a slide deck. If the > choices made in the protocol documents actually linked back to these > findings for justification, I might see it differently, but at present > there does not seem to be much connection between these findings and = some > of the design decisions made in the protocol. The data formats in the > protocol don't seem to support every field that was discovered in this > study, nor does there seem to be any consistent metric that was used = for > deciding whether to include a particular field based on its prevalence = in > these findings. >=20 > We discussed this a few times in the WG when deciding whether to adopt = and ultimately publish this document. In the end the WG reached = consensus that it was worth publishing because the research described in = it led directly to the fields registered by the json-response draft. >=20 > The detail you described in that last sentence are probably things we = should consider adding either to this document or to json-response. It would make more sense to me to publish this document as an RFC if = json-response provided explanations for why particular fields are = supported and cited this document as a reference. Alissa >=20 > -MSK --Apple-Mail=_858D528D-8A17-4E53-BE0D-55F8CCFC06F4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii On Oct 29, 2014, at 11:50 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Wed, Oct 29, 2014 at 4:29 PM, Alissa Cooper <alissa@cooperw.in> wrote:
I'm with Barry -- this seems like it would have made more sense if
published on a wiki, as a research paper, or in a slide deck. If the
choices made in the protocol documents actually linked back to these
findings for justification, I might see it differently, but at present
there does not seem to be much connection between these findings and some
of the design decisions made in the protocol. The data formats in the
protocol don't seem to support every field that was discovered in this
study, nor does there seem to be any consistent metric that was used for
deciding whether to include a particular field based on its prevalence in
these findings.

We discussed this a few times in the WG when deciding whether to adopt and ultimately publish this document.  In the end the WG reached consensus that it was worth publishing because the research described in it led directly to the fields registered by the json-response draft.

The detail you described in that last sentence are probably things we should consider adding either to this document or to json-response.

It would make more sense to me to publish this document as an RFC if json-response provided explanations for why particular fields are supported and cited this document as a reference.

Alissa


-MSK

--Apple-Mail=_858D528D-8A17-4E53-BE0D-55F8CCFC06F4-- From nobody Thu Oct 30 07:20:36 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4239A1AD0BB; Thu, 30 Oct 2014 07:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEUm5aSsWiCx; Thu, 30 Oct 2014 07:20: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 D08771A00F2; Thu, 30 Oct 2014 07:20:28 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 8B638165107; Thu, 30 Oct 2014 10:20:28 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 48AB51650ED; Thu, 30 Oct 2014 10:20:26 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 10:22:48 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Thu, 30 Oct 2014 10:20:25 -0400 From: Andy Newton To: Stephen Farrell Thread-Topic: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-rdap-sec-10: (with COMMENT) Thread-Index: AQHP9EjT8uVSkcSGZkiRcgB8Mts035xI88YA Date: Thu, 30 Oct 2014 14:20:24 +0000 Message-ID: <17F414D0-9713-4063-81DC-A1871427823C@arin.net> References: <20141030135248.15698.53754.idtracker@ietfa.amsl.com> In-Reply-To: <20141030135248.15698.53754.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2C33819306AC0549AFE6AA89B184EA71@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/a7bQjShHGSQcw0RO-XyIxRY-Low Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-rdap-sec-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:20:30 -0000 On Oct 30, 2014, at 9:52 AM, Stephen Farrell wr= ote: > - Why not just say "TLS MUST be used" in all cases? Is there a > real need to not use TLS for weirds ever? In addition to what John Levine said regarding the interop issues with TLS, 1) The information to be served over RDAP is served over Whois today, and t= hat has no protections at all. Since Whois will remain with us for sometim= e, a MUST TLS can impose adoption issues for some service operators where t= hey don=92t have those issues with Whois. Which leads to item #2... 2) As a service operator, we frequently get spikes. If we had to always ser= ve this data over TLS, there is a good chance we could not handle the load.= Those spikes aren=92t always predictable. Why is it difficult to handle th= is? See #3=85 3) It=92s almost 2015, and we should have load balancers that can handle TL= S. But when you want those same load balancers to work with IPv6, not so mu= ch. While the vendors claim they can do this, their glossyware and reality = do not match. So given the choice between IPv6 connectivity and always usin= g TLS, we have to go with IPv6. -andy= From nobody Thu Oct 30 07:21:48 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE921AD395 for ; Thu, 30 Oct 2014 07:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVGV6_AqcMtJ for ; Thu, 30 Oct 2014 07:21:44 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43A51AD0BB for ; Thu, 30 Oct 2014 07:21:42 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4DE1D20DA1 for ; Thu, 30 Oct 2014 10:21:42 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 30 Oct 2014 10:21:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=Sd2XNEMT3n31PaNxgJ41TCP533I=; b=O00KA1ARJxcEmYa1V1NS6 E8ozca2EN/gkY/BqHnVZ0vsDjvmKauHy0Gjr1abN06nNEFyONvoLBgKeiqssYmIu y7aqbL6P86wdCyDXMDSC24QddwNVEHF/WVxkOMlLnX9PRJO5F13I7yaoLRgQfDNr 2HSLvoL2g+zyo62HjzgQ8s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=Sd2XNEMT3n31PaNxgJ41TCP 533I=; b=LALNZb2Z/90KNEVV9dnrbMyx0c0CJ0B3saCoDNISifgpK4BpZfwC3Yr FgeBDX8hgPZbhegU7chp+dxWL7XD2IqRe9rjGfmPUf3UxYdriAacnCtpYzXWXBYK kQ4EIZoef9VheTO+RSNAPzyyezvC+1BE7uvajuAHumpvIranTIKQ= X-Sasl-enc: sGSo2HXaRLIHIe8C0BNuUmry3zvOVYJYb6plU0g6ad8V 1414678901 Received: from sjc-vpn6-1922.cisco.com (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id 6037F6800D2; Thu, 30 Oct 2014 10:21:41 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 30 Oct 2014 07:21:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <11974DBD-B6C6-4AB8-8BB1-F671F037C80A@cooperw.in> References: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/LqXWdPSXnZLW1X0ISbPtvOt9oFA Cc: "weirds-chairs@tools.ietf.org" , IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:21:46 -0000 On Oct 29, 2014, at 6:04 AM, Hollenbeck, Scott = wrote: >> -----Original Message----- >> From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Alissa >> Cooper >> Sent: Tuesday, October 28, 2014 7:14 PM >> To: The IESG >> Cc: weirds-chairs@tools.ietf.org; weirds@ietf.org; draft-ietf-weirds- >> rdap-query@tools.ietf.org >> Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap- >> query-16: (with DISCUSS and COMMENT) >>=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-weirds-rdap-query-16: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to http://www.ietf.org/iesg/statement/discuss- >> criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> =3D Section 3.2.3 =3D >> If I'm reading the document correctly, when searching for an entity, >> the >> search pattern is expected to represent an entity using the syntax >> specified in Section 6.1 of draft-ietf-weirds-json-response. But when >> the >> path segment is provided, rather than a search, Section 3.1.5 says >> this: >>=20 >> The parameter represents an entity (such as a contact, >> registrant, or registrar) identifier whose syntax is specific to = the >> registration provider. For example, for some DNRs contact >> identifiers are specified in RFC 5730 [RFC5730] and RFC 5733 >> [RFC5733]. >>=20 >> This makes it seem as if an entity in a path segment uses different >> syntax (actually, non-standard syntax that is up to the registration >> provider) than an entity that someone might search for. Is there some >> specific field in the entity definition in >> draft-ietf-weirds-json-response that is supposed to = correspond >> to? Aren't HTTP GETs for both path segments and searches meant to >> provide >> responses based on the same underlying data? If so, I don't = understand >> why there is a specified syntax for entities in one but not the = other. >> This also seems inconsistent with the following text in Section 6.1 = of >> draft-ietf-weirds-json-response: >>=20 >> The entity object class appears throughout this document and is an >> appropriate response for the /entity/XXXX query defined in >> Registration Data Access Protocol Lookup Format >> [I-D.ietf-weirds-rdap-query] >=20 > It's actually Section 5.1 of json-response. That section reference is = incorrect (and could be removed as suggested below). If only xml2rfc = made it possible to tag cross-document section references... >=20 > The json-response document doesn't actually provide a syntax = specification for entity handles. The closest it comes is "a string = representing an registry unique identifier of the entity" (we need to = change "an registry" to "a registry"). The text in 3.2.3 (Entity Search) = should be consistent with 3.1.5 (Entity Path Segment Specification) and = json-response. 3.1.5 says this: >=20 > "The parameter represents an entity (such as a contact, = registrant, or registrar) identifier whose syntax is specific to the = registration provider." >=20 > This is consistent with json-response. Would this change in 3.2.3 = address your concern? >=20 > OLD > "where XXXX is a search pattern representing an entity name as = specified in Section 6.1 of [I-D.ietf-weirds-json-response]" >=20 > NEW > "where XXXX is a search pattern representing an entity (such as a = contact, registrant, or registrar) identifier whose syntax is specific = to the registration provider=94 Yes, this addresses my concern, assuming it works for Andy. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> =3D Section 3 =3D >> "The query URL is >> constructed by concatenating the base URL to the help path segment >> specified in either Section 3.1.6." >>=20 >> The "either" is extraneous, or there is some other section missing at >> the >> end of this sentence. >=20 > "either" should be removed. Thanks for that catch. >=20 >> =3D Section 4.2 and Section 8: >> I think it would be helpful here to point out that the >> identity/authorization of the searcher may be a relevant factor in >> determining how broad the response set should be for any particular >> query >> (and not just a single static policy that applies to all searchers >> equally). >=20 > I can add this to both sections: >=20 > "Note that there might not be a single, static information return = policy that applies to all clients equally. Client identity and = associated authorizations can be a relevant factor in determining how = broad the response set will be for any particular query." >=20 > Does that work? Yes, sounds good. Thanks, Alissa >=20 > Scott From nobody Thu Oct 30 07:24:44 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACA01AD3B1 for ; Thu, 30 Oct 2014 07:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQy3uX4Efa97 for ; Thu, 30 Oct 2014 07:24:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E57A1AD3AE for ; Thu, 30 Oct 2014 07:24:28 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0647220A45 for ; Thu, 30 Oct 2014 10:24:27 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 30 Oct 2014 10:24:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=Ehr5/09IlngMGmz7j7sctgybzq4=; b=ny38LCEOOJB420l7R+KIN It685sz+6ZzI3Xo0j9PaNM84sxxV2U9Q2EhELxt3n35RJ6Cyg0n02nS+2kqSOmX9 yBOx/4BvwEoY/VDXYQGbvHqjv1XU461nwV1U2MyXamwvkQzMI+qCXRV0GnZ5hn4t P6CYRypols+OYZ/T//ES80= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=Ehr5/09IlngMGmz7j7sctgy bzq4=; b=pA9YcicX4qoqxaUUUejTseRyp4oTJF+Dp3dnmu48wY6Az5MGZeEHO4Y K0JUM1wVG5zTaJggMZK9slcTNLH/NEx5lnSe9LiYN0VwnSeGWkSByPtwD3uWevUX rnBOHCq1rbqA7uCXIkPHv2Lhf2DyJPUSs0w+N2UzfvnP8p5YBhj0= X-Sasl-enc: YHtEWGfUncr09uDcAvv97QSqUD+qbDR26TehJY4UA/G4 1414679067 Received: from sjc-vpn6-1922.cisco.com (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 324C068010D; Thu, 30 Oct 2014 10:24:27 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <23FB3A98-8047-4505-B91F-FB9ABCAC8407@arin.net> Date: Thu, 30 Oct 2014 07:24:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <81AA7EAA-76C9-49CE-9B9C-B717E00A08CB@cooperw.in> References: <20141028231454.16979.8007.idtracker@ietfa.amsl.com> <23FB3A98-8047-4505-B91F-FB9ABCAC8407@arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/8oSaOVHfEIxLFMmhgDwsDJ8BM48 Cc: "weirds@ietf.org" , "weirds-chairs@tools.ietf.org" , IESG , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:24:35 -0000 On Oct 30, 2014, at 4:09 AM, Andy Newton wrote: >=20 > On Oct 28, 2014, at 7:14 PM, Alissa Cooper wrote: >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I think this document is missing a discussion of the fact that while >> jCard was selected as the format for entity representation because it = can >> flexibly accommodate the spectrum of the kinds of entities that = require >> representation in RDAP, the full jCard specification includes many = fields >> that are unrelated to the uses of the RDAP protocol and therefore not >> expected to be stored or made available by servers. This is a = different >> point than the point made in Appendix A.1 (which should really be in >> Section 14 IMO) about the use of status values, which implies that = the >> fields exist in the server-side database but are not shared in = certain >> circumstances. >=20 > This is a good point. Does inserting the following paragraph after = the first paragraph in Section 5.1 address this? >=20 > The entity object class uses jCard [RFC7095] to represent contact = information, > such as postal addresses, email addresses, phone numbers and names of=20= > organizations and individuals. Many of the types of information that = can be > represented with jCard are unlikely to be used in RDAP, such as = birthdays, > anniversaries, and gender. s/are unlikely to be used/have no use/ Otherwise looks good. >=20 >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> =3D Section 3.2 =3D >> I love an idiom as much as the next person, but it would be better to = use >> names in examples that are not culturally specific. >>=20 >> =3D Section 4 =3D >> The reference to I-D.ietf-jcardcal-jcard should be replaced with RFC >> 7095, I think. >>=20 >> =3D Section 6.1 =3D >> Following on from my DISCUSS, I know the example in this section is = just >> an example, but it includes all kinds of information about Joe User = that >> no registry should be asking for and no registrant should willingly >> provide (gender? anniversary? really?!). It would be nice for the = example >> to reflect what reality might/should actually be like. >=20 > Agreed (though your section numbers are off). Sorry about that, too many document reviews going on at once =85 Thanks, Alissa >=20 > Thanks. >=20 > -andy From nobody Thu Oct 30 07:25:20 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2277D1A00E4; Thu, 30 Oct 2014 07:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGgjDpiBKqZl; Thu, 30 Oct 2014 07:25:10 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id C9C3E1AD3BE; Thu, 30 Oct 2014 07:25:01 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 813B72137C1; Thu, 30 Oct 2014 10:25:01 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 0F8DD2137AC; Thu, 30 Oct 2014 10:25:01 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 10:27:41 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Thu, 30 Oct 2014 10:25:00 -0400 From: Andy Newton To: Alissa Cooper Thread-Topic: [weirds] Alissa Cooper's Abstain on draft-ietf-weirds-object-inventory-06: (with COMMENT) Thread-Index: AQHP89AvZJlQeg0CtUCeKvYi9SL0Y5xIduuAgAB8woCAAAJSgA== Date: Thu, 30 Oct 2014 14:24:59 +0000 Message-ID: <078E6574-886E-4FF8-BCB1-7BBDD818C0C5@arin.net> References: <20141029232910.320.95416.idtracker@ietfa.amsl.com> <027A5923-CEE2-45AB-BD85-EB2B0EB76E50@cooperw.in> In-Reply-To: <027A5923-CEE2-45AB-BD85-EB2B0EB76E50@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: multipart/alternative; boundary="_000_078E6574886E4FF8BCB17BBDD818C0C5arinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/xyEFxSc7fV-G4zIPQ5PleHgVH_w Cc: "draft-ietf-weirds-object-inventory@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , IESG , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Abstain on draft-ietf-weirds-object-inventory-06: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:25:18 -0000 --_000_078E6574886E4FF8BCB17BBDD818C0C5arinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 30, 2014, at 10:16 AM, Alissa Cooper > wrote: It would make more sense to me to publish this document as an RFC if json-r= esponse provided explanations for why particular fields are supported and c= ited this document as a reference. We can add that to json-response. Scott and I did go through this informati= on when formulating json-response (and rdap-query). -andy --_000_078E6574886E4FF8BCB17BBDD818C0C5arinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: <4FF2BDD0EB97414AA2B384A36335943D@corp.arin.net> Content-Transfer-Encoding: quoted-printable
On Oct 30, 2014, at 10:16 AM, Alissa Cooper <alissa@cooperw.in> wrote:


It would make more sense to me to publish this document as an RFC if j= son-response provided explanations for why particular fields are supported = and cited this document as a reference.

We can add that to json-response. Scott and I did go through this info= rmation when formulating json-response (and rdap-query).

-andy
--_000_078E6574886E4FF8BCB17BBDD818C0C5arinnet_-- From nobody Thu Oct 30 07:49:04 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63BC1A0115 for ; Thu, 30 Oct 2014 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAobAyurYasg for ; Thu, 30 Oct 2014 07:48:54 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D9C1AD44B for ; Thu, 30 Oct 2014 07:48:50 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 624FF20B58 for ; Thu, 30 Oct 2014 10:48:49 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 30 Oct 2014 10:48:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=jFOtAAM9ySZTrTWOv6UpvXgH+Tw=; b=YhvPrN97DU5MBohpuqRkM laQbT8aFH26fGduDOkwJEAum6amA0vM9iWNjwqc7S/+SV3HoTnvepfypF1EUlbRu rW4G2q9jxxHfZTUcIZG3jvhVtrvpuTpuVuR4gVdZuQ0aXXsivnjN1CzA5QVHVJnQ WR6XAtdYUlcLSUcePZKR7U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=jFOtAAM9ySZTrTWOv6UpvXg H+Tw=; b=No6qInLV5DYVeG44OXhm3x6cdUKzk3P20PW/ePbv0QIbU3FFWh2xylc igEptiSsTZEC0DFpJ/dCymOOZLj8CZ3VrmnKMOsxYvzlSaIWi7Pu14zuMQ2rrtdk bULofKHoWZ8qeCtDbDveCPwoIEkJMrjPhTMNPHwpzkD6HkhHoduY= X-Sasl-enc: aSJmq7Tx7DFndpjU9HW6uAjPPWUfMLNxujdwBvsvkAkn 1414680528 Received: from sjc-vpn6-1922.cisco.com (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id 93E736800F5; Thu, 30 Oct 2014 10:48:48 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <20141029182032.56782.qmail@ary.lan> Date: Thu, 30 Oct 2014 07:48:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141029182032.56782.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/53aXv2iGpekgn4FFs2DCHmhgbqI Cc: weirds@ietf.org, IESG Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:48:58 -0000 On Oct 29, 2014, at 11:20 AM, John Levine wrote: >>> TLS. I'm especially curious about this since clients are required to >>> support HTTPS anyway. >>=20 >> The current text is a reflection of operational possibilities in >> which the server operator does not support queries that could return >> PII. I don't believe we had WG support for requiring HTTPS in such >> situations. Do we need to mandate TLS for all servers? >=20 > One of my early bootstrap proposals was https only, and people said > no, don't do that. Even though everyone supports https, the wide > variation in CAs and ciphers makes interop failures surprisingly > common. For example, imagine a ccTLD that uses a cert signed by an > authority that is widely used in its own country, and unknown > elsewhere. >=20 I think Scott=92s answer points in the direction where I'm thinking this = should go, which is to require use of TLS for entity queries but perhaps = not for other queries. That seems to me like a more balanced approach = than saying that the possibility of interop failure (or a load problem, = per Andy=92s response to Stephen) negates the need for any sort of = confidentiality requirement in all cases. Servers that cannot support = TLS can then still support a more limited set of queries. > Also keep in mind that not all URLS start with http or https. For a > small provider handling what would currently be SWIPs, it might well > be easier to use ftp. I don=92t understand this comment since I thought RDAP requires servers = to support HTTP. Alissa >=20 > R's, > John >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Thu Oct 30 08:00:20 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F76D1AC41B for ; Thu, 30 Oct 2014 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm4fihA-i7uf for ; Thu, 30 Oct 2014 08:00:17 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000711AD36B for ; Thu, 30 Oct 2014 07:59:45 -0700 (PDT) Received: (qmail 39795 invoked from network); 30 Oct 2014 14:59:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9b72.54525260.k1410; bh=S9GihsjQMaSgNujtisWBCVZFFNfkUWizCFW75U84rmY=; b=C1afLBw/nwyC0eHOrG+aIVeDosKOK2n4th+GimR7IhSFgpn4IF3xgiCyPYhZjj8DLJN1HQd5XHRTFJY4wuUEUEKyMJ8dzHa3FaSkJ+zpZ/HHkaL+gmvOoEuiHUyHrWFGl+ctvLTOhFOMTI8wtZhz6sFnHpYTblgGTEYz6P/tumSZK+OgjTV709q1/KSaDBrAylxudHUYbq57keH00I2X7bWZVCO8VE+u2N8UXtntJVIH8Rg6ArIdSj1z+fU2D53A DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9b72.54525260.k1410; bh=S9GihsjQMaSgNujtisWBCVZFFNfkUWizCFW75U84rmY=; b=hHO6JRX2cqsNO+CFWkZZCmuysYhtqPa4oQRm1riQKdYVRbDyx8tiwXTngm8PXK/GPVq56+yM7sCVZoOt7sgIiiGIrybJR8fAIiOSj8Y4dB71fTLk57BKO9o0jpirM7G66mDD3cwQUpoz4KaFDnngCKSi78K/eZwY7VVrYbUtD4zjyjgBKwMkS7iQ2S925CczlW0E1kmCE+yJLh//XXpfZ9hTqEMg5XiRIp7VqU1V1mn62rQGiEaEhifsTBi6Pcl8 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 30 Oct 2014 14:59:44 -0000 Date: 30 Oct 2014 10:59:44 -0400 Message-ID: From: "John R Levine" To: "Alissa Cooper" In-Reply-To: References: <20141029182032.56782.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-191545719-1414681184=:8790" Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/9DljeXCMoEHVcKjwQnocKNd5J0M Cc: weirds@ietf.org, IESG Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:00:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-191545719-1414681184=:8790 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > I think Scott’s answer points in the direction where I'm thinking this > should go, which is to require use of TLS for entity queries but perhaps > not for other queries. ... But there's no particular reason to expect that an entity query will return PII any more than any other query. Ask about one of the entities for, say, ibm.com and you'll just get some role account. Ask anything about someone's vanity domain, entity or not, and it's all PII. > I don’t understand this comment since I thought RDAP requires servers to support HTTP. Nope. The bootstrap is http, but the URLs it points to or that other servers redirect to can be anything. Speaking as one of the world's smallest registries (if you want a watkins-glen.ny.us domain, you know who to ask), sticking a few things on anonymous FTP would be pretty easy. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. --0-191545719-1414681184=:8790-- From nobody Thu Oct 30 08:06:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFDB1AD460; Thu, 30 Oct 2014 08:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVUeQ8cVRnbf; Thu, 30 Oct 2014 08:06:19 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 542F21AD45F; Thu, 30 Oct 2014 08:06:14 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 0D9221650ED; Thu, 30 Oct 2014 11:06:14 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 5115D1650E7; Thu, 30 Oct 2014 11:06:13 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 11:08:35 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Thu, 30 Oct 2014 11:06:12 -0400 From: Andy Newton To: Scott Hollenbeck Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) Thread-Index: AQHP8wTl04TaTfEJpEevEZPfqIUblJxHTuEAgAF72oCAAAVAAIAAMx8A Date: Thu, 30 Oct 2014 15:06:12 +0000 Message-ID: <4F2AB5CC-2AB7-4D42-8DD9-312CD3490C12@arin.net> References: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <395E6D17-B800-4589-8A23-249BAE6711BD@arin.net> <831693C2CDA2E849A7D7A712B24E257F49509564@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49509564@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: multipart/alternative; boundary="_000_4F2AB5CC2AB74D428DD9312CD3490C12arinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/T-_2BePiTLd_HOMzmwKGJVDz_6s Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:06:31 -0000 --_000_4F2AB5CC2AB74D428DD9312CD3490C12arinnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 30, 2014, at 8:03 AM, Hollenbeck, Scott > wrote: OLD "where XXXX is a search pattern representing an entity name as specified in= Section 6.1 of [I-D.ietf-weirds-json-response]" NEW "where XXXX is a search pattern representing an entity (such as a contact, = registrant, or registrar) identifier whose syntax is specific to the regist= ration provider" Scott, I am confused. One is a search by handle and the other a search by a= person or organization=92s name. Doesn=92t this eliminate the name search? [SAH] I thought the comment had to do with lookups by entity handle (3.1.5)= and searches by entity handle (3.2.3). The text in the two sections descri= bes handle syntax inconsistently. That=92s what I attempted to correct. So the old is? where XXXX is a search pattern representing an entity handle as specified in Section 6.1 ... Note s/handle/name/. If so, I get it. -andy --_000_4F2AB5CC2AB74D428DD9312CD3490C12arinnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6DF706A4001DED4BB89BBCF2CC1227FB@corp.arin.net> Content-Transfer-Encoding: quoted-printable
On Oct 30, 2014, at 8:03 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

OLD
"where XXXX is a search pattern repres= enting an entity name as specified in Section 6.1 of [I-D.ietf-weirds-json-= response]"

NEW
"where XXXX is a search pattern representing an entity (such as a cont= act, registrant, or registrar) identifier whose syntax is specific to the r= egistration provider"
 
Scott, I am confused. One is a search by handle and the other a search by a= person or organization=92s name. Doesn=92t this eliminate the name search?=
 
= [SAH] I thought the comment had to do with lookups by entity handle (3.1.5)= and searches by entity handle (3.2.3). The text in the two sections descri= bes handle syntax inconsistently. That=92s what I attempted to correct.

So the old is?

  where XXXX is a search pattern representing an entity handle as=
  specified in Section 6.1 ...

Note s/handle/name/.

If so, I get it.

-andy
--_000_4F2AB5CC2AB74D428DD9312CD3490C12arinnet_-- From nobody Thu Oct 30 08:08:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E681AD434; Thu, 30 Oct 2014 08:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXQm_YhVrjnS; Thu, 30 Oct 2014 08:08:10 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E25F1AD485; Thu, 30 Oct 2014 08:07:30 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 6AFD5DA023F; Thu, 30 Oct 2014 15:10:49 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 32EEC53E084; Thu, 30 Oct 2014 08:07:00 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 30 Oct 2014 08:06:59 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4950987F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 30 Oct 2014 11:06:49 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F4950987F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/mOHTuDpQAwQ26aSYdxby812n7oU Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:08:13 -0000 On Oct 30, 2014, at 9:50 AM, Hollenbeck, Scott = wrote: > "A client typically does not know in advance if a server requires = client authentication to process a query. If a client sends a request = for a query that can be processed without authentication information, a = server can return an RDAP response consistent with local policies for = unauthenticated access. If authentication is required, a server MUST = return an HTTP 401 (Unauthorized) response to challenge the = authorization of a user agent. The authentication process can then = proceed as described in Section 2 of RFC 7235 [RFC7235]." No, that's how it works today. The problem is that this doesn't = address the use case where a client without credentials gets an answer, = just not the same answer as it would have got if it had credentials. = There's no programmatic way to advise the client that it would benefit = from sending credentials without completely denying access for clients = that don't have credentials to send. And if you notify the user out of = band, there's still no protocol mechanism for providing credentials if = you don't get an error code from the HTTP server. The client could = just supply them pre-emptively, but if you want clients to do that, you = need to say so, and explain how to do it. From nobody Thu Oct 30 08:16:05 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16A81AD4CD; Thu, 30 Oct 2014 08:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHdHySwEoVMx; Thu, 30 Oct 2014 08:15:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 079481AD496; Thu, 30 Oct 2014 08:15:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030151507.16788.11438.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 08:15:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/eSZ-6DGkCtaArms69P4-qx6RbVk Cc: weirds@ietf.org, weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, suresh.krishnan@ericsson.com Subject: [weirds] Jari Arkko's Yes on draft-ietf-weirds-bootstrap-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:16:00 -0000 Jari Arkko has entered the following ballot position for draft-ietf-weirds-bootstrap-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Discuss cleared in favour of Barry's Discuss which covers the same thing. A few other comments: Everyone should be aware though that we are creating a live database that would be queried by software, not by implementors. Anyway, I think that is fine. Suresh Krishnan had this comment in his Gen-ART review: * Sections 5.2 and 5.3 -> The document uses some non-documentation addresses (AFAIK) in some of the examples. e.g. 28.2.0.0/16 for an IPv4 prefix and 2600::/16 for an IPv6 prefix. Is it possible to rewrite these examples using reserved documentation addresses? Strangely enough, idnits does not seem to catch them either. From nobody Thu Oct 30 08:16:58 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA301AD486; Thu, 30 Oct 2014 08:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FkRWcjrdEt8; Thu, 30 Oct 2014 08:16:31 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF811AD4AE; Thu, 30 Oct 2014 08:16:19 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 30 Oct 2014 08:16:17 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Thu, 30 Oct 2014 08:16:17 -0700 From: Edward Lewis To: Kathleen Moriarty , The IESG Thread-Topic: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) Thread-Index: AQHP88V3Eu/ymyeeqUSsqrFDWkP4tJxI86MA Date: Thu, 30 Oct 2014 15:16:16 +0000 Message-ID: References: <20141029214342.30884.77333.idtracker@ietfa.amsl.com> In-Reply-To: <20141029214342.30884.77333.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3497512574_10703757" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/iw9h6LZke8TrDpIYLEj9S41qWW8 Cc: "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:16:38 -0000 --B_3497512574_10703757 Content-type: multipart/alternative; boundary="B_3497512574_10641996" --B_3497512574_10641996 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99m concerned that this discuss is trying to place policy into the protoc= ol. I=E2=80=99m not convinced it is, but I want to say something now rather than wait= . At a recent ICANN meeting there was a presentation of the coming RDAP protocol and how it is a candidate to replace WhoIs. One of the =E2=80=9Cselling points=E2=80=9D is that RDAP can support different policy settings, as opposed to WhoIs which, though it=E2=80=99s simplicity supports just the one default policy. The current text suggests status codes, which is fine. Going beyond that t= o =E2=80=9CRECOMMEND=E2=80=9D actions in response to the codes is too far for me because = it is not clear to me how this would enhance interoperability of implementations while at the same time, =E2=80=9Ccementing=E2=80=9D the status codes as having meaning. Perhaps the document can mention that codes and their meanings need to be defined, but I think being so detailed as this list is too far down the pat= h of pressing an assumed policy into the protocol. From: Kathleen Moriarty Date: Wednesday, October 29, 2014 at 17:43 To: The IESG Cc: "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) > Kathleen Moriarty has entered the following ballot position for > draft-ietf-weirds-json-response-11: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for your work on this draft and including options for privacy > protections. I do support Alissa's discuss on the -sec draft and as > such, my discuss here is specific to this draft and values set forth in > it for privacy. The general security and privacy considerations would be > good to reference from one place. >=20 > I think it would help to have the explicit guidance or recommendations > for privacy included directly in the privacy section. While the example > in the appendix is good, I'd prefer to see explicit recommendations for > each of the relevant status codes from section 10.2.2. How about > something along the lines of the following: >=20 > Current Privacy Considerations section: > This specification suggests status values to denote contact and > registrant information that has been marked as private and/or has > been redacted or obscured. See Section 10.2.2 for the list of status > values. See Appendix A.1 on guidance to apply those values to > contacts and registrants. >=20 > Suggested Privacy Considerations section: > This specification suggests status values to denote contact and > registrant information that has been marked as private and/or has > been redacted or obscured. See Section 10.2.2 for the complete list > of status > values. A few of the status values indicate that there are privacy > concerns associated with the object instance. For the following > status > codes, the RECOMMENDED actions include: > 7. private - The object is not be shared in query responses, unless > the > user is authorized to view this information. > 8. redacted - The data has already been redacted, and may be > returned > in a response in the data redacted form. This is a safer > option to choose > to prevent unauthorized access to associated object instances > than marking > them as private. > 9. obscured - The data has already been obscured, and may be > returned in a > response in the obscured form. This option may reveal privacy > sensitive > information and should only be used when data sensitivity does > not require > a more protective option like "private" or "redacted". >=20 > See Appendix A.1 or an example applying those values to > contacts and registrants. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for addressing the SecDir review and including information on a > possible cache poisoning attack. > http://www.ietf.org/mail-archive/web/secdir/current/msg05183.html > Some nits were included as well that might be helpful. >=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds >=20 --B_3497512574_10641996 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
I’m concerned that this= discuss is trying to place policy into the protocol.  I’m not co= nvinced it is, but I want to say something now rather than wait.
<= br>
At a recent ICANN meeting there was a presentation of the comi= ng RDAP protocol and how it is a candidate to replace WhoIs.  One of th= e “selling points” is that RDAP can support different policy set= tings, as opposed to WhoIs which, though it’s simplicity supports just= the one default policy.

The current text suggests = status codes, which is fine.  Going beyond that to “RECOMMENDR= 21; actions in response to the codes is too far for me because it is not cle= ar to me how this would enhance interoperability of implementations while at= the same time, “cementing” the status codes as having meaning. =  Perhaps the document can mention that codes and their meanings need to= be defined, but I think being so detailed as this list is too far down the = path of pressing an assumed policy into the protocol.

From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>=
Date: Wednesday, October 29, 2014= at 17:43
To: The IESG <iesg@ietf.org>
Cc: "weirds-chairs= @tools.ietf.org" <weird= s-chairs@tools.ietf.org>, "weirds@ie= tf.org" <weirds@ietf.org>, "<= a href=3D"mailto:draft-ietf-weirds-json-response@tools.ietf.org">draft-ietf-we= irds-json-response@tools.ietf.org" <draft-ietf-weirds-json-response@tools.ietf.or= g>
Subject: [weirds] Kathle= en Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS a= nd COMMENT)

Kathleen Moriarty has entered the following ballot pos= ition for
draft-ietf-weirds-json-response-11: Discuss
When responding, please keep the subject line intact and reply = to all
email addresses included in the To and CC lines. (Feel free= to cut this
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT p= ositions.


The document, along with o= ther ballot positions, can be found here:



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

Thanks fo= r your work on this draft and including options for privacy
protec= tions.  I do support Alissa's discuss on the -sec draft and as
such, my discuss here is specific to this draft and values set forth = in
it for privacy.  The general security and privacy con= siderations would be
good to reference from one place.
<= br>
I think it would help to have the explicit guidance or recomme= ndations
for privacy included directly in the privacy section.&nbs= p; While the example
in the appendix is good, I'd prefer to s= ee explicit recommendations for
each of the relevant status codes = from section 10.2.2.  How about
something along the line= s of the following:

Current Privacy Considerations = section:
   This specification suggests status values to= denote contact and
   registrant information that has b= een marked as private and/or has
   been redacted or obs= cured.  See Section 10.2.2 for the list of status
 =   values.  See Appendix A.1 on guidance to apply those values= to
   contacts and registrants.

Suggested Privacy Considerations section:
   This spec= ification suggests status values to denote contact and
  = ; registrant information that has been marked as private and/or has
   been redacted or obscured.  See Section 10.2.2 for = the complete list
of status
   values. &n= bsp;A few of the status values indicate that there are privacy
&nb= sp;  concerns associated with the object instance.  For the f= ollowing
status
   codes, the RECOMMENDED acti= ons include:
      7. private - The = object is not be shared in query responses, unless
the
&= nbsp;         user is authorize= d to view this information.
      8.= redacted - The data has already been redacted, and may be
returne= d
          in a= response in the data redacted form.  This is a safer
op= tion to choose
        &nb= sp; to prevent unauthorized access to associated object instances
=
than marking
        =   them as private.
      9= . obscured - The data has already been obscured, and may be
return= ed in a
         &nbs= p;response in the obscured form.  This option may reveal privacy
sensitive
        = ;  information and should only be used when data sensitivity does<= /div>
not require
       &n= bsp;  a more protective option like "private" or "redacted".
=

   See Appendix A.1 or an example applying tho= se values to
   contacts and registrants.

=

--------------------------------------------------= --------------------
COMMENT:
--------------------------= --------------------------------------------

Thanks= for addressing the SecDir review and including information on a
p= ossible cache poisoning attack.
Some nits were included as wel= l that might be helpful.


___________= ____________________________________
weirds mailing list
weirds@ietf.org

<= /html> --B_3497512574_10641996-- --B_3497512574_10703757 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBR3D8q1mpQkQI/yqS6e 0U5UdcRpXjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MzAxNTE2MTRaMA0GCSqGSIb3DQEBAQUABIIBAEKTV7QD59cJZcyfM769QXDp/lwLg39ZNrGV 5uTQLF325RDquA1QS/H8VWSmvbLzYz5k6NMiF8wteBJ86zAcNXs6Qgcu5pd6vIUDVHiVmvE0 sPCHWSS3a9abmd2KW/3KcYUECZrfl+cY/3koUuZo1Eaz8n5CFdQPVWRuRQB2LF9hcwBmpToq 0cpOCQpxgEDZnbuzJCsvzSd6+2IOmJyjeoVVpYtsRm51MG8jfM0vrPicYjxQTPS6xnXHrYo2 UsrSx4gh4fCGMMi5RAdSD3m1/LTdrpXD+O2Sp8saad4GRa3e4fNjs9thdAsyJ0jSjMklvNNM Nwp7nw9M/XOLTuE/4KQ= --B_3497512574_10703757-- From nobody Thu Oct 30 08:22:47 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D951AD4EE; Thu, 30 Oct 2014 08:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XRH36mLPz5S; Thu, 30 Oct 2014 08:22:26 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 925001AD505; Thu, 30 Oct 2014 08:22:07 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 4E7FE2137E5; Thu, 30 Oct 2014 11:22:07 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 805852137E3; Thu, 30 Oct 2014 11:22:06 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 11:24:46 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Thu, 30 Oct 2014 11:22:05 -0400 From: Andy Newton To: John R Levine , Alissa Cooper Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) Thread-Index: AQHP8wUfAbyOxJO9lUm9pJSTJUWYk5xHcAgAgAA3CACAAVctAIAAAw4AgAAGPoA= Date: Thu, 30 Oct 2014 15:22:05 +0000 Message-ID: <22FC776A-56E9-4FB0-9419-02543C2049E6@arin.net> References: <20141029182032.56782.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: <209AFE0503FB8A47B2BDF8F7CAA8E6B4@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/VqPQtTeyxCNqIYDn8-9Ey5DcW38 Cc: "weirds@ietf.org" , IESG Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:22:36 -0000 On Oct 30, 2014, at 10:59 AM, John R Levine wrote: >> I think Scott=92s answer points in the direction where I'm thinking this= should go, which is to require use of TLS for entity queries but perhaps n= ot for other queries. ... >=20 > But there's no particular reason to expect that an entity query will retu= rn PII any more than any other query. Ask about one of the entities for, s= ay, ibm.com and you'll just get some role account. Ask anything about some= one's vanity domain, entity or not, and it's all PII. More to the point, lookups for networks and domains (which is ~99% of all q= ueries today) will have entities embedded in them. MUST HTTPS for entities = would work for thin domain registries but not for anybody else. >> I don=92t understand this comment since I thought RDAP requires servers = to support HTTP. >=20 > Nope. The bootstrap is http, but the URLs it points to or that other ser= vers redirect to can be anything. Speaking as one of the world's smallest = registries (if you want a watkins-glen.ny.us domain, you know who to ask), = sticking a few things on anonymous FTP would be pretty easy. Ummm=85 what? No, I don=92t think that would work. Additionally, the bootst= rap doc mentions RDAP URLs. Maybe that isn=92t specific enough, but RDAP is= not specified over anything other than HTTP(S). -andy= From nobody Thu Oct 30 08:24:11 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAB81AD49C; Thu, 30 Oct 2014 08:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaC7BuZ9eA_i; Thu, 30 Oct 2014 08:24:01 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B091AD034; Thu, 30 Oct 2014 08:23:35 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKVFJX9DNZxCwwwZid4WU/xeiA6aQ0d3Nh@postini.com; Thu, 30 Oct 2014 08:23:38 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9UFNVPd030969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 11:23:31 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 11:23:20 -0400 From: "Hollenbeck, Scott" To: Andy Newton Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) Thread-Index: AQHP8wThqQazUPVAGEi2/UP5B6hs2JxHTuEAgAF72oCAAAVAAIAAMx8A//+9mDA= Date: Thu, 30 Oct 2014 15:23:30 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49509C3C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141028231403.6992.74962.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F495080C1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <395E6D17-B800-4589-8A23-249BAE6711BD@arin.net> <831693C2CDA2E849A7D7A712B24E257F49509564@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <4F2AB5CC-2AB7-4D42-8DD9-312CD3490C12@arin.net> In-Reply-To: <4F2AB5CC-2AB7-4D42-8DD9-312CD3490C12@arin.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_831693C2CDA2E849A7D7A712B24E257F49509C3CBRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/HLcGvPA7SjUUh_LT_9IsvXSD5HM Cc: "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:24:08 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F49509C3CBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Andy Newton [mailto:andy@arin.net] Sent: Thursday, October 30, 2014 11:06 AM To: Hollenbeck, Scott Cc: Alissa Cooper; The IESG; weirds-chairs@tools.ietf.org; weirds@ietf.org;= draft-ietf-weirds-rdap-query@tools.ietf.org Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-que= ry-16: (with DISCUSS and COMMENT) On Oct 30, 2014, at 8:03 AM, Hollenbeck, Scott > wrote: OLD "where XXXX is a search pattern representing an entity name as specified in= Section 6.1 of [I-D.ietf-weirds-json-response]" NEW "where XXXX is a search pattern representing an entity (such as a contact, = registrant, or registrar) identifier whose syntax is specific to the regist= ration provider" Scott, I am confused. One is a search by handle and the other a search by a= person or organization's name. Doesn't this eliminate the name search? [SAH] I thought the comment had to do with lookups by entity handle (3.1.5)= and searches by entity handle (3.2.3). The text in the two sections descri= bes handle syntax inconsistently. That's what I attempted to correct. So the old is? where XXXX is a search pattern representing an entity handle as specified in Section 6.1 ... Note s/handle/name/. If so, I get it. -andy [SAH] Ah, OK, yes, it would be better to say "entity handle" in the two pla= ces where we're talking about handles. 3.2.3 also describes search by entit= y name. I see what broke here... The text in 3.2.2 that describes a search by entity name refers to what use= d to be in Section 6.1 of json-response. The old text isn't there anymore. = What we want now is described in 5.1, but it's now part of the vcard in the= vcardArray. We need to refer to either the FN property or the N property. = I *think* FN is more appropriate - right? --_000_831693C2CDA2E849A7D7A712B24E257F49509C3CBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Andy New= ton [mailto:andy@arin.net]
Sent: Thursday, October 30, 2014 11:06 AM
To: Hollenbeck, Scott
Cc: Alissa Cooper; The IESG; weirds-chairs@tools.ietf.org; weirds@ie= tf.org; draft-ietf-weirds-rdap-query@tools.ietf.org
Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-r= dap-query-16: (with DISCUSS and COMMENT)

 

 

On Oct 30, 2014, at 8:03 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">shollenbeck@verisign.com>= wrote:



OLD

"where XXXX is = a search pattern representing an entity name as specified in Section 6.1 of= [I-D.ietf-weirds-json-response]"

NEW
"where XXXX is a search pattern representing an entity (such as a cont= act, registrant, or registrar) identifier whose syntax is specific to the r= egistration provider"

 

Scott, I am confused. One is a search by handle and = the other a search by a person or organization’s name. Doesn’t = this eliminate the name search?

 

[SAH] I thought the comment had to do with= lookups by entity handle (3.1.5) and searches by entity handle (3.2.3). Th= e text in the two sections describes handle syntax inconsistently. That’s what I attempted to correct.

 

So the old is?

 

  where XXXX is a search pattern representing a= n entity handle as

  specified in Section 6.1 ...

 

Note s/handle/name/.

 

If so, I get it.

 

-andy

[SAH] Ah, OK, yes, it would be better to s= ay “entity handle” in the two places where we’re talking = about handles. 3.2.3 also describes search by entity name. I see what broke here…

 

The text in 3.2.2 that describes a search = by entity name refers to what used to be in Section 6.1 of json-response. T= he old text isn’t there anymore. What we want now is described in 5.1, but it’s now part of the vcard in the vcardArray. We need to= refer to either the FN property or the N property. I *think* FN is = more appropriate – right?

--_000_831693C2CDA2E849A7D7A712B24E257F49509C3CBRN1WNEXMBX01vc_-- From nobody Thu Oct 30 08:29:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8A01A01D6; Thu, 30 Oct 2014 08:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vZTAiqqVimI; Thu, 30 Oct 2014 08:29:37 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD8D1AD4EA; Thu, 30 Oct 2014 08:28:53 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 30 Oct 2014 08:28:51 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Thu, 30 Oct 2014 08:28:51 -0700 From: Edward Lewis To: Stephen Farrell , The IESG Thread-Topic: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-json-response-11: (with COMMENT) Thread-Index: AQHP9EgsWGJEFOswwkuFU98J+A73tJxI9iGA Date: Thu, 30 Oct 2014 15:28:51 +0000 Message-ID: References: <20141030134742.16217.19224.idtracker@ietfa.amsl.com> In-Reply-To: <20141030134742.16217.19224.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3497513329_10686713" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/gQhO1bbhNjUyrdeqiEgC0Ojg7TE Cc: "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-json-response-11: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:29:39 -0000 --B_3497513329_10686713 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable From: Stephen Farrell Date: Thursday, October 30, 2014 at 9:47 To: The IESG Cc: "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-json-response-11: (with COMMENT) >- I think it would have been a fine thing had the WG decided to >do a more comprehensive privacy analysis of RDAP but I don't >see that in this document set at least. I do like Kathleen's >suggested text better than that currently in the privacy >considerations section though. I objected to that in another response. There will be many use cases for RDAP in many different privacy environments. It=E2=80=99s best that the protocol is able to accommodate the various environments in an interoperable way and *not*, as WhoIs does by default, impose one particular model. The data being held in registration databases is largely under the oversight of a few and significantly separate organizations. Privacy is a topic/issue broadly considered. (I can=E2=80=99t speak for all organizations and environments, but I have worked in various segments of internet registration operations and have come across this issue in all where I=E2=80=99ve worked.) >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds --B_3497513329_10686713 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTn8Ez514YiudPMJFLo fj5EIt6E8zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MzAxNTI4NDlaMA0GCSqGSIb3DQEBAQUABIIBAKePI/REXbzthtufgYx6p5wRaiPvV12fcd8W BmiFTDJGz+TOGlOdoL4M6jdDFQZv6IMUXC6hKZWFwYPza+xVf0HNtINiL1FDOKwItbEUES0U c9PrAIbgTAFX98Y5HfqjSfPzS/pE8H1itM6Dw1oxressM5wVBpPxXaaUWm4D0RlcIXeVij8O tm2Z2dd1LeZICMZzOE0V3LwfKd8gj4Cn0lFOMBAmM0QomE4m00Sr90l6fmc30Ivoozr/r24x 7pUWhNzp9+sjhXuU1jQeZwK0C1Gele279tlztUMojAwDqhMLXrmq/2AcQn0LG7PLvEVFuWo8 TDRmx6zfFas4rcDH7mE= --B_3497513329_10686713-- From nobody Thu Oct 30 08:53:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1E41AD4E5 for ; Thu, 30 Oct 2014 08:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIG9zukswz6i for ; Thu, 30 Oct 2014 08:53:13 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2FB1A0233 for ; Thu, 30 Oct 2014 08:53:11 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ij19so2834219vcb.24 for ; Thu, 30 Oct 2014 08:53:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TOCMsbOwdIt7P9dStLgOvCm7MMpL47WS/7ekUj6b2LA=; b=gNsys5+mjjOfqSuVAbHYLeGC8cb/5m6wRs9zwSFT5QaJ5Zk1SlXOyZzCGDE0JUg9eR FQlMRF6CUHM4PsjaoqF2d4kfinxyPp+D3gr+bqJyfaEELiVFQL15nQx6VWhoySY3uYGN ud8ziPdl1Zo4cX1+knL1oTXzYphcTAPZmkhV5E/WZHuo66MyjNZndMVjbRkDOTAP2hQE FuuvRaH7V0mk7ve3uQAdld2kG/h1PVDgHWZc9A6IIWyfBxtE2A1PuWxW0yDHwZ3vyRgC CtCsOAAakCUQ7oC88SXUKEvsb9xPS6QQpXgUjAp2O80q2bRg5bH3GFbVWOJv6tej59cv QIAA== X-Gm-Message-State: ALoCoQmkCjTn/eibBxz37V3gfM8jZgLVDgbPb0ugjL/oEXfhWIQA8tiLXIyovwPehXGv7s9rfnXP MIME-Version: 1.0 X-Received: by 10.52.135.35 with SMTP id pp3mr503919vdb.54.1414684389895; Thu, 30 Oct 2014 08:53:09 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Thu, 30 Oct 2014 08:53:09 -0700 (PDT) In-Reply-To: <107E1EEF-9EAA-4A81-9DDE-C6CBB3C6E6E6@nominum.com> References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> <107E1EEF-9EAA-4A81-9DDE-C6CBB3C6E6E6@nominum.com> Date: Thu, 30 Oct 2014 08:53:09 -0700 Message-ID: From: Richard Barnes To: Ted Lemon Content-Type: multipart/alternative; boundary=bcaec52d4e538783be0506a5e08c Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/BmU0cEgx0LY45OTbkENlrnwooYk Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , weirds@ietf.org Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:53:15 -0000 --bcaec52d4e538783be0506a5e08c Content-Type: text/plain; charset=UTF-8 On Thu, Oct 30, 2014 at 5:33 AM, Ted Lemon wrote: > On Oct 30, 2014, at 3:39 AM, Richard Barnes wrote: > > This is a feature request, not a DISCUSS. > > > > There are bazillions of HTTP servers out there today that get by just > fine with a binary, per-resource distinction between authorized and > unauthorized. And I can see situations where that would make sense here > too. For example, a server might not grant access to entity records > without authorization. > > No, this isn't correct. If you look at the base spec, it's clear that > some queries may get one answer if authenticated, and a different answer if > not authenticated. That's not something that HTTP authentication supports > without tweaks, so the security document needs to describe those tweaks. > The security document currently appears to be claiming to address this use > case, but it clearly doesn't. Hence the DISCUSS. > Your assertions here are obviously false. Consider, for example: https://tools.ietf.org/wg/weirds/trac/wiki It presents different content depending on whether the client is authenticated or not. If you are unauthenticated, you see the "login" link. If you are authenticated, it says "logged in as ...", and shows more options. Different content depending on authentication state. > One way to address the DISCUSS would be to say "this security model does > not support one of the use cases described in the base spec: returning > different answers depending on whether or not the client has > authenticated. A mechanism for addressing this is left as future work." > I think that would be unfortunate, but it would resolve the DISCUSS Returning different answers is fully supported, just like for the example above. The only thing that's missing is a hint to the client that it should authenticate which is clearly a nice-to-have, not a requirement. --Richard --bcaec52d4e538783be0506a5e08c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 30, 2014 at 5:33 AM, Ted Lemon <Ted.Lemon@nominum.com<= /a>> wrote:
= On Oct 30, 2014, at 3:39 AM, Richard Barnes <rlb@ipv.sx= > wrote:
> This is a feature request, not a DISCUSS.
>
> There are bazillions of HTTP servers out there today that get by just = fine with a binary, per-resource distinction between authorized and unautho= rized.=C2=A0 And I can see situations where that would make sense here too.= =C2=A0 For example, a server might not grant access to entity records witho= ut authorization.

No, this isn't correct.=C2=A0 =C2=A0If you look at the base spec= , it's clear that some queries may get one answer if authenticated, and= a different answer if not authenticated.=C2=A0 =C2=A0That's not someth= ing that HTTP authentication supports without tweaks, so the security docum= ent needs to describe those tweaks.=C2=A0 =C2=A0The security document curre= ntly appears to be claiming to address this use case, but it clearly doesn&= #39;t.=C2=A0 =C2=A0Hence the DISCUSS.

Y= our assertions here are obviously false.=C2=A0 Consider, for example:
= =C2=A0 https://tools= .ietf.org/wg/weirds/trac/wiki

It presents different content depe= nding on whether the client is authenticated or not.=C2=A0 If you are unaut= henticated, you see the "login" link.=C2=A0 If you are authentica= ted, it says "logged in as ...", and shows more options.=C2=A0 Di= fferent content depending on authentication state.

=C2=A0=
One way to address the DISCUSS would be to say "this security model do= es not support one of the use cases described in the base spec: returning d= ifferent answers depending on whether or not the client has authenticated.= =C2=A0 =C2=A0A mechanism for addressing this is left as future work."= =C2=A0 =C2=A0I think that would be unfortunate, but it would resolve the DI= SCUSS

Returning different answers is fully = supported, just like for the example above.=C2=A0 The only thing that's= missing is a hint to the client that it should authenticate which is clear= ly a nice-to-have, not a requirement.

--Richard
--bcaec52d4e538783be0506a5e08c-- From nobody Thu Oct 30 08:54:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5701AD4F4; Thu, 30 Oct 2014 08:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejr4eWNTdpVk; Thu, 30 Oct 2014 08:53:55 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2038F1AD4E5; Thu, 30 Oct 2014 08:53:39 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKVFJfAmf/SS9Gr0R7DWollCifSa2GepNH@postini.com; Thu, 30 Oct 2014 08:53:41 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9UFrbHn002233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 11:53:37 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 11:53:36 -0400 From: "Hollenbeck, Scott" To: Ted Lemon Thread-Topic: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) Thread-Index: AQHP9FMpg2W8ta9wgkqAhRJ6fc4Gl5xIwwoA Date: Thu, 30 Oct 2014 15:53:36 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49509D27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F4950987F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/HJuMHPcbkCRNQqcI8-65PPnkr4Q Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:54:04 -0000 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Thursday, October 30, 2014 11:07 AM > To: Hollenbeck, Scott > Cc: The IESG; draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > chairs@tools.ietf.org; weirds@ietf.org > Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap- > sec-10: (with DISCUSS) >=20 > On Oct 30, 2014, at 9:50 AM, Hollenbeck, Scott > wrote: > > "A client typically does not know in advance if a server requires > client authentication to process a query. If a client sends a request > for a query that can be processed without authentication information, a > server can return an RDAP response consistent with local policies for > unauthenticated access. If authentication is required, a server MUST > return an HTTP 401 (Unauthorized) response to challenge the > authorization of a user agent. The authentication process can then > proceed as described in Section 2 of RFC 7235 [RFC7235]." >=20 > No, that's how it works today. The problem is that this doesn't > address the use case where a client without credentials gets an answer, > just not the same answer as it would have got if it had credentials. > There's no programmatic way to advise the client that it would benefit > from sending credentials without completely denying access for clients > that don't have credentials to send. Yes, there is. The json-response document describes status values (section = 10.2.2) to indicate that a response element is private, redacted, or obscur= ed. If I'm a client and I see those status values in a response I know that= I might benefit (receive more information) by sending credentials. Which l= eads us to... > And if you notify the user out > of band, there's still no protocol mechanism for providing credentials > if you don't get an error code from the HTTP server. The client could > just supply them pre-emptively, but if you want clients to do that, you > need to say so, and explain how to do it. We're not suggesting out of band notification or non-standard HTTP behavior= . RFC 2617 says "A client MAY preemptively send the corresponding Authoriza= tion header with requests for resources in that space without receipt of an= other challenge from the server". This text doesn't appear in RFC 7235, whi= ch now says "The "Authorization" header field allows a user agent to authen= ticate itself with an origin server -- usually, but not necessarily, after = receiving a 401 (Unauthorized) response." Would it be sufficient to add text that refers to the status codes and prov= ides instruction for sending the authorization header to preemptively provi= de credentials? Scott From nobody Thu Oct 30 08:56:05 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E3F1AD4F6 for ; Thu, 30 Oct 2014 08:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYgNDoEFjid1 for ; Thu, 30 Oct 2014 08:55:55 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9DE1AD4ED for ; Thu, 30 Oct 2014 08:55:55 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lf12so740086vcb.2 for ; Thu, 30 Oct 2014 08:55:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u0zCsLXVhMN7U/ULpELSnUcSJVksIOghgxkjVADCSZM=; b=lG2A7ciwLMRpnjfjYO8nFgMeBz4BfdJ1ybyp0+GLNYF0/iYRHVaI5TDKQceAKHELmm 93N6d6I9X3XaCcJxYLNNJL9v1lW1+tGq/I3VR/pni76yiuFxmhXi6wp4MWRV3eDp3dI2 bzk7zNui7ytVdw914vta4Mk813EYhQ3/Klq9gCEebLmFq68w7LlLBHTvI4Xah+A51DXg +Li21AJKpVyq4sDlB2NB9YwOtX+4I94G/sXXrmLgCIUkXIYJiv03OaUYz5yRHO9e8wSC NGXEONw7ztbuQUM/dty9yp5sEq1cwNi07TO1bJMXVhSC+cUFg9Wu+jjDtYHKx1ZrXAcg Ig+A== X-Gm-Message-State: ALoCoQlrIvpGoRPMn9gHrAkBjz8X92pJiXUygs13AqOn3FAqZynMgDmQ+q47mGDRbZWNnxXNc+5N MIME-Version: 1.0 X-Received: by 10.220.143.16 with SMTP id s16mr525331vcu.53.1414684554342; Thu, 30 Oct 2014 08:55:54 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Thu, 30 Oct 2014 08:55:54 -0700 (PDT) In-Reply-To: <5452442D.50901@qti.qualcomm.com> References: <20141030062925.11472.79559.idtracker@ietfa.amsl.com> <5452442D.50901@qti.qualcomm.com> Date: Thu, 30 Oct 2014 08:55:54 -0700 Message-ID: From: Richard Barnes To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7b33db6a54c6060506a5ea28 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/SlGZWhYlfeVkDjM7e526Hdyanz4 Cc: "weirds-chairs@tools.ietf.org" , draft-ietf-weirds-bootstrap@tools.ietf.org, The IESG , weirds@ietf.org Subject: Re: [weirds] Richard Barnes' No Objection on draft-ietf-weirds-bootstrap-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:56:00 -0000 --047d7b33db6a54c6060506a5ea28 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 30, 2014 at 6:59 AM, Pete Resnick wrote: > On 10/29/14 11:29 PM, Richard Barnes wrote: > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> The use of JSON in this syntax is slightly disappointing. Generally, >> using JSON arrays to contain items of different types is not a great >> idea. It seems like the "services" entries should actually be objects, >> with entries indicating the semantics of the inner arrays, e.g.: >> >> OLD: [ ["1.0.0.0/8", "192.0.0.0/8"], ["https://rir1.example.com/myrdap/"] >> ] >> NEW: { "resources": ["1.0.0.0/8", "192.0.0.0/8"], "urls": >> ["https://rir1.example.com/myrdap/"] } >> >> This should not be hard to describe in the notation of Section 10.2, and >> it only uses a few more bytes on the wire. >> >> > > Your faithful Responsible AD made the almost identical comment during AD > Evaluation. The implementation ship had apparently sailed, with > interoperable implementations, and so I decided that rough consensus and > running code outweighed prettiness. > I thought that might be the case. I expect that's the case for my other COMMENT as well. That's why they're COMMENTs :) > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --047d7b33db6a54c6060506a5ea28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 30, 2014 at 6:59 AM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
On 10/29/14 11:29 PM, Richard Barnes wrote:
-------------------------------------------------------------= ---------
COMMENT:
-------------------------------------------------------------= ---------

The use of JSON in this syntax is slightly disappointing.=C2=A0 Generally,<= br> using JSON arrays to contain items of different types is not a great
idea.=C2=A0 It seems like the "services" entries should actually = be objects,
with entries indicating the semantics of the inner arrays, e.g.:

OLD: [ ["1.0.0.0/8&= quot;, "192.0.0.0/8"], ["https://rir1.example.com/myrdap/"]
]
NEW: { "resources": ["1.0.0.0/8", "192.0.0.0/8"], "urls":
["https= ://rir1.example.com/myrdap/"] }

This should not be hard to describe in the notation of Section 10.2, and it only uses a few more bytes on the wire.
=C2=A0 =C2=A0

 Your faithful Responsible AD made the almost identical comment during AD Ev= aluation. The implementation ship had apparently sailed, with interoperable= implementations, and so I decided that rough consensus and running code ou= tweighed prettiness.

I thought that might be the case= .=C2=A0 I expect that's the case for my other COMMENT as well.=C2=A0 Th= at's why they're COMMENTs :)

=C2=A0

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478


--047d7b33db6a54c6060506a5ea28-- From nobody Thu Oct 30 09:07:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D231A001E; Thu, 30 Oct 2014 09:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCAzRtXUscVy; Thu, 30 Oct 2014 09:07:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8CE1A0005; Thu, 30 Oct 2014 09:07:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030160728.8790.61213.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 09:07:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/z7_nUo1A8_kSr5KlTTEIk2VRkhI Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Ted Lemon's No Objection on draft-ietf-weirds-rdap-sec-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 16:07:30 -0000 Ted Lemon has entered the following ballot position for draft-ietf-weirds-rdap-sec-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Barry has pointed out that there is a way to trigger the clients to send credentials using a login link, so that addresses my concern. I didn't actually see that explicitly mentioned in the document, but Pete says it's there so I'll take his word for it. From nobody Thu Oct 30 09:10:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6EC1A006F; Thu, 30 Oct 2014 09:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLmR7AkGEZi2; Thu, 30 Oct 2014 09:10:21 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0401A005D; Thu, 30 Oct 2014 09:10:20 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id DDC47DA023F; Thu, 30 Oct 2014 16:13:39 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 65B5553E084; Thu, 30 Oct 2014 09:09:50 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 30 Oct 2014 09:09:50 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 30 Oct 2014 12:09:40 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> <107E1EEF-9EAA-4A81-9DDE-C6CBB3C6E6E6@nominum.com> To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/HLBaC8v3AWjy_YQKf9go5pma1gg Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , weirds@ietf.org Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 16:10:26 -0000 On Oct 30, 2014, at 11:53 AM, Richard Barnes wrote: > It presents different content depending on whether the client is = authenticated or not. If you are unauthenticated, you see the "login" = link. If you are authenticated, it says "logged in as ...", and shows = more options. Different content depending on authentication state. This is a crappy example, because the wiki login mechanism is actually = pretty broken--frequently when I submit a change after logging in, it = complains that I'm not logged in. But admittedly that is likely = browser brokenness, so not really the protocol spec's problem. The = reason I raised the discuss is that my experience is that this is hard = to get right, and usually not gotten right. I think some language in = the spec to make this clearer would be good, but I've cleared my discuss = on the basis of your response and Pete's explanation on the call. From nobody Thu Oct 30 09:14:09 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244071A008F; Thu, 30 Oct 2014 09:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYm9BtbDmaR0; Thu, 30 Oct 2014 09:14:02 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA2F1A007E; Thu, 30 Oct 2014 09:14:00 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 98FBEDA022A; Thu, 30 Oct 2014 16:17:19 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5977753E084; Thu, 30 Oct 2014 09:13:30 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 30 Oct 2014 09:13:17 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49509D27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 30 Oct 2014 12:13:08 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F4950987F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49509D27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Z2JKmjNrSL_P8dMjKuwVfAiD0qE Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 16:14:05 -0000 On Oct 30, 2014, at 11:53 AM, Hollenbeck, Scott = wrote: > Would it be sufficient to add text that refers to the status codes and = provides instruction for sending the authorization header to = preemptively provide credentials? It would be nice to have some text saying "servers may provide a login = page that triggers HTTP authentication; clients should continue sending = the http authentication header once they receive an initial 401 response = from the HTTP server, as long as the scheme portion of the URL doesn't = change." I've seen clients get this wrong, and speaking as someone = who's tried to make this work, the login mechanism isn't obvious based = on reading the relevant RFC. From nobody Thu Oct 30 10:07:36 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7C11A037F; Thu, 30 Oct 2014 10:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amMi3gidIeUY; Thu, 30 Oct 2014 10:07:27 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id EDC801A0469; Thu, 30 Oct 2014 09:57:47 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id A8FB9165113; Thu, 30 Oct 2014 12:57:47 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id F00751650FB; Thu, 30 Oct 2014 12:57:46 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 13:00:08 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Thu, 30 Oct 2014 12:57:46 -0400 From: Andy Newton To: Scott Hollenbeck Thread-Topic: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) Thread-Index: AQHP9EiKHJzLWpX0p0e62eZEacYaGpxJAL+AgAANEgCAABHsgA== Date: Thu, 30 Oct 2014 16:57:45 +0000 Message-ID: References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F4950987F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49509D27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49509D27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: multipart/alternative; boundary="_000_A72EAF3F8D93465D910233886E4F05E2arinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/qpUTj-EjTMfBMmDKpKRiTocxdwQ Cc: "weirds@ietf.org" , "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , Ted Lemon , The IESG Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:07:29 -0000 --_000_A72EAF3F8D93465D910233886E4F05E2arinnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 30, 2014, at 11:53 AM, Hollenbeck, Scott > wrote: No, that's how it works today. The problem is that this doesn't address the use case where a client without credentials gets an answer, just not the same answer as it would have got if it had credentials. There's no programmatic way to advise the client that it would benefit from sending credentials without completely denying access for clients that don't have credentials to send. Yes, there is. The json-response document describes status values (section = 10.2.2) to indicate that a response element is private, redacted, or obscur= ed. If I'm a client and I see those status values in a response I know that= I might benefit (receive more information) by sending credentials. Which l= eads us to=85 Section 10.2.1 is also relevant to indicating the response would be differe= nt if credentials were given. -andy --_000_A72EAF3F8D93465D910233886E4F05E2arinnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3A2D8BD557E6144F8166A01D433125EB@corp.arin.net> Content-Transfer-Encoding: quoted-printable
On Oct 30, 2014, at 11:53 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

No, that's how it works today.   The pr= oblem is that this doesn't
address the use case where a client without credentials gets an answer,
just not the same answer as it would have got if it had credentials.
There's no programmatic way to advise the client that it would benefit
from sending credentials without completely denying access for clients
that don't have credentials to send.

Yes, there is. The json-response document describes status values (section = 10.2.2) to indicate that a response element is private, redacted, or obscur= ed. If I'm a client and I see those status values in a response I know that= I might benefit (receive more information) by sending credentials. Which leads us to=85

Section 10.2.1 is also relevant to indicating the response would be di= fferent if credentials were given.

-andy
--_000_A72EAF3F8D93465D910233886E4F05E2arinnet_-- From nobody Thu Oct 30 10:11:41 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FDF1A1A31; Thu, 30 Oct 2014 10:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3RDdr12viE8; Thu, 30 Oct 2014 10:11:28 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6D51A1A43; Thu, 30 Oct 2014 10:05:57 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 79DA3DA0241; Thu, 30 Oct 2014 17:09:16 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 50F1D53E080; Thu, 30 Oct 2014 10:05:26 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 30 Oct 2014 10:05:26 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 30 Oct 2014 13:05:14 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <07CA148C-2CA9-42BC-80B2-46EE69C653C2@nominum.com> References: <20141030015946.19422.59066.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F4950987F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49509D27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: Andy Newton X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/abNIMHYpRNmIgACPC-hYRrShdbI Cc: "weirds@ietf.org" , "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:11:34 -0000 On Oct 30, 2014, at 12:57 PM, Andy Newton wrote: > Section 10.2.1 is also relevant to indicating the response would be = different if credentials were given. That doesn't help, because it's a signal to the user, and if the user = agent and/or server don't provide a way to trigger the credentials being = sent, the user has no action to take. From nobody Thu Oct 30 10:22:57 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4986E1A036A for ; Thu, 30 Oct 2014 10:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoFBBH0SV9s5 for ; Thu, 30 Oct 2014 10:22:55 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472171A0354 for ; Thu, 30 Oct 2014 10:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414689775; x=1446225775; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=NEpykP7DJb3IdeObUP91Ka+ogoiLaN6VjFE8oEIt84g=; b=LmgCCd0YqTgMOhJRJIW8K6iR/oDFRC5a/PHk9WVn2FfregiQ9uzi13QI Mco9/rh1+oOoDJOg0mgW4tfE3KNNL+RBnq+qhQMQfJKXe4aOdE+3l4Y+l buR6rLqCoZKgQVuFh4eQQq7HBdXatP1cpN5TsyYOIK8qiQE1u90X57eFa s=; X-IronPort-AV: E=McAfee;i="5600,1067,7607"; a="80008729" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 30 Oct 2014 10:22:54 -0700 X-IronPort-AV: E=Sophos;i="5.07,286,1413270000"; d="scan'208";a="31648459" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Oct 2014 10:22:53 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 10:22:52 -0700 Received: from apc-qrc004-rpdu-k02-lf.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 30 Oct 2014 10:22:51 -0700 Message-ID: <545273EA.3060203@qti.qualcomm.com> Date: Thu, 30 Oct 2014 10:22:50 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.46.201.192) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/6B_fLYeT5NaIMuVhIs65MvlE3wM Subject: [weirds] IESG Telechat high-order bit X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:22:57 -0000 Just wanted to let you know that the IESG Telechat discussion went well and I think we have straightforward ways to address all outstanding issues. Some of the DISCUSSes have been or about to be cleared already. The rest I think I understand what needs to be said in the docs. We'll chat tomorrow and into next week. Thanks to everyone (especially the authors) who have been driving this forward. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Oct 30 10:23:23 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB171A0101; Thu, 30 Oct 2014 10:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnGLWAjtF-Ko; Thu, 30 Oct 2014 10:23:18 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B141A0354; Thu, 30 Oct 2014 10:23:18 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 30 Oct 2014 10:23:16 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Thu, 30 Oct 2014 10:23:16 -0700 From: Edward Lewis To: Kathleen Moriarty Thread-Topic: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) Thread-Index: AQHP88V3Eu/ymyeeqUSsqrFDWkP4tJxI86MAgABYqID//8rTAA== Date: Thu, 30 Oct 2014 17:23:15 +0000 Message-ID: References: <20141029214342.30884.77333.idtracker@ietfa.amsl.com> 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.4.5.141003 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3497520194_11126432" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/TGzndnA1XUQeWRQbA-pyPf_2_48 Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:23:19 -0000 --B_3497520194_11126432 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable From: Kathleen Moriarty Date: Thursday, October 30, 2014 at 12:33 To: Edward Lewis Cc: The IESG , "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) >Could you recommend alternate text? My objective wasn't to set >policy, but rather to raise awareness on risks and privacy options as >well as the ways in which the options could be used. It could be >very helpful to know what marking something one way or another means >and what might be possible. The policies actually implemented could >differ between administrators. > >If the risks are made known, then decisions could be made. I feel the current text is sufficient. At most, guidance would be to define what the receiver of a particular privacy status code should do (in reaction). But I=E2=80=99m not even sure of that. This is needed in DNS, but the DNS protocol is entirely different from RDAP so I can=E2=80=99t draw a useful analogy. I=E2=80=99ll leave it to the imagination (to avoid a specific statement) that the topic of what is to be released about a registration is a very wide-open question even if you ignore the transport (RDAP or WhoIs or IRIS or RWhoIS or =E2=80=A6). The expertise needed to hammer this out is likely external to the IETF. I guess the question is whether one RDAP =E2=80=9Cprocess=E2=80=9D can support data for= a registry under one privacy model and a registry under a different privacy model. The implementation needs to know how to respond within each model, but I don=E2=80=99t see that impacting the RDAP protocol exchange. --B_3497520194_11126432 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSYY/CQyzVwQjVbQru1 i8yevX4/mzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEw MzAxNzIzMTRaMA0GCSqGSIb3DQEBAQUABIIBAAniJ+PK6kyVe0X8IbYw5BlJiAqCGW3XU6F6 A8rFCxNsPv1VcphTGDERLa2zA3JwYWDUpI1VyfETFHOzn8Da77/2pLapiRPLePw2IMe2wm93 rMhZY3ypIyv18w91My687ZhJzTNACC4BTQPMG6rmAPy2NSEif3SNrekJ4GMgVFNx5BAj1OUq sdr+YzsmRek2HEIuBmojwG64RSamKeiTatEgwh2j73+3nd9kqwNqRkcy7y5HTu332PLGs1ua DEk/unifx9pIyk1I8pyV7O+kTERwgeuJ6dsZu8Dey4EDG4ZO8fD5b7vMMts6SExJQWTQShkT 1fPYa0TIObsNCInugh4= --B_3497520194_11126432-- From nobody Thu Oct 30 10:25:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9861A036A for ; Thu, 30 Oct 2014 10:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04HNqUtWanVW for ; Thu, 30 Oct 2014 10:25:27 -0700 (PDT) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02EB1A0178 for ; Thu, 30 Oct 2014 10:25:26 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKVFJ0hpjFaGXfQj4UWF+lmikaie8XDJwu@postini.com; Thu, 30 Oct 2014 10:25:27 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9UHPPna008565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 13:25:25 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 13:25:14 -0400 From: "Hollenbeck, Scott" To: Pete Resnick , "weirds@ietf.org" Thread-Topic: [weirds] IESG Telechat high-order bit Thread-Index: AQHP9GYne1Bv4W95skGoghrUQu8oDZxI5AOQ Date: Thu, 30 Oct 2014 17:25:24 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49509FBB@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <545273EA.3060203@qti.qualcomm.com> In-Reply-To: <545273EA.3060203@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/tuflNk7U5CPAgvxDCFHZRnA2OqM Subject: Re: [weirds] IESG Telechat high-order bit X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:25:29 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Pete Resnick > Sent: Thursday, October 30, 2014 1:23 PM > To: weirds@ietf.org > Subject: [weirds] IESG Telechat high-order bit >=20 > Just wanted to let you know that the IESG Telechat discussion went well > and I think we have straightforward ways to address all outstanding > issues. Some of the DISCUSSes have been or about to be cleared already. > The rest I think I understand what needs to be said in the docs. We'll > chat tomorrow and into next week. Thanks to everyone (especially the > authors) who have been driving this forward. Thanks, Pete. I'm looking forward to the debrief. Scott From nobody Thu Oct 30 10:43:48 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096671A0252 for ; Thu, 30 Oct 2014 10:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZWCeeflB0XM; Thu, 30 Oct 2014 10:43:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 119AE1A040C; Thu, 30 Oct 2014 10:43:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030174344.30814.33178.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 10:43:44 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/5TXrrZyVCDbAxiatGuuFMTBR16U Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:43:47 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ From nobody Thu Oct 30 10:44:05 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56481A19EF for ; Thu, 30 Oct 2014 10:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSBM4h2jt2QG; Thu, 30 Oct 2014 10:44:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7829C1A19E7; Thu, 30 Oct 2014 10:44:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030174402.30814.78191.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 10:44:02 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/FzfZZ3hbP9zfp5aS2CeDImJSpZs Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:44:05 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ From nobody Thu Oct 30 10:44:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43051A19F7 for ; Thu, 30 Oct 2014 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkaOgBV9PpCI; Thu, 30 Oct 2014 10:44:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B26451A01AE; Thu, 30 Oct 2014 10:44:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, mszucs@afilias.info, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030174418.30880.34830.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 10:44:18 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/5-NBooElWdgIQEHD8j0ZERyj3n4 Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:44:21 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ From nobody Thu Oct 30 10:44:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863781A0AF7 for ; Thu, 30 Oct 2014 10:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhn506Yyyja0; Thu, 30 Oct 2014 10:44:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D431A0217; Thu, 30 Oct 2014 10:44:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030174439.30860.54589.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 10:44:39 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/5eYZApsdMoSjdfTwd7OHYZk3iXQ Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:44:40 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ From nobody Thu Oct 30 10:44:58 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505341A0217 for ; Thu, 30 Oct 2014 10:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz5HpfZD0UqE; Thu, 30 Oct 2014 10:44:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 004DF1A19ED; Thu, 30 Oct 2014 10:44:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-using-http@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030174452.30840.99505.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 10:44:52 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/4etP8sBPik7UFv4H8FuJb9afsZc Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:44:56 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ From nobody Thu Oct 30 12:24:57 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5645F1A1A5F for ; Thu, 30 Oct 2014 12:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdX0XcWDX_z9; Thu, 30 Oct 2014 12:24:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 615181A1B88; Thu, 30 Oct 2014 12:24:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-object-inventory@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030192452.19818.26640.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 12:24:52 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/jbHG6EgdrZZSRao_MnhW9bV_EtM Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 19:24:55 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ From nobody Thu Oct 30 14:20:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392ED1A87E9 for ; Thu, 30 Oct 2014 14:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bm3f1fwD_U2 for ; Thu, 30 Oct 2014 14:20:26 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08071A87AA for ; Thu, 30 Oct 2014 14:20:25 -0700 (PDT) Received: (qmail 94692 invoked from network); 30 Oct 2014 21:20:24 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 30 Oct 2014 21:20:24 -0000 Date: 30 Oct 2014 21:20:02 -0000 Message-ID: <20141030212002.60063.qmail@ary.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: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/sU4lTiQnL9PLkBew162sI7pTy4k Cc: Ted.Lemon@nominum.com Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 21:20:27 -0000 >It would be nice to have some text saying "servers may provide a login page that triggers >HTTP authentication; clients should continue sending the http authentication header once >they receive an initial 401 response from the HTTP server, as long as the scheme portion >of the URL doesn't change." I've seen clients get this wrong, and speaking as someone >who's tried to make this work, the login mechanism isn't obvious based on reading the >relevant RFC. A lot of the clients for RDAP are going to be using wget or curl or python scripts, not web browsers. Remember that the results are JSON, so browser isn't going to produce very nice results unless it's already running a Javascript thing to interpret and format the JSON. It occurs to me that the obvious workaround is to use a different URL for authenticated access. You have to make some out of band arrangements to get the login credentials, so at the same time they can tell you what URL to use. R's, John From nobody Thu Oct 30 14:26:33 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765F71A8843 for ; Thu, 30 Oct 2014 14:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-0JItNLxzbT for ; Thu, 30 Oct 2014 14:26:23 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1099E1A8842 for ; Thu, 30 Oct 2014 14:26:23 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 66482DA0249 for ; Thu, 30 Oct 2014 21:29:43 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id BFCE453E084; Thu, 30 Oct 2014 14:25:52 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 30 Oct 2014 14:25:40 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <20141030212002.60063.qmail@ary.lan> Date: Thu, 30 Oct 2014 17:25:32 -0400 Content-Transfer-Encoding: 7bit Message-ID: References: <20141030212002.60063.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/yiIKKO8V_1tnO-xqZyJL0OwuvhM Cc: weirds@ietf.org Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 21:26:25 -0000 On Oct 30, 2014, at 5:20 PM, John Levine wrote: > It occurs to me that the obvious workaround is to use a different URL > for authenticated access. You have to make some out of band > arrangements to get the login credentials, so at the same time they > can tell you what URL to use. That would certainly work too. From nobody Thu Oct 30 14:35:02 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D491A882F for ; Thu, 30 Oct 2014 14:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dZTPDWzGuwF for ; Thu, 30 Oct 2014 14:34:58 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2CB1A87D8 for ; Thu, 30 Oct 2014 14:34:57 -0700 (PDT) Received: (qmail 96205 invoked from network); 30 Oct 2014 21:34:56 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 30 Oct 2014 21:34:56 -0000 Date: 30 Oct 2014 21:34:34 -0000 Message-ID: <20141030213434.60114.qmail@ary.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <20141030065634.11484.73249.idtracker@ietfa.amsl.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/WyW_3NyspKfxHQxNMQX6Gsfd6eI Cc: rlb@ipv.sx Subject: Re: [weirds] Richard Barnes' No Objection on draft-ietf-weirds-bootstrap-10: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 21:34:59 -0000 >I'm a little unclear as to why this document is necessary. It seems like >given the use of 30X redirects in -using-http, you could just start with >an IANA root server and redirect your way down the tree. It may appear >that this bootstrap mechanism saves queries to the root, but you could >achieve the same effect or better using 301 redirects with appropriate >caching. We considered that, but rejected it because clients were unlikely to do appropriate caching and the load on IANA would be excessive. If you do a lookup for foo.com and remember where it went, how does your client know how to rewrite the different URL that looks up bar.com? That foo.co.uk and bar.org.uk go to the same place, but baz.ac.uk does not? It's a swamp. The plan is that people will slurp down the whole boostrap file at some tolerable rate, like once a week. IANA has told us that they believe they can handle the load. If someone wants to use the bootstrap info to create their own universal redirect site (no doubt to sell the traffic info to domain speculators) they can always do so. FYI, the overall traffic for WHOIS lookups is enormous. The last time I looked at the registry reports, the volume of WHOIS traffic for .com and .net was roughly the same as the volume of DNS lookup traffic. R's, John From nobody Thu Oct 30 14:56:28 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589651AD0BB; Thu, 30 Oct 2014 04:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id medXKu-wtVQw; Thu, 30 Oct 2014 04:27:07 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0521AD0CB; Thu, 30 Oct 2014 04:27:06 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id hs14so4275006lab.33 for ; Thu, 30 Oct 2014 04:27:05 -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=nJar+aVgRI94tFBn1X4yr2nJtor4OjVmkTmqnvLnFKg=; b=kSTUAh8SqDSYhPqkfZVOUpdkbiUN+wEWFfH/ccMuPs3jA2Qeqyt8KirkNyNSGbcvW0 oVw/gFjU39IK+CIYIJUl35iikow61PBxq9tk5EWKAtT1bZ7tCO66tgkE4AvlgNohcLCQ tjm849DhGWPAf706wu51ryi9z2J+DkB7B+2WLDIh1NuLVPByqJ4dERvc+LkHkPhU7PVK NU5LcSv1qMOyIgleAtb2PDMQCKfwFeyCwVuiQEjnwacHJV3costOmiR5OjDoo7bqeovj Xqa1k0beDWJ1E5qVFUtK4EpLwp2Z021HtBOodrPYMbSbs36GxyYJJOJM+MhCjvo6uMMJ QuLA== MIME-Version: 1.0 X-Received: by 10.112.135.229 with SMTP id pv5mr18101000lbb.52.1414668424933; Thu, 30 Oct 2014 04:27:04 -0700 (PDT) Received: by 10.112.95.7 with HTTP; Thu, 30 Oct 2014 04:27:04 -0700 (PDT) In-Reply-To: <07C08197-D2E1-4B37-9560-65090C3E57A6@arin.net> References: <20141029214342.30884.77333.idtracker@ietfa.amsl.com> <07C08197-D2E1-4B37-9560-65090C3E57A6@arin.net> Date: Thu, 30 Oct 2014 07:27:04 -0400 Message-ID: From: Kathleen Moriarty To: Andy Newton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/KDCXqVi4g67v59jyWQKLN4eu1YE X-Mailman-Approved-At: Thu, 30 Oct 2014 14:56:25 -0700 Cc: "weirds@ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 11:27:15 -0000 Thanks, Andy. I'm glad the text was helpful. On Thu, Oct 30, 2014 at 7:24 AM, Andy Newton wrote: > > On Oct 29, 2014, at 5:43 PM, Kathleen Moriarty wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks for your work on this draft and including options for privacy >> protections. I do support Alissa's discuss on the -sec draft and as >> such, my discuss here is specific to this draft and values set forth in >> it for privacy. The general security and privacy considerations would b= e >> good to reference from one place. >> >> I think it would help to have the explicit guidance or recommendations >> for privacy included directly in the privacy section. While the example >> in the appendix is good, I'd prefer to see explicit recommendations for >> each of the relevant status codes from section 10.2.2. How about >> something along the lines of the following: >> >> Current Privacy Considerations section: >> This specification suggests status values to denote contact and >> registrant information that has been marked as private and/or has >> been redacted or obscured. See Section 10.2.2 for the list of status >> values. See Appendix A.1 on guidance to apply those values to >> contacts and registrants. >> >> Suggested Privacy Considerations section: >> This specification suggests status values to denote contact and >> registrant information that has been marked as private and/or has >> been redacted or obscured. See Section 10.2.2 for the complete list >> of status >> values. A few of the status values indicate that there are privacy >> concerns associated with the object instance. For the following >> status >> codes, the RECOMMENDED actions include: >> 7. private - The object is not be shared in query responses, unless >> the >> user is authorized to view this information. >> 8. redacted - The data has already been redacted, and may be >> returned >> in a response in the data redacted form. This is a safer >> option to choose >> to prevent unauthorized access to associated object instances >> than marking >> them as private. >> 9. obscured - The data has already been obscured, and may be >> returned in a >> response in the obscured form. This option may reveal privacy >> sensitive >> information and should only be used when data sensitivity does >> not require >> a more protective option like "private" or "redacted". >> >> See Appendix A.1 or an example applying those values to >> contacts and registrants. > > This sounds like a good idea to me. Thanks for the text. > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for addressing the SecDir review and including information on a >> possible cache poisoning attack. >> http://www.ietf.org/mail-archive/web/secdir/current/msg05183.html >> Some nits were included as well that might be helpful. > > I thought I included them. But I=E2=80=99ll circle back to that review fo= r the nits. Thanks. > > -andy --=20 Best regards, Kathleen From nobody Thu Oct 30 14:56:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E981AD0D7; Thu, 30 Oct 2014 04:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RstUfWOKCasW; Thu, 30 Oct 2014 04:58:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 901FD1A0007; Thu, 30 Oct 2014 04:58:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141030115822.25445.35358.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 04:58:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/hs5TuS2GKPgrWnrzlQ7z6x2Vq5U X-Mailman-Approved-At: Thu, 30 Oct 2014 14:56:25 -0700 Cc: draft-ietf-weirds-object-inventory@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Kathleen Moriarty's No Objection on draft-ietf-weirds-object-inventory-06: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 11:58:24 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-weirds-object-inventory-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't see any mention of privacy concerns with ant of the elements suggested for the RDAP model in this draft. Although I think the sec and response drafts should be the ones to state what actions can be taken, this one describes the elements that should be in the data model (but apparently doesn't match up exactly), so noting which are privacy sensitive might be helpful. I would have thought that was one of the motivators for this work, but that wasn't included in the description for section 1. I do think this change should be made, but also think the changes are more important in the sec and response drafts. From nobody Thu Oct 30 14:56:31 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04CF1A0073; Thu, 30 Oct 2014 09:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuI-QNkx_lEi; Thu, 30 Oct 2014 09:28:52 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FEE1A005F; Thu, 30 Oct 2014 09:28:51 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id l4so4599662lbv.14 for ; Thu, 30 Oct 2014 09:28:49 -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=AIwj5TR7Kz8awu1ACA4JqduJgWdwzeYdaF/Hex1yvUo=; b=emwLkXg79YsA8XGWzIClx3Ab66zyyn5fw6wwAfRzwMnQ4wHK6bjnSdVTb2TTspccm2 m92bP9TDplIpZ70AODmiAbnSQPTWM5ob0EI9417WZxPPnHa8gwgAhblCKCEI7M6P585X 6GsyKe5sQympCMbpGUsLEQsZWWu5zv19FB/8Lb9iu0VbsUJw0GLU4md7lFNbXSrYsiTh +JoZm4CCPlXzX51xgyOQEqde3WUux3odLA8LjyganCsjDXJ/3sDyMfGBUwP07CPzayqO xiXwtPJQPUUt/ykTET7O+6zn2GrNk4WVtMiU+QU2+Xo9o2Qo057H1JxRvAuolJ6L2IL8 XA6w== MIME-Version: 1.0 X-Received: by 10.112.173.69 with SMTP id bi5mr20097165lbc.61.1414686529499; Thu, 30 Oct 2014 09:28:49 -0700 (PDT) Received: by 10.112.95.7 with HTTP; Thu, 30 Oct 2014 09:28:49 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4950954D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141030010044.24345.22556.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F4950954D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 30 Oct 2014 12:28:49 -0400 Message-ID: From: Kathleen Moriarty To: "Hollenbeck, Scott" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/4MDjq0BmOjTc3xoIEMj5jzMkv-w X-Mailman-Approved-At: Thu, 30 Oct 2014 14:56:25 -0700 Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 16:28:55 -0000 Hi Scott, Thanks for you quick and detailed response. My response is inline. On Thu, Oct 30, 2014 at 7:58 AM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] >> Sent: Wednesday, October 29, 2014 9:01 PM >> To: The IESG >> Cc: weirds-chairs@tools.ietf.org; draft-ietf-weirds-rdap- >> sec@tools.ietf.org; weirds@ietf.org >> Subject: Kathleen Moriarty's Discuss on draft-ietf-weirds-rdap-sec-10: >> (with DISCUSS and COMMENT) >> >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-weirds-rdap-sec-10: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss- >> criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks for your work on this draft and improving security for the whois >> function in weirds. There are a lot of options now and the work is >> appreciated. I have a lot of comments and suggestions that should be >> pretty easy to resolve. You may find a discuss and comment on the same >> section, so I've tried to label the start of each item with the draft >> section numbers. >> >> Section 3.1 >> Could you also include a reference to RFC5280? If the use of PKI and >> CAs >> is listed, a pointer to the security considerations would be very >> helpful >> to the reader. The pointer should be to the full draft, not just the >> security consideration section as it covers important things like the >> need for path validation. Path validation includes checking the >> certificate validity, the path/chain (root is trusted), etc. I'm not >> looking for you to add much text, just to punt off to the existing >> documents if people are interested in the security behind these >> recommendations for federation, authentication, authorization, etc. > > A reference to RFC 5280 is already included in the 6th paragraph (page 4, 3rd paragraph down from the top). My bad, sorry I missed that. There was a lot of reading for this telechat and what you have looks good. > >> Section 3.2 >> Could you expand on the details here a bit? Between this draft and the >> response draft, I don't see enough information or guidance on how one >> might leverage value settings on objects and what are the right actions >> to take based on those values. My discuss on the response draft is >> specific to that draft, but the same concept applies here. If the >> guidance belongs in the response draft, then recommended actions or a >> list of options if it varies from administrator to administrator would >> be >> helpful at the start of the sections that provide the lists of values >> that can be set on objects. >> >> This section of the sec draft should then reference the response draft >> letting the reader know where to look for authorization and access >> control options and guidelines. > > I'm not sure what else I can add to this section. Response-object-specific guidance belongs in the response document. Assuming Andy and I make those mods to the response draft, would a reference at the end of Section 3.2 be sufficient? Yes, a reference is fine since that is specific to the response draft, thanks. > >> Section 3.4 >> Since the protocol allows for the use of values to mark objects as >> private, obscured, redacted, this should be mentioned in this section >> with a pointer to the response draft section 10.2.2 and the recommended >> actions in the (hopefully) updated Privacy Considerations section of >> that >> draft. For confidentially, leaving out the data with the "redacted" >> value set if possible will do a lot more than trying to protect it with >> TLS, so I think it's important to note that in this section. The >> "private" value should limit access (I'd like to see some mention of >> how >> that is accomplished, but probably in the Response draft). The >> "obscured" value is interesting, but since it is only obscured, it may >> to >> be the best option for confidentially protection. > > Fine. Thanks. > >> Possible new section for Access Controls - >> Since user based access is possible, I'd like to see a section added to >> cover that as well. Is access tied to the roles designated in 10.2.4 >> of >> the Response draft? Should it be? Having the combination of user >> roles >> and data object values gives a lot of flexibility, but that is talked >> about enough in the drafts (IMO). > > Fine. Access to information is tied to the identity of the client and associated authorizations, not the roles identified in the response data records. OK, making that clear would be helpful. Thanks. > >> Security consideration section: >> It's good that you are recommending against use of the Null cipher, but >> could you add a reference to the UTA TLS best practices draft here as >> well? That will cover quite a few bases with out having to repeat >> stuff >> here. >> https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ > > Fine, it's in WG last call. I'll add an informative reference. Thank you. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I support Alissa's discuss for a privacy threat model. >> >> Section 3.1 >> As an FYI (not asking for anything to be done here except to >> participate >> in HTTPAuth last calls) - HTTP Digest and Basic just went through a >> revision and are just about done. There are a few minor updates and >> the >> security considerations in the updated documents spell out the >> remaining >> issues. Although these are the solutions for HTTP Auth, most people >> don't rely on it and use other methods, so we don't have >> implementations >> of better options. There are a few other options in the HTTPAuth WG >> about to go to IETF last call or are WG drafts. If you are going to >> rely >> on HTTPAuth methods, maybe there should be a push for the improved >> options from the WEIRDS WG - at least pitching in to review during last >> calls. >> https://datatracker.ietf.org/wg/httpauth/documents/ >> >> Section 3.1 >> I'm a little uneasy with just having a pointer to TLS to fix everything >> in OAuth and OpenID. Could you put in pointers to main framework >> documents like RFC6749 with a statement that says security >> considerations >> are included in those drafts? The security considerations differ >> between >> token types (bearer vs. Holder of Key) and that is out-of scope for >> this >> draft, so punting to the OAuth drafts would be very helpful instead of >> just pointing to TLS (but please do leave that in). >> >> This is just a comment the references do appear at end of the Security >> considerations section, & I'd recommend you move those up to section >> 3.1 >> as it will be a lot easier for the reader. > > There's already a reference to RFC 6749 in Section 3.1.1, where we talk specifically about federated authentication. Would adding a sentence there to specifically refer to the security considerations be sufficient? It's fine as-is, this was just a comment because it is in the security consideration section. Section 3.1 read to me as TLS is used to secure it as opposed to just pointing to each of the specs for their own considerations + recommending TLS. All the text is there, just the placement isn't as I would have put it. It's fine to ignore this comment. Thanks. > >> Section 3.1 >> Just a question, should SAML 2.0 be listed as an option since this is a >> RESTful interface and we are talking about client authentication via a >> federated identity scheme or is that not an option? Thanks. > > It would be a more appropriate addition to Section 3.1.1. The document currently says: > > "Federated authentication mechanisms used by RDAP MUST be fully supported by HTTP. OAuth, OpenID, and CA-based mechanisms are three possible approaches to provide federated authentication." I could add SAML to the list since we're not mandating anything. If it is used by implementations, that might be helpful. If it is not, like you said it is just an option and is fine either way. This was just a comment for that reason. Thanks & I'll leave it up to you. I just added this because of it's use/adoption with other RESTful services. That may or may not be the case here. Thanks, Kathleen > > Scott > -- Best regards, Kathleen From nobody Thu Oct 30 14:56:33 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214ED1A008A; Thu, 30 Oct 2014 09:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx76R4GYcml1; Thu, 30 Oct 2014 09:33:36 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604AB1A007F; Thu, 30 Oct 2014 09:33:35 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gq15so4631885lab.7 for ; Thu, 30 Oct 2014 09:33:33 -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=keqVGUdq6EHkXZzS9YWwiWGNVqCr51BKBgr3SFkjrfQ=; b=T2wm49Yd1MXAJHFvut4wVNUAkESG26QqfO1SoX1ccWklQBM7mxih95WVGMkam9uTB3 HB2N1Me0dd2ulqvTL15YPPd1+28uPkcPC/mUZ2F8Od6AyuZGIP0A7fXrnox2TZ+bvdOb 32JbFim7kqiqSpboLAQ1N0Djm2K4cjqt5TUDMSmX7/lSEDd5ZWpghqJckDf5IVcv+fNc iN7qPVcRnb6tZn2NLpxwUjMbTxajc7pyPvPFuwH/pl+gPiSf+tqZkFv2WODQDafW1Wlr fU4wGbX1/qsBO2qD9pCkvvyzILWtBeYZkQTHWtiyVX2+b+iMyPI8c/227SBMqa8deNhR 3HgQ== MIME-Version: 1.0 X-Received: by 10.152.206.36 with SMTP id ll4mr20541178lac.64.1414686813677; Thu, 30 Oct 2014 09:33:33 -0700 (PDT) Received: by 10.112.95.7 with HTTP; Thu, 30 Oct 2014 09:33:33 -0700 (PDT) In-Reply-To: References: <20141029214342.30884.77333.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 12:33:33 -0400 Message-ID: From: Kathleen Moriarty To: Edward Lewis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/BV44i_E7UB4DJuBZ2S_zSSbDzhE X-Mailman-Approved-At: Thu, 30 Oct 2014 14:56:25 -0700 Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" , The IESG , "weirds@ietf.org" Subject: Re: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 16:33:38 -0000 Hi Ed, Thanks for raising your concern. On Thu, Oct 30, 2014 at 11:16 AM, Edward Lewis wro= te: > I=E2=80=99m concerned that this discuss is trying to place policy into th= e protocol. > I=E2=80=99m not convinced it is, but I want to say something now rather t= han wait. > > At a recent ICANN meeting there was a presentation of the coming RDAP > protocol and how it is a candidate to replace WhoIs. One of the =E2=80= =9Cselling > points=E2=80=9D is that RDAP can support different policy settings, as op= posed to > WhoIs which, though it=E2=80=99s simplicity supports just the one default= policy. > > The current text suggests status codes, which is fine. Going beyond that= to > =E2=80=9CRECOMMEND=E2=80=9D actions in response to the codes is too far f= or me because it is > not clear to me how this would enhance interoperability of implementation= s > while at the same time, =E2=80=9Ccementing=E2=80=9D the status codes as h= aving meaning. > Perhaps the document can mention that codes and their meanings need to be > defined, but I think being so detailed as this list is too far down the p= ath > of pressing an assumed policy into the protocol. Could you recommend alternate text? My objective wasn't to set policy, but rather to raise awareness on risks and privacy options as well as the ways in which the options could be used. It could be very helpful to know what marking something one way or another means and what might be possible. The policies actually implemented could differ between administrators. If the risks are made known, then decisions could be made. Thanks, Kathleen > > From: Kathleen Moriarty > Date: Wednesday, October 29, 2014 at 17:43 > To: The IESG > Cc: "weirds-chairs@tools.ietf.org" , > "weirds@ietf.org" , > "draft-ietf-weirds-json-response@tools.ietf.org" > > Subject: [weirds] Kathleen Moriarty's Discuss on > draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-weirds-json-response-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for your work on this draft and including options for privacy > protections. I do support Alissa's discuss on the -sec draft and as > such, my discuss here is specific to this draft and values set forth in > it for privacy. The general security and privacy considerations would be > good to reference from one place. > > I think it would help to have the explicit guidance or recommendations > for privacy included directly in the privacy section. While the example > in the appendix is good, I'd prefer to see explicit recommendations for > each of the relevant status codes from section 10.2.2. How about > something along the lines of the following: > > Current Privacy Considerations section: > This specification suggests status values to denote contact and > registrant information that has been marked as private and/or has > been redacted or obscured. See Section 10.2.2 for the list of status > values. See Appendix A.1 on guidance to apply those values to > contacts and registrants. > > Suggested Privacy Considerations section: > This specification suggests status values to denote contact and > registrant information that has been marked as private and/or has > been redacted or obscured. See Section 10.2.2 for the complete list > of status > values. A few of the status values indicate that there are privacy > concerns associated with the object instance. For the following > status > codes, the RECOMMENDED actions include: > 7. private - The object is not be shared in query responses, unless > the > user is authorized to view this information. > 8. redacted - The data has already been redacted, and may be > returned > in a response in the data redacted form. This is a safer > option to choose > to prevent unauthorized access to associated object instances > than marking > them as private. > 9. obscured - The data has already been obscured, and may be > returned in a > response in the obscured form. This option may reveal privacy > sensitive > information and should only be used when data sensitivity does > not require > a more protective option like "private" or "redacted". > > See Appendix A.1 or an example applying those values to > contacts and registrants. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for addressing the SecDir review and including information on a > possible cache poisoning attack. > http://www.ietf.org/mail-archive/web/secdir/current/msg05183.html > Some nits were included as well that might be helpful. > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --=20 Best regards, Kathleen