This looks good to me, plus what John said about allo= wing entries to include the template/location of an RDAP server.

<= /div>

On Fri, = Aug 8, 2014 at 9:20 AM, Olaf Kolkman <olaf@evangineer.net>= wrote:

On Aug 6, 2014, at 6:09 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

> While we wait for Peter, I thought I'd take a crack at this. =C2= =A0Maybe he'll just agree with what I say. =C2=A0:-)
>
> So here's what I propose for a complete replacement of what's = in that section now.

The goal was to _not_ give instructions.

>
> IANA Considerations
>
> IANA has already created registries for top-level domain names and the= ir registries [DOMAINREG], Autonomous System numbers [ASREG], IPv4 network = blocks [IPV4REG] and IPv6 network blocks [IPV6REG]. =C2=A0The management po= licies of these registries are established and maintained under other arran= gements and are not germane to this specification.

That looks good, as it is a statement of fact.

> In order to support implementations of the RDAP protocol, IANA is requ= ested to generate, periodically, copies of the contents of these registries= according to the format described in this document.

With the above we stepping into =E2=80=98instruction territory=E2=80= =99. I would just describe what the requirement is:

In order to support implementations of the RDAP protocol, the content of th= ese registries need to be made available in the format described in this do= cument, using the protocol described in [REF]. RDAP clients can then use it= as configuration data to determine where to send particular queries.

>
> The frequency with which the generated versions of these registries ne= eds to be updated will depend on the frequency with which the registry rece= ives new or updated entries.

Perhaps:

In order to maintain coherency, the RDAP bootstrap data should be updated w= henever new or updated data enters the registries.

=E2=80=94

It occurs to me that when this is ready we should inform ICANN and the NRO = that the specification is done and that they could consider to define an SL= A in order to perform these functions.

=E2=80=94Olaf

--047d7bb70cbe28d2a20500228206-- From nobody Fri Aug 8 12:45: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 59EDE1A035D for ; Fri, 8 Aug 2014 12:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri_AAQN97C62 for ; Fri, 8 Aug 2014 12:45:10 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93011A034E for ; Fri, 8 Aug 2014 12:45:10 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1XFq69-0004km-68 for weirds@ietf.org; Fri, 08 Aug 2014 19:45:09 +0000 Received: from mail-oa0-f48.google.com ([209.85.219.48]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1XFq69-0006eb-5t for weirds@ietf.org; Fri, 08 Aug 2014 19:45:09 +0000 Received: by mail-oa0-f48.google.com with SMTP id m1so4379236oag.21 for ; Fri, 08 Aug 2014 12:45:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=it0BLbYpBsoVO9TccbiYs/cbASAMrf/qisk6Od3zzas=; b=nMAJsh4CahV4zqvnivPDgk2aruzvkvP0Lin4yya8Dh7jiDzIlpCJnIAc2gqW5MXYwU Rc9FGZsC3fwkn2MxElgmI8nG2DxyDqXkt9mtwCJYz6K2W2q5hgWOhHQybjkDIVGigoA3 quojlBunlPd/iR6jDFc0UewN18/szYAUwVgq5oIIzL5hrpohj8AyQOEsOrz/mlz0fX2A 03GmE5agJk1XMC0SIZhvE9rvY/EQQTyZG1JyzvOQgQjPNw28Nk9rW/Qrd1yxu1Ra7gdG Au7bs91QSFuXW6E9kNVErXREZ2lk5p85+Xx2K+gP0lycOu7GS0lpv2AyWHXO+xdWJRAf UZfw== X-Gm-Message-State: ALoCoQkYsWsz4oz3qSfMD+CByd3ikn7SFBvRhSWVn6jnDkudgoY/iw1T9UO+nUkLJUrW+iVPyNZKq3qmSlWIqAc7CYhKfqD1kNfhg9o3W9Y95LRouqErwVk= X-Received: by 10.182.245.164 with SMTP id xp4mr32924611obc.23.1407527104372; Fri, 08 Aug 2014 12:45:04 -0700 (PDT) X-Received: by 10.182.245.164 with SMTP id xp4mr32924600obc.23.1407527104272; Fri, 08 Aug 2014 12:45:04 -0700 (PDT) Received: from [192.168.2.13] (TOROON474AW-LP130-04-1177588849.dsl.bell.ca. [70.48.148.113]) by mx.google.com with ESMTPSA id d11sm15547432obs.26.2014.08.08.12.45.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 12:45:02 -0700 (PDT) Message-ID: <53E528BB.6060502@afilias.info> Date: Fri, 08 Aug 2014 15:44:59 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: WEIRDS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/p8flQmhfx6FeCtcvSyYmttiGuvM Subject: [weirds] Required data in 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, 08 Aug 2014 19:45:12 -0000 It is not clear throughout draft-ietf-weirds-json-response-07 whether members defined for an object are required or not. Each object class generally has a statement like "This object has the following members: ..." Does this mean a server must return all the members defined in the list when returning that object? I did not interpret the spec this way, but the inter-op test cases did, resulting in many "FAILS" on the test. If this is not the intention, then the spec should be clarified by saying something like "This object has one or more of the following members: ..." -Ernie From nobody Fri Aug 8 13:02: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 B419F1A044F for ; Fri, 8 Aug 2014 13:02: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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 O39XOg4GNEAG for ; Fri, 8 Aug 2014 13:02:30 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 74DCF1A0421 for ; Fri, 8 Aug 2014 13:02:30 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 2BFFC213787; Fri, 8 Aug 2014 16:02: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 smtp2.arin.net (Postfix) with ESMTP id 8C1B82136C7; Fri, 8 Aug 2014 16:02:29 -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, 8 Aug 2014 16:03: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; Fri, 8 Aug 2014 16:02:29 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] Required data in responses Thread-Index: AQHPs0FHIXg1i3kL0kuUUBKnZhQk75vHY+kA Date: Fri, 8 Aug 2014 20:02:28 +0000 Message-ID: References: <53E528BB.6060502@afilias.info> In-Reply-To: <53E528BB.6060502@afilias.info> 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_C11BBB2E798E4894B255EBDD774F689Carinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/jaF41uWYC7RjU4If-P-6q1V2KwY Cc: "weirds@ietf.org" Subject: Re: [weirds] Required data in 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, 08 Aug 2014 20:02:43 -0000 --_000_C11BBB2E798E4894B255EBDD774F689Carinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 8, 2014, at 3:44 PM, Ernie Dainow > wrote: It is not clear throughout draft-ietf-weirds-json-response-07 whether membe= rs defined for an object are required or not. Each object class generally h= as a statement like "This object has the following members: ..." Does this mean a server must return all the members defined in the list whe= n returning that object? I did not interpret the spec this way, but the int= er-op test cases did, resulting in many "FAILS" on the test. If this is not the intention, then the spec should be clarified by saying s= omething like "This object has one or more of the following members: ..." >From section 3: Clients processing JSON responses MUST 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 MAY remove values as is needed by the policies of the server operator. -andy --_000_C11BBB2E798E4894B255EBDD774F689Carinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

On Aug 8, 2014, at 3:44 PM, Ernie Dainow <edainow@afilias.info> wrote:

It is not clear throughout draft-ietf-weirds-json= -response-07 whether members defined for an object are required or not. Eac= h object class generally has a statement like "This object has the fol= lowing members: ..."

Does this mean a server must return all the members defined in the list whe= n returning that object? I did not interpret the spec this way, but the int= er-op test cases did, resulting in many "FAILS" on the test.

If this is not the intention, then the spec should be clarified by saying s= omething like "This object has one or more of the following members: .= .."

From section 3:

   Clients processing JSON responses =
MUST 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 MAY remove values as is needed by the policies of the server
   operator.

-andy

--_000_C11BBB2E798E4894B255EBDD774F689Carinnet_-- From nobody Mon Aug 11 06:57: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 B93941A037F for ; Mon, 11 Aug 2014 06:57:54 -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 muwWl4FAjh8e for ; Mon, 11 Aug 2014 06:57:53 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8C31A02F6 for ; Mon, 11 Aug 2014 06:57:53 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so4281543wib.4 for ; Mon, 11 Aug 2014 06:57: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=5anz5q9dzKN3PNUe5aytkuce+rPa8eyGreT1ddvrA14=; b=vK7gnIMwOK34h0cYVW6eKIHYmPFe0ApTWLoSkqOmf2T97lkoQS6qKfMlA9MZeWoFSl IbQ6+p/r5kkGTdC+VczvCmSqGWgoXJr0ZVnDLsYF5C/Q7rZaXUSvueZup80TRU8YUap3 awGop1sUeDO+S5KZ0hJpgV4Yi7o3O1uux05+2RsNqOPsOX8RRbc5uwUJNi54zQq+LNuz NCMrpvuHIY+aOJx2EUxqjscxUt2uoGZ591qFghk28c4OctMBSuOgOyIFGpSVEWxo1gab oYQEJ1w8I7T7iiaYC+xSek5gQ6C1c/AEL4Tj3cEy+CcHGX+w/gvoWjDcWbCkMFBjli67 M8uQ== MIME-Version: 1.0 X-Received: by 10.194.142.200 with SMTP id ry8mr53328385wjb.37.1407765472165; Mon, 11 Aug 2014 06:57:52 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Mon, 11 Aug 2014 06:57:52 -0700 (PDT) In-Reply-To: References: <0AE6788A-22C1-4741-8BC1-A26EC38D94B4@evangineer.net> Date: Mon, 11 Aug 2014 06:57:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Olaf Kolkman Content-Type: multipart/alternative; boundary=089e0122862ce545db05005af0fd Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/h6xORqC7HH9Sgq8IvqMCGWUufhw Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-bootstrap IANA Considerations 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, 11 Aug 2014 13:57:54 -0000 --089e0122862ce545db05005af0fd Content-Type: text/plain; charset=UTF-8 On Fri, Aug 8, 2014 at 11:38 AM, Murray S. Kucherawy wrote: > This looks good to me, plus what John said about allowing entries to > include the template/location of an RDAP server. > So do we have consensus on this text? Can Marc and Guillaume proceed to incorporate it into the bootstrap document so that everything else can get updated and we can proceed to our WGLCs? Our first do-or-die milestone is September 5, which is only about three weeks away... -MSK --089e0122862ce545db05005af0fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 8, 2014 at 11:38 AM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:

This looks good to me,= plus what John said about allowing entries to include the template/locatio= n of an RDAP server.

So do we have consensus on thi= s text?=C2=A0 Can Marc and Guillaume proceed to incorporate it into the boo= tstrap document so that everything else can get updated and we can proceed = to our WGLCs?

Our first do-or-die milestone is September 5, which is only = about three weeks away...

-MSK

--089e0122862ce545db05005af0fd-- From nobody Mon Aug 11 06:59:38 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B321E1A02F6 for ; Mon, 11 Aug 2014 06:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RP_MATCHES_RCVD=-0.668, 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 0RgnHzmBkG5r for ; Mon, 11 Aug 2014 06:59: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 7ED701A00C6 for ; Mon, 11 Aug 2014 06:59:35 -0700 (PDT) Received: from [206.123.31.195] (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A9F9B4039B for ; Mon, 11 Aug 2014 09:59:34 -0400 (EDT) Message-ID: <53E8CC3E.5050300@viagenie.ca> Date: Mon, 11 Aug 2014 09:59:26 -0400 From: Guillaume Leclanche User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: weirds@ietf.org References: <0AE6788A-22C1-4741-8BC1-A26EC38D94B4@evangineer.net> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ZTpxP4spNN_nnsVYx1xc1GrrMJM Subject: Re: [weirds] draft-ietf-weirds-bootstrap IANA Considerations 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, 11 Aug 2014 13:59:37 -0000 Le 2014-08-11 09:57, Murray S. Kucherawy a écrit :

On Fri, Aug 8, 2014 at 11:38 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

This looks good to me, plus what John said about allowing entries to include the template/location of an RDAP server.

So do we have consensus on this text? Can Marc and Guillaume proceed to incorporate it into the bootstrap document so that everything else can get updated and we can proceed to our WGLCs?

I'm working on it :)

Guillaume

Our first do-or-die milestone is September 5, which is only about three weeks away...

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

From nobody Mon Aug 11 07:14: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 010BB1A03E6 for ; Mon, 11 Aug 2014 07:14:46 -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 NnF-GdZQlqKb for ; Mon, 11 Aug 2014 07:14:44 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1EE1A03F1 for ; Mon, 11 Aug 2014 07:14:43 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so4324641wiv.1 for ; Mon, 11 Aug 2014 07:14:42 -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=oJMv69kh9O4Q1P6okW8O8w6XV57mtsWAgQngAPjdauo=; b=0nJT6lyBlcWOeTA6FXdvRV+ucd5NAJ1P4b7oOLgCgRFYnDA6wBQiqViC971OUorwJY OvHhYP2hlZsOWyoKatXKEjlikADUmCaEC5l8nhB+lRiTrnillfJoHUYRv7pKFp3Kd/qU WzyfdQyHyccxle7sedwxQhluIgXtiIREm1xbrzBWkn1GLbW3SxpG6z3kkB0/MJMtO1Tc +UtrrS4rhDwwtpjMZHzauLXIBHHGlyydPJEQn5XnRLtgYqM2iOf7oYvl1RK8934c0I8y lPbNFXzPPbCGdlUxVh7DW3r/B2tMNcCl5zrDd6z37j4Fd7OxMqYODLGJte1jqYjqVteI 6jXw== MIME-Version: 1.0 X-Received: by 10.180.38.39 with SMTP id d7mr25630048wik.24.1407766481975; Mon, 11 Aug 2014 07:14:41 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Mon, 11 Aug 2014 07:14:41 -0700 (PDT) In-Reply-To: <53E8CC3E.5050300@viagenie.ca> References: <0AE6788A-22C1-4741-8BC1-A26EC38D94B4@evangineer.net> <53E8CC3E.5050300@viagenie.ca> Date: Mon, 11 Aug 2014 07:14:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Guillaume Leclanche Content-Type: multipart/alternative; boundary=e89a8f646fcf15c0cd05005b2dd9 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/P3X9gQckQrTTBBIQFKYi7B_qWFc Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-bootstrap IANA Considerations 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, 11 Aug 2014 14:14:46 -0000 --e89a8f646fcf15c0cd05005b2dd9 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 11, 2014 at 6:59 AM, Guillaume Leclanche < guillaume.leclanche@viagenie.ca> wrote: > So do we have consensus on this text? Can Marc and Guillaume proceed to > incorporate it into the bootstrap document so that everything else can get > updated and we can proceed to our WGLCs? > > > I'm working on it :) > That's half of what we need. :-) The other half is agreement from the working group. That's what I was hoping to gauge here. -MSK --e89a8f646fcf15c0cd05005b2dd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 11, 2014 at 6:59 AM, Guillaume Leclanche <guillaume.leclanche@viagenie.ca> wrote:

So do we have consensus on this text?=C2=A0= Can Marc and Guillaume proceed to incorporate it into the bootstrap document so that everything else can get updated and we can proceed to our WGLCs?

I'm working on it :)=

That's half of= what we need.=C2=A0 :-)=C2=A0 The other half is agreement from the working= group.=C2=A0 That's what I was hoping to gauge here.

-MSK

--e89a8f646fcf15c0cd05005b2dd9-- From nobody Mon Aug 11 10:52: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 729CC1A04AB for ; Mon, 11 Aug 2014 10:52:54 -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 R1fM1UKl5Mvi for ; Mon, 11 Aug 2014 10:52:51 -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 48E051A048D for ; Mon, 11 Aug 2014 10:52:35 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKU+kC4opkj+nlDk1woE5HwJlJviXntDOE@postini.com; Mon, 11 Aug 2014 10:52:51 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 s7BHqYMo020566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 13:52:34 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 11 Aug 2014 13:52:33 -0400 From: "Hollenbeck, Scott" To: Andy Newton , John Levine Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-11.txt Thread-Index: AQHPrPVg8ORTiZQH+EGxSOsqS5cPipvClTUAgAkpzQA= Date: Mon, 11 Aug 2014 17:52:33 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49479120@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140731192651.7329.qmail@joyce.lan> <72BE0B9A-1D5C-48D2-90D8-F435E825208D@arin.net> In-Reply-To: <72BE0B9A-1D5C-48D2-90D8-F435E825208D@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_831693C2CDA2E849A7D7A712B24E257F49479120BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/HfJKBU-Wjl_64fADButzg5ih9hM Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-11.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, 11 Aug 2014 17:52:54 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F49479120BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andy Newton Sent: Tuesday, August 05, 2014 1:53 PM To: John Levine Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-11.txt On Jul 31, 2014, at 3:26 PM, John Levine > wrote: Nos. 8, 9, 10 are from Andy. Andy? #8 and #9 were discussed on this list, and I thought we had agreement to in= clude them. [SAH] Before I actually put writing time into these let me ask one more tim= e if anyone has any concerns or statements of support. #8 is "Search of dom= ain names by nameserver name. It could look something like /domains?nsLdhN= ame=3DXXXXX" #9 is "Search of domain names by nameserver IP address. It cou= ld look something like /domains?nsIp=3DYYYYY". Yes? No? #10 was a request to remove search by entity handles. However, after discus= sion on this mailing list we decided to keep it. This one can be closed. [SAH] Does anyone have any issues with closing this? Search by entity handl= e is currently described in Section 3.2.3. -andy --_000_831693C2CDA2E849A7D7A712B24E257F49479120BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: weirds [= mailto:weirds-bounces@ietf.org] On Behalf Of Andy Newton
Sent: Tuesday, August 05, 2014 1:53 PM
To: John Levine
Cc: weirds@ietf.org
Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-11.tx= t

On Jul 31, 2014, at 3:26 PM, John Levine <johnl@taugh.com> wrote:

Nos. 8, 9, 10 are from Andy. And= y?

#8 and #9 were discussed on this list, and I thought= we had agreement to include them.

[SAH] Before I actually put writing time i= nto these let me ask one more time if anyone has any concerns or statements= of support. #8 is “Search of domain names by nameserver name. It could look something like /domains?nsLdhName=3DXXXXX”= #9 is “Search of domain names by nameserver IP address. It could loo= k something like /domains?nsIp=3DYYYYY”. Yes? No?

#10 was a request to remove search by entity handles= . However, after discussion on this mailing list we decided to keep it. Thi= s one can be closed.

[SAH] Does anyone have any issues with clo= sing this? Search by entity handle is currently described in Section 3.2.3.=

-andy

--_000_831693C2CDA2E849A7D7A712B24E257F49479120BRN1WNEXMBX01vc_-- From nobody Tue Aug 12 08:50: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 6F86F1A04B7 for ; Tue, 12 Aug 2014 08:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RP_MATCHES_RCVD=-0.668, 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 41zmiYIp_xmS for ; Tue, 12 Aug 2014 08:50:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 178021A04B1 for ; Tue, 12 Aug 2014 08:50:06 -0700 (PDT) Received: from [IPv6:2620:0:230:c000:fc44:43d4:bd74:e1ed] (unknown [IPv6:2620:0:230:c000:fc44:43d4:bd74:e1ed]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 46B9940379 for ; Tue, 12 Aug 2014 11:50:05 -0400 (EDT) Message-ID: <53EA37A3.3010200@viagenie.ca> Date: Tue, 12 Aug 2014 11:49:55 -0400 From: Guillaume Leclanche User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: weirds@ietf.org References: <0AE6788A-22C1-4741-8BC1-A26EC38D94B4@evangineer.net> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/mq9pjYLeootoNUF6-kDRSfT-u-o Subject: Re: [weirds] draft-ietf-weirds-bootstrap IANA Considerations 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, 12 Aug 2014 15:50:07 -0000

Le 2014-08-11 09:57, Murray S. Kucherawy a écrit :

On Fri, Aug 8, 2014 at 11:38 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

This looks good to me, plus what John said about allowing entries to include the template/location of an RDAP server.

So do we have consensus on this text? Can Marc and Guillaume proceed to incorporate it into the bootstrap document so that everything else can get updated and we can proceed to our WGLCs?

Hello,

here's a proposal for the whole IANA considerations section. Some justifications:
1) IANA is really requested to create new registries, that can not technically be copies of the existing ones where whois server info can be found: this document does not have the same entries nor structure as the existing registries, so it can not just be converted.
2) The text regarding the policies is Murray's proposal as everyone here agreed with it
3) The last paragraph tries to discuss the sync issue based on Olaf's proposal.

Comments ?

Guillaume

IANA is requested to do the following:

   o Create a new registry "IPv4 Address Space RDAP Bootstrap Service"
      in the JSON format, as shown above.
   o Create a new registry "IPv6 Address Space RDAP Bootstrap Service"
      in the JSON format, as shown above.
   o Create a new registry "Autonomous System Number Space RDAP
      Bootstrap Service" in the JSON format, as shown above.
   o Create a new registry "Domain Name Space RDAP Bootstrap Service"
      in the JSON format, as shown above.

Those new registries may be maintained in IANA own format, such as XML, in
addition to the JSON-based format described in this document.

IANA has already created registries for top-level domain names and their
registries [DOMAINREG], Autonomous System numbers [ASREG], IPv4 network
blocks [IPV4REG] and IPv6 network blocks [IPV6REG]. The management
policies of these registries are established and maintained under other
arrangements and are not germane to this specification.

In order to maintain coherency, the RDAP Bootstrap Service
registries should be updated if necessary whenever new or updated data
enter [DOMAINREG], [ASREG], [IPV4REG], or [IPV6REG].

From nobody Tue Aug 12 10:49: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 153111A0481 for ; Tue, 12 Aug 2014 10:49:14 -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 Cyakyk65ICQ5 for ; Tue, 12 Aug 2014 10:49:12 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768F61A034E for ; Tue, 12 Aug 2014 10:49:12 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so6244747wib.9 for ; Tue, 12 Aug 2014 10:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wC8YtwrVo/QaGxfEq5g9jSmomR4Vvm/ZQknZ55IPpCQ=; b=BdoojCrDCxrvKlWiX+RGrEgxR3Z1J/3kiPsTvvah5K5pKeAATXZelIvkvtNOZmW4/z RKdV5QJo6zXSi/LGQ8GGW1ymj4aWxswjkLqJyV+ocd9Np/iiEYfp3rLcMLOnlM0kcP2G 98pNZ1JlgaQ/7z9ofZ6xzhC35wqlWUA0gKKN97FV+3b48EMGGDAq+1MXfMRBqIXJwNph DfLAE+jH92Qpp+DEjIZ5Fkh4hZNfUBmSDsYNkw+n795Xf1jyYSDXAFe4fhQh4Gd490jp UwZJwIFt7ACXqBvYfSVygt0dmd6JwAXmo7+6ROWDZ1tCx0LgU/ew6yaxvmeyfc+hnFQT Ae5w== MIME-Version: 1.0 X-Received: by 10.180.104.163 with SMTP id gf3mr33844457wib.24.1407865751035; Tue, 12 Aug 2014 10:49:11 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Tue, 12 Aug 2014 10:49:10 -0700 (PDT) In-Reply-To: <53EA37A3.3010200@viagenie.ca> References: <0AE6788A-22C1-4741-8BC1-A26EC38D94B4@evangineer.net> <53EA37A3.3010200@viagenie.ca> Date: Tue, 12 Aug 2014 10:49:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Guillaume Leclanche Content-Type: multipart/alternative; boundary=14dae9cc914efb663f050072497c Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/gLCDEEaXnLw-HBON5r40xs1gwB0 Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-bootstrap IANA Considerations 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, 12 Aug 2014 17:49:14 -0000 --14dae9cc914efb663f050072497c Content-Type: text/plain; charset=UTF-8 On Tue, Aug 12, 2014 at 8:49 AM, Guillaume Leclanche < guillaume.leclanche@viagenie.ca> wrote: > here's a proposal for the whole IANA considerations section. Some > justifications: > 1) IANA is really requested to create new registries, that can not > technically be copies of the existing ones where whois server info can be > found: this document does not have the same entries nor structure as the > existing registries, so it can not just be converted. > A number of concerns here: If we really can't copy this (I'm not sure I understand your justification, but I'll go back and look at it again), then we can probably at least populate some of the data from the old registry to the new one, no? I'm worried about the burden of creating a second set of registries with almost the same purpose as the first, or at least the appearance of a lot of overlap. If there's really no way around that, we need to spend some time explaining in this document why that's the case. In addition to creating the registries, we'll need to do things like select and describe the policy for updating the registry, and anything else required by RFC 5226. This runs headlong into the concerns expressed by John Klensin and others that we're treading on ICANN's terrain. I don't think we want to go there. This seems like a change in direction from what we'd agreed on in Toronto and prior. I'm getting very nervous. -MSK --14dae9cc914efb663f050072497c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 12, 2014 at 8:49 AM, Guillaume Leclanche <guillaume.leclanche@viagenie.ca> wrote:

=20 =20 =20
here's a proposal for the w= hole IANA considerations section. Some justifications:
1) IANA is really requested to create new registries, that can not technically be copies of the existing ones where whois server info can be found: this document does not have the same entries nor structure as the existing registries, so it can not just be converted.

A number of concer= ns here:

If we really can't copy this (I'm not su= re I understand your justification, but I'll go back and look at it aga= in), then we can probably at least populate some of the data from the old r= egistry to the new one, no?

I'm worried about the burden of creating a second set of= registries with almost the same purpose as the first, or at least the appe= arance of a lot of overlap.=C2=A0 If there's really no way around that,= we need to spend some time explaining in this document why that's the = case.

In addition to creating the registries, we'll need to do= things like select and describe the policy for updating the registry, and = anything else required by RFC 5226.=C2=A0 This runs headlong into the conce= rns expressed by John Klensin and others that we're treading on ICANN&#= 39;s terrain.=C2=A0 I don't think we want to go there.

This seems like a change in direction from what we'd agreed o= n in Toronto and prior.=C2=A0 I'm getting very nervous.

-MSK