From jyee@afilias.info Sat Jun 1 08:36:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5617A21F9E53 for ; Sat, 1 Jun 2013 08:36:03 -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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U56Z1yvJlVt for ; Sat, 1 Jun 2013 08:35:58 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4EC21F9E42 for ; Sat, 1 Jun 2013 08:35:57 -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 1UinqX-0002y2-49 for weirds@ietf.org; Sat, 01 Jun 2013 15:35:57 +0000 Received: from mail-oa0-f50.google.com ([209.85.219.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UinqX-0005Yq-3k for weirds@ietf.org; Sat, 01 Jun 2013 15:35:57 +0000 Received: by mail-oa0-f50.google.com with SMTP id l20so427027oag.23 for ; Sat, 01 Jun 2013 08:35:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/S9HRNAcbIRW+pPXH5l+XNYlHNoiEN33gfC3VW2ZXhw=; b=dC9Uul+g7na5RinjQgfdGaKhZpog+bO+744H5YEItb1wqy1hUR7/A6T9WfewXwtwGH /mVCW+ywiDe7q8IYSoghjS+vXOBcYjfXttJsFafuLwrMYhzcGQ7KnqMMaSwFc6CwcuSZ CRXNP5qOHIe9jO5tyr69Qs9aqvYapiRsGXw4uJ33MWVDfXaONtMU2x6gwLsdafmSmQzy eJMq6MmsfTXw9GAAL4+K/cLN11m6WZr8krKmMLmtbSzEi/p18nVBpBRTLdMGFLMu6Pmj GcSWi6dqrMlO5DtahgyYDUFrmzRJDK3Z/Vu0FnOtPlxB9imaGqvVEuoUsgh7zYs0R8Jn fX3A== X-Received: by 10.60.79.165 with SMTP id k5mr7336708oex.108.1370100951664; Sat, 01 Jun 2013 08:35:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.79.165 with SMTP id k5mr7336704oex.108.1370100951574; Sat, 01 Jun 2013 08:35:51 -0700 (PDT) Received: by 10.76.128.68 with HTTP; Sat, 1 Jun 2013 08:35:51 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD6F69@CHAXCH01.corp.arin.net> References: <51A915A8.5070509@dnsbelgium.be> <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD6F69@CHAXCH01.corp.arin.net> Date: Sat, 1 Jun 2013 11:35:51 -0400 Message-ID: From: Joseph Yee To: Andy Newton Content-Type: multipart/alternative; boundary=089e012281b6867b6704de197cdd X-Gm-Message-State: ALoCoQmavr4g/Iv2Cuy4Ph9OMGtYFocKKDQ/9GNqq753t39zS0tTdsuiR5KP95/05kBPxmATcQHtASTWxIgAOIBEpMvp3duth/K6qw/z5L9ib9z2NFIW7a6XtbvIr2wLMNtrIU32kOHj Cc: "weirds@ietf.org" Subject: Re: [weirds] Accept-Language header X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 15:36:03 -0000 --089e012281b6867b6704de197cdd Content-Type: text/plain; charset=UTF-8 On Fri, May 31, 2013 at 5:48 PM, Andy Newton wrote: > On 5/31/13 5:27 PM, "Pieter Vandepitte" > wrote: > > >I have a question about > >http://tools.ietf.org/html/draft-ietf-weirds-using-http-05#section-9.3 > > > >What's the rationale behind the rule that servers should ignore the > >Accept-Language header? It would be nice if a client could inform the > >server about its preferred language in some way, so that e.g. a Terms of > >Use in a Notice object can be sent back in the most appropriate language > >(i.e. the language of the requester if available, otherwise english). > >The accept-language header seems the most appropriate to me in this > >case... > > I don't pretend to know the reason, but our I18N experts tell us that such > usage is inappropriate. There have been long, long discussions on > internationalization. But the result was that if you want to present the > notices in different languages, differentiate them using the 'lang' > property. I do think it will be rare for a registry to support more than a > handful of languages. > > -andy > > I personally would not say it's inappropriate, but relying on accept-language only would not achieve your goal, and in some scenarios: risky. It may be safe relatively for notice, but the way I read the draft, it meant for whole. And given the 'otherwise English' is ignoring user preference in some manner. The value of accept-language is not only language, but includes preference in fairly loose way. accept-language: es Which Spanish is user requesting? Spain Spanish? Chile Spanish? Argentina Spanish? Assuming there's difference in vocab between them accept-language: es; q=1.0, en;q=1.0 (or even just accept-language: es, en) How should it be interpreted? The preference weight both language the same. Serve only one, which one? Spanish because it's listed first? English because of server's preference? Serve both? accept-language: es; q=0.0, en; q=0.0 (could be user error, agent error, or attack. And 'now what?' Don't serve notice? Ignore and serve what you have only) Also note, the json response format for lookup is strict, there's no change of (for example) date format with different accept-language value. Sure it's more of (some) user expectation than protocol specification. But it's ignoring accept-language. And imagine how complicate it could get. The best way, IMO, is to be as specific as possible to identify what server pass back. Best Joseph P.S. ${lang} or ${lang}-${country} are the most common one, but it can be extended with region and dialect. _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --089e012281b6867b6704de197cdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 31, 2013 at 5:48 PM, Andy Newton <andy@arin.net> wrote:
On 5/31/13 5:27 PM, "Pieter Vandepitte" <pieter.vandepitte@dnsbelgium.be>
wrote:

>I have a question about
>http://tools.ietf.org/html/draft-ietf-weirds-= using-http-05#section-9.3
>
>What's the rationale behind the rule that servers should ignore the=
>Accept-Language header? It would be nice if a client could inform the >server about its preferred language in some way, so that e.g. a Terms o= f
>Use in a Notice object can be sent back in the most appropriate languag= e
>(i.e. the language of the requester if available, otherwise english). >The accept-language header seems the most appropriate to me in this
>case...

I don't pretend to know the reason, but our I18N experts tell us = that such
usage is inappropriate. There have been long, long discussions on
internationalization. But the result was that if you want to present the notices in different languages, differentiate them using the 'lang'=
property. I do think it will be rare for a registry to support more than a<= br> handful of languages.

-andy


I personally would not say it's inappropria= te, but relying on accept-language only would not achieve your goal, and in= some scenarios: risky.

It may be safe relatively for notice, but the way I read the= draft, it meant for whole.=C2=A0 And given the 'otherwise English'= is ignoring user preference in some manner.

The value of= accept-language is not only language, but includes preference in fairly lo= ose way.

accept-language: es
Which Spanish is user requesting?=C2= =A0 Spain Spanish? Chile Spanish? Argentina Spanish?=C2=A0 Assuming there&#= 39;s difference in vocab between them

accept-language: es= ; q=3D1.0, en;q=3D1.0=C2=A0 (or even just accept-language: es, en)
How should it be interpreted?=C2=A0 The preference weight both l= anguage the same.=C2=A0 Serve only one, which one? Spanish because it's= listed first?=C2=A0 English because of server's preference?=C2=A0 Serv= e both?

accept-language: es; q=3D0.0, en; q=3D0.0
(could be user= error, agent error, or attack.=C2=A0 And 'now what?' Don't ser= ve notice?=C2=A0 Ignore and serve what you have only)

Also note, the json response format for lookup is strict, there's no ch= ange of (for example) date format with different accept-language value.=C2= =A0 Sure it's more of (some) user expectation than protocol specificati= on.=C2=A0 But it's ignoring accept-language.=C2=A0 And imagine how comp= licate it could get.=C2=A0 The best way, IMO, is to be as specific as possi= ble to identify what server pass back.=C2=A0

Best
Joseph

P.S. ${lang} or = ${lang}-${country} are the most common one, but it can be extended with reg= ion and dialect.=C2=A0


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

--089e012281b6867b6704de197cdd-- From andy@arin.net Sun Jun 2 04:45:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C43F21F9F37 for ; Sun, 2 Jun 2013 04:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=-2.078, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-tt+PtP74Fr for ; Sun, 2 Jun 2013 04:45: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 823FF21F9F2F for ; Sun, 2 Jun 2013 04:45:04 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 1C69D213690; Sun, 2 Jun 2013 07:45:04 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id B9AF3213663 for ; Sun, 2 Jun 2013 07:45:03 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sun, 2 Jun 2013 07:44:44 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.104]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Sun, 2 Jun 2013 07:44:22 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: IANA registry for JSON response values Thread-Index: AQHOX4aFBfUjR25bjEu5sp0hROoxiw== Date: Sun, 2 Jun 2013 11:44:21 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD8160@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <514A0AD2254DD949893A565FF8CBF392@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] IANA registry for JSON response values X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 11:45:10 -0000 All, As work begins on the next revision of draft-ietf-weirds-json-response, I'd like opinions on an item that was mentioned in a thread a month ago. The current draft lists in the appendixes suggested values for status, event actions, variant relations, and roles. Should these be more formalized into an IANA registry so that clients can have a better understanding of their meaning and to allow an easy mechanism to add to the list of values? And if so, what type of IANA registry would be appropriate? Would Expert Review to avoid redundant registrations and keep to other similar guidelines be good enough, or would we want to require publication of a specification, publication of an RFC, etc..? -andy From superuser@gmail.com Sun Jun 2 11:06:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C8A21F85C3 for ; Sun, 2 Jun 2013 11:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1moXlFmYfRS for ; Sun, 2 Jun 2013 11:06:41 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 919A121F8AD5 for ; Sun, 2 Jun 2013 11:06:40 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id c10so2020589wiw.3 for ; Sun, 02 Jun 2013 11:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mSH99ielUSPwQClYaD14qvWLJ7ZsDwPXC0pbfWFaTLQ=; b=ev24vF6nI4CXLwBAHL2uQI3jXQfLpym5ZziaXDNEJ4x+7TZZqj5KQy+zdnTaGkC017 L9mcX7o9XUn7sVPFZ02XO91hpCNEqC6c6vOdaBdpQTG+750fJ7bybBcrP0TkFSMFwPDt vbXRWo/Nk637t1cdMM1xwNsEFz4B1PWUfMF1NcWjaJ4JgnUe4AJBMTwmc/N+K+wovyAl 20E5yWdSJI5SmbbCcElBbEh4X9ogHjhrlu+yJdDvEbLDUFB0laMUh7oyNdwaThGG4VZo wh1kLyMPW+LBoeqKf/ryj/5WaSFSbOW4fFrTf5FGVVdQSzy2K3Bh29IIqgsgGY7k98Tk rsjA== MIME-Version: 1.0 X-Received: by 10.180.212.74 with SMTP id ni10mr9685875wic.41.1370196399436; Sun, 02 Jun 2013 11:06:39 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Sun, 2 Jun 2013 11:06:39 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD8160@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD8160@CHAXCH01.corp.arin.net> Date: Sun, 2 Jun 2013 11:06:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=001a11c363baa93c0c04de2fb543 Cc: "weirds@ietf.org" Subject: Re: [weirds] IANA registry for JSON response values X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 18:06:42 -0000 --001a11c363baa93c0c04de2fb543 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 2, 2013 at 4:44 AM, Andy Newton wrote: > The current draft lists in the appendixes suggested values for status, > event actions, variant relations, and roles. Should these be more > formalized into an IANA registry so that clients can have a better > understanding of their meaning and to allow an easy mechanism to add to > the list of values? > Good question. > And if so, what type of IANA registry would be appropriate? Would Expert > Review to avoid redundant registrations and keep to other similar > guidelines be good enough, or would we want to require publication of a > specification, publication of an RFC, etc..? > Whatever we choose, we will be expected to justify our choice here, especially if it's one of the more strict levels like IETF Review, etc. There are a lot of specs that have in the past chosen the more strict ones out of fear of things that never really materialized, and the IESG is hoping to limit that as much as possible going forward. -MSK --001a11c363baa93c0c04de2fb543 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 2, 2013 at 4:44 AM, Andy Newton <andy@arin.net> wrote:
The current draft lists in the appendixes suggested values for status,
event actions, variant relations, and roles. Should these be more
formalized into an IANA registry so that clients can have a better
understanding of their meaning and to allow an easy mechanism to add to
the list of values?

Good question.
= =A0
And if so, what type of IANA registry would be appropriate? Would Expert Review to avoid redundant registrations and keep to other similar
guidelines be good enough, or would we want to require publication of a
specification, publication of an RFC, etc..?

Whatever we choose, we will be expected to justify our choice here, e= specially if it's one of the more strict levels like IETF Review, etc.= =A0 There are a lot of specs that have in the past chosen the more strict o= nes out of fear of things that never really materialized, and the IESG is h= oping to limit that as much as possible going forward.

-MSK
--001a11c363baa93c0c04de2fb543-- From superuser@gmail.com Mon Jun 3 07:55:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA04921F9998 for ; Mon, 3 Jun 2013 07:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg8vQmZmFyhp for ; Mon, 3 Jun 2013 07:55:03 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9F45F21F9985 for ; Mon, 3 Jun 2013 07:55:02 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id n12so3339399wgh.12 for ; Mon, 03 Jun 2013 07:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tejp1//pcrrn6lh20L5fuKPtZr4ozn92BuJ/xFiKcAk=; b=M25gNJr8Q7T/dKK/eX5dxUf0G9xWVaMGxXtIUYpVFuthSpc+lBZYkp/VgvYw9NWg6L itjUjVAt5s3ruxjCL+uaCInUX9fvxlGHC4cFivQNxLV7vhU7QFhsDM9SE7sCoTgd/IVV uyNuYuYr+182fDldRL1PMlq5g3HtKv9i3VZE0qhERUiTWEhgZkA42HystXDu0RgMXxT/ FxWI63zuDA90JmcYBUos9cv/LY8E7utW3o85VF89lybIvPFGwJxMjBljnKi9LOIA/1aF KsB/Y5YcY24cedcdwSGJsImzHHa8QDfVsE5UN7WWNm8KG9IZ3giXvnp1ct1LQwTm0lCj AF6Q== MIME-Version: 1.0 X-Received: by 10.180.206.235 with SMTP id lr11mr13252079wic.59.1370271301769; Mon, 03 Jun 2013 07:55:01 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Mon, 3 Jun 2013 07:55:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Jun 2013 07:55:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c333a63021b904de412638 Subject: Re: [weirds] Call for IETF 87 (Berlin) agenda items X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:55:03 -0000 --001a11c333a63021b904de412638 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 20, 2013 at 5:01 PM, Murray S. Kucherawy wrote: > Colleagues, > > Scheduling of working group sessions for IETF 87 is now open. The due > date for a meeting request is June 3rd (two weeks). As usual, the > questions we have for the group are: > > 1) Do you think we need to meet? > > 2) If "yes", do you have specific open issues you'd like to discuss? > These can be open document issues, presentations relevant to document > development, procedural discussions, etc. > > 3) Are there any specific presentations we should seek out? > > > I only received one reply to this for two short topics. We have to make the meeting request today, in fact within a matter of hours. So, last call...! -MSK --001a11c333a63021b904de412638 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 20, 2013 at 5:01 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
Colleagues,

Scheduling of working group sessions for IETF 87 is now open.=A0 The d= ue date for a meeting request is June 3rd (two weeks).=A0 As usual, the que= stions we have for the group are:

1) Do you think we need to meet?

2) If &qu= ot;yes", do you have specific open issues you'd like to discuss?= =A0 These can be open document issues, presentations relevant to document d= evelopment, procedural discussions, etc.

3) Are there any specific presentations we should seek out?<= br>



I only received one reply to this for two short topics.=A0 We have to make = the meeting request today, in fact within a matter of hours.=A0 So, last ca= ll...!

-MSK
--001a11c333a63021b904de412638-- From nkong@cnnic.cn Mon Jun 3 08:31:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6991E11E80A4 for ; Mon, 3 Jun 2013 08:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1shgSuHDAEZ for ; Mon, 3 Jun 2013 08:31:24 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id DF18811E80D1 for ; Mon, 3 Jun 2013 08:31:23 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [192.168.1.112]) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 03 Jun 2013 23:31:14 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ning Kong In-Reply-To: Date: Mon, 3 Jun 2013 23:31:19 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8F0FB357-A735-4A29-A381-3CFEB2FE83C0@cnnic.cn> References: To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1503) Cc: "weirds@ietf.org" Subject: Re: [weirds] Call for IETF 87 (Berlin) agenda items X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 15:31:29 -0000 > 1) Do you think we need to meet? Yes. > 2) If "yes", do you have specific open issues you'd like to discuss? = These can be open document issues, presentations relevant to document = development, procedural discussions, etc. IMO, both redirect and search need to be further discussed. > 3) Are there any specific presentations we should seek out? Redirect and search. Cheers, Ning= From internet-drafts@ietf.org Mon Jun 3 09:28:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3425D11E80D2; Mon, 3 Jun 2013 09:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3JnkzJemKOt; Mon, 3 Jun 2013 09:28:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF06521F9310; Mon, 3 Jun 2013 09:28:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603162834.7372.37348.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 09:28:34 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 16:28:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Security Services for the Registration Data Access Proto= col Author(s) : Scott Hollenbeck Ning Kong Filename : draft-ietf-weirds-rdap-sec-04.txt Pages : 10 Date : 2013-06-03 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-sec-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shollenbeck@verisign.com Mon Jun 3 09:29:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768C811E80A4 for ; Mon, 3 Jun 2013 09:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plLrm-nxqLKR for ; Mon, 3 Jun 2013 09:29:52 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2BA21F934B for ; Mon, 3 Jun 2013 09:29:51 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUazEf+AJIpG5ewyO6MKLQihzUTJs1bXy@postini.com; Mon, 03 Jun 2013 09:29:52 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r53GTlmY009488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 12:29:48 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 3 Jun 2013 12:29:47 -0400 From: "Hollenbeck, Scott" To: Pete Resnick , "weirds@ietf.org" Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 Thread-Index: AQHOXIqoS2b5MIkv0UCoWcNg6C3lGJkkNdFw Date: Mon, 3 Jun 2013 16:29:46 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2439FE3D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <51A62E7B.1020906@qti.qualcomm.com> In-Reply-To: <51A62E7B.1020906@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 Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 16:29:56 -0000 I just posted draft-ietf-weirds-rdap-sec-04 to address Pete's comments. Scott > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Pete Resnick > Sent: Wednesday, May 29, 2013 12:36 PM > To: weirds@ietf.org > Subject: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 >=20 > As with -using-http, please give the authors and/or Murray the chance > to > respond first: >=20 > Overall, I'm not clear on why this wasn't folded in to the -using-http > document, more or less as the security considerations section, but I > have no objection to keeping them separate. >=20 > Section 3.1: >=20 > RDAP MUST include an authentication framework that can accommodate > anonymous access as well as verification of identities using a > range > of authentication methods and credential services. >=20 > Specifying that a protocol MUST do something (as against an > implementation or an actor in the protocol) is...weird. Don't you > really > mean, "RDAP's authentication framework needs to accomodate..."? There > are no specific protocol/implementation requirements here. >=20 > Section 3.2: >=20 > RDAP MUST include an authorization framework that is capable of > providing granular (per registration data object) access controls > according to the policies of the operator. >=20 > The same as in 3.1. I suggest, "An RDAP server MUST provide granular > access controls (that is, on a per registration data object basis) in > order to implement authorization policies." >=20 > RFCs 4732, 5280, and 6749 strike me as Informative, not Normative > references. >=20 > pr >=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 edainow@afilias.info Mon Jun 3 11:00:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0429E21F94BA for ; Mon, 3 Jun 2013 11:00:03 -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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHMH0rSFDGmr for ; Mon, 3 Jun 2013 10:59:46 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 69B3121F85B4 for ; Mon, 3 Jun 2013 10:58:39 -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 1UjZ1i-0002iR-4g for weirds@ietf.org; Mon, 03 Jun 2013 17:58:38 +0000 Received: from mail-lb0-f176.google.com ([209.85.217.176]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UjZ1i-0003Ip-48 for weirds@ietf.org; Mon, 03 Jun 2013 17:58:38 +0000 Received: by mail-lb0-f176.google.com with SMTP id z5so806414lbh.7 for ; Mon, 03 Jun 2013 10:58:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=scGoMy6BHX/NaVh7wY4Wggq9gpf7vCeORM2kBAOYsHc=; b=GeV/2zR8xDt2rZGq8Fxk9+zb/rwsFrr4MpOXP8f819AI9ZuKkaACC8zncgHIwtWR2e wLlVOqQeBgoGpsYX8FXadGdAlW1QFO1d/74EJDZy8+C7dUimHvm/mxBABnTJQv/islx3 hc9RMbC2+k66abgqq9ckxPDDOs/Lgfaco1XqEQHQ83l1oHSw4ps1gSUOveS8sVNMjbuh z3ohzylonzSa8REqEMkltasJxg8wqRQINPtPdu9r/2t/WGZ6ldw4hS+x1trQiywl8CQw UuixG47pAMw/DyzXoiCiKygO3mqu4O8u2/mGRFoEUQI3D2vUZvHwVLiDgsg/H8cUN5Ta v5NQ== X-Received: by 10.112.33.17 with SMTP id n17mr11254969lbi.72.1370282311957; Mon, 03 Jun 2013 10:58:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.33.17 with SMTP id n17mr11254961lbi.72.1370282311782; Mon, 03 Jun 2013 10:58:31 -0700 (PDT) Received: by 10.112.25.33 with HTTP; Mon, 3 Jun 2013 10:58:31 -0700 (PDT) Date: Mon, 3 Jun 2013 13:58:31 -0400 Message-ID: From: Ernie Dainow To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=14dae93d94466faa1004de43b6c0 X-Gm-Message-State: ALoCoQnetC4fDiFFAKlm9nwNtuHTLKJ8ne4rIq4KCGc7737n2GLpPfPqG77ukxAQV3UQ4L/67dfDikHfwu/3gPUpJ5FBhsez5atVRIebKl4XsFtdffizwYeXy7RDUAfbNyDM2vGGJ/9l Subject: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:00:03 -0000 --14dae93d94466faa1004de43b6c0 Content-Type: text/plain; charset=ISO-8859-1 There are a number of fields defined in ICANN Registry Agreements that are not reflected in draft-ietf-weirds-json-response-03. As contractual requirements, some registries will need to report them. I think it would be best to define standard RDAP elements for these. A few examples I have come across are: Domain Object: ENS_AuthID Maintainer URL (email) Sponsoring Registrar IANA ID Nameserver Object: Currently Associated (true/false) IP addresses associated Contact (Entity): Currently Associated (true/false) Registrar (Entity): Referral URL: Registrar IANA ID It might be worth a more complete and systematic search of existing ICANN contracts to locate other missing fields. This could be a useful addition to draft-ietf-weirds-object-inventory. http://www.icann.org/en/about/agreements/registries -Ernie --14dae93d94466faa1004de43b6c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are a number of fields defined in ICANN Registr= y Agreements that are not reflected in draft-ietf-weirds-json-response-03. = As contractual requirements, some registries will need to report them. I th= ink it would be best to define standard RDAP elements for these.=A0

A few examples I have come across are:

Domain Object:
=A0 ENS_AuthID
=A0 Maintainer U= RL (email)
=A0 Sponsoring Registrar IANA ID

<= div> Nameserver Object:
=A0 Currently Associated (true/false)
=A0 IP addresses associated
=A0
Contact (Entity):
=A0 Currently Ass= ociated (true/false)

Registrar (Entity): =A0
=A0 Referral URL:
=A0 Registrar IANA ID

It might be worth a m= ore complete and systematic search of existing ICANN contracts to locate ot= her missing fields. This could be a useful addition to draft-ietf-weirds-ob= ject-inventory.

=
-Ernie

--14dae93d94466faa1004de43b6c0-- From francisco.arias@icann.org Mon Jun 3 11:13:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503CD21E808B for ; Mon, 3 Jun 2013 11:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWzvzUC4BPmt for ; Mon, 3 Jun 2013 11:13:01 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB1A21F84EF for ; Mon, 3 Jun 2013 11:11:36 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 3 Jun 2013 11:11:35 -0700 From: Francisco Arias To: Ernie Dainow , "weirds@ietf.org" Date: Mon, 3 Jun 2013 11:11:36 -0700 Thread-Topic: [weirds] ICANN Whois Specifications Thread-Index: Ac5ghcjEuIFxZ/hoQrWY+0J8/sh38Q== 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.4.130416 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CDD22A4D1C4D8franciscoariasicannorg_" MIME-Version: 1.0 Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:13:17 -0000 --_000_CDD22A4D1C4D8franciscoariasicannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps Steve's message http://www.ietf.org/mail-archive/web/weirds/current= /msg01153.html could be a useful start point. -- Francisco. On 6/3/13 10:58 AM, "Ernie Dainow" > wrote: There are a number of fields defined in ICANN Registry Agreements that are = not reflected in draft-ietf-weirds-json-response-03. As contractual require= ments, some registries will need to report them. I think it would be best t= o define standard RDAP elements for these. A few examples I have come across are: Domain Object: ENS_AuthID Maintainer URL (email) Sponsoring Registrar IANA ID Nameserver Object: Currently Associated (true/false) IP addresses associated Contact (Entity): Currently Associated (true/false) Registrar (Entity): Referral URL: Registrar IANA ID It might be worth a more complete and systematic search of existing ICANN c= ontracts to locate other missing fields. This could be a useful addition to= draft-ietf-weirds-object-inventory. http://www.icann.org/en/about/agreements/registries -Ernie --_000_CDD22A4D1C4D8franciscoariasicannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Perhaps Steve'= s message http://www.ietf.org/mail-archive/web/weirds/current/msg01= 153.html could be a useful start point.

-- 
Francisco.


On 6/3/1= 3 10:58 AM, "Ernie Dainow" <edai= now@afilias.info> wrote:

There are = a number of fields defined in ICANN Registry Agreements that are not reflec= ted in draft-ietf-weirds-json-response-03. As contractual requirements, som= e registries will need to report them. I think it would be best to define s= tandard RDAP elements for these. 

A few examples I have come acros= s are:

Domain Object:
  ENS_AuthID<= /div>
  Maintainer URL (email)
  Sponsoring Registr= ar IANA ID

Nameserver Object:
  Cur= rently Associated (true/false)
  IP addresses associated
 
C= ontact (Entity):
  Currently Associated (true/false)

Registrar (Entity):  
  Referral URL:=
  Registrar IANA ID

It might be wo= rth a more complete and systematic search of existing ICANN contracts to lo= cate other missing fields. This could be a useful addition to draft-ietf-we= irds-object-inventory.



 --_000_CDD22A4D1C4D8franciscoariasicannorg_-- From shollenbeck@verisign.com Mon Jun 3 11:42:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DAB21F8F78 for ; Mon, 3 Jun 2013 11:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUQHS+Fowwgh for ; Mon, 3 Jun 2013 11:42:24 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2793C21F8ECB for ; Mon, 3 Jun 2013 11:40:53 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUazjNF4YHr5bStTabQuLgJdiHEao1mu9@postini.com; Mon, 03 Jun 2013 11:41:13 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r53Ien26014061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 14:40:49 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 3 Jun 2013 14:40:49 -0400 From: "Hollenbeck, Scott" To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] ICANN Whois Specifications Thread-Index: AQHOYIRWJyLklf+ZP0ynoKtIyKQYXpkkTfUA Date: Mon, 3 Jun 2013 18:40:48 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2439FFC9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F2439FFC9BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:42:39 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F2439FFC9BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Ernie Dainow Sent: Monday, June 03, 2013 1:59 PM To: weirds@ietf.org Subject: [weirds] ICANN Whois Specifications There are a number of fields defined in ICANN Registry Agreements that are = not reflected in draft-ietf-weirds-json-response-03. As contractual require= ments, some registries will need to report them. I think it would be best t= o define standard RDAP elements for these. These requirements refer to today's existing *WHOIS* services. Whether or n= ot they are appropriate additions to RDAP is open to debate. I agree that w= e should look at them, but I do not think they should be blindly included j= ust because they're part of the legacy system. To be included in RDAP they = need to be useful to a large portion of the community. This is one of the reasons I've been discouraging use of the term "RESTful = WHOIS" to describe our work. Saddling ourselves with the WHOIS data model m= eans we're stuck with perpetuating the inefficiencies that come along with = it. Scott --_000_831693C2CDA2E849A7D7A712B24E257F2439FFC9BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Ernie Dainow
Sent: Monday, June 03, 2013 1:59 PM
To: weirds@ietf.org
Subject: [weirds] ICANN Whois Specifications

 

There are a number of fields defined in ICANN Regist= ry Agreements that are not reflected in draft-ietf-weirds-json-response-03.= As contractual requirements, some registries will need to report them. I t= hink it would be best to define standard RDAP elements for these. 

 

These requirements refer to today’s = existing *WHOIS* services. Whether or not they are appropriate addit= ions to RDAP is open to debate. I agree that we should look at them, but I do not think they should be blindly included just because they= ’re part of the legacy system. To be included in RDAP they need to be= useful to a large portion of the community.

 

This is one of the reasons I’ve been= discouraging use of the term “RESTful WHOIS” to describe our w= ork. Saddling ourselves with the WHOIS data model means we’re stuck w= ith perpetuating the inefficiencies that come along with it.

 

Scott

 

--_000_831693C2CDA2E849A7D7A712B24E257F2439FFC9BRN1WNEXMBX01vc_-- From superuser@gmail.com Mon Jun 3 12:16:31 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC7C11E80D9 for ; Mon, 3 Jun 2013 12:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPW1ha-X8ndt for ; Mon, 3 Jun 2013 12:16:21 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id D7C631F0D44 for ; Mon, 3 Jun 2013 12:09:46 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi5so3002028wib.2 for ; Mon, 03 Jun 2013 12:09:46 -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=5rr1PYhEe4RDBhIUKST2bM+qQAq8A9/47TBEhy6e6PQ=; b=E7hs5VZ12J+xQPUhflhZWLM0bYDtRBodG1QVWYZrsLXsRm4YoU1oH+rbW5yHDQ7uw8 izKl8WK1v2OUTZ206xpI4NnpKdKdAe3TnoTTdA4IkjFbUnnbSpjd0p+IqcssEaasAtCW AckXUwfFPCar3au2dGgY09ScxNmSNLeTr8PIsuYFwnnqpae5sRLUwrMqFxtLTMrFzqMg HqUCLY78+FE/ZbuL4KCR5V9lkAUT1PxAknSSujasqybFQs02pYIyFbDaiYSlBf7HZKN6 LKQZ9USLoa9SX5UVZ0teMxyIIFk5mPySbcplTZ3N5OEIWCV4Ra8r9wv1sEEdeB6Eg1bM vjjw== MIME-Version: 1.0 X-Received: by 10.180.206.235 with SMTP id lr11mr14285537wic.59.1370286586054; Mon, 03 Jun 2013 12:09:46 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Mon, 3 Jun 2013 12:09:45 -0700 (PDT) In-Reply-To: <8F0FB357-A735-4A29-A381-3CFEB2FE83C0@cnnic.cn> References: <8F0FB357-A735-4A29-A381-3CFEB2FE83C0@cnnic.cn> Date: Mon, 3 Jun 2013 12:09:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ning Kong Content-Type: multipart/alternative; boundary=001a11c333a633cf2f04de44b55b Cc: "weirds@ietf.org" Subject: Re: [weirds] Call for IETF 87 (Berlin) agenda items X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 19:16:31 -0000 --001a11c333a633cf2f04de44b55b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 8:31 AM, Ning Kong wrote: > > > 1) Do you think we need to meet? > Yes. > > > 2) If "yes", do you have specific open issues you'd like to discuss? > These can be open document issues, presentations relevant to document > development, procedural discussions, etc. > IMO, both redirect and search need to be further discussed. > > > 3) Are there any specific presentations we should seek out? > Redirect and search. > > > Anyone want to volunteer? -MSK --001a11c333a633cf2f04de44b55b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --001a11c333a633cf2f04de44b55b-- From aservin@lacnic.net Mon Jun 3 12:46:23 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E4B1F0D3E for ; Mon, 3 Jun 2013 12:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqAC1X55D8tH for ; Mon, 3 Jun 2013 12:46:09 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id A0B7821E80DA for ; Mon, 3 Jun 2013 12:35:09 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [200.7.87.33]) by mail.lacnic.net.uy (Postfix) with ESMTP id 216A030841C; Mon, 3 Jun 2013 16:34:53 -0300 (UYT) Message-ID: <51ACEFEA.6040700@lacnic.net> Date: Mon, 03 Jun 2013 16:35:06 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <8F0FB357-A735-4A29-A381-3CFEB2FE83C0@cnnic.cn> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] Call for IETF 87 (Berlin) agenda items X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 19:46:23 -0000 Not sure if I follow, but about "Redirects" the authors of the drafts could lead. Carlos is going to push a new version soon. We could use that as a starting point. Regards, /as On 6/3/13 4:09 PM, Murray S. Kucherawy wrote: > On Mon, Jun 3, 2013 at 8:31 AM, Ning Kong > wrote: > > > > 1) Do you think we need to meet? > Yes. > > > 2) If "yes", do you have specific open issues you'd like to > discuss? These can be open document issues, presentations relevant > to document development, procedural discussions, etc. > IMO, both redirect and search need to be further discussed. > > > 3) Are there any specific presentations we should seek out? > Redirect and search. > > > > Anyone want to volunteer? > > -MSK > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From carlosm3011@gmail.com Mon Jun 3 12:56:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F226521F915C for ; Mon, 3 Jun 2013 12:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG6Hk1qNJl3r for ; Mon, 3 Jun 2013 12:56:17 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B1C421F0D4D for ; Mon, 3 Jun 2013 12:48:51 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id jw11so3175329veb.18 for ; Mon, 03 Jun 2013 12:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HTeFFJMGkAwGuwfL/jXofnD7uF8Y0S4cozlGwCBQ+ak=; b=xVvS6O+D3aQIINoGMuRi/d3PKFFrSqH4Uaa0AbO+KQidzQQD0G/vOlveGsPzIcOUXP f1W6yrQfwxMyxj+tdztHSX8k+piYlTHOyYvp4cEYGSYp3DVLNDlNJijMkrMBunWYZY2I YbKNoMbBhQQem8qrlgMdhvdLWzQJ3y4iZrawZOHpZwKvqg2JJX6PEkQPhhg9Y+TEvuV5 fw/S9SvJIsTuJG8YTKC+wStqjJhJumwXaRL8SC/TyibxDm3XNTGvEAEdTsSJVltd64SM 7g9dq4G4kyxxIrXAhkyrdl2mjTbV7egnxO2jRXqrbpmpXeFNNX1xeE6hy4BCXAUbqEbY FVnw== X-Received: by 10.220.138.13 with SMTP id y13mr17485283vct.59.1370288931132; Mon, 03 Jun 2013 12:48:51 -0700 (PDT) Received: from europa.local ([2001:470:d815:fe0:80ef:ef2d:6e2:c2e6]) by mx.google.com with ESMTPSA id ih10sm42662758vdb.1.2013.06.03.12.48.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 12:48:50 -0700 (PDT) Message-ID: <51ACF31E.1000701@gmail.com> Date: Mon, 03 Jun 2013 16:48:46 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Arturo Servin References: <8F0FB357-A735-4A29-A381-3CFEB2FE83C0@cnnic.cn> <51ACEFEA.6040700@lacnic.net> In-Reply-To: <51ACEFEA.6040700@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Call for IETF 87 (Berlin) agenda items X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 19:56:27 -0000 If the WG can provide a little more input on what specific aspect of redirects you want discussed, it'd be great. So, yes (thanks Arturo for putting me forward, this will not be forgotten :D ) I can lead the redirect item. regards ~Carlos On 6/3/13 4:35 PM, Arturo Servin wrote: > > Not sure if I follow, but about "Redirects" the authors of the drafts > could lead. > > Carlos is going to push a new version soon. We could use that as a > starting point. > > Regards, > /as > > > > On 6/3/13 4:09 PM, Murray S. Kucherawy wrote: >> On Mon, Jun 3, 2013 at 8:31 AM, Ning Kong > > wrote: >> >> >> > 1) Do you think we need to meet? >> Yes. >> >> > 2) If "yes", do you have specific open issues you'd like to >> discuss? These can be open document issues, presentations relevant >> to document development, procedural discussions, etc. >> IMO, both redirect and search need to be further discussed. >> >> > 3) Are there any specific presentations we should seek out? >> Redirect and search. >> >> >> >> Anyone want to volunteer? >> >> -MSK >> >> >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >> > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Mon Jun 3 18:29:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A77021F992A for ; Mon, 3 Jun 2013 18:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.412 X-Spam-Level: X-Spam-Status: No, score=-7.412 tagged_above=-999 required=5 tests=[AWL=3.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byDLEv7tsQcv for ; Mon, 3 Jun 2013 18:29:17 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5E03F21E80A9 for ; Mon, 3 Jun 2013 17:46:44 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 02E8E213653; Mon, 3 Jun 2013 20:46:14 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 710C22134FC; Mon, 3 Jun 2013 20:46:11 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 3 Jun 2013 20:46:04 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.104]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Mon, 3 Jun 2013 20:45:48 -0400 From: Andy Newton To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] ICANN Whois Specifications Thread-Index: AQHOYIQ2weBqCM/1Bk2sY5mV/PjGWpkkuKMA Date: Tue, 4 Jun 2013 00:45:47 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD898D@CHAXCH01.corp.arin.net> 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.4.130416 x-originating-ip: [192.149.252.97] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DD898DCHAXCH01corpari_" MIME-Version: 1.0 Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:29:33 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DD898DCHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ernie, Thanks for putting this together. Some of these are already covered through= other structures. For instance, email addresses are already accounted for = in jCard and URLs in links. I do think registrar ID should be added as it shows up in a lot of whois se= rvers and there is an IANA registry for them. Some of the others do not have an explanation. What is an ENS_AuthID? And w= hat does "Currently Associated" mean? I don't think we should blindly put i= n items we don't understand. -andy From: Ernie Dainow > Date: Monday, June 3, 2013 1:58 PM To: "weirds@ietf.org" > Subject: [weirds] ICANN Whois Specifications There are a number of fields defined in ICANN Registry Agreements that are = not reflected in draft-ietf-weirds-json-response-03. As contractual require= ments, some registries will need to report them. I think it would be best t= o define standard RDAP elements for these. A few examples I have come across are: Domain Object: ENS_AuthID Maintainer URL (email) Sponsoring Registrar IANA ID Nameserver Object: Currently Associated (true/false) IP addresses associated Contact (Entity): Currently Associated (true/false) Registrar (Entity): Referral URL: Registrar IANA ID It might be worth a more complete and systematic search of existing ICANN c= ontracts to locate other missing fields. This could be a useful addition to= draft-ietf-weirds-object-inventory. http://www.icann.org/en/about/agreements/registries -Ernie --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DD898DCHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <26CD3A78D51D9C429E227444F17A9688@corp.arin.net> Content-Transfer-Encoding: quoted-printable
Ernie,

Thanks for putting this together. Some of these are already covered th= rough other structures. For instance, email addresses are already accounted= for in jCard and URLs in links.

I do think registrar ID should be added as it shows up in a lot of who= is servers and there is an IANA registry for them.

Some of the others do not have an explanation. What is an ENS_AuthID? = And what does "Currently Associated" mean? I don't think we shoul= d blindly put in items we don't understand.

-andy

From: Ernie Dainow <edainow@afilias.info>
Date: Monday, June 3, 2013 1:58 PM<= br> To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: [weirds] ICANN Whois Speci= fications

There are a number of fields defined in ICANN Registry Agreements that= are not reflected in draft-ietf-weirds-json-response-03. As contractual re= quirements, some registries will need to report them. I think it would be b= est to define standard RDAP elements for these. 

A few examples I have come across are:

Domain Object:
  ENS_AuthID
  Maintainer URL (email)
  Sponsoring Registrar IANA ID

Nameserver Object:
  Currently Associated (true/false)
  IP addresses associated
 
Contact (Entity):
  Currently Associated (true/false)

Registrar (Entity):  
  Referral URL:
  Registrar IANA ID

It might be worth a more complete and systematic search of existing IC= ANN contracts to locate other missing fields. This could be a useful additi= on to draft-ietf-weirds-object-inventory.


-Ernie



--_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DD898DCHAXCH01corpari_-- From nkong@cnnic.cn Mon Jun 3 18:31:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4715121F998D for ; Mon, 3 Jun 2013 18:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxx4I4X5363g for ; Mon, 3 Jun 2013 18:31:07 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 466B621E80D1 for ; Mon, 3 Jun 2013 17:50:06 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [218.241.103.124]) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 04 Jun 2013 08:49:17 +0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_364D208D-2A2C-429B-92F2-32770563ECA3" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ning Kong In-Reply-To: Date: Tue, 4 Jun 2013 08:49:15 +0800 Message-Id: <73BF75A1-A142-4E07-B873-D4926FD520A6@cnnic.cn> References: <8F0FB357-A735-4A29-A381-3CFEB2FE83C0@cnnic.cn> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1503) Cc: weirds@ietf.org Subject: Re: [weirds] Call for IETF 87 (Berlin) agenda items X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:31:21 -0000 --Apple-Mail=_364D208D-2A2C-429B-92F2-32770563ECA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I'd like to lead the discussion of search. Ning > On Mon, Jun 3, 2013 at 8:31 AM, Ning Kong wrote: >=20 > > 1) Do you think we need to meet? > Yes. >=20 > > 2) If "yes", do you have specific open issues you'd like to discuss? = These can be open document issues, presentations relevant to document = development, procedural discussions, etc. > IMO, both redirect and search need to be further discussed. >=20 > > 3) Are there any specific presentations we should seek out? > Redirect and search. >=20 >=20 >=20 > Anyone want to volunteer? >=20 > -MSK=20 --Apple-Mail=_364D208D-2A2C-429B-92F2-32770563ECA3 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
I'd like to lead the discussion of search.

Ning

On Mon, Jun 3, 2013 at 8:31 AM, Ning Kong <nkong@cnnic.cn> wrote:

> 1) Do you think we need to meet?
Yes.

> 2) If "yes", do you have specific open issues you'd like to discuss?  These can be open document issues, presentations relevant to document development, procedural discussions, etc.
IMO, both redirect and search need to be further discussed.

> 3) Are there any specific presentations we should seek out?
Redirect and search.



Anyone want to volunteer?

-MSK

--Apple-Mail=_364D208D-2A2C-429B-92F2-32770563ECA3-- From james.mitchell@ausregistry.com.au Mon Jun 3 21:57:53 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339A121F81FE for ; Mon, 3 Jun 2013 21:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC-efx5Myo7K for ; Mon, 3 Jun 2013 21:57:39 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [120.29.255.35]) by ietfa.amsl.com (Postfix) with ESMTP id DD68321F99BA for ; Mon, 3 Jun 2013 21:04:45 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 04 Jun 2013 14:04:40 +1000 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Tue, 4 Jun 2013 14:04:42 +1000 From: James Mitchell To: Andy Newton , Ernie Dainow , "weirds@ietf.org" Date: Tue, 4 Jun 2013 14:04:34 +1000 Thread-Topic: [weirds] ICANN Whois Specifications Thread-Index: Ac5g2KPWJdV6n4BYS6yc9vgmcD6iuw== Message-ID: In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD898D@CHAXCH01.corp.arin.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CDD39FFA99F64jamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 04:57:53 -0000 --_000_CDD39FFA99F64jamesmitchellausregistrycomau_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have seen ICANN use the term GURID (Globally Unique R-something ID?) for = the IANA ID (https://radar.icann.org). .au does not require registrars to be ICANN accredited, instead a locally-u= nique identifier is used (the identifier used in EPP to indicate sponsoring= registrar). I see no reason why a registrar cannot have both a locally-uni= que identifier and a globally-unique identifier. The locally unique identif= ier may or may not meet the ROID syntax requirements of RFC5730. James From: Andy Newton > Date: Tuesday, 4 June 2013 10:45 AM To: Ernie Dainow >, "weir= ds@ietf.org" > Subject: Re: [weirds] ICANN Whois Specifications Ernie, Thanks for putting this together. Some of these are already covered through= other structures. For instance, email addresses are already accounted for = in jCard and URLs in links. I do think registrar ID should be added as it shows up in a lot of whois se= rvers and there is an IANA registry for them. Some of the others do not have an explanation. What is an ENS_AuthID? And w= hat does "Currently Associated" mean? I don't think we should blindly put i= n items we don't understand. -andy From: Ernie Dainow > Date: Monday, June 3, 2013 1:58 PM To: "weirds@ietf.org" > Subject: [weirds] ICANN Whois Specifications There are a number of fields defined in ICANN Registry Agreements that are = not reflected in draft-ietf-weirds-json-response-03. As contractual require= ments, some registries will need to report them. I think it would be best t= o define standard RDAP elements for these. A few examples I have come across are: Domain Object: ENS_AuthID Maintainer URL (email) Sponsoring Registrar IANA ID Nameserver Object: Currently Associated (true/false) IP addresses associated Contact (Entity): Currently Associated (true/false) Registrar (Entity): Referral URL: Registrar IANA ID It might be worth a more complete and systematic search of existing ICANN c= ontracts to locate other missing fields. This could be a useful addition to= draft-ietf-weirds-object-inventory. http://www.icann.org/en/about/agreements/registries -Ernie --_000_CDD39FFA99F64jamesmitchellausregistrycomau_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have seen ICANN use th= e term GURID (Globally Unique R-something ID?) for the IANA ID (https://radar.icann.org).

<= /div>
.au does not require registrars to be ICANN accredited, instead a= locally-unique identifier is used (the identifier used in EPP to indicate = sponsoring registrar). I see no reason why a registrar cannot have both a l= ocally-unique identifier and a globally-unique identifier. The locally uniq= ue identifier may or may not meet the ROID syntax requirements of RFC5730.<= /div>

James

From: Andy Newton <andy@arin.net>
Date: T= uesday, 4 June 2013 10:45 AM
To: Ernie Dainow <edainow@afilias.= info>, "weirds@ietf.org" <= weirds@ietf.org>
Subject: Re: [weirds] ICANN Whois Specificati= ons

Ernie,
=

Thanks for putting this together. Some of these are alr= eady covered through other structures. For instance, email addresses are al= ready accounted for in jCard and URLs in links.

I = do think registrar ID should be added as it shows up in a lot of whois serv= ers and there is an IANA registry for them.

Some o= f the others do not have an explanation. What is an ENS_AuthID? And what do= es "Currently Associated" mean? I don't think we should blindly put in item= s we don't understand.

-andy

<= span id=3D"OLK_SRC_BODY_SECTION">





= --_000_CDD39FFA99F64jamesmitchellausregistrycomau_-- From johnl@iecc.com Tue Jun 4 00:36:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17E321F9193 for ; Tue, 4 Jun 2013 00:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyNtozybRtVO for ; Tue, 4 Jun 2013 00:36:25 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EAA9E21F8FB6 for ; Mon, 3 Jun 2013 23:41:41 -0700 (PDT) Received: (qmail 61489 invoked from network); 4 Jun 2013 06:41:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 4 Jun 2013 06:41:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51ad8c24.xn--i8sz2z.k1306; i=johnl@user.iecc.com; bh=MQzgSQgbuqSUUG/ViYBQx62fUWPaws+DwD9MK8CHZlU=; b=lvJXC+1VGAzsUsu3yee9HrwLGjDShLkuwmfEZz0zBOKeH6Qd+fuVaXEQptT0kaNRf9zItfCW1/OjqVGlyB+5RPqp4dyosvBvB808qyeN91q+qrOIVJ29H7VsJHa7C4VxAeYKNrvN7I7S/K+JosYIQFg5gPk0vDp84G54cMUbAS9n+7vSZi0YKgokImtQFkJtJVbI58ZwC9+if2UwNEV/kWay8OWYWYArFajmWRYBCpmJSraEtzcl9EBquPK9VmYP DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51ad8c24.xn--i8sz2z.k1306; olt=johnl@user.iecc.com; bh=MQzgSQgbuqSUUG/ViYBQx62fUWPaws+DwD9MK8CHZlU=; b=Yvp/iH9MhK7OpQ2Rgf8adgTh82o1aka/RsLmt7a5z1ZQPQHrDgRGcUPjT9Sg613sG6SZZF05SV36BthDBb/pOAmRrSvDM6IZEaC277irAoB9Hb7BcRHvsxiuGLp8GFdFF8iV1HrmT6LGJfykSM1zEeLRiL5r5kyIqWm4ORQ2NuSPtx5q9E6gcWKnSJk2HWpignerrn0TTQbUZ4ZiDjj7F1PRMczBAAYqRbsnQRo9T3SdpdpmOoEQ8C/PR5WdE9tf Date: 4 Jun 2013 06:41:18 -0000 Message-ID: <20130604064118.11765.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] Call for IETF 87 (Berlin) agenda items X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 07:36:38 -0000 We punted bootstrapping. I believe someone has a draft almost ready to go, and since it was contentious last time it would probably be useful to see if it still is. If the guy with the I-D won't be in Berlin, I think I understand it well enough to present it. From andy@arin.net Tue Jun 4 05:46:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E3F21F9B89 for ; Tue, 4 Jun 2013 05:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.05 X-Spam-Level: X-Spam-Status: No, score=-4.05 tagged_above=-999 required=5 tests=[AWL=-1.451, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlCVJsoTCiWR for ; Tue, 4 Jun 2013 05:46:12 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 757FD21F9CE2 for ; Tue, 4 Jun 2013 04:20:09 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 12A2A164FCC; Tue, 4 Jun 2013 07:20:05 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 9E584164F9F; Tue, 4 Jun 2013 07:20:02 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 4 Jun 2013 07:19:48 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.69]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 07:19:56 -0400 From: Andy Newton To: James Mitchell , Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] ICANN Whois Specifications Thread-Index: AQHOYIQ2weBqCM/1Bk2sY5mV/PjGWpkkuKMAgAB6oQCAADaRAA== Date: Tue, 4 Jun 2013 11:19:55 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DDDBAC@CHAXCH02.corp.arin.net> 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.4.130416 x-originating-ip: [192.149.252.96] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DDDBACCHAXCH02corpari_" MIME-Version: 1.0 Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 12:46:30 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DDDBACCHAXCH02corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: James Mitchell > Date: Tuesday, June 4, 2013 12:04 AM To: Andrew Newton >, Ernie Dainow >, "weirds@ietf.org" > Subject: Re: [weirds] ICANN Whois Specifications I have seen ICANN use the term GURID (Globally Unique R-something ID?) for = the IANA ID (https://radar.icann.org). .au does not require registrars to be ICANN accredited, instead a locally-u= nique identifier is used (the identifier used in EPP to indicate sponsoring= registrar). I see no reason why a registrar cannot have both a locally-uni= que identifier and a globally-unique identifier. The locally unique identif= ier may or may not meet the ROID syntax requirements of RFC5730. James, Here is what I plan to put in the next draft. I think it meets your needs o= f having both types of identifiers: "publicIds" : [ { "type": "IANA Registrar ID", "identifier" : "1" } ], o publicIds - an array of objects, with each object containing the following memebers: * type - a string denoting the type of public identifier * identifier - a public identifier of the type denoted by 'type' Let me know if you think we need to add something. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DDDBACCHAXCH02corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
From: James Mitchell <james.mitchell@ausregistry.com.a= u>
Date: Tuesday, June 4, 2013 12:04 A= M
To: Andrew Newton <andy@arin.net>, Ernie Dainow <edainow@afilias.info>, "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] ICANN Whois S= pecifications

I have seen ICANN use the term GURID (Globally Unique R-something ID?)=  for the IANA ID (https://radar.ic= ann.org).

.au does not require registrars to be ICANN accredited, instead a loca= lly-unique identifier is used (the identifier used in EPP to indicate spons= oring registrar). I see no reason why a registrar cannot have both a locall= y-unique identifier and a globally-unique identifier. The locally unique identifier may or may not meet the ROID syn= tax requirements of RFC5730.

James,

Here is what I plan to put in the next draft. I think it meets your ne= eds of having both types of identifiers:

  =     "publicIds" :
      [
        {
          "type": "IANA Registrar I= D",
          "identifier" : "1"         }
      ],


   o  publicIds - an array of obj= ects, with each object containing the

      following memebers:


      *  type - a string den= oting the type of public identifier


      *  identifier - a publ= ic identifier of the type denoted by 'type'



Let me know if you think we need to add somethin= g.


-andy

--_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DDDBACCHAXCH02corpari_-- From carlosm3011@gmail.com Tue Jun 4 10:01:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED6321F9990 for ; Tue, 4 Jun 2013 10:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EKY62gRowGc for ; Tue, 4 Jun 2013 10:01:04 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5EE21F9DD3 for ; Tue, 4 Jun 2013 07:49:21 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id da11so260325veb.20 for ; Tue, 04 Jun 2013 07:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XAFGdlQLnFxr0avk760e/TtsnRJ5iEtGStQBzpzrzvk=; b=sFCob6oQmGthGt7tAoaoT7PtxMnKJID3zIW3VTIQENbYhsfBYGn2F02JsKVZydR3aK JbLok5ohLQntoQoezsKN3bKtQFhnpV1X57rPZgPvtwziuwc7UI8tJSHghJ3XnTMfsUTj USLOQd99M3iGkp44PJdX5IrlDeFe5/6pfsU0TsmBMTNZwbuJ3mc66ikFQoWwN048c9yG OlxRUke3y+2cOiafzNLSIxpHQBhox2BUglHkA4Abc49iKTj2p38358Hs6/dLlX4udKyP +3ZNK8cgVSeGHVUJ0DIM78BrOwD0mibGXGZDniIiMyhZWncsCZVmNfamJaVQ4dBLH/kI DKLg== X-Received: by 10.52.20.148 with SMTP id n20mr13541541vde.116.1370357360802; Tue, 04 Jun 2013 07:49:20 -0700 (PDT) Received: from europa.local ([2001:13c7:7001:7000:8163:9b65:2952:9dce]) by mx.google.com with ESMTPSA id tf2sm45082499veb.8.2013.06.04.07.49.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 07:49:19 -0700 (PDT) Message-ID: <51ADFE6C.6050304@gmail.com> Date: Tue, 04 Jun 2013 11:49:16 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Levine References: <20130604064118.11765.qmail@joyce.lan> In-Reply-To: <20130604064118.11765.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] Call for IETF 87 (Berlin) agenda items X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:01:22 -0000 I've been working on the topic myself. If you care to share, or 'the guy' cares to share, I'd be happy to help. regards ~Carlos On 6/4/13 3:41 AM, John Levine wrote: > We punted bootstrapping. I believe someone has a draft almost ready > to go, and since it was contentious last time it would probably be > useful to see if it still is. > > If the guy with the I-D won't be in Berlin, I think I understand it > well enough to present it. > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From nkong@cnnic.cn Tue Jun 4 10:21:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE9D21F9C87 for ; Tue, 4 Jun 2013 10:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pegn7uQWHspK for ; Tue, 4 Jun 2013 10:21:31 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 95B1221F9C1F for ; Tue, 4 Jun 2013 08:32:02 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [192.168.1.112]) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 04 Jun 2013 23:31:51 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ning Kong In-Reply-To: <51A618F4.8020802@qti.qualcomm.com> Date: Tue, 4 Jun 2013 23:31:52 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <67153352-D4CE-4578-9E7C-36410017CD80@cnnic.cn> References: <51A618F4.8020802@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1503) Cc: weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:21:40 -0000 Hi Pete, Thanks for your review. Please see our (Andy, Byron and myself) = feedbacks inline. > Section 3 says: >=20 > Second, multiple response formats are supported by this protocol. = At > present the IETF Web Extensible Internet Data Service (WEIRDS) > working group is defining only a JSON [RFC4627] response format, but > server operators may use other data formats when those formats are > requested. >=20 > However, section 4.1 says: >=20 > RDAP clients MUST include an Accept: header field specifying > application/rdap+json, application/json, or both. Servers receiving > an RDAP request MUST return an entity with Content-Type application/ > rdap+json. >=20 > Why are those two not contradictory? We think the wording in Section 3 needs to be rewritten so as to not be = contradictory: Second, the semantics of the request/response allow for future and/or = non-standard response formats. At present, the IETF Web Extensibility = Internet Registration Data Service (WEIRDS) working group is defining = only a JSON [RFC4627] response format, and this document only describes = how RDAP is transported using HTTP with this format. > Section 5.1: >=20 > it encodes the answer in the format most appropriate according to = the > standard and defined rules for processing the HTTP Accept header > field, and return that answer in the body of a 200 response. >=20 > The first part is a little convoluted. Does it simply mean, "it = encodes the answer appropriately based on the HTTP Accept header field"? = Also, grammatical nit: s/return/returns. This can be simplified to the following: If a server has the information requested by the client and wishes to = respond to the client with the information according to its policies, it = returns that answer in the body of a 200 response. > Section 5.2: >=20 > If a server wishes to inform a client that the answer to a given > query can be found elsewhere, it MUST return a 301 response code to > indicate a permanent move, or a 307 response code to indicate a non- > permanent redirection, and include an HTTP(s) URL in the Location: > header field. >=20 > Is that MUST there for interoperability reasons? That is, is it = plausible that a server might choose something other than 301 or 307 and = this document is specifically limiting the server to only choose 301 or = 307? The same question for including the URL in the Location header = field. If it *is* a specific limitation, I suggest a minor rewording to = make it clearer: >=20 > If a server wishes to inform a client that the answer to a given > query can be found elsewhere, it MUST return either a 301 response > code to indicate a permanent move, or a 307 response code to = indicate > a non- permanent redirection, and it MUST include an HTTP(s) URL in > the Location: header field. >=20 > If it is not a limitation, but rather just a statement of what the = server does, I suggest: >=20 > If a server wishes to inform a client that the answer to a given > query can be found elsewhere, it returns a 301 response code to > indicate a permanent move, or a 307 response code to indicate a non- > permanent redirection, and includes an HTTP(s) URL in the Location: > header field. As for the response codes, technically 301 and 307 are not the only = choices for redirections. 302 and 303 can also work based on RFC 2616 = but maybe are not best choices. So we think MUSTs are necessary for the = response codes. Based on the section 10.3.2 of RFC 2616, if a 301 response code is = received, a new permernent URI SHOULD be given by the Location field in = the response. So it's not necessary to use MUST for "include an HTTP(s) = URL in the Location: header field". So, we'd like to use the following text based on your first one: If a server wishes to inform a client that the answer to a given query = can be found elsewhere, it MUST return either a 301 response code to = indicate a permanent move, or a 307 response code to indicate a = non-permanent redirection, and it includes an HTTP(s) URL in the = Location: header field. > I have similar questions for the MUSTs in 5.3 and 5.4 and the SHOULD = in 5.5. Based on RFC 2616, 404 and 400 both are the appropriated choices. So the = MUSTs in the section 5.3 and 5.4 are not necessary. The same conclusion = for 429 can be given by the RFC 6585, so the SHOULDs in section 5.5 are = not necessary either. So we'll rewrite these three sections soon based on the above analysis. > Section 6: >=20 > I'd like to understand the exceptions that exist that justify = SHOULD/SHOULD NOT instead of MUST/MUST NOT for the name syntax. The reason for SHOULD NOT instead of MUST NOT is that violation of these = rules will not cause interoperability with all implementations, just = those using the methods outlined in the last paragraph of that section. > The syntax itself allows a name of "X______". It also imposes no = length limit. Is that OK? There is no length limitation in the JSON standard. So we think this is = ok. > Section 8.2: Shouldn't this registration go in = draft-ietf-weirds-json-response? Also, the reference to 6839 is = Informative, not Normative, as far as I can tell. We think it's in here because json-query needs it too. The working group = insisted on it being in this doc. And 6839 should be informative. > Section 9.1: I think the MAYs in there could turn out badly. Might I = suggest instead: >=20 > 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. >=20 > The MAYs seem to imply that there are places in the protocol where = they MAY use IRIs, and AFAICT that's not true. We like this wording much better. > Appendix B: s/MAY/can. You're not really specifying a protocol option = here. Agreed. > Appendix C: A note in here for the RFC Editor to remove this section = would be useful. Agreed. Cheers, Ning= From edainow@afilias.info Tue Jun 4 11:44:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8CE21F85B8 for ; Tue, 4 Jun 2013 11:44:15 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70me4wm41zZ2 for ; Tue, 4 Jun 2013 11:44:10 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3B65521F86DC for ; Tue, 4 Jun 2013 11:40:34 -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 1Ujw9p-0001Y7-47 for weirds@ietf.org; Tue, 04 Jun 2013 18:40:33 +0000 Received: from mail-ob0-f170.google.com ([209.85.214.170]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Ujw9p-0005pr-3m for weirds@ietf.org; Tue, 04 Jun 2013 18:40:33 +0000 Received: by mail-ob0-f170.google.com with SMTP id ef5so1028834obb.15 for ; Tue, 04 Jun 2013 11:40:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=TztsZFCdu5QB6kdDmOmNg5WBmys4ZHToP8TiWziGu4I=; b=kgR/lG05t0BkzrlpKxRLR743FMmeF559Ibww7DhyrYrYh+Vq8CPyhZMX3kJJZ8f8+T t9wChoA0acNZ8ZjE1MqepAlZc5YNb1U75VjeQZBaos98n0bD9cdsYXrEv93oKpj2I2Ve 59DVU1NhRB+jFP/APCNVab0a2r1olYsq59xadwzfN0JqL7We83i49zsDB5kP2HGr/3kY dgKxAw0/fjbdCZmj3t/E0etc2JvAlMNUTS5d6jmuvlkvVdvdKRVp/WNiGqeWpwvq3aXt 9edGaJXuxcG4umR2rhHUlpeGXXZ7Yvwwrllqk9JKwSIetIt3lWF2M++M7+GjTnu4qYDp Xcog== X-Received: by 10.60.178.242 with SMTP id db18mr12290464oec.74.1370371227649; Tue, 04 Jun 2013 11:40:27 -0700 (PDT) X-Received: by 10.60.178.242 with SMTP id db18mr12290456oec.74.1370371227524; Tue, 04 Jun 2013 11:40:27 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id ei16sm3330486oeb.7.2013.06.04.11.40.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 11:40:26 -0700 (PDT) Message-ID: <51AE3496.8070009@afilias.info> Date: Tue, 04 Jun 2013 14:40:22 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD898D@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD898D@CHAXCH01.corp.arin.net> Content-Type: multipart/alternative; boundary="------------050306040903030600070701" X-Gm-Message-State: ALoCoQn9R4HSpv7aq+SzDpexwsVDsEHUkS4tDysBQ0H8jRowfgFvlods0kdZSMI5Teaz5Uss710HRUrc29i8Sui/K95qyLfMI5Q7t6ut5sxFzTBnLygCawE1aqpNb9hTHZI49wODSkI5 Cc: "weirds@ietf.org" Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:44:15 -0000 This is a multi-part message in MIME format. --------------050306040903030600070701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/3/2013 8:45 PM, Andy Newton wrote: > Ernie, > > Thanks for putting this together. Some of these are already covered > through other structures. For instance, email addresses are already > accounted for in jCard and URLs in links. From the ICANN Specifications: The Maintainer URL (email or website). The maintainer is a person that has been designated by the Registrar for the registration of the domain (for example a reseller, could also depend on the registrant). If Maintainer is an email, using a jCard embedded in the Domain object would not have context to identify what it is. So it seems best to use a jCard in an Entity object and use another role, say "Maintainer", for this type of entity. For a website link, we should recommend the relation type. Best fit by name seems to be "service", but this seems to have particular reference to Atom. http://www.iana.org/assignments/link-relations/link-relations.xml -Ernie --------------050306040903030600070701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 6/3/2013 8:45 PM, Andy Newton wrote:
Ernie,

Thanks for putting this together. Some of these are already covered through other structures. For instance, email addresses are already accounted for in jCard and URLs in links.

From the ICANN Specifications:
    The Maintainer URL (email or website). The maintainer is a person that has been designated by the Registrar for the registration of the domain (for example a reseller, could also depend on the registrant).

If Maintainer is an email, using a jCard embedded in the Domain object would not have context to identify what it is. So it seems best to use a jCard in an Entity object and use another role, say "Maintainer", for this type of entity.

For a website link, we should recommend the relation type. Best fit by name seems to be "service", but this seems to have particular reference to Atom. http://www.iana.org/assignments/link-relations/link-relations.xml

-Ernie

--------------050306040903030600070701-- From presnick@qti.qualcomm.com Tue Jun 4 12:56:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E7B21F85C0 for ; Tue, 4 Jun 2013 12:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O75UNAG14tsf for ; Tue, 4 Jun 2013 12:56:19 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 28DBE21F9C66 for ; Tue, 4 Jun 2013 12:44:25 -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=1370375065; x=1401911065; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lA2ZZgwgemaiaKA70Iek1rBURH6wuAbyu2uMMhVRKC8=; b=Y5Uu9RguMEHmwumn4He8NLgNnJAlVdKNj8slL2584knl8KLT8pGMYH6j mjaHblh4ewq/jwZF0stUi8hTwl8KFQ00Rxpm+RFB7cw8e9qLz0hqMHrv+ NWUQf/wGojRdE053ik9vOuTYwCiqbBMaGHUTfJ3ErbEmgARoem37XY7D+ k=; X-IronPort-AV: E=Sophos;i="4.87,802,1363158000"; d="scan'208";a="43407504" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 04 Jun 2013 12:44:24 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Jun 2013 12:44:24 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 4 Jun 2013 12:44:23 -0700 Message-ID: <51AE4394.30801@qti.qualcomm.com> Date: Tue, 4 Jun 2013 14:44: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: Ning Kong References: <51A618F4.8020802@qti.qualcomm.com> <67153352-D4CE-4578-9E7C-36410017CD80@cnnic.cn> In-Reply-To: <67153352-D4CE-4578-9E7C-36410017CD80@cnnic.cn> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 19:56:26 -0000 On 6/4/13 10:31 AM, Ning Kong wrote: > Hi Pete, > > Thanks for your review. Please see our (Andy, Byron and myself) feedbacks inline. > > >> Section 3 says: >> >> Second, multiple response formats are supported by this protocol. At >> present the IETF Web Extensible Internet Data Service (WEIRDS) >> working group is defining only a JSON [RFC4627] response format, but >> server operators may use other data formats when those formats are >> requested. >> >> However, section 4.1 says: >> >> RDAP clients MUST include an Accept: header field specifying >> application/rdap+json, application/json, or both. Servers receiving >> an RDAP request MUST return an entity with Content-Type application/ >> rdap+json. >> >> Why are those two not contradictory? >> > We think the wording in Section 3 needs to be rewritten so as to not be contradictory: > > Second, the semantics of the request/response allow for future and/or non-standard response formats. At present, the IETF Web Extensibility Internet Registration Data Service (WEIRDS) working group is defining only a JSON [RFC4627] response format, and this document only describes how RDAP is transported using HTTP with this format. > OK, but I think that reveals another potential problem: I was going to suggest that instead of, "At present, the IETF Web Extensibility Internet Registration Data Service (WEIRDS) working group is defining only a JSON [RFC4627] response format", because referring to the WG in the document isn't the best, that perhaps you'd rather say, "At present, only a JSON [RFC4627] response format is being defined", but that led me to want to add "in [draft-ietf-weirds-json-response]". And there's your problem. Section 4.1 is requiring (as in, a "MUST") the use of the JSON format, which sounds to me like a normative dependency on draft-ietf-weirds-json-response. You need to decide whether you want to write a more generic HTTP draft, in which case mandating that the application/rdap+json MUST be used is inappropriate, or if this draft is inextricably linked to the use of JSON, in which case you'll want to make a normative reference to -response, and I'll wonder why this draft is being advanced at a different time than the others. >> Section 5.1: >> >> it encodes the answer in the format most appropriate according to the >> standard and defined rules for processing the HTTP Accept header >> field, and return that answer in the body of a 200 response. >> > This can be simplified to the following: > > If a server has the information requested by the client and wishes to respond to the client with the information according to its policies, it returns that answer in the body of a 200 response. > That's fine. >> Section 5.2: >> >> If a server wishes to inform a client that the answer to a given >> query can be found elsewhere, it MUST return a 301 response code to >> indicate a permanent move, or a 307 response code to indicate a non- >> permanent redirection, and include an HTTP(s) URL in the Location: >> header field. >> >> Is that MUST there for interoperability reasons? That is, is it plausible that a server might choose something other than 301 or 307 and this document is specifically limiting the server to only choose 301 or 307? The same question for including the URL in the Location header field. If it *is* a specific limitation, I suggest a minor rewording to make it clearer: >> >> If a server wishes to inform a client that the answer to a given >> query can be found elsewhere, it MUST return either a 301 response >> code to indicate a permanent move, or a 307 response code to indicate >> a non- permanent redirection, and it MUST include an HTTP(s) URL in >> the Location: header field. >> >> If it is not a limitation, but rather just a statement of what the server does, I suggest: >> >> If a server wishes to inform a client that the answer to a given >> query can be found elsewhere, it returns a 301 response code to >> indicate a permanent move, or a 307 response code to indicate a non- >> permanent redirection, and includes an HTTP(s) URL in the Location: >> header field. >> > As for the response codes, technically 301 and 307 are not the only choices for redirections. 302 and 303 can also work based on RFC 2616 but maybe are not best choices. So we think MUSTs are necessary for the response codes. > Does "not the best choices" mean that clients receiving those responses won't work as well (i.e., an interoperability issue), or does it mean simply that they are not the most descriptive and therefore aesthetically less pleasing? It seems to me that saying "not the best choices" does not imply "MUSTs are necessary". If the former, your suggestion is fine: > If a server wishes to inform a client that the answer to a given query can be found elsewhere, it MUST return either a 301 response code to indicate a permanent move, or a 307 response code to indicate a non-permanent redirection, and it includes an HTTP(s) URL in the Location: header field. > If the latter, perhaps my second suggestion is better. >> I have similar questions for the MUSTs in 5.3 and 5.4 and the SHOULD in 5.5. >> > Based on RFC 2616, 404 and 400 both are the appropriated choices. So the MUSTs in the section 5.3 and 5.4 are not necessary. The same conclusion for 429 can be given by the RFC 6585, so the SHOULDs in section 5.5 are not necessary either. > > So we'll rewrite these three sections soon based on the above analysis. > Excellent. >> Section 6: >> >> I'd like to understand the exceptions that exist that justify SHOULD/SHOULD NOT instead of MUST/MUST NOT for the name syntax. >> > The reason for SHOULD NOT instead of MUST NOT is that violation of these rules will not cause interoperability with all implementations, just those using the methods outlined in the last paragraph of that section. > Ah, I now understand. That's fine. >> The syntax itself allows a name of "X______". It also imposes no length limit. Is that OK? >> > There is no length limitation in the JSON standard. So we think this is ok. > That's fine. And you are also OK with a single ALPHA followed by only underscores? That's fine with me if that's your intention. >> Section 8.2: Shouldn't this registration go in draft-ietf-weirds-json-response? Also, the reference to 6839 is Informative, not Normative, as far as I can tell. >> > We think it's in here because json-query needs it too. The working group insisted on it being in this doc. This goes back to the issue of whether this document should be requiring JSON or whether it should be left to other documents. > And 6839 should be informative. > OK. >> Section 9.1: I think the MAYs in there could turn out badly. Might I suggest instead: >> >> 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. >> >> The MAYs seem to imply that there are places in the protocol where they MAY use IRIs, and AFAICT that's not true. >> > We like this wording much better. > Great. >> Appendix B: s/MAY/can. You're not really specifying a protocol option here. >> > Agreed. > > >> Appendix C: A note in here for the RFC Editor to remove this section would be useful. >> > Agreed. > Cool. Thanks for working on this. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From andy@arin.net Tue Jun 4 14:37:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D92321F942B for ; Tue, 4 Jun 2013 14:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.808 X-Spam-Level: X-Spam-Status: No, score=-3.808 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTuxbDxW1gSL for ; Tue, 4 Jun 2013 14:37:33 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 9129521F9B6E for ; Tue, 4 Jun 2013 13:57:02 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id F40F71651FC; Tue, 4 Jun 2013 16:57:01 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 642081651E7; Tue, 4 Jun 2013 16:57:01 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 4 Jun 2013 16:56:33 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.190]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 16:56:42 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] ICANN Whois Specifications Thread-Index: AQHOYIQ2weBqCM/1Bk2sY5mV/PjGWpkkuKMAgAFvUwD//+L/AA== Date: Tue, 4 Jun 2013 20:56:41 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEA1EF@CHAXCH01.corp.arin.net> In-Reply-To: <51AE3496.8070009@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DEA1EFCHAXCH01corpari_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:37:44 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DEA1EFCHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ernie Dainow > Date: Tuesday, June 4, 2013 2:40 PM To: Andrew Newton > Cc: "weirds@ietf.org" > Subject: Re: [weirds] ICANN Whois Specifications If Maintainer is an email, using a jCard embedded in the Domain object woul= d not have context to identify what it is. So it seems best to use a jCard = in an Entity object and use another role, say "Maintainer", for this type o= f entity. Isn't "registrant" the same thing as "maintainer"? Otherwise I agree. For a website link, we should recommend the relation type. Best fit by name= seems to be "service", but this seems to have particular reference to Atom= . http://www.iana.org/assignments/link-relations/link-relations.xml Agreed. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DEA1EFCHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <32FCAC2CF491E2469E18AFF0BF4B5E34@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: Ernie Dainow <edainow@afilias.info>
Date: Tuesday, June 4, 2013 2:40 PM=
To: Andrew Newton <andy@arin.net>
Cc: "weirds@ietf.org" <= weirds@ietf.org>
Subject: Re: [weirds] ICANN Whois S= pecifications

If Maintainer is an email, using a jCard embedded in the Domain object would = not have context to identify what it is. So it seems best to use a jCard in= an Entity object and use another role, say "Maintainer", for thi= s type of entity.

Isn't "registrant" the same thing as "maintainer"?= Otherwise I agree.


For a website link, we should recommend the relation type. Best fit by name se= ems to be "service", but this seems to have particular reference = to Atom. http://www.iana.org/assign= ments/link-relations/link-relations.xml

Agreed.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DEA1EFCHAXCH01corpari_-- From marc.blanchet@viagenie.ca Tue Jun 4 14:58:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24E721F91B8 for ; Tue, 4 Jun 2013 14:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.797 X-Spam-Level: X-Spam-Status: No, score=-102.797 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73rQ1szVIiS0 for ; Tue, 4 Jun 2013 14:58:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8463221F905F for ; Tue, 4 Jun 2013 14:58:29 -0700 (PDT) Received: from mb.lan (modemcable061.246-162-184.mc.videotron.ca [184.162.246.61]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 810A9403F8 for ; Tue, 4 Jun 2013 17:58:24 -0400 (EDT) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> Date: Tue, 4 Jun 2013 17:58:22 -0400 To: "weirds@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:58:38 -0000 hello, please find an attempt to provide a solution to the "bootstrap" = problem, i.e. finding the authoritative registration data server. I = don't pretend this is fully baked but enough to get a good discussion = going. Please comment. Regards, Marc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Finding the Authoritative Registration Data = (RDAP) Server Author(s) : Marc Blanchet Filename : draft-blanchet-weirds-bootstrap-00.txt Pages : 7 Date : 2013-06-04 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-blanchet-weirds-bootstrap There's also a htmlized version available at: http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pieter.vandepitte@dnsbelgium.be Wed Jun 5 00:10:41 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8319F21F8E2C for ; Wed, 5 Jun 2013 00:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAIAnB9diF56 for ; Wed, 5 Jun 2013 00:10:35 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id AB72321F91B7 for ; Wed, 5 Jun 2013 00:10:30 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 786E9426002E; Wed, 5 Jun 2013 09:10:28 +0200 (CEST) Message-ID: <51AEE464.1030205@dnsbelgium.be> Date: Wed, 05 Jun 2013 09:10:28 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Pete Resnick References: <51A618F4.8020802@qti.qualcomm.com> <67153352-D4CE-4578-9E7C-36410017CD80@cnnic.cn> <51AE4394.30801@qti.qualcomm.com> In-Reply-To: <51AE4394.30801@qti.qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 07:10:41 -0000 Hi > You need to decide whether you want to write a more generic HTTP > draft, in which case mandating that the application/rdap+json MUST be > used is inappropriate, or if this draft is inextricably linked to the > use of JSON, in which case you'll want to make a normative reference > to -response, and I'll wonder why this draft is being advanced at a > different time than the others. Pete has a point here. I think currently the drafts are very much depending on each other (which is not necessarily a problem) I think if it almost definitely sure other content types will ever be introduced in the future, it would be better to split up documents into a - data model document: abstract data model (not json, really abstract) - data binding document: binding of the model to some content type: e.g. json or xml - protocol document: abstract protocol (currently searches and lookups), messages and allowed responses - protocol binding: rest binding, soap binding, thrift, protobuf, avro, ... binding On the other hand, the charter states it will define a 'simple' protocol and so my question is if we will ever need to have such a heavy weight rfc. imho i would remove the "multiple response formats supported". It probably won't happen. I'm having another issue with the same draft. I'm currently working on an implementation and for me it's unclear which object MUST be returned by which response code. e.g. can a 404 for a /domain/xxx query return a domain object? I'm looking for a way to make a differentiation to the client whether a registration is not found but available and whether a registration is not found and not available because it is not supported (like characters not allowed)... one solution is to return a domain object with different statuses, another is to return an error object with different titles. Any recommendations? Pieter From superuser@gmail.com Wed Jun 5 00:37:13 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE68521F9A52 for ; Wed, 5 Jun 2013 00:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw2GWLUM04HZ for ; Wed, 5 Jun 2013 00:37:13 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0343621F9A46 for ; Wed, 5 Jun 2013 00:37:12 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so1033662wgh.29 for ; Wed, 05 Jun 2013 00:37:12 -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=ujV1fLO67/50XXI/o2iz53MyMEtbFbgtDRM4A00krmc=; b=QaBQ9AS2e4Ss0Ao7AwM6MOZVEDBQ/wO7QlTKz9Lqq58H3OXC/JwofqzCp2ND9H1s6f iKaapfjo98gB0ggPj6s1akPmfHjOQtMl1hcTgRWRv2EwC/kY1iIbz0x/z5JWmwoZ3pf9 NqQUJ/6umva9jl0Sbf1cV1wtszEyu+2oDyMpBlbpCI93au3uB2oUbW8Uwe6SG+/G1Jc1 ylFRlLVlRuE4DimB0EySOr84eGn4E9ukGY4aVv+vNR2g12b+5mnSPK7mO2A8091frN2r yYevjBtpJ6ZBptuLxhHZvtF1pD6EWF3UNgYotkNuF1uaf8Ks6qStrQzMsNVZxZL3NqJF vMfw== MIME-Version: 1.0 X-Received: by 10.180.206.235 with SMTP id lr11mr5129474wic.59.1370417832177; Wed, 05 Jun 2013 00:37:12 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Wed, 5 Jun 2013 00:37:12 -0700 (PDT) In-Reply-To: <51ADFE6C.6050304@gmail.com> References: <20130604064118.11765.qmail@joyce.lan> <51ADFE6C.6050304@gmail.com> Date: Wed, 5 Jun 2013 00:37:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Carlos Martinez Content-Type: multipart/alternative; boundary=001a11c333a614b7ae04de63443a Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] Call for IETF 87 (Berlin) agenda items X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 07:37:13 -0000 --001a11c333a614b7ae04de63443a Content-Type: text/plain; charset=ISO-8859-1 Thanks to the volunteers. We'll reach out to you soon to get commitment for a time slot. We have requested a one-hour meeting in Berlin given the comments on this thread. -MSK, co-chair On Tue, Jun 4, 2013 at 7:49 AM, Carlos M. Martinez wrote: > I've been working on the topic myself. If you care to share, or 'the > guy' cares to share, I'd be happy to help. > > regards > > ~Carlos > > On 6/4/13 3:41 AM, John Levine wrote: > > We punted bootstrapping. I believe someone has a draft almost ready > > to go, and since it was contentious last time it would probably be > > useful to see if it still is. > > > > If the guy with the I-D won't be in Berlin, I think I understand it > > well enough to present it. > > > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --001a11c333a614b7ae04de63443a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks to the volunteers.=A0 We'll reach out to y= ou soon to get commitment for a time slot.

We have requested a one-h= our meeting in Berlin given the comments on this thread.

-MSK,= co-chair


On Tue,= Jun 4, 2013 at 7:49 AM, Carlos M. Martinez <carlosm3011@gmail.com> wrote:
I've been working on the topic myself. I= f you care to share, or 'the
guy' cares to share, I'd be happy to help.

regards

~Carlos

On 6/4/13 3:41 AM, John Levine wrote:
> We punted bootstrapping. =A0I believe someone has a draft almost ready=
> to go, and since it was contentious last time it would probably be
> useful to see if it still is.
>
> If the guy with the I-D won't be in Berlin, I think I understand i= t
> well enough to present it.
>
> __________________= _____________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds
>
_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--001a11c333a614b7ae04de63443a-- From shollenbeck@verisign.com Wed Jun 5 04:04:46 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC6521F9A99 for ; Wed, 5 Jun 2013 04:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv3wTjeXnZrP for ; Wed, 5 Jun 2013 04:04:40 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6693921F9A94 for ; Wed, 5 Jun 2013 04:03:52 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUa8bF/tUaXeKCxUqOn+4RHaIUVvPX/Nk@postini.com; Wed, 05 Jun 2013 04:03:58 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r55B3WvP032522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 07:03:32 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Jun 2013 07:03:31 -0400 From: "Hollenbeck, Scott" To: Marc Blanchet , "weirds@ietf.org" Thread-Topic: [weirds] bootstrap draft Thread-Index: AQHOYW66LO8x7Lc9B0KiTkfNiE2lj5km9KkA Date: Wed, 5 Jun 2013 11:03:31 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243A2175@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> In-Reply-To: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 11:04:46 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Marc Blanchet > Sent: Tuesday, June 04, 2013 5:58 PM > To: weirds@ietf.org > Subject: [weirds] bootstrap draft >=20 > hello, > please find an attempt to provide a solution to the "bootstrap" > problem, i.e. finding the authoritative registration data server. I > don't pretend this is fully baked but enough to get a good discussion > going. Please comment. Thanks for taking the time to write this, Marc. One suggestion at first gla= nce: RFC 1035 doesn't use the term "NXDOMAIN". Would you consider "name err= or" or "response code 3" instead? Scott From pieter.vandepitte@dnsbelgium.be Wed Jun 5 07:03:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9229521F9ACD for ; Wed, 5 Jun 2013 07:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqu6L9s-WqBf for ; Wed, 5 Jun 2013 07:03:15 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 5698B21F9ABB for ; Wed, 5 Jun 2013 07:03:14 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 8B9294270005 for ; Wed, 5 Jun 2013 16:03:11 +0200 (CEST) Message-ID: <51AF451F.8070302@dnsbelgium.be> Date: Wed, 05 Jun 2013 16:03:11 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [weirds] inconsistencies in json-response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:03:22 -0000 Hi, Section 5 (Common Data Structures) states: This section defines common data structures to be used in response. Each of these structures MAY appear within any object class of a response. but for example the IP Network (6.4) does not mention 'port43' and 'notices' whereas it does mention other 'shared' members. This is confusing for an implementer. Does it mean these members are not allowed? Same for other Object Classes: e.g. Domain and Entity does not mention notices and lang. I think either we remove members which are defined in Common Data Structures and add a link to section 5, or we explicitly add all allowed members to the appropriate subsections of section 6 and remove the above mentioned phrase. Best regards Pieter From superuser@gmail.com Wed Jun 5 07:16:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41921F9A48 for ; Wed, 5 Jun 2013 07:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx1C6QLZAweA for ; Wed, 5 Jun 2013 07:16:28 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 73EF221F99CF for ; Wed, 5 Jun 2013 07:16:28 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so1400159wgh.32 for ; Wed, 05 Jun 2013 07:16:27 -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=yrrbalbmdcMO4BK2hQUUIvhXiUy08R1B9DAJpmWa+6c=; b=qsSAM1TDAI9bkXi17lYk3aQdG0jBDX5Lp4TjSrtPIcTlQd+nMGQGSHZEPn1IGWD4Vs viKXRFhO1j0mxGyee/vE83DXH2+PmyLPw3e6vrpZ1zPmV3DTH972fZ6d6kS80W66UolN nu3E2QiE2Wvz+RxQTe4527aGrgnJ6dREeGrpGhNqTKn5CnIxzcEpDaXhC//qk+JmZnOA w46UFKvXZ3byfVXUU7NLNgBWRPjBQFkaAQ//qmIOOkbuctguVBWCTxTtYyPIJhq1pCjG eW4lPI9D2b06zxnsUxt+K3PIRbMufLrAAnqVRZuhoX2duK9TZ2EbDSACvkONN3/6QY1y zxUA== MIME-Version: 1.0 X-Received: by 10.180.206.235 with SMTP id lr11mr6831606wic.59.1370441787421; Wed, 05 Jun 2013 07:16:27 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Wed, 5 Jun 2013 07:16:27 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243A2175@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F243A2175@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 5 Jun 2013 07:16:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=001a11c333a6ecbbf204de68d73c Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:16:29 -0000 --001a11c333a6ecbbf204de68d73c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 4:03 AM, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > > Behalf Of Marc Blanchet > > Sent: Tuesday, June 04, 2013 5:58 PM > > To: weirds@ietf.org > > Subject: [weirds] bootstrap draft > > > > hello, > > please find an attempt to provide a solution to the "bootstrap" > > problem, i.e. finding the authoritative registration data server. I > > don't pretend this is fully baked but enough to get a good discussion > > going. Please comment. > > Thanks for taking the time to write this, Marc. One suggestion at first > glance: RFC 1035 doesn't use the term "NXDOMAIN". Would you consider "name > error" or "response code 3" instead? > > > ...or at least declare in a definitions section that NXDOMAIN is a symbolic name for response code 3. I've done that in other drafts. -MSK --001a11c333a6ecbbf204de68d73c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 4:03 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
> -----Original Message= -----
> From: weirds-bounces@ietf.o= rg [mailto:weirds-bounces@ie= tf.org] On
> Behalf Of Marc Blanchet
> Sent: Tuesday, June 04, 2013 5:58 PM
> To: weirds@ietf.org
> Subject: [weirds] bootstrap draft
>
> hello,
> =A0please find an attempt to provide a solution to the "bootstrap= "
> problem, i.e. finding the authoritative registration data server. =A0I=
> don't pretend this is fully baked but enough to get a good discuss= ion
> going. Please comment.

Thanks for taking the time to write this, Marc. One suggestion at fir= st glance: RFC 1035 doesn't use the term "NXDOMAIN". Would yo= u consider "name error" or "response code 3" instead?


...or at least declare in a definitions section = that NXDOMAIN is a symbolic name for response code 3.=A0 I've done that= in other drafts.

-MSK

--001a11c333a6ecbbf204de68d73c-- From shollenbeck@verisign.com Wed Jun 5 07:17:45 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A883621F9AA3 for ; Wed, 5 Jun 2013 07:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj+Ei3t+KrYw for ; Wed, 5 Jun 2013 07:17:39 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id 30A2221F99CF for ; Wed, 5 Jun 2013 07:17:37 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUa9IgIoscKcSbVkYJfeSvupzEVwBkOfs@postini.com; Wed, 05 Jun 2013 07:17:39 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 r55EHXs6005635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 10:17:33 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Jun 2013 10:17:33 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" Thread-Topic: [weirds] bootstrap draft Thread-Index: AQHOYfdExskFcxu2B0ySB/scMNqPY5knKs9Q Date: Wed, 5 Jun 2013 14:17:32 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243A263B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F243A2175@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_831693C2CDA2E849A7D7A712B24E257F243A263BBRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:17:45 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F243A263BBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Murray S. Kucherawy [mailto:superuser@gmail.com] Sent: Wednesday, June 05, 2013 10:16 AM To: Hollenbeck, Scott Cc: Marc Blanchet; weirds@ietf.org Subject: Re: [weirds] bootstrap draft On Wed, Jun 5, 2013 at 4:03 AM, Hollenbeck, Scott > wrote: > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:wei= rds-bounces@ietf.org] On > Behalf Of Marc Blanchet > Sent: Tuesday, June 04, 2013 5:58 PM > To: weirds@ietf.org > Subject: [weirds] bootstrap draft > > hello, > please find an attempt to provide a solution to the "bootstrap" > problem, i.e. finding the authoritative registration data server. I > don't pretend this is fully baked but enough to get a good discussion > going. Please comment. Thanks for taking the time to write this, Marc. One suggestion at first gla= nce: RFC 1035 doesn't use the term "NXDOMAIN". Would you consider "name err= or" or "response code 3" instead? ...or at least declare in a definitions section that NXDOMAIN is a symbolic= name for response code 3. I've done that in other drafts. Yup, that could work, too. Scott --_000_831693C2CDA2E849A7D7A712B24E257F243A263BBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Murray S= . Kucherawy [mailto:superuser@gmail.com]
Sent: Wednesday, June 05, 2013 10:16 AM
To: Hollenbeck, Scott
Cc: Marc Blanchet; weirds@ietf.org
Subject: Re: [weirds] bootstrap draft

 

On Wed, Jun 5, 2013 at 4:03 AM, Hollenbeck, Scott &l= t;shollenbeck= @verisign.com> wrote:

> -----Original Me= ssage-----
> From: weirds-bounces@ietf.o= rg [mailto:weirds-bounces@ie= tf.org] On
> Behalf Of Marc Blanchet
> Sent: Tuesday, June 04, 2013 5:58 PM
> To: weirds@ietf.org
> Subject: [weirds] bootstrap draft
>
> hello,
>  please find an attempt to provide a solution to the "bootst= rap"
> problem, i.e. finding the authoritative registration data server. &nbs= p;I
> don't pretend this is fully baked but enough to get a good discussion<= br> > going. Please comment.

Thanks for taking the= time to write this, Marc. One suggestion at first glance: RFC 1035 doesn't= use the term "NXDOMAIN". Would you consider "name error&quo= t; or "response code 3" instead?

 

...or at least declar= e in a definitions section that NXDOMAIN is a symbolic name for response co= de 3.  I've done that in other drafts.

Yup, that could work, = too.

 

Scott

 

--_000_831693C2CDA2E849A7D7A712B24E257F243A263BBRN1WNEXMBX01vc_-- From marc.blanchet@viagenie.ca Wed Jun 5 07:22:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1525B21F9AAC for ; Wed, 5 Jun 2013 07:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiemlkhM-jvR for ; Wed, 5 Jun 2013 07:22:09 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 50DD821F9AAA for ; Wed, 5 Jun 2013 07:22:09 -0700 (PDT) Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 471EE46F53; Wed, 5 Jun 2013 10:22:08 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_55FAB2C3-9065-4346-8DA7-2358AA306223" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Marc Blanchet In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243A263B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 5 Jun 2013 10:22:07 -0400 Message-Id: <5C3F3B75-ADE3-42E7-BAF2-A618C552F165@viagenie.ca> References: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F243A2175@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F243A263B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1503) Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:22:10 -0000 --Apple-Mail=_55FAB2C3-9065-4346-8DA7-2358AA306223 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2013-06-05 =E0 10:17, "Hollenbeck, Scott" = a =E9crit : > From: Murray S. Kucherawy [mailto:superuser@gmail.com]=20 > Sent: Wednesday, June 05, 2013 10:16 AM > To: Hollenbeck, Scott > Cc: Marc Blanchet; weirds@ietf.org > Subject: Re: [weirds] bootstrap draft > =20 > On Wed, Jun 5, 2013 at 4:03 AM, Hollenbeck, Scott = wrote: > > -----Original Message----- > > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > > Behalf Of Marc Blanchet > > Sent: Tuesday, June 04, 2013 5:58 PM > > To: weirds@ietf.org > > Subject: [weirds] bootstrap draft > > > > hello, > > please find an attempt to provide a solution to the "bootstrap" > > problem, i.e. finding the authoritative registration data server. I > > don't pretend this is fully baked but enough to get a good = discussion > > going. Please comment. >=20 > Thanks for taking the time to write this, Marc. One suggestion at = first glance: RFC 1035 doesn't use the term "NXDOMAIN". Would you = consider "name error" or "response code 3" instead? >=20 >=20 > =20 > ...or at least declare in a definitions section that NXDOMAIN is a = symbolic name for response code 3. I've done that in other drafts. >=20 ok. thanks. done in local copy. Marc. > Yup, that could work, too. > =20 > Scott > =20 --Apple-Mail=_55FAB2C3-9065-4346-8DA7-2358AA306223 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Le 2013-06-05 =E0 = 10:17, "Hollenbeck, Scott" <shollenbeck@verisign.com> = a =E9crit :

From: Murray S. Kucherawy = [mailto:superuser@gmail.com] 
Sent: Wednesday, June 05, 2013 = 10:16 AM
To: Hollenbeck, = Scott
Cc: Marc= Blanchet; weirds@ietf.org
Subject: Re: [weirds] bootstrap = draft
On Wed, Jun 5, = 2013 at 4:03 AM, Hollenbeck, Scott <shollenbeck@verisign.com> = wrote:

> = -----Original Message-----
> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On
> = Behalf Of Marc Blanchet
> Sent: Tuesday, June 04, 2013 5:58 = PM
> To: weirds@ietf.org
> Subject: [weirds] bootstrap = draft
>
> hello,
>  please find an attempt to = provide a solution to the "bootstrap"
> problem, i.e. finding the = authoritative registration data server.  I
> don't pretend = this is fully baked but enough to get a good discussion
> going. = Please comment.

Thanks for taking the time to write this, Marc. One = suggestion at first glance: RFC 1035 doesn't use the term "NXDOMAIN". = Would you consider "name error" or "response code 3" = instead?

 

...or at least declare in a definitions section that = NXDOMAIN is a symbolic name for response code 3.  I've done that in = other = drafts.

ok.= thanks. done in local = copy.

Marc.

Yup, that could work, = too.
 
Scott
 
=
= --Apple-Mail=_55FAB2C3-9065-4346-8DA7-2358AA306223-- From carlosm3011@gmail.com Wed Jun 5 07:24:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8F121F9B12 for ; Wed, 5 Jun 2013 07:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CBLIteQaboB for ; Wed, 5 Jun 2013 07:24:15 -0700 (PDT) Received: from mail-gg0-x22d.google.com (mail-gg0-x22d.google.com [IPv6:2607:f8b0:4002:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D508021F9B0F for ; Wed, 5 Jun 2013 07:24:07 -0700 (PDT) Received: by mail-gg0-f173.google.com with SMTP id l4so363430ggn.32 for ; Wed, 05 Jun 2013 07:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9eXMdMzNH0Yw57ixrSSTlYdTCbyGkSfW+V33LVW8tpU=; b=cMjOrvcwbM1pbI2o/D/GFE213ahsPG7FZtuuh69SKGNTEKCrL8/+7Pp9Hgmkv+b6oF uiVWS7CF1HDYLsl6PKuHVP/14Vw7k4rq7uohDRPJz7N7tYsAy7SsW5RvKMv54FMoPsUT ixOzPGnQiMBZVlAs4XCKsm/k+VzWJ28VbiHXjnFEq1Hyi51dasCtCWvL7gLnomhSQYYL rpInqKgqJtqn+oyiZ7kO1amyhWyNO7zUoeVnuSMFLsyrYJJm3tIkj8cIcGRVQIBVjhRP QjJPaBxURFD+DpWgljAfMRJNSAOhSYVW4Zq48L0ylte1G3NQWqjlr5lt8qfc36fq2KGo i8sg== X-Received: by 10.236.231.136 with SMTP id l8mr24577149yhq.124.1370442247415; Wed, 05 Jun 2013 07:24:07 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([200.7.87.57]) by mx.google.com with ESMTPSA id w62sm107866337yhd.27.2013.06.05.07.24.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 07:24:06 -0700 (PDT) Message-ID: <51AF4A10.4020901@gmail.com> Date: Wed, 05 Jun 2013 11:24:16 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marc Blanchet References: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> In-Reply-To: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:24:16 -0000 Marc, thanks for writing this down. I personally favor the DNS approach (was one of the possibilities listed early on, before we decided bootstrapping was out of scope). Regarding the doc itself, I think it works well for ipv4 and ipv6 addresses, but I'm not sure how it works for autnums since the ASN number space (and thus its registry) is flat and not hierarchical like the ipv4/ipv6 spaces. The children of ip4.rdap.arpa / ip6.rdap.arpa can be sub-delegated in the same way as the reverse tree is. However, in the case of ASNs, there isn't an equivalent approach. You mention management by a single entity, but I believe that the strength of the DNS approach is the ability to delegate. Maybe we can come up with such an idea for autnum. Further comments: - The document proposes clients should query the rdap.arpa tree for A/AAAA records but doesn't specify how to construct a URL for the actual HTTP request. - In the case of names it does suggest a way to construct the resulting URL, but IMO, the explanation is not clear enough. Also, while I don't have a problem with the 'static' way the URL is constructed, others may. I think at least mentioning the issue and explaining why the decision to go static is needed. Other questions (I don't have an answer for them, and they don't mean criticism, they just pop out of my mind): - Why query for A/AAAA ? Why not query, for example, for TXT and put the RDAP URLs in TXT records ? As another possibility someone (I think it was Andy) brought up the NAPTR records. - Why a different tree for ip4 / ip6 ? The same A/AAAA/TXTs could be put in the reverse tree that's already there and, in most cases, already signed with DNSSEC. - The most discussed weakness of the DNS approach in the past has been the issue with javascript-only clients which cannot make arbitrary DNS queries. Some ideas were discussed, including the possibility of providing 'helper' services. Maybe we can add that discussion in this doc. Thanks again! ~Carlos On 6/4/13 6:58 PM, Marc Blanchet wrote: > hello, > please find an attempt to provide a solution to the "bootstrap" problem, i.e. finding the authoritative registration data server. I don't pretend this is fully baked but enough to get a good discussion going. Please comment. > > Regards, Marc. > > ================================ > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Finding the Authoritative Registration Data (RDAP) Server > Author(s) : Marc Blanchet > Filename : draft-blanchet-weirds-bootstrap-00.txt > Pages : 7 > Date : 2013-06-04 > > 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-blanchet-weirds-bootstrap > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Wed Jun 5 07:31:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B92621F8EBC for ; Wed, 5 Jun 2013 07:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYH+EEUYZ4PA for ; Wed, 5 Jun 2013 07:31:12 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE6B21F9AAA for ; Wed, 5 Jun 2013 07:31:12 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id A06A816511E; Wed, 5 Jun 2013 10:31:08 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 5558B1650EB; Wed, 5 Jun 2013 10:31:06 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 5 Jun 2013 10:30:48 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.190]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 10:30:59 -0400 From: Andy Newton To: Pieter Vandepitte , "weirds@ietf.org" Thread-Topic: [weirds] inconsistencies in json-response Thread-Index: AQHOYfWA689fSAeB80m+O1p8rgChaZknLqQA Date: Wed, 5 Jun 2013 14:30:58 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEC485@CHAXCH01.corp.arin.net> In-Reply-To: <51AF451F.8070302@dnsbelgium.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <1D63A548E7A82A45A66149F9101829AD@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] inconsistencies in json-response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:31:16 -0000 Thanks Pieter. I'll clean that up. That is a left-over from a previous revision where the common data structures were not well defined. -andy On 6/5/13 10:03 AM, "Pieter Vandepitte" wrote: >Hi, > >Section 5 (Common Data Structures) states: > > This section defines common data structures to be used in response. > Each of these structures MAY appear within any object class of a > response. > >but for example the IP Network (6.4) does not mention 'port43' and >'notices' whereas it does mention other 'shared' members. This is >confusing for an implementer. Does it mean these members are not allowed? > >Same for other Object Classes: e.g. Domain and Entity does not mention >notices and lang. > >I think either we remove members which are defined in Common Data >Structures and add a link to section 5, or we explicitly add all allowed >members to the appropriate subsections of section 6 and remove the above >mentioned phrase. > >Best regards > >Pieter >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Wed Jun 5 07:50:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ADF21F898B for ; Wed, 5 Jun 2013 07:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPfYr5qmAspk for ; Wed, 5 Jun 2013 07:49:58 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 26CBE21F8930 for ; Wed, 5 Jun 2013 07:49:58 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id BB750213669; Wed, 5 Jun 2013 10:49:57 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 50E76213596; Wed, 5 Jun 2013 10:49:57 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 5 Jun 2013 10:49:38 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.190]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 10:49:49 -0400 From: Andy Newton To: "carlos@lacnic.net" , Marc Blanchet Thread-Topic: [weirds] bootstrap draft Thread-Index: AQHOYW65gxF3aHVj2kC+4xG1HI1s0pkncOgA///EEgA= Date: Wed, 5 Jun 2013 14:49:47 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED4C8@CHAXCH01.corp.arin.net> In-Reply-To: <51AF4A10.4020901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <0855F471D4FFFD48B4E9860D231C1B8B@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:50:03 -0000 On 6/5/13 10:24 AM, "Carlos M. Martinez" wrote: >- The document proposes clients should query the rdap.arpa tree for >A/AAAA records but doesn't specify how to construct a URL for the actual >HTTP request. This draft seems to be written from the standpoint that RDAP clients will have good DNS libraries. If that is the assumption, I think it is a bad plan (and a topic we have discussed before). If that is not the case, then showing how HTTP URLs will be constructed will be necessary. Additionally, guidance that both A and AAAA queries would lead a reader to believe that an RDAP client has a DNS facility that allows it, whereas most RDAP clients will be built onto of HTTP libraries. >- Why query for A/AAAA ? Why not query, for example, for TXT and put the >RDAP URLs in TXT records ? As another possibility someone (I think it >was Andy) brought up the NAPTR records. PLEASE NO! Let's not do DNS manipulation beyond what can be done in an HTTP URL. I also fear any DNS TXT debate. For the record, my NicInfo client does bootstrapping for IPv4, IPv6, and ASNs without any of this machinery. I simply grabbed the IANA XML files. Given the redirect model that the RIRs can setup where we redirect to the appropriate RIR if the query went to the wrong server (needed for ERX anyway), this is good enough. Domains are a bit different. -andy From gavin.brown@centralnic.com Wed Jun 5 08:09:54 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFC221F89A5 for ; Wed, 5 Jun 2013 08:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okBaLbI7YmWq for ; Wed, 5 Jun 2013 08:09:50 -0700 (PDT) Received: from smtp.centralnic.com (unknown [193.105.170.214]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCFE21F9AC0 for ; Wed, 5 Jun 2013 08:09:49 -0700 (PDT) Received: from CNIC-MBP-200117.local (unknown [31.68.68.36]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id E70C872066E; Wed, 5 Jun 2013 15:09:46 +0000 (UTC) Message-ID: <51AF54B9.8010601@centralnic.com> Date: Wed, 05 Jun 2013 16:09:45 +0100 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marc Blanchet X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:09:55 -0000 Hi Marc, (wearing my CentralNic hat) I am concerned about how this specification would effect those of us who operate name registries within another's namespace. As the registry for .uk.com domains (and a number of others), how do I get our RDAP service registered in the rdap.arpa zone? Do I ask IANA to create the records in the DNS, or do I ask Verisign? Would IANA even accept a request from me? I would not like to have to ask Verisign for permission to have a visible RDAP service. The DNS was designed to allow people to create registries within their zones without asking permission from their parent, and I hope RDAP will not hinder this freedom. (not hat, or perhaps my RDAP.ORG hat) Section 8 of this draft appears to conflict with draft-ietf-weirds-rdap-query, section 4, which permits a "base URL" to which the standard path segments are appended. There is no mechanism in your design for an RDAP client to determine the appropriate base URL, only the host part. There is also no way to determine whether HTTPS should be preferred over HTTP. I suppose you could use a NAPTR record instead of address records, but an HTTP redirect seems more RDAP-like to me (which is why RDAP.ORG exists). G. -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From carlos@lacnic.net Wed Jun 5 08:11:53 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F18421F99E6 for ; Wed, 5 Jun 2013 08:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smZDgrELKthQ for ; Wed, 5 Jun 2013 08:11:52 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id D47CF21F9AD6 for ; Wed, 5 Jun 2013 08:11:51 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:7000:cd6c:5ba1:decc:86e4]) by mail.lacnic.net.uy (Postfix) with ESMTP id A5ABB308437; Wed, 5 Jun 2013 12:11:29 -0300 (UYT) Message-ID: <51AF553C.5050305@lacnic.net> Date: Wed, 05 Jun 2013 12:11:56 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED4C8@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED4C8@CHAXCH01.corp.arin.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: carlos@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:11:53 -0000 Hey, On 6/5/13 11:49 AM, Andy Newton wrote: > On 6/5/13 10:24 AM, "Carlos M. Martinez" wrote: ... snip... >> - Why query for A/AAAA ? Why not query, for example, for TXT and put the >> RDAP URLs in TXT records ? As another possibility someone (I think it >> was Andy) brought up the NAPTR records. > > PLEASE NO! Let's not do DNS manipulation beyond what can be done in an > HTTP URL. I also fear any DNS TXT debate. Ha! Sorry if it wasn't you :D > > For the record, my NicInfo client does bootstrapping for IPv4, IPv6, and > ASNs without any of this machinery. I simply grabbed the IANA XML files. > Given the redirect model that the RIRs can setup where we redirect to the > appropriate RIR if the query went to the wrong server (needed for ERX > anyway), this is good enough. My redirector-only implementation does the same. Works well enough, but it still does not provide a complete solution as the URLs can only be constructed by having researched the base URLs for each provider beforehand. > > -andy ~Carlos From edainow@afilias.info Wed Jun 5 09:41:25 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3778E21F9B5D for ; Wed, 5 Jun 2013 09:41:25 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YWOgbz7IdYk for ; Wed, 5 Jun 2013 09:41:06 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id E708021F9B79 for ; Wed, 5 Jun 2013 09:40: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 1UkGkr-0004MG-5c for weirds@ietf.org; Wed, 05 Jun 2013 16:40:09 +0000 Received: from mail-ob0-f173.google.com ([209.85.214.173]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UkGkr-0000AM-5D for weirds@ietf.org; Wed, 05 Jun 2013 16:40:09 +0000 Received: by mail-ob0-f173.google.com with SMTP id wc20so2932642obb.4 for ; Wed, 05 Jun 2013 09:40:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=asAcEAoCuMLpM3+HCR8PvlMmrLmW7prC9BUISNKbuxs=; b=TcqwjcsX9aObjhZCkw2Ete+HS4jXv4U00Hv3pBbLZARjLiDBIO8dI6mWZGVVTcFHE4 kXLECDpWnBj4FLiQKl6Z1Leto7DQuICufVhC7QbLIoaOgJ+cE4/z2ury4AvENlR3ZqEk GWnYCN+EDH5FSDHIItl+JIPY/u/nNb+DeV8HdnpyI62XSFjATuU3DwqBMtA0Qf/6miL6 tBTdYWM1yzqShpcrCcjEAz5IwnbmZf1JsepmYzLzZTSTy1dQB/5lH4eDQZHgyCMyMu8a NrkL9Zbpt0XS7IDbI3PhAqfKmLaPdOkdLmUvuEkmn98llERFgCatoIQZm/d2nIPSBpHD PDgA== X-Received: by 10.60.117.41 with SMTP id kb9mr4517708oeb.33.1370450404150; Wed, 05 Jun 2013 09:40:04 -0700 (PDT) X-Received: by 10.60.117.41 with SMTP id kb9mr4517701oeb.33.1370450404067; Wed, 05 Jun 2013 09:40:04 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id oe10sm9295785oeb.6.2013.06.05.09.40.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 09:40:03 -0700 (PDT) Message-ID: <51AF69DF.5040409@afilias.info> Date: Wed, 05 Jun 2013 12:39:59 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEA1EF@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEA1EF@CHAXCH01.corp.arin.net> Content-Type: multipart/alternative; boundary="------------000708010509090006060703" X-Gm-Message-State: ALoCoQnpF4JhREVPtlmuBjlPP7zXrLdHyIyibzmh4wqktmS6thDqR1gm9MaRtR48CfIogyhf/bHr/sApbEbDDdrlycNtoTWYzzj14GDH5Bbr2/c0V/fR3u83LoIuli6nWU/pRw+pwqGL Cc: "weirds@ietf.org" Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:41:25 -0000 This is a multi-part message in MIME format. --------------000708010509090006060703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/4/2013 4:56 PM, Andy Newton wrote: > From: Ernie Dainow > > Date: Tuesday, June 4, 2013 2:40 PM > To: Andrew Newton > > Cc: "weirds@ietf.org " > > Subject: Re: [weirds] ICANN Whois Specifications > > From the ICANN Specifications: > The Maintainer URL (email or website). The maintainer is a > person that has been designated by the Registrar for the > registration of the domain (for example a reseller, could also > depend on the registrant). > > If Maintainer is an email, using a jCard embedded in the Domain > object would not have context to identify what it is. So it seems > best to use a jCard in an Entity object and use another role, say > "Maintainer", for this type of entity. > > > Isn't "registrant" the same thing as "maintainer"? Otherwise I agree. > > I think the maintainer is separate from the registrant, as in a reseller. registrant -----> reseller -------> registrar -Ernie --------------000708010509090006060703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 6/4/2013 4:56 PM, Andy Newton wrote:
From: Ernie Dainow <edainow@afilias.info>
Date: Tuesday, June 4, 2013 2:40 PM
To: Andrew Newton <andy@arin.net>
Cc: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] ICANN Whois Specifications

From the ICANN Specifications:
    The Maintainer URL (email or website). The maintainer is a person that has been designated by the Registrar for the registration of the domain (for example a reseller, could also depend on the registrant).

If Maintainer is an email, using a jCard embedded in the Domain object would not have context to identify what it is. So it seems best to use a jCard in an Entity object and use another role, say "Maintainer", for this type of entity.

Isn't "registrant" the same thing as "maintainer"? Otherwise I agree.


I think the maintainer is separate from the registrant, as in a reseller.
     registrant ----->  reseller -------> registrar

-Ernie

--------------000708010509090006060703-- From andy@arin.net Wed Jun 5 10:58:13 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FB021F9640 for ; Wed, 5 Jun 2013 10:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYv2ArE7shkh for ; Wed, 5 Jun 2013 10:58:08 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB4F21F9A69 for ; Wed, 5 Jun 2013 10:58:08 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id C8B4C165223; Wed, 5 Jun 2013 13:58:07 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 5BCF01650E7; Wed, 5 Jun 2013 13:58:07 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 5 Jun 2013 13:57:54 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.190]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 13:58:07 -0400 From: Andy Newton To: "Carlos M. Martinez" Thread-Topic: [weirds] bootstrap draft Thread-Index: AQHOYW65gxF3aHVj2kC+4xG1HI1s0pkncOgA///EEgCAAEk/AP//61yA Date: Wed, 5 Jun 2013 17:58:06 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> In-Reply-To: <51AF553C.5050305@lacnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:58:13 -0000 On 6/5/13 11:11 AM, "Carlos M. Martinez" wrote: >My redirector-only implementation does the same. Works well enough, but >it still does not provide a complete solution as the URLs can only be >constructed by having researched the base URLs for each provider >beforehand. Since this information does not change too much, a "works well enough" implementation is all we need. What's wrong with the IANA keeping a registry of domain registry operators to RDAP base URLs? Since the IANA keeps its registries in XML, a client can just go fetch that every so often (every 6 months or so) and update its map. And that strategy is already available for IP addresses and ASNs. -andy From andy@arin.net Wed Jun 5 10:59:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E744221F9B9B for ; Wed, 5 Jun 2013 10:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.294 X-Spam-Level: X-Spam-Status: No, score=-3.294 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eXCGGHAx4Am for ; Wed, 5 Jun 2013 10:59:34 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 6D00921F9A24 for ; Wed, 5 Jun 2013 10:59:34 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id AA91C213684; Wed, 5 Jun 2013 13:59:20 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 2F74C21365A; Wed, 5 Jun 2013 13:59:20 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 5 Jun 2013 13:59:06 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.190]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 13:59:18 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] ICANN Whois Specifications Thread-Index: AQHOYIQ2weBqCM/1Bk2sY5mV/PjGWpkkuKMAgAFvUwD//+L/AIABjbOA///TF4A= Date: Wed, 5 Jun 2013 17:59:18 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5F8@CHAXCH01.corp.arin.net> In-Reply-To: <51AF69DF.5040409@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.34.130] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5F8CHAXCH01corpari_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:59:40 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5F8CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ernie Dainow > Date: Wednesday, June 5, 2013 12:39 PM To: Andrew Newton > Cc: "weirds@ietf.org" > Subject: Re: [weirds] ICANN Whois Specifications I think the maintainer is separate from the registrant, as in a reseller. registrant -----> reseller -------> registrar There are many more relationships that a registrant has with a registry tha= n just these two. I don't think it is wise to define a new term for each ty= pe of relationship a registrant has with the registry. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5F8CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <618709729732BA4DA4376F8C16D21F52@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: Ernie Dainow <edainow@afilias.info>
Date: Wednesday, June 5, 2013 12:39= PM
To: Andrew Newton <andy@arin.net>
Cc: "weirds@ietf.org" <= weirds@ietf.org>
Subject: Re: [weirds] ICANN Whois S= pecifications

I think the maintainer is separate from the registrant, as in a reseller.
     registrant ----->  reseller -------> registrar

There are many more relationships that a registrant has with a registr= y than just these two. I don't think it is wise to define a new term for ea= ch type of relationship a registrant has with the registry.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5F8CHAXCH01corpari_-- From aservin@lacnic.net Wed Jun 5 11:02:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC8521F99D4 for ; Wed, 5 Jun 2013 11:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z24zZv79cK1T for ; Wed, 5 Jun 2013 11:02:13 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id B0EAD21F9A52 for ; Wed, 5 Jun 2013 11:02:03 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [200.7.87.33]) by mail.lacnic.net.uy (Postfix) with ESMTP id 2777930843C; Wed, 5 Jun 2013 15:01:41 -0300 (UYT) Message-ID: <51AF7D11.6020101@lacnic.net> Date: Wed, 05 Jun 2013 15:01:53 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "Carlos M. Martinez" , "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:02:17 -0000 X-List-Received-Date: Wed, 05 Jun 2013 18:02:17 -0000 Andy, That could work. It could be in addition to redirects or instead of. Regards, as On 6/5/13 2:58 PM, Andy Newton wrote: > On 6/5/13 11:11 AM, "Carlos M. Martinez" wrote: > >> My redirector-only implementation does the same. Works well enough, but >> it still does not provide a complete solution as the URLs can only be >> constructed by having researched the base URLs for each provider >> beforehand. > > Since this information does not change too much, a "works well enough" > implementation is all we need. > > What's wrong with the IANA keeping a registry of domain registry operators > to RDAP base URLs? Since the IANA keeps its registries in XML, a client > can just go fetch that every so often (every 6 months or so) and update > its map. And that strategy is already available for IP addresses and ASNs. > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From shollenbeck@verisign.com Wed Jun 5 11:09:34 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AF221F9A52 for ; Wed, 5 Jun 2013 11:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FW5dcrFWGFK for ; Wed, 5 Jun 2013 11:09:28 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id CA1A121F9A24 for ; Wed, 5 Jun 2013 11:09:23 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUa9+xpNNyew2Ao8ltSUlS5pDlePE9aG3@postini.com; Wed, 05 Jun 2013 11:09:27 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r55I97Qg015393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 14:09:07 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Jun 2013 14:09:06 -0400 From: "Hollenbeck, Scott" To: Andy Newton , "Carlos M. Martinez" Thread-Topic: [weirds] bootstrap draft Thread-Index: AQHOYW65gxF3aHVj2kC+4xG1HI1s0pkncOgA///EEgCAAEk/AP//61yAgAACN3A= Date: Wed, 5 Jun 2013 18:09:06 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243A2AE4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <51AF553C.5050305@lacnic.net> <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.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 Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:09:34 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Andy Newton > Sent: Wednesday, June 05, 2013 1:58 PM > To: Carlos M. Martinez > Cc: weirds@ietf.org > Subject: Re: [weirds] bootstrap draft >=20 > On 6/5/13 11:11 AM, "Carlos M. Martinez" wrote: >=20 > >My redirector-only implementation does the same. Works well enough, > but > >it still does not provide a complete solution as the URLs can only be > >constructed by having researched the base URLs for each provider > >beforehand. >=20 > Since this information does not change too much, a "works well enough" > implementation is all we need. >=20 > What's wrong with the IANA keeping a registry of domain registry > operators > to RDAP base URLs? Since the IANA keeps its registries in XML, a client > can just go fetch that every so often (every 6 months or so) and update > its map. And that strategy is already available for IP addresses and > ASNs. Simple and consistent with existing practice? That takes all the fun out of= over-engineering a solution! Seriously, though, if the IANA registry map is already being used to solve = a similar problem - and has been demonstrated to work - there's a lot to be= said for reusing existing technology. Scott From marc.blanchet@viagenie.ca Wed Jun 5 11:17:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2347321F84AA for ; Wed, 5 Jun 2013 11:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TQ0CAdRdLnJ for ; Wed, 5 Jun 2013 11:17:10 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CC69F21F8E12 for ; Wed, 5 Jun 2013 11:16:44 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 33D2240415; Wed, 5 Jun 2013 14:16:44 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Marc Blanchet In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> Date: Wed, 5 Jun 2013 14:16:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26346BE3-B1BB-4A76-8963-A35596263829@viagenie.ca> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1503) Cc: "Carlos M. Martinez" , "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:17:11 -0000 Le 2013-06-05 =E0 13:58, Andy Newton a =E9crit : > On 6/5/13 11:11 AM, "Carlos M. Martinez" wrote: >=20 >> My redirector-only implementation does the same. Works well enough, = but >> it still does not provide a complete solution as the URLs can only be >> constructed by having researched the base URLs for each provider >> beforehand. >=20 > Since this information does not change too much, a "works well enough" > implementation is all we need. >=20 > What's wrong with the IANA keeping a registry of domain registry = operators > to RDAP base URLs? Since the IANA keeps its registries in XML, a = client > can just go fetch that every so often (every 6 months or so) and = update > its map. And that strategy is already available for IP addresses and = ASNs. ok. I think there are pros and cons for each approach. I'm half way done = writing a separate draft on the "exclusive" use of IANA registries to = see where it goes and will publish it tonight or tomorrow. Then, we can = discuss and compare. I think that topic warrants some discussion time = during Berlin... While bootstrapping was not clearly in scope at the beginning, I think = it is pretty important to get it done. We don't want various = implementations doing different things as we have seen just here and = behave differently and having different answers.=20 Marc. >=20 > -andy From edainow@afilias.info Wed Jun 5 11:24:01 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC4921F9B99 for ; Wed, 5 Jun 2013 11:24:01 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P81UAc5ft3rn for ; Wed, 5 Jun 2013 11:23:55 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8433521F9BA4 for ; Wed, 5 Jun 2013 11:23:49 -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 1UkIN8-0001IK-3P for weirds@ietf.org; Wed, 05 Jun 2013 18:23:46 +0000 Received: from mail-oa0-f46.google.com ([209.85.219.46]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UkIN7-0006e7-6L for weirds@ietf.org; Wed, 05 Jun 2013 18:23:46 +0000 Received: by mail-oa0-f46.google.com with SMTP id h2so1428425oag.33 for ; Wed, 05 Jun 2013 11:23:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=hNq+yaJ0Oq2iXluTeJDCoMYEE3nfhAI1kCcAKEfZpTY=; b=RSXjB+AvN8FTQbqgcen1IW8YfTTTbLgHsBtl3CSqP4mNANeeG6lh5IV/VKjcc2jvy9 WTGZsr+Qovvs9T/DtVcpeynmQbkwPbTvHMIbpnYCfNWFrrt7pDCpMj+P6J8cy30cg7sk hb6dfuINMOwFo031pJblw5jiLpE9k920X4V2ThAOwGQ+K7GdrkD5C3huwEJBfQWZtFX3 kkFQqrLLVqmNZXAhi47MJPfnkWPkgkrH2MZl44icaI/JL/BgMKdFJ04HTJ6aCLMZxKuz 97umBijtE8drkFyD4omoXxWU0r60lCTqtn0Z50YsY1mwTGk6f2Ri7YimJ+qarduLwGwU Ceug== X-Received: by 10.60.178.242 with SMTP id db18mr15286790oec.74.1370456620491; Wed, 05 Jun 2013 11:23:40 -0700 (PDT) X-Received: by 10.60.178.242 with SMTP id db18mr15286785oec.74.1370456620371; Wed, 05 Jun 2013 11:23:40 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id ei16sm8332264oeb.7.2013.06.05.11.23.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 11:23:39 -0700 (PDT) Message-ID: <51AF8227.6030305@afilias.info> Date: Wed, 05 Jun 2013 14:23:35 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD898D@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD898D@CHAXCH01.corp.arin.net> Content-Type: multipart/alternative; boundary="------------010004000203020705080509" X-Gm-Message-State: ALoCoQk3SZZsY//zsx/JRLs4f7QR7ccKO0xrXixMxtXjcz/Z4esIbuWx8mQkbqNTsG1ca4ZgnrNOWDMgHjB1Q+zNO47tHvXV/eLAMqwRoeFgTp/BCBvaqLAxnr1kDll1+Uhw9Dcw5ErB Cc: "weirds@ietf.org" Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:24:01 -0000 This is a multi-part message in MIME format. --------------010004000203020705080509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/3/2013 8:45 PM, Andy Newton wrote: > ... > > Some of the others do not have an explanation. What is an ENS_AuthID? > And what does "Currently Associated" mean? I don't think we should > blindly put in items we don't understand. > > From ICANN Specifications: ENS_AuthId identifies the authorization of the registration, (this enables tracking of registrations performed using the same ENS_AuthId). "Currently Associated" indicates whether the contact or nameserver is associated with a registered domain. A concise way to support this is by adding some status values, "associated"/"not associated" or more generically, "in use"/"not in use". These have been ICANN requirements in several agreements since 2009. -Ernie --------------010004000203020705080509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 6/3/2013 8:45 PM, Andy Newton wrote:
...

Some of the others do not have an explanation. What is an ENS_AuthID? And what does "Currently Associated" mean? I don't think we should blindly put in items we don't understand.


From ICANN Specifications: 
    ENS_AuthId identifies the authorization of the registration,
    (this enables tracking of registrations performed using the same ENS_AuthId).

"Currently Associated" indicates whether the contact or nameserver is associated with a registered domain. A concise way to support this is by adding some status values, "associated"/"not associated" or more generically, "in use"/"not in use".

These have been ICANN requirements in several agreements since 2009.

-Ernie


--------------010004000203020705080509-- From carlos@lacnic.net Wed Jun 5 11:35:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AAE21F8CDD for ; Wed, 5 Jun 2013 11:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DM7C-V7Hcwi for ; Wed, 5 Jun 2013 11:35:23 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id EF7D021F9A8C for ; Wed, 5 Jun 2013 11:34:06 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:7000:25bd:5601:95ef:ec56]) by mail.lacnic.net.uy (Postfix) with ESMTP id 7F3BA30845F; Wed, 5 Jun 2013 15:33:18 -0300 (UYT) Message-ID: <51AF847C.90707@lacnic.net> Date: Wed, 05 Jun 2013 15:33:32 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <51AF553C.5050305@lacnic.net> <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> <831693C2CDA2E849A7D7A712B24E257F243A2AE4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243A2AE4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: carlos@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:35:24 -0000 Adding a column to the ipv4, ipv6 and asn registries listing 'RDAP base URL' for each allocation registrationi would work ? On 6/5/13 3:09 PM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of Andy Newton >> Sent: Wednesday, June 05, 2013 1:58 PM >> To: Carlos M. Martinez >> Cc: weirds@ietf.org >> Subject: Re: [weirds] bootstrap draft >> >> On 6/5/13 11:11 AM, "Carlos M. Martinez" wrote: >> >>> My redirector-only implementation does the same. Works well enough, >> but >>> it still does not provide a complete solution as the URLs can only be >>> constructed by having researched the base URLs for each provider >>> beforehand. >> Since this information does not change too much, a "works well enough" >> implementation is all we need. >> >> What's wrong with the IANA keeping a registry of domain registry >> operators >> to RDAP base URLs? Since the IANA keeps its registries in XML, a client >> can just go fetch that every so often (every 6 months or so) and update >> its map. And that strategy is already available for IP addresses and >> ASNs. > Simple and consistent with existing practice? That takes all the fun out of over-engineering a solution! > > Seriously, though, if the IANA registry map is already being used to solve a similar problem - and has been demonstrated to work - there's a lot to be said for reusing existing technology. > > Scott From carlos@lacnic.net Wed Jun 5 11:36:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACF621F935A for ; Wed, 5 Jun 2013 11:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odoDjQSXWOLT for ; Wed, 5 Jun 2013 11:36:36 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3889921F9700 for ; Wed, 5 Jun 2013 11:36:32 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy (unknown [200.7.87.57]) by mail.lacnic.net.uy (Postfix) with ESMTP id 1323630845F; Wed, 5 Jun 2013 15:35:40 -0300 (UYT) Message-ID: <51AF8509.3020900@lacnic.net> Date: Wed, 05 Jun 2013 15:35:53 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <51AF553C.5050305@lacnic.net> <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> <831693C2CDA2E849A7D7A712B24E257F243A2AE4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243A2AE4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: carlos@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:36:42 -0000 Sorry I hit enter to quickly. The issue of bootstrapping for names remains though. On 6/5/13 3:09 PM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of Andy Newton >> Sent: Wednesday, June 05, 2013 1:58 PM >> To: Carlos M. Martinez >> Cc: weirds@ietf.org >> Subject: Re: [weirds] bootstrap draft >> >> On 6/5/13 11:11 AM, "Carlos M. Martinez" wrote: >> >>> My redirector-only implementation does the same. Works well enough, >> but >>> it still does not provide a complete solution as the URLs can only be >>> constructed by having researched the base URLs for each provider >>> beforehand. >> Since this information does not change too much, a "works well enough" >> implementation is all we need. >> >> What's wrong with the IANA keeping a registry of domain registry >> operators >> to RDAP base URLs? Since the IANA keeps its registries in XML, a client >> can just go fetch that every so often (every 6 months or so) and update >> its map. And that strategy is already available for IP addresses and >> ASNs. > Simple and consistent with existing practice? That takes all the fun out of over-engineering a solution! > > Seriously, though, if the IANA registry map is already being used to solve a similar problem - and has been demonstrated to work - there's a lot to be said for reusing existing technology. > > Scott From carlos@lacnic.net Wed Jun 5 11:37:36 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77D421F9263 for ; Wed, 5 Jun 2013 11:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAaop9BiGxyx for ; Wed, 5 Jun 2013 11:37:36 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0E48421F9B4D for ; Wed, 5 Jun 2013 11:37:29 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:7000:25bd:5601:95ef:ec56]) by mail.lacnic.net.uy (Postfix) with ESMTP id 0B9D6308463; Wed, 5 Jun 2013 15:36:54 -0300 (UYT) Message-ID: <51AF8553.5020501@lacnic.net> Date: Wed, 05 Jun 2013 15:37:07 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: carlos@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:37:36 -0000 I'll add my experience doing that to the redirects draft (if the WG agrees), Andy you can chip in if you want. Having this experience documented may be a good thing. regards ~Carlos On 6/5/13 2:58 PM, Andy Newton wrote: > On 6/5/13 11:11 AM, "Carlos M. Martinez" wrote: > >> My redirector-only implementation does the same. Works well enough, but >> it still does not provide a complete solution as the URLs can only be >> constructed by having researched the base URLs for each provider >> beforehand. > Since this information does not change too much, a "works well enough" > implementation is all we need. > > What's wrong with the IANA keeping a registry of domain registry operators > to RDAP base URLs? Since the IANA keeps its registries in XML, a client > can just go fetch that every so often (every 6 months or so) and update > its map. And that strategy is already available for IP addresses and ASNs. > > -andy From edainow@afilias.info Wed Jun 5 11:42:05 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2463E21F8825 for ; Wed, 5 Jun 2013 11:42:04 -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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwly1DX9-Qvy for ; Wed, 5 Jun 2013 11:41:56 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 914EB21F9B65 for ; Wed, 5 Jun 2013 11:41:14 -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 1UkIe1-0003Ce-5c for weirds@ietf.org; Wed, 05 Jun 2013 18:41:13 +0000 Received: from mail-la0-f49.google.com ([209.85.215.49]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UkIe1-0007S1-4z for weirds@ietf.org; Wed, 05 Jun 2013 18:41:13 +0000 Received: by mail-la0-f49.google.com with SMTP id fp12so1139177lab.22 for ; Wed, 05 Jun 2013 11:41:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=OVcl46AoYx6BgxRep7DGky7VPlTBfWsCc/rO/pCQ+8w=; b=HQciDmE/3SmvBNd9kCDcIlQLINw+0t5qhtkpC+If2Ueg0HPab94mT20SNNLgPrlWFt hyvcM8NLLBwPGB5mnGiHIO4WvkZq/asaiWrZ8qJaPM6dqNTTuOPc68LFgcQ89q9ZvRnu dskDp2HybyLG+ROEHw5/2dXCiFzucTqzXw3893WfPl/2pQEixGvKC65/L4mc4kPX62kM uahmyTGvQ+nyuw6VfZJkavHHsWqEsMnk09MS3qB9NgO3YUR+CPxQmykWnv6iiW4e8qSx uAwHSC7cYTj5lmagdOHF/RPpF7YZucuGWLVQnYa9xhxU4hUnu2mZ628d2owunZbRq18z LTUw== X-Received: by 10.112.3.194 with SMTP id e2mr14999186lbe.74.1370457667247; Wed, 05 Jun 2013 11:41:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.3.194 with SMTP id e2mr14999177lbe.74.1370457667046; Wed, 05 Jun 2013 11:41:07 -0700 (PDT) Received: by 10.112.25.33 with HTTP; Wed, 5 Jun 2013 11:41:06 -0700 (PDT) In-Reply-To: <51AF8553.5020501@lacnic.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DED5E5@CHAXCH01.corp.arin.net> <51AF8553.5020501@lacnic.net> Date: Wed, 5 Jun 2013 14:41:06 -0400 Message-ID: From: Ernie Dainow To: "Carlos M. Martinez" Content-Type: multipart/alternative; boundary=14dae94edbeb6ca1b204de6c8a28 X-Gm-Message-State: ALoCoQkVmQgiPy1uBix89TORqpP7iGGfbzWSIA/TdVoptudDRHiHVf4G2dJMUs6PpaeaeO96KJx1OOQhXWwX2wXDzlSbrKHK0nKFoz9r8Lzg5EJkB6+sQyfCWXEhxEfWeMVeCt7sBMqk Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:42:05 -0000 --14dae94edbeb6ca1b204de6c8a28 Content-Type: text/plain; charset=ISO-8859-1 An IANA map seems a lot simpler than a full reverse DNS approach. Its not too hard to write code in a client to update and store its IANA map regularly. An RDAP redirector should certainly do automated frequent updates, say every night. It then provides a backup for clients who don't. In addition, registry operators who change their RDAP urls in IANA should keep their old service operating for a reasonable length of time so clients don't fail. -Ernie On Wed, Jun 5, 2013 at 2:37 PM, Carlos M. Martinez wrote: > I'll add my experience doing that to the redirects draft (if the WG > agrees), Andy you can chip in if you want. Having this experience > documented may be a good thing. > > regards > > ~Carlos > > On 6/5/13 2:58 PM, Andy Newton wrote: > > On 6/5/13 11:11 AM, "Carlos M. Martinez" wrote: > > > >> My redirector-only implementation does the same. Works well enough, but > >> it still does not provide a complete solution as the URLs can only be > >> constructed by having researched the base URLs for each provider > >> beforehand. > > Since this information does not change too much, a "works well enough" > > implementation is all we need. > > > > What's wrong with the IANA keeping a registry of domain registry > operators > > to RDAP base URLs? Since the IANA keeps its registries in XML, a client > > can just go fetch that every so often (every 6 months or so) and update > > its map. And that strategy is already available for IP addresses and > ASNs. > > > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --14dae94edbeb6ca1b204de6c8a28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
An IANA map seems a lot simpler than a full reverse DNS ap= proach.

Its not too hard to write code in a client to up= date and store its IANA map regularly.

An RDAP red= irector should certainly do automated frequent updates, say every night. It= then provides a backup for clients who don't.

In addition, registry operators who change their RDAP u= rls in IANA should keep their old service operating for a reasonable length= of time so clients don't fail.

-Ernie



On Wed, Jun 5, 2013 at 2:37 PM, Carlos M. Martinez <carlos@lacnic.= net> wrote:
I'll add my experience doing that to the= redirects draft (if the WG
agrees), Andy you can chip in if you want. Having this experience
documented may be a good thing.

regards

~Carlos

On 6/5/13 2:58 PM, Andy Newton wrote:
> On 6/5/13 11:11 AM, &quo= t;Carlos M. Martinez" <carlos@= lacnic.net> wrote:
>
>> My redirector-only implementation does the same. Works well enough= , but
>> it still does not provide a complete solution as the URLs can only= be
>> constructed by having researched the base URLs for each provider >> beforehand.
> Since this information does not change too much, a "works well en= ough"
> implementation is all we need.
>
> What's wrong with the IANA keeping a registry of domain registry o= perators
> to RDAP base URLs? Since the IANA keeps its registries in XML, a clien= t
> can just go fetch that every so often (every 6 months or so) and updat= e
> its map. And that strategy is already available for IP addresses and A= SNs.
>
> -andy

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

--14dae94edbeb6ca1b204de6c8a28-- From superuser@gmail.com Wed Jun 5 12:06:53 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBEB21F9BC9 for ; Wed, 5 Jun 2013 12:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKMPQFGd6H0e for ; Wed, 5 Jun 2013 12:06:50 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 32C9921F85C3 for ; Wed, 5 Jun 2013 12:04:52 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hm9so2129954wib.10 for ; Wed, 05 Jun 2013 12:04: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=bsCyBLxBz1tc+09oNSPHb3k31ar7LmBeoEthfi0RvCw=; b=zNRIXkjFqlrcsqYdQPrZX3YiFAzn1I/IOwPGBL/vU2GyZbtwBTXXPcS8ryIdQrh7Kf 9PY7nJt7P4BaH41lfWgZDgNWJZjcV2ewdPC/kKCObC8Bmt8wjQJrMKkogNhRRlUY3C9b 6P+KnwUdA7Zpo5/sXWzJUFA7w9eDm4DaZrNwhn2/ASmfsiOf+hQq0HlptMi/gAlN+yER HSvY19kvk2T15wm3b5Gw8AVKhzJVcCd0RQJjZwWNvP2Dbh3l+nU7YHWduBQFbDD6hdJv djNW3I/3FuWwui/cJnAC3AyD3QUlOuOHvfUOAFOkxwpgz37gRMgb3u4+ESzMXSEPjKYW sEYg== MIME-Version: 1.0 X-Received: by 10.180.208.81 with SMTP id mc17mr8138674wic.35.1370459053370; Wed, 05 Jun 2013 12:04:13 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Wed, 5 Jun 2013 12:04:13 -0700 (PDT) In-Reply-To: References: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F243A2175@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 5 Jun 2013 12:04:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=001a11c33bb00e428c04de6cdd2a Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:06:53 -0000 --001a11c33bb00e428c04de6cdd2a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 7:16 AM, Murray S. Kucherawy wrote: > On Wed, Jun 5, 2013 at 4:03 AM, Hollenbeck, Scott < > shollenbeck@verisign.com> wrote: > >> >> Thanks for taking the time to write this, Marc. One suggestion at first >> glance: RFC 1035 doesn't use the term "NXDOMAIN". Would you consider "name >> error" or "response code 3" instead? >> >> >> > ...or at least declare in a definitions section that NXDOMAIN is a > symbolic name for response code 3. I've done that in other drafts. > > > > ...or reference RFC2308, which defines it. -MSK --001a11c33bb00e428c04de6cdd2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --001a11c33bb00e428c04de6cdd2a-- From marc.blanchet@viagenie.ca Wed Jun 5 13:54:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF03421F909A for ; Wed, 5 Jun 2013 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwaOFjiMzzCA for ; Wed, 5 Jun 2013 13:54: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 19BE521F90EF for ; Wed, 5 Jun 2013 13:54:16 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BA8EC40415 for ; Wed, 5 Jun 2013 16:54:09 -0400 (EDT) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_40801A11-C140-4FD6-B087-757EFAB6FD26" Date: Wed, 5 Jun 2013 16:54:08 -0400 References: <20130605204940.20845.36199.idtracker@ietfa.amsl.com> To: "weirds@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:54:24 -0000 --Apple-Mail=_40801A11-C140-4FD6-B087-757EFAB6FD26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello, this is a draft on bootstrapping, but instead of using DNS as the other = draft I sent, this one uses IANA XML registries, as discussed. That way = we have two proposal on the table we can compare. At one time, one of = these two drafts will be dropped... ;-) Please comment. Regards, Marc. D=E9but du message r=E9exp=E9di=E9 : > De : internet-drafts@ietf.org > Objet : I-D Action: = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt > Date : 5 juin 2013 16:49:40 HAE > =C0 : i-d-announce@ietf.org > R=E9pondre =E0 : internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Finding the Authoritative Registration Data = (RDAP) Service > Author(s) : Marc Blanchet > Filename : = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt > Pages : 6 > Date : 2013-06-05 >=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, using data available in IANA registries. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-blanchet-weirds-bootstrap-ianaregis= tries >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregistries-= 00 >=20 >=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 --Apple-Mail=_40801A11-C140-4FD6-B087-757EFAB6FD26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Objet : I-D Action: = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
=
Date : 5 juin 2013 = 16:49:40 HAE
R=E9pondre =E0 : = internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.


Title =           : Finding = the Authoritative Registration Data (RDAP) Service
Author(s) =       : Marc Blanchet
Filename =        : = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
Pages =           : 6
Date =            : = 2013-06-05

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, using data available in IANA = registries.


The IETF datatracker status page for this draft = is:
https://datatracker.ietf.org/doc/draft-blanchet-weirds-boot= strap-ianaregistries

There's also a htmlized version = available = at:
http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregi= stries-00


Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
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

= = --Apple-Mail=_40801A11-C140-4FD6-B087-757EFAB6FD26-- From nkong@cnnic.cn Wed Jun 5 19:18:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1522121F9985 for ; Wed, 5 Jun 2013 19:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqH9Sln5z+2s for ; Wed, 5 Jun 2013 19:18:26 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id EC41D21F9984 for ; Wed, 5 Jun 2013 19:18:25 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [218.241.103.181]) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 06 Jun 2013 10:18:18 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ning Kong In-Reply-To: <51AE4394.30801@qti.qualcomm.com> Date: Thu, 6 Jun 2013 10:18:24 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51A618F4.8020802@qti.qualcomm.com> <67153352-D4CE-4578-9E7C-36410017CD80@cnnic.cn> <51AE4394.30801@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1503) Cc: weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 02:18:43 -0000 Hi Pete, Please see our feedbacks inline. =20 >> We think the wording in Section 3 needs to be rewritten so as to not = be contradictory: >>=20 >> Second, the semantics of the request/response allow for future and/or = non-standard response formats. At present, the IETF Web Extensibility = Internet Registration Data Service (WEIRDS) working group is defining = only a JSON [RFC4627] response format, and this document only describes = how RDAP is transported using HTTP with this format. >> =20 >=20 > OK, but I think that reveals another potential problem: I was going to = suggest that instead of, "At present, the IETF Web Extensibility = Internet Registration Data Service (WEIRDS) working group is defining = only a JSON [RFC4627] response format", because referring to the WG in = the document isn't the best, that perhaps you'd rather say, "At present, = only a JSON [RFC4627] response format is being defined", but that led me = to want to add "in [draft-ietf-weirds-json-response]". And there's your = problem. Section 4.1 is requiring (as in, a "MUST") the use of the JSON = format, which sounds to me like a normative dependency on = draft-ietf-weirds-json-response. >=20 > You need to decide whether you want to write a more generic HTTP = draft, in which case mandating that the application/rdap+json MUST be = used is inappropriate, or if this draft is inextricably linked to the = use of JSON, in which case you'll want to make a normative reference to = -response, and I'll wonder why this draft is being advanced at a = different time than the others. We agree that this document should be a more generic HTTP draft. So we'd = like to remove the MUSTs from section 4.1. If WG agree with that direction, we'd like to check and modify the = wording of JSON in the whole draft soon. >>> Section 5.2: >>>=20 >>> If a server wishes to inform a client that the answer to a given >>> query can be found elsewhere, it MUST return a 301 response code = to >>> indicate a permanent move, or a 307 response code to indicate a = non- >>> permanent redirection, and include an HTTP(s) URL in the Location: >>> header field. >>>=20 >>> Is that MUST there for interoperability reasons? That is, is it = plausible that a server might choose something other than 301 or 307 and = this document is specifically limiting the server to only choose 301 or = 307? The same question for including the URL in the Location header = field. If it *is* a specific limitation, I suggest a minor rewording to = make it clearer: >>>=20 >>> If a server wishes to inform a client that the answer to a given >>> query can be found elsewhere, it MUST return either a 301 response >>> code to indicate a permanent move, or a 307 response code to = indicate >>> a non- permanent redirection, and it MUST include an HTTP(s) URL = in >>> the Location: header field. >>>=20 >>> If it is not a limitation, but rather just a statement of what the = server does, I suggest: >>>=20 >>> If a server wishes to inform a client that the answer to a given >>> query can be found elsewhere, it returns a 301 response code to >>> indicate a permanent move, or a 307 response code to indicate a = non- >>> permanent redirection, and includes an HTTP(s) URL in the = Location: >>> header field. >>> =20 >> As for the response codes, technically 301 and 307 are not the only = choices for redirections. 302 and 303 can also work based on RFC 2616 = but maybe are not best choices. So we think MUSTs are necessary for the = response codes. >> =20 >=20 > Does "not the best choices" mean that clients receiving those = responses won't work as well (i.e., an interoperability issue), or does = it mean simply that they are not the most descriptive and therefore = aesthetically less pleasing? It seems to me that saying "not the best = choices" does not imply "MUSTs are necessary". If the former, your = suggestion is fine: >=20 >> If a server wishes to inform a client that the answer to a given = query can be found elsewhere, it MUST return either a 301 response code = to indicate a permanent move, or a 307 response code to indicate a = non-permanent redirection, and it includes an HTTP(s) URL in the = Location: header field. >> =20 >=20 > If the latter, perhaps my second suggestion is better. After re-discussion among us, we don't think using a 302 or 303 would be = an interoperability problem, as long as clients understand all four = redirect codes adequately, so maybe we should drop the MUSTs and expand = to mention all the redirects. We recall a discussion early on about not = profiling HTTP that might apply here. So the modified text is based on your second suggestion as following: If a server wishes to inform a client that the answer to a given query = can be found elsewhere, it returns either a 301 response code to = indicate a permanent move, or a 302, 303 or 307 response code to = indicate a non-permanent redirection, and it includes an HTTP(s) URL in = the Location: header field. >>> The syntax itself allows a name of "X______". It also imposes no = length limit. Is that OK? >>> =20 >> There is no length limitation in the JSON standard. So we think this = is ok. >> =20 >=20 > That's fine. And you are also OK with a single ALPHA followed by only = underscores? That's fine with me if that's your intention. X__ does not violate the reasoning given in the second paragraph of that = section, so we think we don't care. A future IETF RFC could very well = define FOO____ and that would be fine. >>> Section 8.2: Shouldn't this registration go in = draft-ietf-weirds-json-response? Also, the reference to 6839 is = Informative, not Normative, as far as I can tell. >>> =20 >> We think it's in here because json-query needs it too. The working = group insisted on it being in this doc. >=20 > This goes back to the issue of whether this document should be = requiring JSON or whether it should be left to other documents. I think even if JSON is not mandatory in HTTP draft, it still makes = sense to keep this section in this draft. Because this section is needed = by not only one document. Cheers, Ning From nkong@cnnic.cn Wed Jun 5 19:39:05 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA8921F96EC for ; Wed, 5 Jun 2013 19:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDTQKXXTmhJC for ; Wed, 5 Jun 2013 19:39:00 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 53F8C21F96EB for ; Wed, 5 Jun 2013 19:38:59 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [218.241.103.181]) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 06 Jun 2013 10:38:55 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ning Kong In-Reply-To: <51AEE464.1030205@dnsbelgium.be> Date: Thu, 6 Jun 2013 10:39:02 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4DC0A688-CE61-4FA6-9DFA-A7CAE8D16EA7@cnnic.cn> References: <51A618F4.8020802@qti.qualcomm.com> <67153352-D4CE-4578-9E7C-36410017CD80@cnnic.cn> <51AE4394.30801@qti.qualcomm.com> <51AEE464.1030205@dnsbelgium.be> To: Pieter Vandepitte X-Mailer: Apple Mail (2.1503) Cc: weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 02:39:05 -0000 Hi Pieter, Thanks for your comments. Please see my feedbacks inline. > Pete has a point here. I think currently the drafts are very much=20 > depending on each other (which is not necessarily a problem) >=20 > I think if it almost definitely sure other content types will ever be=20= > introduced in the future, it would be better to split up documents = into=20 > a > - data model document: abstract data model (not json, really abstract) > - data binding document: binding of the model to some content type:=20 > e.g. json or xml > - protocol document: abstract protocol (currently searches and=20 > lookups), messages and allowed responses > - protocol binding: rest binding, soap binding, thrift, protobuf, = avro,=20 > =E2=80=A6 binding > On the other hand, the charter states it will define a 'simple'=20 > protocol and so my question is if we will ever need to have such a=20 > heavy weight rfc. > imho i would remove the "multiple response formats supported". It=20 > probably won't happen. I don't think RDAP protocol will definitely become complicated if = multiple response formats could be allowed. IMO, it's deficient that = RDAP protocol can only support one special response format.=20 I partly agree with your first idea. We'll try to make it as a more = generic HTTP draft in the next version. I don't want this document = become a HTTP-JSON draft ;-)=20 Any more comments from you are appreciated. > I'm having another issue with the same draft. I'm currently working on=20= > an implementation and for me it's unclear which object MUST be = returned=20 > by which response code. > e.g. can a 404 for a /domain/xxx query return a domain object? I'm=20 > looking for a way to make a differentiation to the client whether a=20 > registration is not found but available and whether a registration is=20= > not found and not available because it is not supported (like=20 > characters not allowed)... one solution is to return a domain object=20= > with different statuses, another is to return an error object with=20 > different titles. >=20 > Any recommendations? I prefer the second one. That is to say, a 404 response code with = different customized "error" information. Cheers, Ning= From zhoulinlin@cnnic.cn Wed Jun 5 23:50:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7117A21F9744 for ; Wed, 5 Jun 2013 23:50:43 -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=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQxJ3TcPax6T for ; Wed, 5 Jun 2013 23:50:38 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 2D7AF21F9942 for ; Wed, 5 Jun 2013 23:50:28 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 06 Jun 2013 14:50:22 +0800 From: "Linlin Zhou" To: "'Marc Blanchet'" , References: <20130605204940.20845.36199.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 6 Jun 2013 14:50:22 +0800 Message-ID: <00db01ce6282$1dde6df0$599b49d0$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DC_01CE62C5.2C01ADF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5iLubE8wks5bFfTCeLRfEATZVT3wATd2sg Content-Language: zh-cn Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 06:50:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00DC_01CE62C5.2C01ADF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Marc, =20 It is said that domain, IP or AS =93is found by doing the longest = match=94 with the corresponding IANA registry information in this draft. I feel the = text here is not very accurate. For domain, you can match the last label of a domain with the domain = column of the IANA xml file. As for IP or AS, check an single IP or AS number, or a CIDR IP address whether it belongs to a range of the IP or AS, then find the rdap server address. =20 Regards, Linlin =20 From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf = Of Marc Blanchet Sent: Thursday, June 06, 2013 4:54 AM To: weirds@ietf.org Subject: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt =20 Hello, this is a draft on bootstrapping, but instead of using DNS as the other draft I sent, this one uses IANA XML registries, as discussed. That way = we have two proposal on the table we can compare. At one time, one of = these two drafts will be dropped... ;-) =20 Please comment. =20 Regards, Marc. =20 D=E9but du message r=E9exp=E9di=E9 : De : internet-drafts@ietf.org Objet : I-D Action: = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Date : 5 juin 2013 16:49:40 HAE =C0 : i-d-announce@ietf.org R=E9pondre =E0 : internet-drafts@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Finding the Authoritative Registration Data = (RDAP) Service Author(s) : Marc Blanchet Filename : = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Pages : 6 Date : 2013-06-05 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, using data available in IANA registries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-blanchet-weirds-bootstrap-ianaregi= str ies There's also a htmlized version available at: http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregistries= -00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 =20 ------=_NextPart_000_00DC_01CE62C5.2C01ADF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear = Marc,

 =

It is said = that domain, IP or AS “is found by doing the longest match” = with the corresponding IANA registry information in this draft. I feel = the text here is not very accurate.

For = domain, you can match the last label of a domain with the domain column = of the IANA xml file.

As for IP = or AS, check an single IP or AS number, or a CIDR IP address whether it = belongs to a range of the IP or AS, then find the rdap server = address.

 =

Regards,

Linlin=

 =

From:= = weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of = Marc Blanchet
Sent: Thursday, June 06, 2013 4:54 = AM
To: weirds@ietf.org
Subject: [weirds] Fwd: I-D = Action: = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt

 

Hello,

 this is a draft on bootstrapping, but instead of = using DNS as the other draft I sent, this one uses IANA XML registries, = as discussed. That way we have two proposal on the table we can compare. =  At one time, one of these two drafts will be dropped... = ;-)

 

Please = comment.

 

Regards, = Marc.

 

D=E9but du message r=E9exp=E9di=E9 = :



Objet : = I-D Action: = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt

Date : = 5 juin = 2013 16:49:40 HAE

R=E9pondr= e =E0 : internet-drafts@ietf.org

 


A New Internet-Draft is = available from the on-line Internet-Drafts directories.


=A0=A0=A0=A0 Title =           : Finding = the Authoritative Registration Data (RDAP) Service
=A0=A0=A0=A0 Author(s) =       : Marc Blanchet
=A0=A0=A0=A0 Filename =        : = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
=A0=A0=A0=A0 Pages =           : 6
=A0=A0=A0=A0 Date =            : = 2013-06-05

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, using data available in IANA = registries.


The IETF datatracker status page for this draft = is:
https://datatracker.ietf.org/doc/draft-blanchet-weirds-bo= otstrap-ianaregistries

There's also a htmlized version = available at:
http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-i= anaregistries-00


Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-= drafts/

_______________________________________________
I-D= -Announce mailing list
I-D-Announce@ietf.org
https://www.i= etf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

 

------=_NextPart_000_00DC_01CE62C5.2C01ADF0-- From johnl@iecc.com Thu Jun 6 03:05:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE63521F9921 for ; Thu, 6 Jun 2013 03:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUDmby8ivbkE for ; Thu, 6 Jun 2013 03:05:43 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9C91121F992A for ; Thu, 6 Jun 2013 03:05:41 -0700 (PDT) Received: (qmail 53637 invoked from network); 6 Jun 2013 10:05:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Jun 2013 10:05:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b05ef4.xn--hew.k1306; i=johnl@user.iecc.com; bh=p93xFgdC39ygU8zYvq/A9JQSVKy4oHYrC5HtkFkO6p0=; b=IRLSkDZvbiJikVweURRlcDGVqgQwv6hc98xWATCeoAXXxsCkffvL+gzauC9dDRYSIueiol2wUmQbGxygs83qCYfLajCmg9EW8m+Ow827vriR8E1Gda4Pgz7TjVtGmjuG4jT86yRLDhex6wT5kpLQqr/oqPz6hXB7+B3ZPyx8lIJoCdjwfPjLDa5a7ZmJQtv3ilko6W8hLC/FHCOMlcWVqCUCgeX2iaEuABI5Wa7oiMfHADlQQJo2cDoL99PEFF3N DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b05ef4.xn--hew.k1306; olt=johnl@user.iecc.com; bh=p93xFgdC39ygU8zYvq/A9JQSVKy4oHYrC5HtkFkO6p0=; b=o2DLKBRqapW6OtvdJ2l87NolTQoNBxomA6YKkvRQoPI7maVY0wbIB83GXNS8wUoNurCi2VK5eSrI8JiSUfVlI/tX9WmbmATicTK/6L/wVguleiXZq8aVRI9C3Nl78CdU7B4+X7IYjMiHGmOhqFknEtXM4TLOkGaTDFNZQPfmdvEcEFHqNV42itSg7HP+lDII6E42pMY9dBiNT4NdqKdlYiACii+Ip6fjnDftg8ZOB8twMLDRve6fmfbAhj5gpJ74 Date: 6 Jun 2013 10:05:17 -0000 Message-ID: <20130606100517.17614.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:05:48 -0000 > this is a draft on bootstrapping, but instead of using DNS as the other draft I sent, this one >uses IANA XML registries, as discussed. That way we have two proposal on the table we can >compare. At one time, one of these two drafts will be dropped... ;-) > >Please comment. So now I'd need an XML parser to do the bootstrap, a JSON parser to handle query results, and a new cache separate from my DNS cache and (if I'm using a browser) the browser cache to handle the bootstrap data? And that means that a URL at IANA is now in the critical path for all lookups? Speaking as a lazy linux user writing scripts with wget, cacheing the file is a pain, so I'll just fetch it each time I do a lookup. I'm paying 25 cents/domain to ICANN so I'm their customer and they better put up with it. Even though I'm looking up ccTLD and RIR data. R's, John From johnl@iecc.com Thu Jun 6 03:16:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD56D21F9925 for ; Thu, 6 Jun 2013 03:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql547In9iQwH for ; Thu, 6 Jun 2013 03:16:16 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 478AD21F93C4 for ; Thu, 6 Jun 2013 03:16:16 -0700 (PDT) Received: (qmail 55146 invoked from network); 6 Jun 2013 10:16:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Jun 2013 10:16:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b0616f.xn--yuvv84g.k1306; i=johnl@user.iecc.com; bh=VMKYRn3r7Vj3MrCQoKk7xnXF9GS1euzyc9gYmZT0gY4=; b=h83ufFjkuYIaBIVtmOMUMTnF73exhqhSyZgrVNZ/yTFpgM/46SSvXbdI1dSCHI3dJofFOqHHCLZYegI1ob58wI4l3kNIxDhVoysofxaGEL44G6Jm5M+cIr0VA+eH2gEmyuvoVaL8Kxt7zUnzBoLQgk7sAZiFDzgayf1GXO00ABLcI/80mqKLgZOyvmuqAGOU3l8HGE77xPvk+QZFlgCzB/c5jZY6KFBRV2TtpHAToY50bD5NJm2sTxLdHW6RAjJq DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b0616f.xn--yuvv84g.k1306; olt=johnl@user.iecc.com; bh=VMKYRn3r7Vj3MrCQoKk7xnXF9GS1euzyc9gYmZT0gY4=; b=ZMUCHv28A3Bjt9y5jHI0O5LdBf7kety5SV9ht4CZ3kImWaFoZIOSC7xsENXhwQuYSIItW450Mv/Lz1+VbJHchaboaDz1Rqq8agFNYe2/5kqO8QDfw2ZxA8sXqNi2N5/Du5SPZQ3un4QwM/QsW1PQrwhKixOHLEHh3D9MOQCNTEVboxCzlvD2/XmC+5dG4GpCDcdek4uYjhfvLc4Mb0QsvxL4cHGMG7cr3uA8QlvQrF1zRUY2ceZRa6iw/Hw7H3ub Date: 6 Jun 2013 10:15:53 -0000 Message-ID: <20130606101553.17693.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <00db01ce6282$1dde6df0$599b49d0$@cn> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:16:20 -0000 For IP numbers and ASNs, what about just querying your closest RIR, and it redirects to another RIR or LIR if appropriate. There's only five RIRs, they all are friends with each other, and they all need to have cross links anyway for legacy space that's been moved from one RIR to another anyway. From johnl@iecc.com Thu Jun 6 03:20:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A9F21F90EF for ; Thu, 6 Jun 2013 03:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-ddMWW8djEC for ; Thu, 6 Jun 2013 03:20:16 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 958A921F96FF for ; Thu, 6 Jun 2013 03:20:15 -0700 (PDT) Received: (qmail 55678 invoked from network); 6 Jun 2013 10:20:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Jun 2013 10:20:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b0625e.xn--30v786c.k1306; i=johnl@user.iecc.com; bh=R0f2OFkQhL0/w0/qMgSFF/9JqKEyBN3bhWIqobproR4=; b=Q9eLVFM4Erj/CxJJ0TXVsaKlCJCxRqH90eqChQx80icW8VHLKOvOCvfPbXpTOhg/AI7L1Ta8F+IP1QCAIKbkY0hoZPNQNwqDX48k00eDfbaBu38+IfCaBQKk5vTVjOPFuN5ApP/t2bMAEVa3w95nIUey+uibD3v0PCCZVqRoeiycOpXg1MzATyYX+zcvLfi6Ug6pf6vxEkHAOhUa7qqBXGEk9s15Vx5WfN8/nawa0pbW9DmNYbVb0RWX+N06MivP DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b0625e.xn--30v786c.k1306; olt=johnl@user.iecc.com; bh=R0f2OFkQhL0/w0/qMgSFF/9JqKEyBN3bhWIqobproR4=; b=itvev0tJyJJftSZwp6WuPQ/1EbqZzHmKeExvNCfKoSEJmitUlgTVQZMUzZbf2x8xYAUo8BOJpvgO0c3l2N6B3f8jS+3F/hJw0QwL/mPVsndu4XjIFGJyZLzPuzXUfeEhW02n2+v+10BEhvR+kLaUhVWAEifk3zPrFYTJxylPuF2SD+NxFz/aF9PNmq+gDnDLTbvSJrwIRJgQFCYfFAMFEG/n4wpKqWOqhrowxq8Df87BY+LsXn82K94WJEU+78dy Date: 6 Jun 2013 10:19:52 -0000 Message-ID: <20130606101952.17732.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <4DC0A688-CE61-4FA6-9DFA-A7CAE8D16EA7@cnnic.cn> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:20:20 -0000 >> imho i would remove the "multiple response formats supported". It >> probably won't happen. >I don't think RDAP protocol will definitely become complicated if multiple response formats >could be allowed. IMO, it's deficient that RDAP protocol can only support one special response >format. Do you really think that other formats will be standardized and documented? Remember that a standard doesn't prevent private extensions. It defines the features that servers and clients have to implement to interoperate. As I understand it, RDAP clients and servers exchange JSON, and we decided some time ago not to support XML and other formats as part of the spec. From andy@arin.net Thu Jun 6 03:28:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9931221F936E for ; Thu, 6 Jun 2013 03:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUCMXZe-vvhb for ; Thu, 6 Jun 2013 03:28:18 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id ACFCB21F92EC for ; Thu, 6 Jun 2013 03:28:18 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 3AC6D1652FB; Thu, 6 Jun 2013 06:28:18 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id B47C81652F4; Thu, 6 Jun 2013 06:28:17 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 06:27:59 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.190]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 06:27:58 -0400 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHOYqCDnjsrd1ed/UWwMLkU+YB9hA== Date: Thu, 6 Jun 2013 10:27:57 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEF971@CHAXCH01.corp.arin.net> In-Reply-To: <20130606100517.17614.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B61D78094ECC0478A64A60802C43BAE@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:28:24 -0000 On 6/6/13 6:05 AM, "John Levine" wrote: >> >So now I'd need an XML parser to do the bootstrap, a JSON parser to >handle query results,... It might be worth asking the IANA if they can also produce their registries in JSON format. Least they can say is "no". > >Speaking as a lazy linux user writing scripts... I hear ya. Hopefully they'll use 'nicinfo -Q --json example.com | jsawk ldhName' or 'nicinfo -Q --value ldhName', which will do all the bootstrapping and caching for them. (adding a feature to only produce entities by role type seems like a good idea for this program now that I think about it) Or they'll just wget to their RDAP server of choice, which will go through the trouble of updating its bootstrapping map. But no matter what mechanism for bootstrapping we pick, I doubt they'll go through the trouble of using it at all. They'll just pick the nearest RDAP server and hope for a redirect. -andy From andy@arin.net Thu Jun 6 03:31:41 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89CA21F8D90 for ; Thu, 6 Jun 2013 03:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 993jRJJ-tE0m for ; Thu, 6 Jun 2013 03:31:35 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id A2C1721F9374 for ; Thu, 6 Jun 2013 03:31:35 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 5981E1652FB; Thu, 6 Jun 2013 06:31:05 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id A201C1652F3; Thu, 6 Jun 2013 06:31:04 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 6 Jun 2013 06:30:46 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.190]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 06:30:45 -0400 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHOYp7lgaR2gU/BD06Woj/3L7+5VpkofIwA Date: Thu, 6 Jun 2013 10:30:44 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEF989@CHAXCH01.corp.arin.net> In-Reply-To: <20130606101553.17693.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <50C66C0084051F40A02ED2B5AFAB85E7@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:31:42 -0000 On 6/6/13 6:15 AM, "John Levine" wrote: >For IP numbers and ASNs, what about just querying your closest RIR, >and it redirects to another RIR or LIR if appropriate. > >There's only five RIRs, they all are friends with each other, and they >all need to have cross links anyway for legacy space that's been moved >from one RIR to another anyway. This always a possibility and something a client should be prepared to do even if they start with the most appropriate RIR using the IANA bootstrapping. But there is nothing wrong with trying to find the most appropriate server first even if it means following a redirect. -andy From johnl@taugh.com Thu Jun 6 05:23:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D3521F95D5 for ; Thu, 6 Jun 2013 05:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rdMk6Ytlx3k for ; Thu, 6 Jun 2013 05:23:11 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAF621F94E1 for ; Thu, 6 Jun 2013 05:23:10 -0700 (PDT) Received: (qmail 3205 invoked from network); 6 Jun 2013 12:23:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=c84.51b07f32.k1306; bh=JeUtxHyG1/V5mqTKXP4sLWrCZT/pC1FhBCaPXjMiseM=; b=NIvR1mw0viWlplmHdUQod8sp9NpFvJyPMIyi9SfZY/D/4LvaIRwUqp8zcal1Rp5GWFXebw4TlGvGIOtDOUfp3WTay2Aptb1M4z/IVIr8IS72k1xu/5y+rNOODrf9+OJRTQOuW5lPBktQO/nc2vqDYibsdyQgPisIJyMazy+oyQAnXLISBtTtQz/a/vCO84XMqIBWgPFlQZa14NKUK9M+M+hskY4VctuIy0Pu5dENVqyD3L3b0/xH+rYOu4P1WbuF 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:cleverness; s=c84.51b07f32.k1306; bh=JeUtxHyG1/V5mqTKXP4sLWrCZT/pC1FhBCaPXjMiseM=; b=eqL/mrzWzdS+btsKQsnTq02ZkG6sFFTu8T57M1Jy5tv3IQ6B35K8D7f6onsPDtAZ3SCcgo/QMs/lYzk2AP5pitXvkJKSweIc3xA1IJbTlQSMTP6N5CB1JImclZYc5FqxEcmfIYHGG44lchLV17wUtXPKcXKFCqtDfSEF7CfZOuJuKGgZbzqaTVdYjCHOBxLD3qcSMdN2pfO2MHXVYaSMkfGABZ/BAoMcodDLnSfPpedOUK4H8j3gxAYtTFlf1CLt Received: (ofmipd 127.0.0.1); 6 Jun 2013 12:22:52 -0000 Date: 6 Jun 2013 14:23:06 +0200 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEF971@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEF971@CHAXCH01.corp.arin.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-975635967-1370521389=:20797" Cc: "weirds@ietf.org" Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 12:23:12 -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. --3825401791-975635967-1370521389=:20797 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > Or they'll just wget to their RDAP server of choice, which will go through > the trouble of updating its bootstrapping map. But no matter what > mechanism for bootstrapping we pick, I doubt they'll go through the > trouble of using it at all. They'll just pick the nearest RDAP server and > hope for a redirect. For IPs and ASNs, I expect you're right. For domains, the various registries are not friends and often have no idea who each other are, so we really do need some sort of external bootstrap. On the other hand, I think that it'd be adequate to have a bootstrap point per TLD, so these should work to find out about example.com and example.on.ca: http://com.domain.rdap.arpa/domain/example.com http://ca.domain.rdap.arpa/domain/example.on.ca The name com.domain.rdap.arpa resolves to a CNAME, A, or AAAA that points at the server. The server might redirect to something like rdap.verisign-grs.com, or it might just be rdap.verisign-grs.com. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-975635967-1370521389=:20797 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjA2MTIyMzA3WjAjBgkqhkiG 9w0BCQQxFgQUgGQ6mK1LWvL95D4KpY6p2ocdOkwweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAToNmTD4TWbS9 +cuIMkPaj6PI3fGFqTKFeLGBx1L4U1CNmrudpI9xw+Rf8iIzS1HTWu4gEU7q oz95vr6mMqHzsrSbDL4Rc/48NBv1NvCrNOSwbDbl6ECvEqPH/0nY1jXvI8XX q9Rvt3Nq5+sDRod7Q7CSn3MlkhEj/XPqyXE1AxtuFrZcxfDFBAL6IGQtfMK6 8Un7d2W7LQlgAQ7XYIOTTTcf0vQB+eK1kbMYQxX4fucvIREIM8fgnAsJgAQk NjgwixsKV3056tySmAsvveohHib4WDuUvQS0nkxT9Gz2cTNN43SaymBgQkGz AMZkzwoYMebh7k2Vc4usKjFgfHRsgw== --3825401791-975635967-1370521389=:20797-- From marc.blanchet@viagenie.ca Thu Jun 6 05:55:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC29021F998C for ; Thu, 6 Jun 2013 05:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUVmmjzyWOah for ; Thu, 6 Jun 2013 05:55:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 97C2121F93E0 for ; Thu, 6 Jun 2013 05:55:47 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DEFE44011E; Thu, 6 Jun 2013 08:55:46 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_57D2C661-DD7C-40C7-845B-47949C981D72" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Marc Blanchet In-Reply-To: <00db01ce6282$1dde6df0$599b49d0$@cn> Date: Thu, 6 Jun 2013 08:55:44 -0400 Message-Id: <7E2417A2-536F-44DB-8348-924AAC045F2C@viagenie.ca> References: <20130605204940.20845.36199.idtracker@ietfa.amsl.com> <00db01ce6282$1dde6df0$599b49d0$@cn> To: "Linlin Zhou" X-Mailer: Apple Mail (2.1503) Cc: weirds@ietf.org Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 12:55:48 -0000 --Apple-Mail=_57D2C661-DD7C-40C7-845B-47949C981D72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2013-06-06 =E0 02:50, "Linlin Zhou" a =E9crit : > Dear Marc, > =20 > It is said that domain, IP or AS =93is found by doing the longest = match=94 with the corresponding IANA registry information in this draft. = I feel the text here is not very accurate. I agree that it is underspecified.... > For domain, you can match the last label of a domain with the domain = column of the IANA xml file. I wanted to be generic enough, so the algorithm can apply to multiple = levels, if the XML file has such. For example, the file may have two = entries: com example.com and the query is for a.example.com, it should do the longest match and = take the second entry. That is what I was trying to convey with the longest match. However, it = is clearly underspecified. I should have had something around "longest = match, per label'. Some text to work out. > As for IP or AS, check an single IP or AS number, or a CIDR IP address = whether it belongs to a range of the IP or AS, then find the rdap server = address. similarly, one may have: 2001::/16 2001:1000::/32 and the query is for 2001:1000:1:1::1. it should do the longest match = and take the second entry. This is what I intended for longest match. =20 I'll add more text in the next rev. Thanks for the comments and review. Regards, Marc. > =20 > Regards, > Linlin > =20 > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On = Behalf Of Marc Blanchet > Sent: Thursday, June 06, 2013 4:54 AM > To: weirds@ietf.org > Subject: [weirds] Fwd: I-D Action: = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt > =20 > Hello, > this is a draft on bootstrapping, but instead of using DNS as the = other draft I sent, this one uses IANA XML registries, as discussed. = That way we have two proposal on the table we can compare. At one time, = one of these two drafts will be dropped... ;-) > =20 > Please comment. > =20 > Regards, Marc. > =20 > D=E9but du message r=E9exp=E9di=E9 : >=20 >=20 > De : internet-drafts@ietf.org > Objet : I-D Action: = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt > Date : 5 juin 2013 16:49:40 HAE > =C0 : i-d-announce@ietf.org > R=E9pondre =E0 : internet-drafts@ietf.org > =20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Finding the Authoritative Registration Data = (RDAP) Service > Author(s) : Marc Blanchet > Filename : = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt > Pages : 6 > Date : 2013-06-05 >=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, using data available in IANA registries. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-blanchet-weirds-bootstrap-ianaregis= tries >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregistries-= 00 >=20 >=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 > =20 --Apple-Mail=_57D2C661-DD7C-40C7-845B-47949C981D72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Le 2013-06-06 =E0 = 02:50, "Linlin Zhou" <zhoulinlin@cnnic.cn> a =E9crit = :

Dear = Marc,
 
It is said that domain, IP or AS =93is found by doing the = longest match=94 with the corresponding IANA registry information in = this draft. I feel the text here is not very = accurate.

I = agree that it is underspecified....

For domain, you can match the last = label of a domain with the domain column of the IANA xml = file.

I wanted = to be generic enough, so the algorithm can apply to multiple levels, if = the XML file has such. For example, the file may have two = entries:

com

and = the query is for a.example.com, it = should do the longest match and take the second = entry.

That is what I was trying to convey with = the longest match. However, it is clearly underspecified. I should have = had something around "longest match, per label'. Some text to work = out.

As for IP or AS, check an single IP = or AS number, or a CIDR IP address whether it belongs to a range of the = IP or AS, then find the rdap server = address.

similarl= y, one may = have:

2001::/16
2001:1000::/32

and the query is for 2001:1000:1:1::1. it should do the = longest match and take the second entry.

This = is what I intended for longest match. =  

I'll add more text in the next = rev.

Thanks for the comments and = review.

Regards, Marc.

 
Regards,
Linlin
 
From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Marc = Blanchet
Sent: Thursday, June 06, 2013 = 4:54 AM
To:  [weirds] Fwd: I-D Action: = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
 
Hello,
 this is a draft on = bootstrapping, but instead of using DNS as the other draft I sent, this = one uses IANA XML registries, as discussed. That way we have two = proposal on the table we can compare.  At one time, one of these = two drafts will be dropped... ;-)
 
Please = comment.
 
Regards, = Marc.
 
D=E9but du message r=E9exp=E9di=E9 = :


De : 

= --Apple-Mail=_57D2C661-DD7C-40C7-845B-47949C981D72-- From andy@arin.net Thu Jun 6 06:57:53 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DF821F9808 for ; Thu, 6 Jun 2013 06:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UZjFJIoKXf4 for ; Thu, 6 Jun 2013 06:57:49 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0E20B21F99A9 for ; Thu, 6 Jun 2013 06:57:46 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 8A87516531B; Thu, 6 Jun 2013 09:57:15 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 12FDF165318; Thu, 6 Jun 2013 09:57:15 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 6 Jun 2013 09:57:14 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.190]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 09:57:14 -0400 From: Andy Newton To: John R Levine Thread-Topic: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHOYqCDnjsrd1ed/UWwMLkU+YB9hJko3v4A///XPQA= Date: Thu, 6 Jun 2013 13:57:14 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEFA6C@CHAXCH01.corp.arin.net> 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.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <7DC68ABE4002EC4EA11FC6E6ABE0824C@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:57:53 -0000 On 6/6/13 8:23 AM, "John R Levine" wrote: > >For domains, the various registries are not friends and often have no >idea=20 >who each other are, so we really do need some sort of external bootstrap. >On the other hand, I think that it'd be adequate to have a bootstrap >point=20 >per TLD, so these should work to find out about example.com and >example.on.ca: > > http://com.domain.rdap.arpa/domain/example.com > http://ca.domain.rdap.arpa/domain/example.on.ca > >The name com.domain.rdap.arpa resolves to a CNAME, A, or AAAA that points >at the server. The server might redirect to something like >rdap.verisign-grs.com, or it might just be rdap.verisign-grs.com. So for .uk and .co.uk, do you envision using DNS wildcards? I just don't like the idea of query for xx.yy and if you get NXDOMAIN, query for yy. -andy From marc.blanchet@viagenie.ca Thu Jun 6 07:19:52 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DA921F939E for ; Thu, 6 Jun 2013 07:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvSSBzQOX594 for ; Thu, 6 Jun 2013 07:19:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 76BEA21F9385 for ; Thu, 6 Jun 2013 07:19:51 -0700 (PDT) Received: from [IPv6:2620::230:c000:821:7146:cdd4:df8b] (unknown [IPv6:2620:0:230:c000:821:7146:cdd4:df8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C6FDE40415; Thu, 6 Jun 2013 10:19:50 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Marc Blanchet In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEFA6C@CHAXCH01.corp.arin.net> Date: Thu, 6 Jun 2013 10:19:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3D6E8E8F-A754-4D37-A76A-C29ED2E326F8@viagenie.ca> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DEFA6C@CHAXCH01.corp.arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1503) Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:19:52 -0000 a) these comments below are more around the first draft using DNS. Le 2013-06-06 =E0 09:57, Andy Newton a =E9crit : > On 6/6/13 8:23 AM, "John R Levine" wrote: >>=20 >> For domains, the various registries are not friends and often have no >> idea=20 >> who each other are, so we really do need some sort of external = bootstrap. >> On the other hand, I think that it'd be adequate to have a bootstrap >> point=20 >> per TLD, so these should work to find out about example.com and >> example.on.ca: >>=20 >> http://com.domain.rdap.arpa/domain/example.com >> http://ca.domain.rdap.arpa/domain/example.on.ca >>=20 >> The name com.domain.rdap.arpa resolves to a CNAME, A, or AAAA that = points >> at the server. The server might redirect to something like >> rdap.verisign-grs.com, or it might just be rdap.verisign-grs.com. >=20 > So for .uk and .co.uk, do you envision using DNS wildcards? I just = don't > like the idea of query for xx.yy and if you get NXDOMAIN, query for = yy. the draft says that wildcards may be used. I don't think we can say = "MUST" use wildcards. So that is why I put the NXDOMAIN discussion in = the draft. However, I do see most operators use wildcards "all the time". = Therefore, I expect the client not to process NXDOMAIN so often, but = should be prepared to. So this is how the draft was written, at least = the intent... Marc. >=20 > -andy >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From andy@arin.net Thu Jun 6 07:39:55 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843DE21F99CA for ; Thu, 6 Jun 2013 07:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.166 X-Spam-Level: X-Spam-Status: No, score=-5.166 tagged_above=-999 required=5 tests=[AWL=-2.567, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYRwvUj59ak0 for ; Thu, 6 Jun 2013 07:39:49 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 5597F21F99CD for ; Thu, 6 Jun 2013 07:39:49 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 6A73F16531B; Thu, 6 Jun 2013 10:39:39 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id E9CC9165309; Thu, 6 Jun 2013 10:39:38 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 10:39:38 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.190]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 10:39:38 -0400 From: Andy Newton To: Marc Blanchet Thread-Topic: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHOYqCDnjsrd1ed/UWwMLkU+YB9hJko3v4A///XPQCAAElggP//wneA Date: Thu, 6 Jun 2013 14:39:37 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF0AEA@CHAXCH01.corp.arin.net> In-Reply-To: <3D6E8E8F-A754-4D37-A76A-C29ED2E326F8@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <8393841AEEEF7D46B7C48E059F8F2DB6@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:39:55 -0000 On 6/6/13 10:19 AM, "Marc Blanchet" wrote: >However, I do see most operators use wildcards "all the time". Therefore, >I expect the client not to process NXDOMAIN so often, but should be >prepared to. So this is how the draft was written, at least the intent... Even if they don't have to process them so often, if it is in the spec then we expect implementers to have to write code to process NXDOMAINs and this complexity is still there. I'd rather this come out of the spec and we put the onus of multi-level domains on the server side. This is in spirit with the rest of the RDAP framework. -andy From johnl@taugh.com Thu Jun 6 07:49:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4820821F94DF for ; Thu, 6 Jun 2013 07:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB2e5Z79VpZx for ; Thu, 6 Jun 2013 07:49:27 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EA75721F9630 for ; Thu, 6 Jun 2013 07:49:20 -0700 (PDT) Received: (qmail 38774 invoked from network); 6 Jun 2013 14:49:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=9775.51b0a175.k1306; bh=fS/z5gCJAO3bZbC4DxZ6hwXzoaTwLRm4uWYI6JP/bWc=; b=TjTNQCpo2J5XK6ZRg0vjK6CUf3GqIcmWEclDwRCBJEInmCB2v8HYrim38fmE2bof3X7/ARMLoOLRJS8rn85h3WyPJHyt0Y44qF2D/YxIGBrv2p+lpSJ4bVbyyij4DHEtEP94jPKdscm5Sw1xiZpn53dsCAuG3E89PYyB/kTpcLV9A0TBJ78fxOeTJAQ7Qhj2PPw3MPgUhrnFrKeIhTQzWM1OG+R3YIbC5j+aAAO2WMkVPJEhBhwrwyJKbZHB5E9/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=9775.51b0a175.k1306; bh=fS/z5gCJAO3bZbC4DxZ6hwXzoaTwLRm4uWYI6JP/bWc=; b=hLU6mbIrcBE1lvKzxr+x4aa0BwHpFNX38C0PA2lRcioQ24R4n/F99NC224qnqaDBhto7Zc+AMEAUl8wvnFgXmd/InNvnDMKveYqMWaxemOucpkunPfekHc6LTPMfJYb/s3wq0c2WB99wEyc8wAdA/Ixjn5qYwXRf6GGtrOX3UH6taKPylM6EJQavBNCTHaOtrjCpAbr4j7OasMQT+PRioJBqBbjLYoumHBJ+y3BeJj3+JJ0do2L4jR3Q/3RurohT Received: (ofmipd 127.0.0.1); 6 Jun 2013 14:49:03 -0000 Date: 6 Jun 2013 16:49:19 +0200 Message-ID: From: "John R Levine" To: weirds@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1204738827-1370530160=:21360" Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:49:28 -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. --3825401791-1204738827-1370530160=:21360 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-ID: >> The name com.domain.rdap.arpa resolves to a CNAME, A, or AAAA that points >> at the server. The server might redirect to something like >> rdap.verisign-grs.com, or it might just be rdap.verisign-grs.com. > > So for .uk and .co.uk, do you envision using DNS wildcards? I just don't > like the idea of query for xx.yy and if you get NXDOMAIN, query for yy. There's two possibilities. One that could work is wildcards: $origin domain.rdap.arpa. *.uk CNAME rdap.nic.uk. *.ac.uk CNAME rdap.ja.net. As far as I can tell, that should work properly due to the closest encloser rule described in RFC 4592. The other possibility is just to bootstrap the TLD, and it's up to Nominet to redirect RDAP queries to Janet when appropriate. Unless someone is aware of TLDs so dysfunctional that they would refuse to do this for a legitimately delegated subregistry, I prefer this approach. It makes clients simpler, and also avoids the question of how IANA is supposed to decide when to believe someone who purports to run a subregistry. For example, I have a contract with Neustar that says I run a bunch of geographic subdomains of .us. How is IANA supposed to tell that I still do run the watkins-glen.ny.us subregistry, but ithaca.ny.us was abandoned by its subregistry a decade ago and reverted to Neustar? Neustar knows what subdomains they've delegated, so they know what RDAP redirects to do. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly --3825401791-1204738827-1370530160=:21360 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjA2MTQ0OTE5WjAjBgkqhkiG 9w0BCQQxFgQUYLNSAMyv3qEX9fSLYIB6Z3GZyrEweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAX30hUd8nJC5k vcauZbCbxHZiQDciljVoNNh8e1GoMoLiugdsRPE8GNDWWDZHgm28I5lIMgZL muzHDjrfAz22W6P1/YKI8QUZgpuxOoTVnnDPncCClHcRrpxK+rNGZg/9XjWl 8kYMDjMbam/RpV/WE3MZ7ffi1oOOxF6KotdAUNZbMNyp1XC/LfdS9p2KZJ6G 0FjMVK7ApNMgI1mUPDjnzFyzetJPMOoS/1QF7bHma/NgPlfVjZrnGosMN7l9 i+cLy91JxkXN+Lp23Ve4ElTVKgGsMCVqTI8NB6JUDD54FnhqFA2dcEUt95lh 0fiTI3evDbWbpi9N6fp/KHxFTsIOEQ== --3825401791-1204738827-1370530160=:21360-- From marc.blanchet@viagenie.ca Thu Jun 6 07:52:55 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0843321F909A for ; Thu, 6 Jun 2013 07:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIbsH2tnVTKD for ; Thu, 6 Jun 2013 07:52:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 87E1C21F9051 for ; Thu, 6 Jun 2013 07:52:54 -0700 (PDT) Received: from [IPv6:2620::230:c000:3100:df0c:614e:2ef8] (unknown [IPv6:2620:0:230:c000:3100:df0c:614e:2ef8]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EBC6E40436; Thu, 6 Jun 2013 10:52:53 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF0AEA@CHAXCH01.corp.arin.net> Date: Thu, 6 Jun 2013 10:52:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF0AEA@CHAXCH01.corp.arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1508) Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:52:55 -0000 Le 2013-06-06 =E0 10:39, Andy Newton a =E9crit : > On 6/6/13 10:19 AM, "Marc Blanchet" wrote: >=20 >> However, I do see most operators use wildcards "all the time". = Therefore, >> I expect the client not to process NXDOMAIN so often, but should be >> prepared to. So this is how the draft was written, at least the = intent... >=20 > Even if they don't have to process them so often, if it is in the spec > then we expect implementers to have to write code to process NXDOMAINs = and > this complexity is still there. yes. > I'd rather this come out of the spec and > we put the onus of multi-level domains on the server side. fair. I was not willing to impose wildcards in the first rev of the = draft. Will see what other people think and if the DNS solution is the = one chosen. Marc. > This is in > spirit with the rest of the RDAP framework. >=20 > -andy From carlosm3011@gmail.com Thu Jun 6 11:54:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5788021F9590 for ; Thu, 6 Jun 2013 11:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EUv471z9+3W for ; Thu, 6 Jun 2013 11:54:37 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1B521F9622 for ; Thu, 6 Jun 2013 11:54:36 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id f10so470926yha.25 for ; Thu, 06 Jun 2013 11:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2adDqin7EF0LTuexHF8EKFNA4SKU4p9aS1SeiMzP4PM=; b=NylfAt6n1J67fkdgOha2XQUQVP8Y1cfhVglCfhYd4BORM1RQf1tIwoWsCa/uVPsym/ OL1qqmuyzExPl4v1YkGokq8bOUwMjptdaH0vzSeWbdkjv2WFPwgvpA7WhYFiv8kL1v24 K4slGCtexv4IAc65UhDhigJcGiasRtZi+pw2S43gfxHuPpbYkvJfOUXJRSsUeED/mKma YPNMBZbdT7ukFpe8+sGTNpXybkBG7rjEkIE2IoR/sAxhCwUV7FUua7ca0ai9ZLn24e17 oWKld7vYiaA6BgZq5TtKu0m6AMxqC+mJddocjxOfKQrxos3OV83Ug8+sWrVLCHbG4xJq 7G1Q== X-Received: by 10.236.88.228 with SMTP id a64mr26131409yhf.85.1370544875897; Thu, 06 Jun 2013 11:54:35 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([2001:13c7:7001:7000:bca1:5bab:31e:d134]) by mx.google.com with ESMTPSA id v27sm114745236yhj.12.2013.06.06.11.54.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 11:54:34 -0700 (PDT) Message-ID: <51B0DAE6.9060106@gmail.com> Date: Thu, 06 Jun 2013 15:54:30 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marc Blanchet References: <20130605204940.20845.36199.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:54:38 -0000 Question / comment : - do we actually need to solve bootstrapping for entity, nameserver ? Is a 'lightweight' bootstrap only with domain, autnum, ip4 and ip6 acceptable ? cheers! ~Carlos On 6/5/13 5:54 PM, Marc Blanchet wrote: > Hello, > this is a draft on bootstrapping, but instead of using DNS as the other > draft I sent, this one uses IANA XML registries, as discussed. That way > we have two proposal on the table we can compare. At one time, one of > these two drafts will be dropped... ;-) > > Please comment. > > Regards, Marc. > > Début du message réexpédié : > >> *De : *internet-drafts@ietf.org >> *Objet : **I-D Action: >> draft-blanchet-weirds-bootstrap-ianaregistries-00.txt* >> *Date : *5 juin 2013 16:49:40 HAE >> *À : *i-d-announce@ietf.org >> *Répondre à : *internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Finding the Authoritative Registration Data (RDAP) >> Service >> Author(s) : Marc Blanchet >> Filename : draft-blanchet-weirds-bootstrap-ianaregistries-00.txt >> Pages : 6 >> Date : 2013-06-05 >> >> 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, using data available in IANA registries. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-blanchet-weirds-bootstrap-ianaregistries >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregistries-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From marc.blanchet@viagenie.ca Thu Jun 6 12:13:36 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A047B11E80EE for ; Thu, 6 Jun 2013 12:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEkHNBz0sEci for ; Thu, 6 Jun 2013 12:13: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 BA80911E80ED for ; Thu, 6 Jun 2013 12:13:35 -0700 (PDT) Received: from h115.viagenie.ca (h115.viagenie.ca [206.123.31.115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1FF3946FC0; Thu, 6 Jun 2013 15:13:35 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <51B0DAE6.9060106@gmail.com> Date: Thu, 6 Jun 2013 15:13:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <82801132-F80F-466F-AC3B-BF3125B977A0@viagenie.ca> References: <20130605204940.20845.36199.idtracker@ietfa.amsl.com> <51B0DAE6.9060106@gmail.com> To: carlos@lacnic.net X-Mailer: Apple Mail (2.1508) Cc: "weirds@ietf.org" Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 19:13:36 -0000 Le 2013-06-06 =E0 14:54, "Carlos M. Martinez" a = =E9crit : > >=20 > Question / comment : >=20 > - do we actually need to solve bootstrapping for entity, nameserver ? = Is > a 'lightweight' bootstrap only with domain, autnum, ip4 and ip6 > acceptable ? - don't have an answer, since I haven't thought through yet. That is why = I put "TBD" in the draft(s)... Marc. >=20 > cheers! >=20 > ~Carlos >=20 > On 6/5/13 5:54 PM, Marc Blanchet wrote: >> Hello, >> this is a draft on bootstrapping, but instead of using DNS as the = other >> draft I sent, this one uses IANA XML registries, as discussed. That = way >> we have two proposal on the table we can compare. At one time, one = of >> these two drafts will be dropped... ;-) >>=20 >> Please comment. >>=20 >> Regards, Marc. >>=20 >> D=E9but du message r=E9exp=E9di=E9 : >>=20 >>> *De : *internet-drafts@ietf.org >>> *Objet : **I-D Action: >>> draft-blanchet-weirds-bootstrap-ianaregistries-00.txt* >>> *Date : *5 juin 2013 16:49:40 HAE >>> *=C0 : *i-d-announce@ietf.org >>> *R=E9pondre =E0 : *internet-drafts@ietf.org = >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>=20 >>>=20 >>> Title : Finding the Authoritative Registration Data (RDAP) >>> Service >>> Author(s) : Marc Blanchet >>> Filename : = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt >>> Pages : 6 >>> Date : 2013-06-05 >>>=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, using data available in IANA registries. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-blanchet-weirds-bootstrap-ianaregis= tries >>>=20 >>> There's also a htmlized version available at: >>> = http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregistries-= 00 >>>=20 >>>=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 >>=20 >>=20 >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >>=20 From jean-philippe.dionne@viagenie.ca Thu Jun 6 12:47:06 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CB621E8054 for ; Thu, 6 Jun 2013 12:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.98 X-Spam-Level: * X-Spam-Status: No, score=1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SPOOF_COM2COM=2.536, SPOOF_COM2OTH=2.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeSoXvfRvb1q for ; Thu, 6 Jun 2013 12:47: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 B271211E80F2 for ; Thu, 6 Jun 2013 12:47:05 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3F38346FC1 for ; Thu, 6 Jun 2013 15:47:05 -0400 (EDT) Message-ID: <51B0E738.4050800@viagenie.ca> Date: Thu, 06 Jun 2013 15:47:04 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <51AF54B9.8010601@centralnic.com> In-Reply-To: <51AF54B9.8010601@centralnic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 19:47:06 -0000 On 06/05/2013 11:09 AM, Gavin Brown wrote: > Section 8 of this draft appears to conflict with > draft-ietf-weirds-rdap-query, section 4, which permits a "base URL" to > which the standard path segments are appended. There is no mechanism in > your design for an RDAP client to determine the appropriate base URL, > only the host part. There is also no way to determine whether HTTPS > should be preferred over HTTP. I suppose you could use a NAPTR record > instead of address records, but an HTTP redirect seems more RDAP-like to > me (which is why RDAP.ORG exists). I noticed that too. I guess a web server serving example.com.domain.rdap.arpa could accomodate to use only / as a base URL. It should be the only service that will be hosted on that domain name. The well-known-uris could also be used to register an alternate base URL. Jean-Philippe From zhoulinlin@cnnic.cn Thu Jun 6 20:09:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2185E21F8F83 for ; Thu, 6 Jun 2013 20:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVPCDBgDfZCe for ; Thu, 6 Jun 2013 20:09:34 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 805F521F8F69 for ; Thu, 6 Jun 2013 20:09:32 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 07 Jun 2013 11:09:29 +0800 From: "Linlin Zhou" To: "'John Levine'" , References: <00db01ce6282$1dde6df0$599b49d0$@cn> <20130606101553.17693.qmail@joyce.lan> In-Reply-To: <20130606101553.17693.qmail@joyce.lan> Date: Fri, 7 Jun 2013 11:09:29 +0800 Message-ID: <01e401ce632c$6d2f99b0$478ecd10$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5invetlaOL0AXBRMq0MxfIXFpMpwAi6fZQ Content-Language: zh-cn Subject: Re: [weirds] draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 03:09:39 -0000 > -----Original Message----- > From: John Levine [mailto:johnl@taugh.com] > Sent: Thursday, June 06, 2013 6:16 PM > To: weirds@ietf.org > Cc: zhoulinlin@cnnic.cn > Subject: Re: [weirds] = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt >=20 > For IP numbers and ASNs, what about just querying your closest RIR, = and it > redirects to another RIR or LIR if appropriate. >=20 I agree that this is also a feasible approach. There are only 5 RIRs = after all. But I am not very clear about how to find the closest RIR. = Can the service discovery tech work? > There's only five RIRs, they all are friends with each other, and they = all need to > have cross links anyway for legacy space that's been moved from one = RIR to > another anyway. From johnl@taugh.com Fri Jun 7 02:43:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FACB21F971F for ; Fri, 7 Jun 2013 02:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fok05R+620u7 for ; Fri, 7 Jun 2013 02:43:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BEC7221F972E for ; Fri, 7 Jun 2013 02:43:30 -0700 (PDT) Received: (qmail 8526 invoked from network); 7 Jun 2013 09:43:29 -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:cleverness; s=214d.51b1ab41.k1306; bh=TZASS3xAPzQuowEpH3xOLEUKncIOvI3uHNG8HeetNmM=; b=NmLs8Z8rZHSrXxtJrstm0ZQzQX6YLLIId6i3KDke/1yd46oDdn2MBLBUgaFyjXZbmMDIem8oxkqaxmHC8DB3zDUEPDnWwRKqutb0vWwGiwJHC+/Kv7ZddN/Yy5M3ja2WU+qn7i96FMLjPAUutTIdGfXZ6eA/9wZUE8v9Lt8Zbwl13hPincFzckPYC7Tvkq3my1RhOBQdcmwPiUB5fQFMHdTtD0/kmvPq8UchMFc60HVZVksSencxEVhjbjIpTPSJ 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:cleverness; s=214d.51b1ab41.k1306; bh=TZASS3xAPzQuowEpH3xOLEUKncIOvI3uHNG8HeetNmM=; b=pyEdbiUaqGV6krd/fMKnMmwLkYaOjtQS0UGPNapzI8CTBX01FXECJkr+WBEfVP4rPGE8XQV/AZwcxYLJOyk0TJd039YCcJq/eut5hopE/ORzV5uc30KrJlXmqHHYODHOFo5maQuyozUrnOoqdMfJ+6ZW2X80tXs/7F6fMyJlVEqvnyc9/4guwOuYYwLIk9liZuDH0xvLV8zkj6F1gv7SxiQyMPx1PWlKuUq8GzyzHQwfnl4/1qV8O5NtBr5QK58/ Received: (ofmipd 127.0.0.1); 7 Jun 2013 09:43:07 -0000 Date: 7 Jun 2013 11:43:28 +0200 Message-ID: From: "John R Levine" To: "Linlin Zhou" In-Reply-To: <01e401ce632c$6d2f99b0$478ecd10$@cn> References: <00db01ce6282$1dde6df0$599b49d0$@cn> <20130606101553.17693.qmail@joyce.lan> <01e401ce632c$6d2f99b0$478ecd10$@cn> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-398676796-1370598209=:2303" Cc: weirds@ietf.org Subject: Re: [weirds] draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 09:43:38 -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. --3825401791-398676796-1370598209=:2303 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> For IP numbers and ASNs, what about just querying your closest RIR, and it >> redirects to another RIR or LIR if appropriate. > I agree that this is also a feasible approach. There are only 5 RIRs after all. But I am not very clear about how to find the closest RIR. Can the service discovery tech work? Since the closest RIR to a given host almost never changes, it could be a one-time configuration setting when the software is installed. Or you could do a kludge like taking the IPv4 address of the local host, and using a static 240 entry table to guess the RIR from the first octet of the address. Whatever you do, the penalty for guessing wrong is quite low. The worst that will happen is that queries will go over the net to an RIR farther away. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly --3825401791-398676796-1370598209=:2303 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjA3MDk0MzI4WjAjBgkqhkiG 9w0BCQQxFgQUopKhPQKYxIcECKSiAllSsCiEfc8weQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAfiMyNkfu5vjQ ybOiYRIKmPipoa31v7FYXNbhHEJsE9elAfVvVhAzYO4DtXW8BtG4wDwpYzxs T2VvH6l7TzhENVk7vTTzdheQjYsWc5J+yabgKGg86F4eY6o+v9r2qIRfijLR zhXxzYA3pWuI9cP/p4my7t2L4mYxiEYJUl6h/n9eYyrtcEPclRxVg8hsnupP SlxamjUQGIC4XRYgVxf1Byxm4Ja0LHSU7/hNlj8yPSqnJQxt03qfpFIQ4hPo GBNhst/lD5vhTmd26AebEab3kNSOO9UYQxVTYbCSgb7kdKP4SWv499uplr+0 ufGD421STDIKhhmsD9aWnObN9gCSUg== --3825401791-398676796-1370598209=:2303-- From nkong@cnnic.cn Sat Jun 8 00:41:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D21F21F99AA for ; Sat, 8 Jun 2013 00:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=1.831, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r1pGG2Ki8jy for ; Sat, 8 Jun 2013 00:41:24 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 0B90321F99A6 for ; Sat, 8 Jun 2013 00:41:23 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [218.241.103.153]) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 08 Jun 2013 15:41:15 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ning Kong In-Reply-To: <20130606101952.17732.qmail@joyce.lan> Date: Sat, 8 Jun 2013 15:41:15 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130606101952.17732.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1508) Cc: weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 07:41:30 -0000 Hi John, > Do you really think that other formats will be standardized and = documented? I'm not sure. IMO, the other formats may not be necessarily documented = because they can be transformed by the JSON response document. > Remember that a standard doesn't prevent private extensions. It > defines the features that servers and clients have to implement to > interoperate. I agree. > As I understand it, RDAP clients and servers exchange > JSON, and we decided some time ago not to support XML and other > formats as part of the spec. Could you please provide some references for this conclusion? IMHO, even if XML and other formats will never be documented by WEIRDS = WG, they should not be forbidden by RDAP protocols. The RDAP specs = should provide an interopration mechanism for RDAP clients and servers = to signal and identify these formats, just like using the Accept Header = Field for JSON format. Cheers, Ning From johnl@taugh.com Sat Jun 8 07:20:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ADB21F995F for ; Sat, 8 Jun 2013 07:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ST5B234iKdah for ; Sat, 8 Jun 2013 07:20:11 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 91DE221F9631 for ; Sat, 8 Jun 2013 07:20:10 -0700 (PDT) Received: (qmail 36422 invoked from network); 8 Jun 2013 14:20:09 -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:cleverness; s=8e44.51b33d99.k1306; bh=1xeBUCrzD+1q75oSHDkishTGXzy+08LwAkBfvZZMMV0=; b=iMjGZ6ve1koRgW3qHjKEbqJ89TF75Bz0dLiD/s0EtRlOikwsvAsyGgW3qh2ywALBkzNeZK8oEHxFK4yVJI7/pkQm8CRMmSorQCmpfgS0bgYd+oT1QR91PbliU1JerZ3BFyxDDK7BTALYBEkU0GBdyDot36YDte3Yo2YWMkgMCw+49tTvKPWVk7yOiGxR6apbw0Vdlza9j2PMSE1UGSYUjZ/WQYIDJlpkkPOh3MBZLLFS25zrw/NZmpPueuwd6Dmz 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:cleverness; s=8e44.51b33d99.k1306; bh=1xeBUCrzD+1q75oSHDkishTGXzy+08LwAkBfvZZMMV0=; b=fJRmKFHxC48sBo6KX0LLXqey32TclUjCA/SjYbnwMPhjLYpqf1grh4JWG3MCFeSXWq8sz4UOLKDDeMRtaKXj9p+lMJVDcr1nD8cLyG6hz0B8sDQ5XPFqk5MOwMg7k60ltrgHIRYr2pN6umxuBEdM5QTHNHZCBSZ1P3jInU3TqaGcyXcJasirVBls2u0NHVfsTv9O3PkCDRTj19uVdsp7ePnBg9w5liUqIKO1OwgtZVsV34knGYNOGhzCXE+g3JjS Received: (ofmipd 127.0.0.1); 8 Jun 2013 14:19:47 -0000 Date: 8 Jun 2013 10:20:09 -0400 Message-ID: From: "John R Levine" To: "Ning Kong" In-Reply-To: References: <20130606101952.17732.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 14:20:12 -0000 >> Do you really think that other formats will be standardized and documented? > I'm not sure. IMO, the other formats may not be necessarily documented because they can be transformed by the JSON response document. I think we agree here. If they're not documented, there's no reason for the standard to mention them. Remember that IETF standards are voluntary, so they don't have to give anyone permission to do anything. >> As I understand it, RDAP clients and servers exchange >> JSON, and we decided some time ago not to support XML and other >> formats as part of the spec. > > Could you please provide some references for this conclusion? We discussed it at great length on the list, the only response format is JSON. Again, if you want to provide XML or anything else as a private extension, that's fine, but there's no reason for the standard to say anything about it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From andy@arin.net Sat Jun 8 08:12:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8081121F871D for ; Sat, 8 Jun 2013 08:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwC4+Rr6h3t6 for ; Sat, 8 Jun 2013 08:12: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 90AA821F86D3 for ; Sat, 8 Jun 2013 08:12:50 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id EAE231653BF; Sat, 8 Jun 2013 11:12:49 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 63A561653B7; Sat, 8 Jun 2013 11:12:49 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sat, 8 Jun 2013 11:12:31 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.128]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Sat, 8 Jun 2013 11:12:30 -0400 From: Andy Newton To: John R Levine , Ning Kong Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 Thread-Index: AQHOXH3gY3KwLlQTlUSonTV+sXMu85kl+1gAgABGigCAAL+0AIABRn4AgACAwQCAAvhZgIAAb3OA///Lj4A= Date: Sat, 8 Jun 2013 15:12:29 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF24BC@CHAXCH01.corp.arin.net> 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.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <446E25C29209924DB0C1F9AAE54BE3AF@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 15:12:56 -0000 On 6/8/13 10:20 AM, "John R Levine" wrote: >>>Could you please provide some references for this conclusion? > >We discussed it at great length on the list, the only response format is >JSON. Again, if you want to provide XML or anything else as a private >extension, that's fine, but there's no reason for the standard to say >anything about it. John is right. This issue has been discussed on the mailing list several times. The intent of the language is to provide for the following: 1) Future specifications in other data formats. In fact, the rules behind JSON naming are constructed to allow automatic conversion to XML and we use to have an algorithm in this draft which showed how to do it. However, nobody was interested in it and that got ripped out. But the possibility is always there, though we'll likely never do it. 2) The use of RDAP URLs in the browser bars of web browsers to get non-RDAP results. The ARIN service does this today by returning XHTML or plain text, and many people find it handy. That doesn't mean we intend generic web browsers to be RDAP clients. It just means we see the utility of using RDAP query URLs in web browsers for non-RDAP purposes. Though I said #1 is unlikely to happen, it is likely that some server operators will do this. -andy From carlosm3011@gmail.com Mon Jun 10 06:47:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E6121F8B07 for ; Mon, 10 Jun 2013 06:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnN384z8e4cI for ; Mon, 10 Jun 2013 06:47:36 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id D31AE21F84B2 for ; Mon, 10 Jun 2013 06:47:35 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id f73so522771yha.27 for ; Mon, 10 Jun 2013 06:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Fqq7CoEjvvfXvJT2WVi4adpPV9lSssysyAou0QTuYzk=; b=gJqGbjTKSAxy2Nc+kegrwxpTWzAqyUnmULB7yP+R1IevH1jJjyWkFgMzHXa0wbzrMI /BbsrPXU9bnaTuVWQ7dXTPxLrIrUqezMEcCznoK3hKfUEtVA9UzTVa+6GAJKMHSggG5X 6sPDehJPC2V1DnHKXz5qZe+m5C4XLZNe6WfzgQK5i4DTZpY8tCKyj0BMZKEBrb18nCUR 20t/YwTbZo5Zs8ak3gqLn8jnj/csk1ThIjWhLFRehNBwIfsPxQgqRN+JO3vS+2OpwPaF 5BYba56L5WZr1xBwg/275fq2pN+/BAW8jZEFAINNXuD7Bu89QyChZhdndInDZAx5wct1 cvNQ== X-Received: by 10.236.106.99 with SMTP id l63mr3158255yhg.9.1370872055350; Mon, 10 Jun 2013 06:47:35 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([200.7.87.57]) by mx.google.com with ESMTPSA id z65sm15572209yhc.9.2013.06.10.06.47.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 06:47:34 -0700 (PDT) Message-ID: <51B5D8F2.4020702@gmail.com> Date: Mon, 10 Jun 2013 10:47:30 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [weirds] Bootstrapping: should it be a client or server -side problem ? X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 13:47:37 -0000 ... or both ? We've been talking a bit about bootstrapping, and for both proposed approaches the issue of client complexity (whether it lies in issuing complex DNS queries or parsing XML files) has been mentioned as a drawbacks. Thinking about this, if we were to move the problem of bootstrapping to the server, then we can do whatever we want (even parse ASN.1 if you are into sadomasochism :-D ). The client complexity issue becomes moot. Bootstrapping clients has the advantage of avoiding having poorly written clients hitting the same RDAP server over and over again, even if they get 301 answers most of the time. Now, if we could agree on creating a 'pool' of RDAP servers, just like NTP.org does with NTP servers, we could perhaps avoid the issue mentioned above. It would work something like this: -- zone 'rdapservers.org' or even better 'rdap-servers.arpa': pool IN A pool IN A pool IN A pool IN A pool IN A pool IN A pool IN A ... same for AAAA records and adding all those who want to chip in ... If we make this decision early on (like, now) before most clients are written and distributed with operating systems, and if we do a good PR work on this, I think we can get a nicely bootstrapped system and we can share the load. Note that having this scheme in place does not prevent the existence of 'smart' clients who want/prefer to bootstrap themselves in order to avoid redirects. cheers! ~Carlos From andy@arin.net Mon Jun 10 07:40:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E38821F938E for ; Mon, 10 Jun 2013 07:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.139 X-Spam-Level: X-Spam-Status: No, score=-8.139 tagged_above=-999 required=5 tests=[AWL=2.460, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHSiN1LOaH-R for ; Mon, 10 Jun 2013 07:39:59 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 38B0A21F9389 for ; Mon, 10 Jun 2013 07:39:59 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id E1DF8213683; Mon, 10 Jun 2013 10:39:28 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 4608D21366B; Mon, 10 Jun 2013 10:39:28 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 10 Jun 2013 10:39:28 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 10:39:26 -0400 From: Andy Newton To: "carlos@lacnic.net" , "" Thread-Topic: [weirds] Bootstrapping: should it be a client or server -side problem ? Thread-Index: AQHOZehOIYDo5CHkZkeCwUO/q5sLag== Date: Mon, 10 Jun 2013 14:39:26 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF2714@CHAXCH01.corp.arin.net> In-Reply-To: <51B5D8F2.4020702@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <1B2340EBACD0D94395A9EFA3B20FBAC3@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Bootstrapping: should it be a client or server -side problem ? X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 14:40:03 -0000 I like the idea, especially since we know people are gonna write dumb clients. -andy On 6/10/13 9:47 AM, "Carlos M. Martinez" wrote: >... or both ? > >We've been talking a bit about bootstrapping, and for both proposed >approaches the issue of client complexity (whether it lies in issuing >complex DNS queries or parsing XML files) has been mentioned as a >drawbacks. > >Thinking about this, if we were to move the problem of bootstrapping to >the server, then we can do whatever we want (even parse ASN.1 if you are >into sadomasochism :-D ). The client complexity issue becomes moot. > >Bootstrapping clients has the advantage of avoiding having poorly >written clients hitting the same RDAP server over and over again, even >if they get 301 answers most of the time. > >Now, if we could agree on creating a 'pool' of RDAP servers, just like >NTP.org does with NTP servers, we could perhaps avoid the issue >mentioned above. > >It would work something like this: > >-- zone 'rdapservers.org' or even better 'rdap-servers.arpa': > >pool IN A >pool IN A >pool IN A >pool IN A >pool IN A >pool IN A >pool IN A > >... same for AAAA records and adding all those who want to chip in ... > >If we make this decision early on (like, now) before most clients are >written and distributed with operating systems, and if we do a good PR >work on this, I think we can get a nicely bootstrapped system and we can >share the load. > >Note that having this scheme in place does not prevent the existence of >'smart' clients who want/prefer to bootstrap themselves in order to >avoid redirects. > >cheers! > >~Carlos >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds > From olaf@NLnetLabs.nl Mon Jun 10 09:29:52 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1968921F8607 for ; Mon, 10 Jun 2013 09:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsvxFmSriRAO for ; Mon, 10 Jun 2013 09:29:51 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3538121F86D5 for ; Mon, 10 Jun 2013 09:29:51 -0700 (PDT) Received: from ip212-238-71-176.hotspotsvankpn.com (ip212-238-71-176.hotspotsvankpn.com [212.238.71.176]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r5AGSnkc024003 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 10 Jun 2013 18:28:50 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.2 open.nlnetlabs.nl r5AGSnkc024003 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1370881759; bh=vvknhjMbYqPOj3gNS0e0cuAjt6Np+yOfKtLNngZjP0U=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=MrEcLjwNrDYpI54Ffsj1QG8FQmqOcevCWxMGW6oKEzXJROMhISEdlN1Ka2UqLh+qY dLGc2tzglGMx+bG0TU2WPx2N4TJfZzjf+BczGNSSW1SyLaU1ECiL3nZBEPRwUVOmgS +nRfBhd1N13B56ezZD5GueED7gsA2N0BrtbiJyW0= Message-ID: <51B5C3A7.4010506@NLnetLabs.nl> Date: Mon, 10 Jun 2013 19:16:39 +0700 From: "Olaf M. Kolkman" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DDDBAC@CHAXCH02.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DDDBAC@CHAXCH02.corp.arin.net> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2KODUHQOIICBDLGFKXNHT" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Mon, 10 Jun 2013 18:28:52 +0200 (CEST) Cc: "weirds@ietf.org" Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:29:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2KODUHQOIICBDLGFKXNHT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/4/13 6:19 PM, Andy Newton wrote: > > "publicIds" : > [ > { > "type": "IANA Registrar ID", > "identifier" : "1" > } > ], > > > o publicIds - an array of objects, with each object containing the > > following memebers: > > > * type - a string denoting the type of public identifier > > > * identifier - a public identifier of the type denoted by 'type'= > > Do we now need a registry for these types? Or guidance for naming them so that there will not be clashes? For instance, the type could include the (domain) name of the registry. No hats. --Olaf ------enig2KODUHQOIICBDLGFKXNHT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRtcOuAAoJEFRqER47aqpk1C0P/RhGnKz2d+K30CUrLZXYYIiq oj4LsMnVZAgbglZB39sivXD4GsrfjoAQiMlmvArfvrJwucm0VNCnQwEBHEo/P+gs /w2IIf4sz7h2uy+sjrcwRZHPU2mfJknC12EGha5AiZGG6cTy/ApA/1k0w8gt50rW xqa8EQMHTpyEJ0fq5culaCP98G061HtWK7Gkpx5ZfLdML6b8U0XBY+vqd9L+2qPS wN2fvQxjdnWYAl+P3D+uhXB7/1i4r5KfV/eYsEv+ky0ioVlvs15+qmycNn1FCQu+ SBrm0/jVi7aqKqbHQyQ5X+QkLaG/PkefBiXo2EFYkK0JQ/BLkLsrCh5+oqDlCpWg F1JZXYDQE3U37yJZpeHd+9awZfbovVxJY/x++oYTduuLob8msOvfUbOFm4CzebEG +ix/VKZj7loSNSz3SzY5AEq88h7Xv7RASdk2W/eicDTNlt1Bn5o44SjDfitZpMQX FgWPhUohnpR1rN8BcaPXYpqZb7Gaidm33GKHQOLP3R8anbq8v809DmeusWaKMq2F k6FoBKRj56UjqrQjzNvc4HaHEyuLwm+P3Wv4t6A9bXRG8jl2NLXADkv5cHNNB7wd pXnzL3Fnz9TMQ5Gv+Xc8OSPg9IEIHZv4OGt3T51VH8b8eJ/duhJvMUiLtrZPbJe7 nnQuEVYGXejmgM3NPsuH =9s+n -----END PGP SIGNATURE----- ------enig2KODUHQOIICBDLGFKXNHT-- From andy@arin.net Mon Jun 10 09:57:49 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6976321F994C for ; Mon, 10 Jun 2013 09:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3FxMeD4s8Nn for ; Mon, 10 Jun 2013 09:57:44 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id E72F221F9750 for ; Mon, 10 Jun 2013 09:57:43 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 2C8C9165132; Mon, 10 Jun 2013 12:57:41 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id B2AB316512F; Mon, 10 Jun 2013 12:57:40 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 10 Jun 2013 12:57:10 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 12:57:07 -0400 From: Andy Newton To: "Olaf M. Kolkman" Thread-Topic: [weirds] ICANN Whois Specifications Thread-Index: AQHOYIQ2weBqCM/1Bk2sY5mV/PjGWpkkuKMAgAB6oQCAADaRAIAJwOiAgAALCYA= Date: Mon, 10 Jun 2013 16:57:07 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF28C7@CHAXCH01.corp.arin.net> In-Reply-To: <51B5C3A7.4010506@NLnetLabs.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <625AF1087404B940975779F35AFE6255@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] ICANN Whois Specifications X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:57:49 -0000 On 6/10/13 8:16 AM, "Olaf M. Kolkman" wrote: >On 6/4/13 6:19 PM, Andy Newton wrote: >> >> "publicIds" : >> [ >> { >> "type": "IANA Registrar ID", >> "identifier" : "1" >> } >> ], >> >> >> o publicIds - an array of objects, with each object containing the >> >> following memebers: >> >> >> * type - a string denoting the type of public identifier >> >> >> * identifier - a public identifier of the type denoted by 'type' >> >> > >Do we now need a registry for these types? Or guidance for naming them >so that there will not be clashes? For instance, the type could include >the (domain) name of the registry. > >No hats. I would think we only need a registry or other information if we believe this will be machine interpreted. I doubt that is the case for these. But I'm willing to be proven otherwise. -andy From johnl@iecc.com Mon Jun 10 14:44:04 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6665621F9452 for ; Mon, 10 Jun 2013 14:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiQVIJx3G9hl for ; Mon, 10 Jun 2013 14:44:00 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3985421F85E0 for ; Mon, 10 Jun 2013 14:43:59 -0700 (PDT) Received: (qmail 86220 invoked from network); 10 Jun 2013 21:43:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Jun 2013 21:43:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b6489e.xn--hew.k1306; i=johnl@user.iecc.com; bh=0lojjjp1QmMHRgzq0A/A0oVNN1b6WUCg2HNXYSKzX+Q=; b=KxD7Etrmu/BBUVNQWSLCSRl/3fmPFwl7o6nJpk+I7yfA/dHSEef4X9iicD83Cwng7caTRLeItWmenYZgvL4tvOPIiHwkaL+A7P6dQrgSsy58ZkU+jYdTqZxuarIOfCGeKE8wHSVtOfWpufc2p+R78XdqyY/ASQKKE6kZqwEVIs4aSxVL2e8PZwiVaG5Gsbx2+Z+uTZu1Z/zYg4yYxzS6N6JoMofEL9PO7vIVdHSOVGmS9nvcYRgGFEAFMfRfgziS DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b6489e.xn--hew.k1306; olt=johnl@user.iecc.com; bh=0lojjjp1QmMHRgzq0A/A0oVNN1b6WUCg2HNXYSKzX+Q=; b=l/HyzfIx8ZIIi9C7L5Dk6TPyWFmoZUkzXAlDpUGJD7ve3tPR41ezNiPfYkTjsF50Fwukqp+l9D0tc+MMFsVOL3oHGtOIcQ0NST7H8GTOxs8JH0TfZ+GSN/MgaaXvMKVi0hSXOWJo6BWXMv9nby8IGcm7jkJGN55Svb7QX6kVpiwUa6e2QLhnehodUGSG5g6FWAnKeslTCtIZem/rM99hnz4Jt17YCqg6+zCPnBrzpe2CUYikHxvXY71pzOZRWn7/ Date: 10 Jun 2013 21:43:36 -0000 Message-ID: <20130610214336.72809.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <51B5D8F2.4020702@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: carlos@lacnic.net Subject: Re: [weirds] Bootstrapping: performance issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 21:44:04 -0000 >Now, if we could agree on creating a 'pool' of RDAP servers, just like >NTP.org does with NTP servers, we could perhaps avoid the issue >mentioned above. For numbers, that seems entirely workable. There are only five RIRs, they're all of similar size, and they have existing working relationships. But for names, it's out of the question. Here's some query numbers from the Feb 2013 monthly reports: TLD Queries .COM 8.1G .NET 714M ,INFO 162M .ORG 116M .BIZ 83M .XXX 3.9M ,AERO 1.6M .POST 1.1M .COOP 475K .MUSEUM 67K (I don't understand why .POST got 1.1M queries, since the domain appeared to have only 8 active names. Squatters getting ready for sunrise, perhaps.) There are more WHOIS queries to Verisign than there are to everyone else put together, and the long tail will be very long, with most domains getting only a few thousand queries a day. The .COM WHOIS servers are getting about 3000 queries per second. There's no way anyone is going to share that. Given the amount of traffic, the vast differences in query rates, and the fact that few of the TLDs have relationships with any other TLDs, the only plausible way to distribute bootstrap info for names is through the DNS. I hope we can resolve this in Berlin. R's, John From gavin.brown@centralnic.com Mon Jun 10 15:36:47 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7A21F99D5 for ; Mon, 10 Jun 2013 15:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.409 X-Spam-Level: *** X-Spam-Status: No, score=3.409 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uPkrPpzlq+Q for ; Mon, 10 Jun 2013 15:36:43 -0700 (PDT) Received: from smtp.centralnic.com (unknown [193.105.170.214]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5821F99D2 for ; Mon, 10 Jun 2013 15:36:42 -0700 (PDT) Received: from [192.168.0.3] (unknown [2.123.110.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 2C8C5720678; Mon, 10 Jun 2013 22:36:39 +0000 (UTC) References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF2714@CHAXCH01.corp.arin.net> Mime-Version: 1.0 (1.0) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF2714@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Gavin Brown Date: Mon, 10 Jun 2013 23:36:37 +0100 To: Andy Newton Cc: "carlos@lacnic.net" , "" Subject: Re: [weirds] Bootstrapping: should it be a client or server -side problem ? X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 22:36:47 -0000 +1. This was my idea if rdap.org ever got too much traffic for my little VM t= o handle. I would be happy to donate the domain for this purpose, but wouldn= 't rdap.arpa be a better name? On 10 Jun 2013, at 15:39, Andy Newton wrote: > I like the idea, especially since we know people are gonna write dumb > clients. >=20 > -andy >=20 > On 6/10/13 9:47 AM, "Carlos M. Martinez" wrote: >=20 >> ... or both ? >>=20 >> We've been talking a bit about bootstrapping, and for both proposed >> approaches the issue of client complexity (whether it lies in issuing >> complex DNS queries or parsing XML files) has been mentioned as a >> drawbacks. >>=20 >> Thinking about this, if we were to move the problem of bootstrapping to >> the server, then we can do whatever we want (even parse ASN.1 if you are >> into sadomasochism :-D ). The client complexity issue becomes moot. >>=20 >> Bootstrapping clients has the advantage of avoiding having poorly >> written clients hitting the same RDAP server over and over again, even >> if they get 301 answers most of the time. >>=20 >> Now, if we could agree on creating a 'pool' of RDAP servers, just like >> NTP.org does with NTP servers, we could perhaps avoid the issue >> mentioned above. >>=20 >> It would work something like this: >>=20 >> -- zone 'rdapservers.org' or even better 'rdap-servers.arpa': >>=20 >> pool IN A >> pool IN A >> pool IN A >> pool IN A >> pool IN A >> pool IN A >> pool IN A >>=20 >> ... same for AAAA records and adding all those who want to chip in ... >>=20 >> If we make this decision early on (like, now) before most clients are >> written and distributed with operating systems, and if we do a good PR >> work on this, I think we can get a nicely bootstrapped system and we can >> share the load. >>=20 >> Note that having this scheme in place does not prevent the existence of >> 'smart' clients who want/prefer to bootstrap themselves in order to >> avoid redirects. >>=20 >> cheers! >>=20 >> ~Carlos >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >>=20 >=20 >=20 >=20 From internet-drafts@ietf.org Wed Jun 12 10:17:46 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A207721F957B; Wed, 12 Jun 2013 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXnYZtt6Gjj7; Wed, 12 Jun 2013 10:17:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6517A21F9A52; Wed, 12 Jun 2013 10:17:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130612171745.12400.30846.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2013 10:17:45 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-05.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:17:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Registration Data Access Protocol Lookup Format Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-05.txt Pages : 12 Date : 2013-06-12 Abstract: This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-query-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shollenbeck@verisign.com Wed Jun 12 10:20:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C2021F9A72 for ; Wed, 12 Jun 2013 10:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TIh0TffGOTi for ; Wed, 12 Jun 2013 10:20:26 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0152E21F9AD9 for ; Wed, 12 Jun 2013 10:20:24 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKUbit2PJunLRUIYSrYRd8ivhVwi2YTTmN@postini.com; Wed, 12 Jun 2013 10:20:25 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 r5CHKLOo029516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Jun 2013 13:20:23 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 13:20:20 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-05.txt Thread-Index: AQHOZ5DEnavaP4e2BEWqiFEsGF1BP5kyUqKw Date: Wed, 12 Jun 2013 17:20:20 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243A8293@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130612171745.12400.30846.idtracker@ietfa.amsl.com> In-Reply-To: <20130612171745.12400.30846.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 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-05.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:20:33 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Wednesday, June 12, 2013 1:18 PM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-05.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 Lookup Format > Author(s) : Andrew Lee Newton > Scott Hollenbeck > Filename : draft-ietf-weirds-rdap-query-05.txt > Pages : 12 > Date : 2013-06-12 This update describes a new /help path segment (thanks for the suggestion, = Ernie) that synchs with text in the soon-to-be-submitted json-response upda= te. Scott From internet-drafts@ietf.org Wed Jun 12 10:57:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C3A21E80AE; Wed, 12 Jun 2013 10:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bngbww6qnn5q; Wed, 12 Jun 2013 10:57:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B6021E80B5; Wed, 12 Jun 2013 10:56:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130612175627.32033.71394.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2013 10:56:27 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:57:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : JSON Responses for the Registration Data Access Protocol= (RDAP) Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-json-response-04.txt Pages : 71 Date : 2013-06-12 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-json-response-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From carlosm3011@gmail.com Wed Jun 12 11:18:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7B821E8096 for ; Wed, 12 Jun 2013 11:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pykJvBIrFX8X for ; Wed, 12 Jun 2013 11:18:06 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 80F7D21E808B for ; Wed, 12 Jun 2013 11:18:06 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id gf11so4390947vcb.39 for ; Wed, 12 Jun 2013 11:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=swn5RKBwElIQI1hbb02m4xGtxN7dVUtCZRYuTsekTzc=; b=kbkyfCtn705fFyravhGureEyAvD/2ayerEX/GHelHJD6Om5XQNzxJx9j18+dFYjtJe TER6iVwy8mg/A30VkZddBIbR52oqsy6y4zj5DC64262yof+zhmhqXzrvPwK3JLYfSVFP UYO3tjaBoHCMciRczgUagF0sBDVwssW8KsonslWv/DL2VN19O/JOZTmnscBmkocRArFD pdzhOXrjpR4phE5qO26+R4cHfI1YPXqlyL075rN7Kz0Fg/6aLOv9BY1F8Pz2x2vcf/s3 WNRGiWlRmDsE64LiazlDnb19H/g9fv/nUgtby69864m3tnylMXy9kaIWbjfWBVbEXVPn P+iA== X-Received: by 10.220.252.66 with SMTP id mv2mr10301720vcb.22.1371061080931; Wed, 12 Jun 2013 11:18:00 -0700 (PDT) Received: from europa.local ([200.7.87.87]) by mx.google.com with ESMTPSA id ih10sm15333309vdb.1.2013.06.12.11.17.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Jun 2013 11:17:59 -0700 (PDT) Message-ID: <51B8BB5B.1060301@gmail.com> Date: Wed, 12 Jun 2013 15:18:03 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Levine References: <20130610214336.72809.qmail@joyce.lan> In-Reply-To: <20130610214336.72809.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: carlos@lacnic.net, weirds@ietf.org Subject: Re: [weirds] Bootstrapping: performance issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:18:11 -0000 Thanks John, that's useful insight. Are those numbers public ? Is there a source we can reference ? As a possible way forward, we could split the pools into names and numbers pools: --- zone 'rdap-servers.arpa' pool.numbers IN A pool.numbers IN A pool.numbers IN A pool.numbers IN A pool.numbers IN A ... pool.names In A <.com rdap server #1> pool.names In A <.com rdap server #2> pool.names In A <.com rdap server #3> pool.names In A <.net rdap server> pool.names In A <.org rdap server> --- END zone Under this scheme: - names and numbers servers would redirect to the 'head' pool of the other camp: rdap server, when receiving a query for a name would redirect to pool.names.rdap-servers.arpa, rdap server, when receiving a query for a number would redirect to pool.numbers.rdap-servers.arpa - each camp can decide how to better share the load, as, given the numbers provided by John, I believe it will be easier to find common ground within each camp rather than try to unify everything under the same umbrella - .com for example could provide more than one entry in order to capture an adequate proportion of the whole queries - quasi-smart clients, while not doing a full bootstrap, can choose which pool to direct their queries to, based on the type of the object they're querying Thoughts ? ~Carlos On 6/10/13 6:43 PM, John Levine wrote: >> Now, if we could agree on creating a 'pool' of RDAP servers, just like >> NTP.org does with NTP servers, we could perhaps avoid the issue >> mentioned above. > > For numbers, that seems entirely workable. There are only five RIRs, > they're all of similar size, and they have existing working > relationships. > > But for names, it's out of the question. Here's some query numbers > from the Feb 2013 monthly reports: > > TLD Queries > > .COM 8.1G > .NET 714M > ,INFO 162M > .ORG 116M > .BIZ 83M > .XXX 3.9M > ,AERO 1.6M > .POST 1.1M > .COOP 475K > .MUSEUM 67K > > (I don't understand why .POST got 1.1M queries, since the domain > appeared to have only 8 active names. Squatters getting ready for > sunrise, perhaps.) > > There are more WHOIS queries to Verisign than there are to everyone > else put together, and the long tail will be very long, with most > domains getting only a few thousand queries a day. > > The .COM WHOIS servers are getting about 3000 queries per second. > There's no way anyone is going to share that. > > Given the amount of traffic, the vast differences in query rates, and > the fact that few of the TLDs have relationships with any other TLDs, > the only plausible way to distribute bootstrap info for names is > through the DNS. I hope we can resolve this in Berlin. > > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Wed Jun 12 11:30:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBEC21E8091 for ; Wed, 12 Jun 2013 11:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.27 X-Spam-Level: X-Spam-Status: No, score=-8.27 tagged_above=-999 required=5 tests=[AWL=2.329, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEgv1qlj7T1L for ; Wed, 12 Jun 2013 11:30:10 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0983221F883B for ; Wed, 12 Jun 2013 11:30:08 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 8FB33213675; Wed, 12 Jun 2013 14:29:38 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 0E6BE213605 for ; Wed, 12 Jun 2013 14:29:38 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 12 Jun 2013 14:29:14 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 14:29:13 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-json-response-04.txt Thread-Index: AQHOZ5ZD63FGu/JbwEqBxeJcLp4xEZkyZk2A Date: Wed, 12 Jun 2013 18:29:13 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4A66@CHAXCH01.corp.arin.net> In-Reply-To: <20130612175627.32033.71394.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <2E1D0724A778E443932DF1CB6E0AE129@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-json-response-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:30:15 -0000 A pretty diff for your reading enjoyment: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-json-response-04 And the change log for -04: 'description' removed from IP network and autnum because it is redundant with the remarks structure. Added 'entities' array to nameservers. Added 'status' to autnum. Added 'publicIds' to entity and domain. Added embedded entities to the entity object class. Added 'idnTable' to variants objects in domain object class. Changed the numbers for startNum and endNum in autnum to numbers instead of strings. Added an example for error response with full rdapConformance and notices. Added a section discussing help. Changed entities to use vcardArray and changed the examples to be current with jCard. Added a section on structured vs unstructured addresses. Added associated to the list of status values. Added a secure DNS section changed the 'delegationKey' object into the 'secureDNS' object. Changed the suggested values to an IANA registry. Added 'proxy' to the list of entity roles. From johnl@taugh.com Wed Jun 12 12:05:58 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AD511E80F9 for ; Wed, 12 Jun 2013 12:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir7rvRTEtAYJ for ; Wed, 12 Jun 2013 12:05:57 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3213411E80F1 for ; Wed, 12 Jun 2013 12:05:56 -0700 (PDT) Received: (qmail 84420 invoked from network); 12 Jun 2013 19:05:50 -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:cleverness; s=149c2.51b8c68e.k1306; bh=ky6DBnieul1HlNcZSFfIgVrq2kv1knRLupKUKK03A60=; b=ZFjNulfARtpkf5BwZgIA2p1S0QEGHcsVk7HNxH7t/GZ0JUa0QGLaouqGgMkYYyih0hFJO1Y8whQ8xaEZf77s9BKP5b+9YRnoWQFOQsbuH4aPkctlhFGDvbkDB1kutw/qAyDuKnBUN5SyJV1nKKpgMgpPVaKGTcnz/SWFDguL8DJForYyW14il//R+wad9rkGO3xXqtFRVGKxKH6naTsCF74TZt3y3kGKT+ha2w8JnoTULHu+8Xd5dWLTSkvxTk58 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:cleverness; s=149c2.51b8c68e.k1306; bh=ky6DBnieul1HlNcZSFfIgVrq2kv1knRLupKUKK03A60=; b=Z9V2oPQ7fxxzadES8E9r3P1WMXboW2zw4CE8r4VUqj7lQGJTGqAfQri++Zr5NwDjIQ79dYAUEdW5V229i/gu1Hcczt3Dtv9lKk47se3et5cWCt+k9S7NnXZWzJd1RQybMZUWJzjK3vYSlFQlYBVY/yy+B1NU/krTlQxNOIbDNoJ2vrd1n/TN1CnDhTqDjznSBAL5hA4hx3qSPILqD63UJiDzVpOCjlpm8h9acDhKhSDVhg1i76MdMxv/zmhto2MK Received: (ofmipd 127.0.0.1); 12 Jun 2013 19:05:28 -0000 Date: 12 Jun 2013 15:05:50 -0400 Message-ID: From: "John R Levine" To: carlos@lacnic.net In-Reply-To: <51B8BB5B.1060301@gmail.com> References: <20130610214336.72809.qmail@joyce.lan> <51B8BB5B.1060301@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1761456863-1371063950=:86135" Cc: weirds@ietf.org Subject: Re: [weirds] Bootstrapping: performance issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 19:05:58 -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. --3825401791-1761456863-1371063950=:86135 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > Thanks John, that's useful insight. Are those numbers public ? Is there > a source we can reference ? They're public, from the monthly registry reports on the ICANN web site. > As a possible way forward, we could split the pools into names and > numbers pools: No, a names pool doing http forwarding is completely out of the question, unless you expect all of the servers in the pool to be run by Verisign. Someone getting 3000 queries/day can't realistically offer to share load with someone getting 3000 queries/second. All you need is for one or two busy clients to pick your IP to get DDoS'ed. And beyond that, there are no existing relationships between ccTLDs and gTLDs to set up the pool. As I said in the messge you quoted: >> There are more WHOIS queries to Verisign than there are to everyone >> else put together, and the long tail will be very long, with most >> domains getting only a few thousand queries a day. >> >> The .COM WHOIS servers are getting about 3000 queries per second. >> There's no way anyone is going to share that. >> >> Given the amount of traffic, the vast differences in query rates, and >> the fact that few of the TLDs have relationships with any other TLDs, >> the only plausible way to distribute bootstrap info for names is >> through the DNS. I hope we can resolve this in Berlin. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1761456863-1371063950=:86135 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjEyMTkwNTUwWjAjBgkqhkiG 9w0BCQQxFgQUzHLJDVf1OEf1TKGD9y+23MmTbNsweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAGM6wy58dhBRo opb+SJ9G6lqIaXxYCMs8RWM+d1sHx68xOlmFSpIadpSDiKAMPV3MTQnzqLqn Q9CluG9hkseZoqNVMLtnams+8eeQ7cvAuRZVGKuq0rkmhf+ZDW/WCTOqNzeG yrZku0Tepe8jxwmMH7UiFk236E79Ma5N0704qcC81j2NNckWA7Dv7cU5BMEm kcppOMGKu4o3VZ7/N/QB7xS4+FsadWVVFph2aXL4KtaqVoObrSCQy3ONo+3K hOuGqpTZqG7Xq9xn6XYRXLHybB1FZ5wrTk6TXqyC/6L2jLUuEjCcY5HCJG2+ Cqv0Zsfon2XXPoAZxVXYsDgw6ILZAQ== --3825401791-1761456863-1371063950=:86135-- From chris@ausregistry.com.au Wed Jun 12 20:23:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A96821F999F for ; Wed, 12 Jun 2013 20:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQprKyIWY17y for ; Wed, 12 Jun 2013 20:23:25 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [120.29.255.35]) by ietfa.amsl.com (Postfix) with ESMTP id EBFE321F9994 for ; Wed, 12 Jun 2013 20:23:24 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 13 Jun 2013 13:23:22 +1000 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 13 Jun 2013 13:23:26 +1000 From: Chris Wright To: John R Levine , "carlos@lacnic.net" Date: Thu, 13 Jun 2013 13:23:22 +1000 Thread-Topic: [weirds] Bootstrapping: performance issues Thread-Index: Ac5nn+mf8GFfJITUR16cuxKns1MRcwAREQaA Message-ID: <8CEF048B9EC83748B1517DC64EA130FB7714A6C3CB@off-win2003-01.ausregistrygroup.local> References: <20130610214336.72809.qmail@joyce.lan> <51B8BB5B.1060301@gmail.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Bootstrapping: performance issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 03:23:30 -0000 I still maintain my original pov from the conversation and presentation don= e way back at the start of this working group, that bootstrapping with SRV = or NAPTR records in the TLD zone is the right way to go for domain name wei= rds queries. It could be done for numbers to, using the reverse lookup zones, but alas, = as others have said there is only a few of them and they can redirect to ea= ch other if that's the way they choose to work. The TLD operator, if required, could redirect to WEIRDS servers for domains= further down their own tree, they need to interact with those people to ge= t name server information anyway, so they could get the WEIRDS server infor= mation as well. The argument that "we want to write clients in javascript and we cant do th= at if we have to do a DNS lookup" is a red herring and irrelevant, as javas= cript running as a system program (AKA node.js) is perfectly able to do DNS= lookups, and javascript running in a browser can call back to the server t= hat served the javascript to do the DNS lookup server side (or indeed be se= eded with the lookup URLs from each TLD when it is served to the browser if= the website operator deemed it necessary). It technically works without a problem and doesn't rely on us creating a ce= ntralised single source of failure - it is the best solution of any present= ed so far and I still don't understand the resistance to it. Thanks Chris -----Original Message----- From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= John R Levine Sent: Thursday, 13 June 2013 5:06 AM To: carlos@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] Bootstrapping: performance issues > Thanks John, that's useful insight. Are those numbers public ? Is=20 > there a source we can reference ? They're public, from the monthly registry reports on the ICANN web site. > As a possible way forward, we could split the pools into names and=20 > numbers pools: No, a names pool doing http forwarding is completely out of the question, u= nless you expect all of the servers in the pool to be run by Verisign.=20 Someone getting 3000 queries/day can't realistically offer to share load wi= th someone getting 3000 queries/second. All you need is for one or two bus= y clients to pick your IP to get DDoS'ed. And beyond that, there are no ex= isting relationships between ccTLDs and gTLDs to set up the pool. As I said in the messge you quoted: >> There are more WHOIS queries to Verisign than there are to everyone=20 >> else put together, and the long tail will be very long, with most=20 >> domains getting only a few thousand queries a day. >> >> The .COM WHOIS servers are getting about 3000 queries per second. >> There's no way anyone is going to share that. >> >> Given the amount of traffic, the vast differences in query rates, and=20 >> the fact that few of the TLDs have relationships with any other TLDs,=20 >> the only plausible way to distribute bootstrap info for names is=20 >> through the DNS. I hope we can resolve this in Berlin. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropp= ed the toothpaste", said Tom, crestfallenly. From johnl@taugh.com Wed Jun 12 21:33:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A87021E808F for ; Wed, 12 Jun 2013 21:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYmScrLdqpoj for ; Wed, 12 Jun 2013 21:33:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 197B721E808E for ; Wed, 12 Jun 2013 21:33:30 -0700 (PDT) Received: (qmail 11794 invoked from network); 13 Jun 2013 04:33:27 -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:cleverness; s=2e11.51b94b97.k1306; bh=gVllKsWto7U5VD1PPEarXnMxKwdB/DuQ1X1A9mvD6R8=; b=gc9nS6k//mDZ9xKE0wKUlYL76lcxNLborYH8nYti8wymYuLD2kgZpGDZR9EWSK8eGHDDsYYrv7jX9HR+oSl9N6Sse/W0kzw8L0IIbdT1gP41PZg2RszBjFTD/XgrIuESE5xXuXkzestjqS4R3MkkvgZQXNFZgT68v1alKwqOESTktWLD3OfuZlzmmgl+YPJRXoGC2MMFdmFnFtuEJgQnk//l9Zq+fcdyH5Ts4g6HRL12EALhcjCQbyRi6bfehT2V 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:cleverness; s=2e11.51b94b97.k1306; bh=gVllKsWto7U5VD1PPEarXnMxKwdB/DuQ1X1A9mvD6R8=; b=GujzHnCbOSjiEbeIpwRHOwiY3HfwY3Bp2bgE3oe1cT7kKDyFFOp2SVi1jGpPKTCTXI3hd5S6JzV95Na1Hj+oe3jELoSMIxkeVSQTsYZzsCMEgcVlHo4WKLNfemBoOB0iLSdWIzaqKcWOFutXu8KtKSN4+TDOGygxLRWLPUEnet/SApkryKt6tTuJwCdpfP3EwBWSYb+Zc52J9nZ5VNtTDEs/aWJU/zIDXipS5VRArBRFlbypL0oE40MTr7bTJpzQ Received: (ofmipd 127.0.0.1); 13 Jun 2013 04:33:05 -0000 Date: 13 Jun 2013 00:33:26 -0400 Message-ID: From: "John R Levine" To: "Chris Wright" In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB7714A6C3CB@off-win2003-01.ausregistrygroup.local> References: <20130610214336.72809.qmail@joyce.lan> <51B8BB5B.1060301@gmail.com> <8CEF048B9EC83748B1517DC64EA130FB7714A6C3CB@off-win2003-01.ausregistrygroup.local> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1657730472-1371098007=:64413" Cc: "weirds@ietf.org" Subject: Re: [weirds] Bootstrapping: performance issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 04:33:33 -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. --3825401791-1657730472-1371098007=:64413 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > I still maintain my original pov from the conversation and presentation > done way back at the start of this working group, that bootstrapping > with SRV or NAPTR records in the TLD zone is the right way to go for > domain name weirds queries. I must be dim, since I could have sworn we drove a stake through this one last year. Could you explain in detail why it is preferable to the alternative of A or AAAA or CNAME labels at .rdap.arpa? Javascript in web browsers and shell scripts can trivially do the A/AAAA/CNAME lookup by sticking the TLD into the URL they are fetching, but have to do backflips to do SRV or NAPTR lookups. What useful abilities will clients have with SRV or NAPTR to justify the extra work? As I recall, you proposed that Javascript clients do an http callback to whatever server provided the Javascript to turn the SRV or NAPTR into a name. Why is this preferable to a much faster DNS lookup? A DNS lookup can be secured with a verifiable chain of trust using DNSSEC; what is the equivalent for a callback to some random web server? Keep in mind that since there are no existing RDAP servers so there is no need for backward compatibility to find RDAP servers on nonstandard ports or at peculiar URIs. Also, section 2.2.3.3 of the appliant guidebook for ICANN's new TLDs specifically lists the records allowed in the new TLD zones, and neither SRV nor NAPTR is on the list. It says: Applicants should be aware that a service based on use of less-common DNS resource records in the TLD zone, even if approved in the registry services review, might not work as intended for all users due to lack of application support. How much work do you think it will be to get the rules changed? Are you offering to negotiate with ICANN to do it? R's, John --3825401791-1657730472-1371098007=:64413 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjEzMDQzMzI2WjAjBgkqhkiG 9w0BCQQxFgQUZHAfpv9XWUm9Zc/OXUTBCCFhK1gweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAQBhKzm0i/7Pj t0O2f1pUzgmi8gMbw8Or2r0yCU0KIU0Quk8dn4ILv116xMxCYfjqEs1XHEQJ O87EzF0l/Sq2dghjYMIGbNGQWeZ3c67SXOlI4l9WAo/LLyA2ukMsWCRjIJ1L FqRrrTXbwepoL4PJjNj5u/9UXTmmUMSmI6uVWC5XseQM9Sl/sW4WuxiCUSuc Nok7I0Yv42BtfHf0z7Z66XquUUMNF6trHrB8fe1Q0Te+/+w9M+lQ17U2XUIX DE6a4Jfc74gRP62z5NdIKK1iyyQ+x1KtZsuZhLckCH6slg/aTIPjXqGbg048 ESjqlWgu+1vlYb37UTHwYoyT5nxv0g== --3825401791-1657730472-1371098007=:64413-- From pieter.vandepitte@dnsbelgium.be Thu Jun 13 01:45:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8727F21F9A6A for ; Thu, 13 Jun 2013 01:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymWbz88GjA-K for ; Thu, 13 Jun 2013 01:45:35 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 6073421F9732 for ; Thu, 13 Jun 2013 01:45:33 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 7E6584260003 for ; Thu, 13 Jun 2013 10:45:30 +0200 (CEST) Message-ID: <51B986AA.7090702@dnsbelgium.be> Date: Thu, 13 Jun 2013 10:45:30 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> <51813D18.3040604@qti.qualcomm.com> <518193E7.2090008@gmail.com> <518195FB.8090204@qti.qualcomm.com> <518AA3AF.9090105@afilias.info> In-Reply-To: <518AA3AF.9090105@afilias.info> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 08:45:39 -0000 Sorry to come back on this one... I can't always keep up with all mails I was currently changing my code to support vcardArray, but I think the examples in draft-ietf-weirds-json-response-04 are wrong Currently in the draft: "vcardArray":[ "vcard", [ /* the vcard */ ] ] so the vcard array is an array of 2 elements with vcardArray[0] == "vcard" and vcardArray[1] == the vcard itself? What if multiple vcards are provided? How would it look then? /* silly */ "vcardArray":[ "vcard", [ /* the vcard 1 */ ], "vcard", [ /* the vcard 2 */ ], ] or like this? "vcardArray":[ "vcard", // <---- this is useless [ /* vcard 1 */ ], [ /* vcard 2 */ ], ] Wouldn't it be better to completely follow jcard? i.e. make a 'stream' of vcards (section 3.2) and perhaps call the property name 'vcards' (ending with 's' like 'entities', 'roles', 'remarks', 'links',...) "vcards": ["vcardstream", ["vcard", [ /* properties */ ] ], ["vcard", [ /* properties */ ] ], ... ] Pieter On 05/08/2013 09:12 PM, Ernie Dainow wrote: > > On 5/1/2013 8:38 PM, Michael Angstadt wrote: >> @Pete: The syntax of the jCards in your examples aren't *quite* >> correct. The first element of the jCard array is the string "vcard". >> The second element is an array which contains all of the property >> arrays. The "vcard" string is redundant in this context, since the >> object field already uses this name, but I am just thinking that >> parsers might have trouble parsing the jCard without it. The examples >> should look like this: >> >> { >> "handle" : "XXXX", >> "vCard" : >> [ >> "vcard", >> [ >> [ "version", {}, "text", "4.0" ], >> [ "fn", {}, "text", "Joe Bob, Inc." ], >> ... >> ] >> ] >> >> Thanks, >> Mike >> > > For RDAP, this is confusing and prone to reversal and case errors. We > should use a different name, as in > > { > "handle" : "XXXX", > "vcardArray" : > [ > "vcard", > [ > > > -Ernie > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds -- *Pieter Vandepitte* *Software Engineer* +32 16 29 89 27 *www.dnsbelgium.be* From pieter.vandepitte@dnsbelgium.be Thu Jun 13 02:05:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A6421F91BC for ; Thu, 13 Jun 2013 02:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByQqvP32PjVK for ; Thu, 13 Jun 2013 02:05:25 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 6939B21F9AB3 for ; Thu, 13 Jun 2013 02:05:22 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 062444260004 for ; Thu, 13 Jun 2013 11:05:20 +0200 (CEST) Message-ID: <51B98B4E.8020001@dnsbelgium.be> Date: Thu, 13 Jun 2013 11:05:18 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <20130610214336.72809.qmail@joyce.lan> <51B8BB5B.1060301@gmail.com> <8CEF048B9EC83748B1517DC64EA130FB7714A6C3CB@off-win2003-01.ausregistrygroup.local> In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB7714A6C3CB@off-win2003-01.ausregistrygroup.local> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] Bootstrapping: performance issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 09:05:29 -0000 I liked the idea of naptr records and consequently being free to choose your own host, port, scheme and base path as specified in http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-05#section-3 And it would be sad to give up that freedom... Ok, it comes at a price of clients having to know how to handle naptr records, but i think it's a minimal requirement for developers who write software for the domain name community to know how to handle them... no? On javascript clients: i don't know the numbers at other tld's but at .be the port 43 queries currently outnumber the web queries. it's imo not the ultimate goal of this WG to develop a protocol for javascript clients in the browser (correct me if i'm wrong). And if needed, one can write a server side proxy client or do some other tricks (like 'abusing' a redirect enabled rdap server which redirects - by querying itself for naptr records - the client to the authoritative server) :-) Pieter On 06/13/2013 05:23 AM, Chris Wright wrote: > I still maintain my original pov from the conversation and presentation done way back at the start of this working group, that bootstrapping with SRV or NAPTR records in the TLD zone is the right way to go for domain name weirds queries. > > It could be done for numbers to, using the reverse lookup zones, but alas, as others have said there is only a few of them and they can redirect to each other if that's the way they choose to work. > > The TLD operator, if required, could redirect to WEIRDS servers for domains further down their own tree, they need to interact with those people to get name server information anyway, so they could get the WEIRDS server information as well. > > The argument that "we want to write clients in javascript and we cant do that if we have to do a DNS lookup" is a red herring and irrelevant, as javascript running as a system program (AKA node.js) is perfectly able to do DNS lookups, and javascript running in a browser can call back to the server that served the javascript to do the DNS lookup server side (or indeed be seeded with the lookup URLs from each TLD when it is served to the browser if the website operator deemed it necessary). > > It technically works without a problem and doesn't rely on us creating a centralised single source of failure - it is the best solution of any presented so far and I still don't understand the resistance to it. > > Thanks > > Chris > > > > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of John R Levine > Sent: Thursday, 13 June 2013 5:06 AM > To: carlos@lacnic.net > Cc: weirds@ietf.org > Subject: Re: [weirds] Bootstrapping: performance issues > >> Thanks John, that's useful insight. Are those numbers public ? Is >> there a source we can reference ? > > They're public, from the monthly registry reports on the ICANN web site. > >> As a possible way forward, we could split the pools into names and >> numbers pools: > > No, a names pool doing http forwarding is completely out of the question, unless you expect all of the servers in the pool to be run by Verisign. > Someone getting 3000 queries/day can't realistically offer to share load with someone getting 3000 queries/second. All you need is for one or two busy clients to pick your IP to get DDoS'ed. And beyond that, there are no existing relationships between ccTLDs and gTLDs to set up the pool. > > As I said in the messge you quoted: > >>> There are more WHOIS queries to Verisign than there are to everyone >>> else put together, and the long tail will be very long, with most >>> domains getting only a few thousand queries a day. >>> >>> The .COM WHOIS servers are getting about 3000 queries per second. >>> There's no way anyone is going to share that. >>> >>> Given the amount of traffic, the vast differences in query rates, and >>> the fact that few of the TLDs have relationships with any other TLDs, >>> the only plausible way to distribute bootstrap info for names is >>> through the DNS. I hope we can resolve this in Berlin. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > -- *Pieter Vandepitte* *Software Engineer* +32 16 29 89 27 *www.dnsbelgium.be* From simon.perreault@viagenie.ca Thu Jun 13 02:36:55 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5018821F9944 for ; Thu, 13 Jun 2013 02:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxCbTnQ8eBDW for ; Thu, 13 Jun 2013 02:36: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 DCE3921F8D10 for ; Thu, 13 Jun 2013 02:36:54 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:84c5:867d:e648:8153]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3CC92403D5 for ; Thu, 13 Jun 2013 05:36:54 -0400 (EDT) Message-ID: <51B992B5.7000402@viagenie.ca> Date: Thu, 13 Jun 2013 11:36:53 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> <51813D18.3040604@qti.qualcomm.com> <518193E7.2090008@gmail.com> <518195FB.8090204@qti.qualcomm.com> <518AA3AF.9090105@afilias.info> <51B986AA.7090702@dnsbelgium.be> In-Reply-To: <51B986AA.7090702@dnsbelgium.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 09:36:55 -0000 Le 2013-06-13 10:45, Pieter Vandepitte a écrit : > Wouldn't it be better to completely follow jcard? i.e. make a 'stream' > of vcards (section 3.2) and perhaps call the property name 'vcards' > (ending with 's' like 'entities', 'roles', 'remarks', 'links',...) > > "vcards": ["vcardstream", > ["vcard", > [ /* properties */ ] > ], > ["vcard", > [ /* properties */ ] > ], > ... > ] yes, or allow either vcardstream or vcard: "vcard": ["vcard", [ /*properties*/ ]], or "vcard": ["vcardstream", ["vcard", [ /*properties*/ ], ...]], After all, the point of "vcard" vs "vcardstream" is precisely to be able to determine what comes next. Simon From andy@arin.net Thu Jun 13 03:29:31 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A01B21F9A3A for ; Thu, 13 Jun 2013 03:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.562 X-Spam-Level: X-Spam-Status: No, score=-4.562 tagged_above=-999 required=5 tests=[AWL=-1.962, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMUc-P5fo4Dp for ; Thu, 13 Jun 2013 03:29: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 99F0121F9A2C for ; Thu, 13 Jun 2013 03:29:26 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 2E8EB213689; Thu, 13 Jun 2013 06:29:26 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 7BDE9213617; Thu, 13 Jun 2013 06:29:23 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 13 Jun 2013 06:29:11 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 13 Jun 2013 06:29:11 -0400 From: Andy Newton To: Pieter Vandepitte , "weirds@ietf.org" Thread-Topic: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) Thread-Index: AQHORrtVX/QJ1Dm96EOjkW94NLZayJjxUEcAgAqlXYCAN+SrAP//2eeA Date: Thu, 13 Jun 2013 10:29:10 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4E60@CHAXCH01.corp.arin.net> In-Reply-To: <51B986AA.7090702@dnsbelgium.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <6DDC9CD1087CDC48BA19DC96B2589F7C@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 10:29:31 -0000 On 6/13/13 4:45 AM, "Pieter Vandepitte" wrote: >Sorry to come back on this one... I can't always keep up with all mails Better to get this hammered out now, right? :) > >I was currently changing my code to support vcardArray, but I think the >examples in draft-ietf-weirds-json-response-04 are wrong > >Currently in the draft: > > "vcardArray":[ > "vcard", > [ /* the vcard */ ] > ] > >so the vcard array is an array of 2 elements with vcardArray[0] =3D=3D >"vcard" and vcardArray[1] =3D=3D the vcard itself? > >What if multiple vcards are provided? How would it look then? So the examples (and descriptive prose) aren't wrong, its just that the draft only supports one vCard per entity. What is the use case for multiple vCard's per entity? A vCard can already have multiple names, multiple addresses, multiple phone numbers, multiple emails, etc. I would think having multiple vCards is not necessary and could be a bit confusing. Maybe Simon could tell us what the original intent is for vCard streams. Is it so that multiple vCards can represent one person or org, or was it just to have a way to serialize multiple vCards for such purposes as transferring a contact database from one computer to another? -andy From andy@arin.net Thu Jun 13 03:35:47 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D167221F99F2 for ; Thu, 13 Jun 2013 03:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.343 X-Spam-Level: X-Spam-Status: No, score=-4.343 tagged_above=-999 required=5 tests=[AWL=-1.744, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wz-Em04Zajh for ; Thu, 13 Jun 2013 03:35:42 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id BFB3221F9A05 for ; Thu, 13 Jun 2013 03:35:41 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 70B1616529A; Thu, 13 Jun 2013 06:35:41 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id BB472165296; Thu, 13 Jun 2013 06:35:40 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 13 Jun 2013 06:35:28 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 13 Jun 2013 06:35:27 -0400 From: Andy Newton To: Pieter Vandepitte , "weirds@ietf.org" Thread-Topic: [weirds] Bootstrapping: performance issues Thread-Index: AQHOZiO1ZzqnsL5XoU6eTKRcwdgzvZkyqSGAgAANWgCAAIsCAIAAX4kA///WIIA= Date: Thu, 13 Jun 2013 10:35:26 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4E75@CHAXCH01.corp.arin.net> In-Reply-To: <51B98B4E.8020001@dnsbelgium.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <59B98153266FEE42B778E12C6B6281E3@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Bootstrapping: performance issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 10:35:47 -0000 On 6/13/13 5:05 AM, "Pieter Vandepitte" wrote: >On javascript clients: i don't know the numbers at other tld's but at >.be the port 43 queries currently outnumber the web queries. it's imo >not the ultimate goal of this WG to develop a protocol for javascript >clients in the browser (correct me if i'm wrong). And if needed, one can >write a server side proxy client or do some other tricks (like 'abusing' >a redirect enabled rdap server which redirects - by querying itself for >naptr records - the client to the authoritative server) :-) Our REST queries surpassed our port 43 queries last year. Keep in mind that "web" queries are not the same thing as REST. We've had web queries for years and years and they have never been as popular as port 43. But after the introduction of REST, it only took one year for those queries to climb above port 43. And when we did the analysis, Javascript clients are in the majority. So taking them into account is very important. I agree with John, NAPTR/SRV would be the death of bootstrapping in RDAP. It isn't successful and its time the IETF admitted that. I would be loath to implement it in my NicInfo client, and I say that having implemented S-NAPTR and U-NAPTR client code in the past (and having been co-author of the S-NAPTR RFC). -andy From pieter.vandepitte@dnsbelgium.be Thu Jun 13 04:13:36 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFC321F9A4E for ; Thu, 13 Jun 2013 04:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H0q6mIjWkjS for ; Thu, 13 Jun 2013 04:13:31 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 0E81221F9A48 for ; Thu, 13 Jun 2013 04:13:26 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 93E564260003; Thu, 13 Jun 2013 13:13:24 +0200 (CEST) Message-ID: <51B9A951.5030403@dnsbelgium.be> Date: Thu, 13 Jun 2013 13:13:21 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <51B98B4E.8020001@dnsbelgium.be> <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4E75@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4E75@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Bootstrapping: performance issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 11:13:37 -0000 Andy, thanks for your comments Is this valuable analysis somewhere available for us (usage of web queries, rest queries, port 43, ...)? It would be great to have and would avoid some discussions on the list :-) Kind regards Pieter On Thu 13 Jun 2013 12:35:26 PM CEST, Andy Newton wrote: > On 6/13/13 5:05 AM, "Pieter Vandepitte" > wrote: > >> On javascript clients: i don't know the numbers at other tld's but at >> .be the port 43 queries currently outnumber the web queries. it's imo >> not the ultimate goal of this WG to develop a protocol for javascript >> clients in the browser (correct me if i'm wrong). And if needed, one can >> write a server side proxy client or do some other tricks (like 'abusing' >> a redirect enabled rdap server which redirects - by querying itself for >> naptr records - the client to the authoritative server) :-) > > Our REST queries surpassed our port 43 queries last year. Keep in mind > that "web" queries are not the same thing as REST. We've had web queries > for years and years and they have never been as popular as port 43. But > after the introduction of REST, it only took one year for those queries to > climb above port 43. > > And when we did the analysis, Javascript clients are in the majority. So > taking them into account is very important. > > I agree with John, NAPTR/SRV would be the death of bootstrapping in RDAP. > It isn't successful and its time the IETF admitted that. I would be loath > to implement it in my NicInfo client, and I say that having implemented > S-NAPTR and U-NAPTR client code in the past (and having been co-author of > the S-NAPTR RFC). > > -andy > -- *Pieter Vandepitte* *Software Engineer* +32 16 29 89 27 *www.dnsbelgium.be* From simon.perreault@viagenie.ca Thu Jun 13 04:36:19 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9C721F99EB for ; Thu, 13 Jun 2013 04:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ-t4NzNIVDg for ; Thu, 13 Jun 2013 04:36:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 022D321F99E2 for ; Thu, 13 Jun 2013 04:36:19 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:84c5:867d:e648:8153]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2BFF2403D5; Thu, 13 Jun 2013 07:36:18 -0400 (EDT) Message-ID: <51B9AEB0.5070103@viagenie.ca> Date: Thu, 13 Jun 2013 13:36:16 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org, Philipp Kewisch References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4E60@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4E60@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 11:36:19 -0000 Le 2013-06-13 12:29, Andy Newton a écrit : > Maybe Simon could tell us what the original intent is for vCard > streams. Is it so that multiple vCards can represent one person or org, or > was it just to have a way to serialize multiple vCards for such purposes > as transferring a contact database from one computer to another? Philipp would be the best person to answer this question. Simon From fneves@registro.br Thu Jun 13 05:53:05 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292A621F96D9 for ; Thu, 13 Jun 2013 05:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVRzPNJx79qI for ; Thu, 13 Jun 2013 05:53:04 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2AD21F9A72 for ; Thu, 13 Jun 2013 05:53:04 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id C43ECE0505; Thu, 13 Jun 2013 09:53:00 -0300 (BRT) Date: Thu, 13 Jun 2013 09:53:00 -0300 From: Frederico A C Neves To: John R Levine Message-ID: <20130613125300.GI92752@registro.br> References: <20130610214336.72809.qmail@joyce.lan> <51B8BB5B.1060301@gmail.com> <8CEF048B9EC83748B1517DC64EA130FB7714A6C3CB@off-win2003-01.ausregistrygroup.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "weirds@ietf.org" Subject: Re: [weirds] Bootstrapping: performance issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 12:53:05 -0000 On Thu, Jun 13, 2013 at 12:33:26AM -0400, John R Levine wrote: > > I still maintain my original pov from the conversation and presentation > > done way back at the start of this working group, that bootstrapping > > with SRV or NAPTR records in the TLD zone is the right way to go for > > domain name weirds queries. > > I must be dim, since I could have sworn we drove a stake through this one > last year. Could you explain in detail why it is preferable to the > alternative of A or AAAA or CNAME labels at .rdap.arpa? As a "salomonical solution" solving, the single point of failure, the inability of redirects to/from unrelated parties, the difficulties involved with the use of SRV class of records, the non use of another TXT record at the apex of the zones and the possibility of name collisions. Use a hexhash("rdap").TLD. % python >>> import hashlib >>> hashlib.sha1("rdap").hexdigest() 'cc749546f2f7320a64ea61ab4a125be59d490b96' cc749546f2f7320a64ea61ab4a125be59d490b96.TLD IN [A|AAAA|CNAME] Fred From pieter.vandepitte@dnsbelgium.be Thu Jun 13 07:05:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F6721F91B7 for ; Thu, 13 Jun 2013 07:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r7vp9GBul9f for ; Thu, 13 Jun 2013 07:04:49 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 9C43221F9A70 for ; Thu, 13 Jun 2013 07:04:33 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id AF2CE4260011 for ; Thu, 13 Jun 2013 16:04:16 +0200 (CEST) Message-ID: <51B9D15F.1010208@dnsbelgium.be> Date: Thu, 13 Jun 2013 16:04:15 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> In-Reply-To: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 14:05:12 -0000 Another note on this solution... (not sure if already mentioned) there's no way of specifying the scheme in this solution. So, suppose one wants to implement confidentiality, the only solution is to redirect to an ssl host. Either to the same host https://com.domain.rdap.arpa/domain/example.com or to another https://rdap.com/domain/example.com Issues: [1] yet another redirect [2] in the first case: not sure if one can request ssl certificates for arpa domains [3] in both cases: vulnerable to a mitm: attacker captures first (non-ssl) request and redirects to bogus server (doing evil capturing stuff) Another issue not related to redirects: in case the client 'knows' it should authenticate to that particular rdap server, credentials are sent in clear Best regards, Pieter On 06/04/2013 11:58 PM, Marc Blanchet wrote: > hello, > please find an attempt to provide a solution to the "bootstrap" problem, i.e. finding the authoritative registration data server. I don't pretend this is fully baked but enough to get a good discussion going. Please comment. > > Regards, Marc. > > ================================ > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Finding the Authoritative Registration Data (RDAP) Server > Author(s) : Marc Blanchet > Filename : draft-blanchet-weirds-bootstrap-00.txt > Pages : 7 > Date : 2013-06-04 > > 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-blanchet-weirds-bootstrap > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > -- *Pieter Vandepitte* *Software Engineer* +32 16 29 89 27 *www.dnsbelgium.be* From edainow@afilias.info Thu Jun 13 11:28:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B879721F9A72 for ; Thu, 13 Jun 2013 11:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+UQSU53Kc3r for ; Thu, 13 Jun 2013 11:27:52 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8A21F9A3D for ; Thu, 13 Jun 2013 11:27:47 -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 1UnCFF-0006wa-59 for weirds@ietf.org; Thu, 13 Jun 2013 18:27:37 +0000 Received: from mail-oa0-f54.google.com ([209.85.219.54]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UnCFF-0001xF-4D for weirds@ietf.org; Thu, 13 Jun 2013 18:27:37 +0000 Received: by mail-oa0-f54.google.com with SMTP id o6so3660888oag.41 for ; Thu, 13 Jun 2013 11:27:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=aZKYF4mnRhwIJRT7eBeQEn+02BrxhKU1lfqnyfj0MsA=; b=KqIJdDrhNPOG3C2xeOOEBcX0yI0DMvEZ/qRSp4MeZlBEQSEFvZahszhsdtns6W752b XPW/VQEMR1nLYP5CnpHTYky1e0Osots9UdxetzAh6jdNU3cAUnJbgNrK/phcUzSgW5vu rMsHsZ/A/XXH9bNiZY+mvQCkXaBmxN81M8gvk7ptvU3abqnROd6SGX+673SAm0NpDbF1 RO8BtclpzIArwzRylDwwt/OQoktTAfMYsZtAXi8Wh+NF2ezSrzaNmZRnfoytc8AIH08W Uj1aRwWpjI7ZIqd7wGZ0+Jr9mAVHojXNzI5798oqS3xR7AyJJhPheHJwwsQtJomPsWL3 aGLA== X-Received: by 10.60.38.10 with SMTP id c10mr1637421oek.58.1371148049042; Thu, 13 Jun 2013 11:27:29 -0700 (PDT) X-Received: by 10.60.38.10 with SMTP id c10mr1637416oek.58.1371148048915; Thu, 13 Jun 2013 11:27:28 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id z5sm39837801obw.4.2013.06.13.11.27.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Jun 2013 11:27:27 -0700 (PDT) Message-ID: <51BA0F0B.5010104@afilias.info> Date: Thu, 13 Jun 2013 14:27:23 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> <51B9D15F.1010208@dnsbelgium.be> In-Reply-To: <51B9D15F.1010208@dnsbelgium.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnYQA6eY6OD59oDhCfHiUfL4Jwvqv4bY3wzAffMVHgTmvPvDtN7xtpdrfOA2xpecaMw+cwox7STSQAUFTZOx9O1yLLRkn3nLIIm5b/s9BVb3uiianskEYjzBjj4xadwNo/3pIar Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 18:28:11 -0000 A DNS solution based on A and CNAME records doesn't fully meet the RDAP requirement. It provides an IP address, which is not the same as a url. A provider may want to use the following scheme to host RDAP services for multiple TLDs on one server: rdap.info/tld1/ rdap.info/tld2/ In addition, there might be a requirement to support earlier versions of the protocol (if RDAP advances beyond 1.0) as rdap.info/tld1/1.0/ rdap.info/tld2/1.0/ All of these can be hosted on a single server with one IP address, using Virtual Hosting to direct each url to the right configuration. A DNS solution that only provides an IP address and not the url does not work. TXT records seem to be the only fit that can provide a simple url and http vs https access (sorry to bring this up, but I missed implied earlier discussions of TXT records). -Ernie On 6/13/2013 10:04 AM, Pieter Vandepitte wrote: > Another note on this solution... (not sure if already mentioned) > > there's no way of specifying the scheme in this solution. So, suppose > one wants to implement confidentiality, the only solution is to redirect > to an ssl host. > > Either to the same host > https://com.domain.rdap.arpa/domain/example.com > or to another > https://rdap.com/domain/example.com > > Issues: > [1] yet another redirect > [2] in the first case: not sure if one can request ssl certificates for > arpa domains > [3] in both cases: vulnerable to a mitm: attacker captures first > (non-ssl) request and redirects to bogus server (doing evil capturing stuff) > > Another issue not related to redirects: in case the client 'knows' it > should authenticate to that particular rdap server, credentials are sent > in clear > > Best regards, > > Pieter > > From kewisch@gmail.com Thu Jun 13 05:31:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD8121F99EC for ; Thu, 13 Jun 2013 05:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqdSQB3qn1Bk for ; Thu, 13 Jun 2013 05:31:42 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9EABD21F9A21 for ; Thu, 13 Jun 2013 05:31:41 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id je9so3636942bkc.32 for ; Thu, 13 Jun 2013 05:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=iqIfnfeZ8k3FeB7IfzDttfRHYZSDk2t1JfQSlQfUTRg=; b=gLReIwLERXlIP0L3OCNbrFpGFJpXImquKHZlKtZ2egqIYFCSZn4rjABUIgnJsgDh0Q v0DhpBVXDO4DqyKGyipHwuFwy5GkUmFU+J9SQoavJOaJa67iBqqz9hs0zr8lugpcHlr4 gG0MCXJVXBhY37O7IoNjkMctOhIV+BgLk2qdpVjCRKTS3Xy3zHUuCVFlob5Z4823AMAM bP2pz1OAzuU+aKvLmDyP3Tb5yQA0up7suM6g5ZYqARIvkKxQaj755o7Ryf7vQv3qTY47 N18+KJX+g7T6EZYKBuEzoCBqRbe+cnoB38VCYM2I1xaK9SNgaQ94u5A9E0Ujmuk1ruC+ eN6g== X-Received: by 10.204.190.7 with SMTP id dg7mr122500bkb.52.1371126700696; Thu, 13 Jun 2013 05:31:40 -0700 (PDT) Received: from oskar.local (tmo-110-196.customers.d1-online.com. [80.187.110.196]) by mx.google.com with ESMTPSA id tl1sm9353253bkb.7.2013.06.13.05.31.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Jun 2013 05:31:40 -0700 (PDT) Message-ID: <51B9BBAD.8050806@gmail.com> Date: Thu, 13 Jun 2013 14:31:41 +0200 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Simon Perreault , weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4E60@CHAXCH01.corp.arin.net> <51B9AEB0.5070103@viagenie.ca> In-Reply-To: <51B9AEB0.5070103@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 13 Jun 2013 11:45:44 -0700 Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 12:31:42 -0000 On 6/13/13 1:36 PM, Simon Perreault wrote: > Le 2013-06-13 12:29, Andy Newton a écrit : >> Maybe Simon could tell us what the original intent is for vCard >> streams. Is it so that multiple vCards can represent one person or >> org, or >> was it just to have a way to serialize multiple vCards for such purposes >> as transferring a contact database from one computer to another? > > Philipp would be the best person to answer this question. > > Simon Sorry, seems I missed this mail. Its meant for the latter, serializing multiple vCards for transfer. Philipp From gavin.brown@centralnic.com Thu Jun 13 12:33:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2117A21F9A9B for ; Thu, 13 Jun 2013 12:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.409 X-Spam-Level: *** X-Spam-Status: No, score=3.409 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4Dr2PCAa8DE for ; Thu, 13 Jun 2013 12:33:37 -0700 (PDT) Received: from smtp.centralnic.com (unknown [193.105.170.214]) by ietfa.amsl.com (Postfix) with ESMTP id 38F6B21F9AA3 for ; Thu, 13 Jun 2013 12:33:36 -0700 (PDT) Received: from [192.168.0.3] (unknown [2.123.110.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 5896972050A for ; Thu, 13 Jun 2013 19:33:33 +0000 (UTC) References: <20130610214336.72809.qmail@joyce.lan> <51B8BB5B.1060301@gmail.com> <8CEF048B9EC83748B1517DC64EA130FB7714A6C3CB@off-win2003-01.ausregistrygroup.local> <20130613125300.GI92752@registro.br> From: Gavin Brown Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (10B146) In-Reply-To: <20130613125300.GI92752@registro.br> Message-Id: <1EC60A5D-09D0-451A-A0F9-F96BACC798B3@centralnic.com> Date: Thu, 13 Jun 2013 20:33:34 +0100 To: "" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [weirds] Bootstrapping: performance issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 19:33:42 -0000 I think an HTTP based bootstrapping solution is the only one that will be ac= ceptable to client implementers. Scaling the server side is clearly a proble= m, but I would like to propose a solution. Let's say we have a well-known bootstrap URI (such as http://rdap.arpa/) whi= ch contains a domain which resolves to one or more addresses. These addresse= s could be anycasted, and advertised by multiple operators, in much the same= way that the AS112 system works. The DNS for the domain could also be anyca= sted. Participation would be voluntary, and operational policy would be based on c= onsensus among the operators (a la the root servers). The HTTP service would= be based on open source code. The number of instances could be tuned so that smaller operators don't carry= a disproportionate volume of traffic. Large operators already have anycast n= etworks that could be used for this purpose. Large consumers of RDAP data co= uld run a local instance to take load off the public operators. Anycasting of TCP services used to be problematic, but I know of a few that e= xist and work fairly well, especially for short-lived and easily cacheable s= ervices. I would prefer to use TLS (ie https://rdap.arpa/) but it's not clear to me h= ow this could scale to multiple operators without using multiple TLSA record= s. Naturally, rdap.arpa would be signed anyway. I think the above is cracking a walnut with a sledgehammer, but thought it w= orth discussing. --=20 Gavin Brown Chief Technology Officer CentralNic Ltd Innovative Registry Services for ccTLD and gTLD registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.= From pieter.vandepitte@dnsbelgium.be Thu Jun 13 13:20:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C29A21F95D7 for ; Thu, 13 Jun 2013 13:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhvLlkjqzKZK for ; Thu, 13 Jun 2013 13:20:33 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 2E17A21F999C for ; Thu, 13 Jun 2013 13:20:32 -0700 (PDT) Received: from lpieterv.dns.be (d54C08A4A.access.telenet.be [84.192.138.74]) by nug.nucleus.be (Postfix) with ESMTPSA id EFE80426000A; Thu, 13 Jun 2013 22:20:30 +0200 (CEST) Message-ID: <51BA298A.6030204@dnsbelgium.be> Date: Thu, 13 Jun 2013 22:20:26 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ernie Dainow References: <8BA4D754-4A21-4360-952D-A875D98ED01D@viagenie.ca> <51B9D15F.1010208@dnsbelgium.be> <51BA0F0B.5010104@afilias.info> In-Reply-To: <51BA0F0B.5010104@afilias.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 20:20:38 -0000 Ernie, I understand the concepts of virtual hosts and ip addresses, but as I understand from the first proposal, a client should lookup the ip address starting from example.com.rdap.arpa to com.rdap.arpa to find the ip address of the server and then send a http (not https) request with the name being looked up, as the host http header. I just wanted to emphasize the additional security issues (besides other issues) involved with that solution (and we should also do the same exercise for other solutions) I totally agree with you that a DNS IP address lookup is not the the way to go, but I'm not (yet) convinced that TXT is the answer. The main issue with the TXT record is the same as NAPTR: in-the-browser javascript clients can't yet perform TXT lookups. This was a non-issue for me, but not for everyone here (which i respect) A single point of failure rdap.org solution (who will operate it) is neither ideal (but i admit, simple for clients), especially when considering https to mitigate mitm attacks, this could cause a lot of traffic. The distributed xml file (or preferrably json) reminds me of an era when hosts files were ftp-ed, but i think that's the reason why dns was invented, so that's why my personal favorite is also some dns-like solution. Nevertheless, it's a simple and effective solution (and works for javascript in-the-browser clients). The file could become huge, especially with the gTLDs, but gzip and browser caching come to the rescue here. I have been thinking of other solutions, alas, no inspiration :-) Pieter On Thu 13 Jun 2013 08:27:23 PM CEST, Ernie Dainow wrote: > A DNS solution based on A and CNAME records doesn't fully meet the > RDAP requirement. It provides an IP address, which is not the same as > a url. > > A provider may want to use the following scheme to host RDAP services > for multiple TLDs on one server: > rdap.info/tld1/ > rdap.info/tld2/ > > In addition, there might be a requirement to support earlier versions > of the protocol (if RDAP advances beyond 1.0) as > rdap.info/tld1/1.0/ > rdap.info/tld2/1.0/ > > All of these can be hosted on a single server with one IP address, > using Virtual Hosting to direct each url to the right configuration. A > DNS solution that only provides an IP address and not the url does not > work. > > TXT records seem to be the only fit that can provide a simple url and > http vs https access (sorry to bring this up, but I missed implied > earlier discussions of TXT records). > > -Ernie > > > On 6/13/2013 10:04 AM, Pieter Vandepitte wrote: >> Another note on this solution... (not sure if already mentioned) >> >> there's no way of specifying the scheme in this solution. So, suppose >> one wants to implement confidentiality, the only solution is to redirect >> to an ssl host. >> >> Either to the same host >> https://com.domain.rdap.arpa/domain/example.com >> or to another >> https://rdap.com/domain/example.com >> >> Issues: >> [1] yet another redirect >> [2] in the first case: not sure if one can request ssl certificates for >> arpa domains >> [3] in both cases: vulnerable to a mitm: attacker captures first >> (non-ssl) request and redirects to bogus server (doing evil capturing >> stuff) >> >> Another issue not related to redirects: in case the client 'knows' it >> should authenticate to that particular rdap server, credentials are sent >> in clear >> >> Best regards, >> >> Pieter >> >> > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds -- *Pieter Vandepitte* *Software Engineer* +32 16 29 89 27 *www.dnsbelgium.be* From johnl@iecc.com Thu Jun 13 15:55:51 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4455021F9B3C for ; Thu, 13 Jun 2013 15:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.899 X-Spam-Level: X-Spam-Status: No, score=-110.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_44=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX73uqtxlwgf for ; Thu, 13 Jun 2013 15:55:47 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D4B8921F9B21 for ; Thu, 13 Jun 2013 15:55:46 -0700 (PDT) Received: (qmail 97037 invoked from network); 13 Jun 2013 22:55:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Jun 2013 22:55:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51ba4df1.xn--3zv.k1306; i=johnl@user.iecc.com; bh=KqSOAUwEje4AfzbuWBSLfYB5Wohg/VityTjkfo48qN0=; b=KKsQHEO6I029Jgvyc1XLf4WIR9pM47w4UibuLXamUj5n4xqlTWGoW7c4dLmclW625Pn82m8FLf5H3ueAWw3Txe5ZeeAe8+mjSShSWuFEkclwdT9xKEhi0g7l2FFGeQnO4YOZLbfQP3kavRb091W93/KVQ07lG4VNVqGV9TC23j+k80zvDGK3twrKRO73Ntv/w6bu9RbQzg5Jh0KAwNfTi4816u5Gl71pyur7SLpykKCwqfwXTaXk8FCzYPtrY2SK DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51ba4df1.xn--3zv.k1306; olt=johnl@user.iecc.com; bh=KqSOAUwEje4AfzbuWBSLfYB5Wohg/VityTjkfo48qN0=; b=XrenGI7WuwbMw4Yx7mqDEH+MZztCv97APoUmGt7QNzu/EbCNMDiO9VltR3ig5cHxzi4KBbpyYgfekzAt6cwNoEC2wc/R1iZ5QxVdW/GRijVKXMaNrdjSujCU5pYGkfDEsT02ZXcCO/3yVSB2Tc6jeyXj1VUEkmawnX2rUocSbJGZ5cNX+WCSBBhgtU5AFXCLR+Mu7CPPS3t2LOnpQZE3Q0r6PCogUoKuk+kBsfOcCL9SgGWjK0Vivx+fukpcW4CZ Date: 13 Jun 2013 22:55:23 -0000 Message-ID: <20130613225523.71669.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4E75@CHAXCH01.corp.arin.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] Bootstrapping: performance issues make http bootstrap impossible X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 22:55:51 -0000 >I agree with John, NAPTR/SRV would be the death of bootstrapping in RDAP. >It isn't successful and its time the IETF admitted that. I would be loath >to implement it in my NicInfo client, and I say that having implemented >S-NAPTR and U-NAPTR client code in the past (and having been co-author of >the S-NAPTR RFC). Thanks. Anyone who thinks that an HTTP bootstrap for names is plausible really needs to do the arithmetic. When I said 3000 queries/sec for Verisign and 3000 queries/day for small domains, those are real numbers, based on the monthly gTLD reports for February 2013 available on the ICANN web site. If you disagree with them, please show your work. That is a difference in query rates of roughly 100,000 to 1. DNS based load sharing, which is what a http bootstrap would use, sends similar amounts of traffic to each address. There isn't any way to send 99.99% of the traffic to one place and 0.001% to each of ten others. (No, you can't use 100,000 A records. Don't even think of proposing stunt DNS servers that serve up some names 100,000 more often than others.) If we wave our hands and imagine against experience that gTLDs and ccTLDs would cooperate closely enough to put different people's servers behind some kind of load sharing system, please describe an actual load sharing system that will split the work that asymmetrically. If you think you'll do it with anycast, same question, plus a bonus question about why you think that anycast works with TCP. As I said, only Verisign can handle that query rate, and I don't think anyone thinks a design that only works for Verisign would be acceptable. Again, if you disagree, please explain how your plan will work and handle the 100,000:1 ratio in query rates between large and small TLDs. A DNS A/AAAA/CNAME bootstrap like .rdap.arpa is entirely workable. Yes, it is a single point of failure, but I think it is reasonable to assume that rdap.arpa would be hosted on the same servers as in-addr.arpa which is served from six places around the world, maybe more if they use anycast. Everybody I know thinks that in-addr.arpa is plenty reliable. The suggestion to use a reserved name .tld, whether a pseudorandom hex name or something else would work technically, but it runs into the same problem as _srv.tld: the ICANN rules for new gTLDs don't allow non-glue A or AAAA records in the TLD zone. I also believe from experience that trying to reserve any host name in all TLDs, even a funny looking one that no TLD is currently using, will run into severe opposition in the IETF. R's, John PS: I understand CentralNIC's desire to make uk.com look like a pseudo-TLD without Verisign's cooperation, but that doesn't strike me as a problem that it is our job to solve, any more than it would be for my watkins-glen.ny.us without Neustar's help. If it works for all the TLDs that talk to IANA, i.e., ccTLDs, gTLDs, and the legacy TLDs, we've succeeded, and the policy boundaries are below the TLDs are local issues. From johnl@iecc.com Thu Jun 13 15:58:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545A621F9B3A for ; Thu, 13 Jun 2013 15:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.169 X-Spam-Level: X-Spam-Status: No, score=-111.169 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boA81qiCVp9W for ; Thu, 13 Jun 2013 15:58:24 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DDDC321F9B34 for ; Thu, 13 Jun 2013 15:58:23 -0700 (PDT) Received: (qmail 97649 invoked from network); 13 Jun 2013 22:58:23 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Jun 2013 22:58:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51ba4e8f.xn--yuvv84g.k1306; i=johnl@user.iecc.com; bh=vHz9A+cp5WjVT5F7NfvACpbzYBXkeYMPtZhJl2FcrZ0=; b=HIKKQNYyIvajAIDxQHvN6T3/qcvcCWF9Qh1eqWMP8u4M30riAhdgvOErBEq0jDffpoy7rGlvUeAx2geXOCL3q87LInZKQ/gVAWf5JlM01GTJmWqxr4UuRI3KVf/j4izOr2482R5G81TCBKpGeRqjIgIWuYY7PLMbyv23J2Ww7uYZx5lyxCYmFFHXFa4pymr8F/29pHwy9bMXf+mrq3nRodQqg0NNLGLkheknp1GTN6X6fZ0fswmIHRaWSo2W/15w DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51ba4e8f.xn--yuvv84g.k1306; olt=johnl@user.iecc.com; bh=vHz9A+cp5WjVT5F7NfvACpbzYBXkeYMPtZhJl2FcrZ0=; b=jsTzBFLoIFr+0nRg1z0uF6LCsT2eJpiCkJn73jSclWTYbHIa7oI8pWuR3FkkRMnCguHXgta6hbugeDpBPOik2PbZUQTVvE9NtkZlCJzMCoXxzUlMVZxo9un4KDCSMsR8Dj8I6KYziZfSkjb02stS4eaU1YepHaTKxBJcUUujTlzuX2JbcXIGK5qYRwzKgxSXZT1iIi9eIS4dbZNV8T2EdHAUwUoBbnqBVxlo2gnLkD3m1t4zN9IoM45STMuudDsT Date: 13 Jun 2013 22:58:00 -0000 Message-ID: <20130613225800.71691.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <51B9D15F.1010208@dnsbelgium.be> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 22:58:28 -0000 >there's no way of specifying the scheme in this solution. So, suppose >one wants to implement confidentiality, the only solution is to redirect >to an ssl host. You hard wire the scheme to be https on port 443. For the DNS lookups, DNSSEC is recommended where available. Problem solved. >[2] in the first case: not sure if one can request ssl certificates for >arpa domains There's nothing technically different about arpa. than any other TLD. Of course you can. For that matter, self-signed certificates are quite adequate to protect the channel, and if you want host verification, use DANE. R's, John From johnl@iecc.com Thu Jun 13 16:18:05 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998A521F9B2A for ; Thu, 13 Jun 2013 16:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.872 X-Spam-Level: X-Spam-Status: No, score=-110.872 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_44=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r6UF3f4g+td for ; Thu, 13 Jun 2013 16:18:01 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 67A7321F9B1A for ; Thu, 13 Jun 2013 16:18:01 -0700 (PDT) Received: (qmail 2028 invoked from network); 13 Jun 2013 23:17:59 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Jun 2013 23:17:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51ba5327.xn--9vv.k1306; i=johnl@user.iecc.com; bh=5lBlhKIO14VNpzrpM37vi/yKU2DTrfiB3a30KE2YLDw=; b=pM0E7mNMH7PYGRI8xOih60fpOAAE+i/1STDiMtedCivqhojTr4Behj8UUo/CjuQFjTtwMA9Lvv18Moe4yzj0Z2qMd0LRb7N70xA3wszaVWTEtSVdbXAm6ey/69dCofQDtMyUufOIbWhau7+Hamjx3Sg3yLp+47jxnGsQoOKSZYLal4gj47n4dKpJPlEn03d/KZGguda7M9nFPZej9UylK00rINOTOirJM04+bQhY16zCCfw3Gt3n6XUmQfAWEKqm DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51ba5327.xn--9vv.k1306; olt=johnl@user.iecc.com; bh=5lBlhKIO14VNpzrpM37vi/yKU2DTrfiB3a30KE2YLDw=; b=EeQWE87nGmsBtL7aLFz1EDIArctBQIIxrdR9VBy2ZfGWvxiRyjDcNginsHWL1K5aaqzF/nGMWQC0dxL5kiGmEiPSsgRayKiGOxFmWieyP2dhZ3/M1SNr8SS3ea3rJafm0NPZutdlpbWD+xj/dH2diPDgzI28k5HctdygJ90sWIbiqCI9TGTq4naIkxcv/0Ga2ZTf1YK0nqS3D0S5xf0aR/XgNFRuJZyrlyuT3Q38YsRr3QCeyK3AACzj+xL39pDS Date: 13 Jun 2013 23:17:37 -0000 Message-ID: <20130613231737.71757.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <51BA0F0B.5010104@afilias.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] principles of bootstraping X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 23:18:05 -0000 It's important to keep in mind that the point of a bootstrap is to get a client going as quickly as possible. There will probably be no more than 1000 different RDAP servers, and hundreds of thousands of RDAP clients. So any time there's a tradeoff between making the client more complex and making the server more complex, the correct answer is to make the client simple and the server complex, unless there is a really, really compelling reason to the contrary. This is an excellent example: >A provider may want to use the following scheme to host RDAP services >for multiple TLDs on one server: >rdap.info/tld1/ >rdap.info/tld2/ What is the functional benefit of requriring that every client in the world support arbitrary URLs in a bootstrap? Surely anyone competent to run a TLD is able to master http virtual hosting and put the information on https://tld1.domain.rdap.arpa/ and https://tld2.domain.rdap.arpa/. In this case, the only difference at the server is a few lines in the server config file and perhaps an extra SSL certificate. Same server, same IP addresses, same data. If you really like your rdap.info names, you can redirect from your rdap.arpa URLs, but I see no benefit from doing so. R's, John From pieter.vandepitte@dnsbelgium.be Thu Jun 13 22:17:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E4521F9BC1 for ; Thu, 13 Jun 2013 22:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XACrUofN9wC1 for ; Thu, 13 Jun 2013 22:17:01 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5921F9BC7 for ; Thu, 13 Jun 2013 22:17:00 -0700 (PDT) Received: from lpieterv.dns.be (d54C08A4A.access.telenet.be [84.192.138.74]) by nug.nucleus.be (Postfix) with ESMTPSA id 673424260003; Fri, 14 Jun 2013 07:16:58 +0200 (CEST) Message-ID: <51BAA74A.2040305@dnsbelgium.be> Date: Fri, 14 Jun 2013 07:16:58 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Levine References: <20130613225800.71691.qmail@joyce.lan> In-Reply-To: <20130613225800.71691.qmail@joyce.lan> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 05:17:11 -0000 Hi John Comments inline On 06/14/2013 12:58 AM, John Levine wrote: >> there's no way of specifying the scheme in this solution. So, suppose >> one wants to implement confidentiality, the only solution is to redirect >> to an ssl host. > > You hard wire the scheme to be https on port 443. For the DNS lookups, > DNSSEC is recommended where available. Problem solved. Me personal, i'm a https believer, so, great idea. not sure if we can sell that to the rest of the community > >> [2] in the first case: not sure if one can request ssl certificates for >> arpa domains > > There's nothing technically different about arpa. than any other TLD. > Of course you can. Technically speaking, yes. But i don't know the current policies applied by CA community. We will have to speak to them before we make a decision > > For that matter, self-signed certificates are quite adequate to > protect the channel, and if you want host verification, use DANE. DANE isn't currently supported in most browsers (in none so far i think). Second, it's a very bad idea to have self signed certificates. So a client now has to have a trust store with thousands of self signed certificates? Perhaps distributed in an XML file ;-) No seriously, this is not the way you want to go. Moreover, a javascript in-the-browser client is a requirement for some people here... Will people have to install self-signed certificates in the browser? Best regards Pieter > > R's, > John > > -- *Pieter Vandepitte* *Software Engineer* +32 16 29 89 27 *www.dnsbelgium.be* From johnl@taugh.com Fri Jun 14 05:10:00 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B7A21F9248 for ; Fri, 14 Jun 2013 05:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVAJPO25nvh7 for ; Fri, 14 Jun 2013 05:09:59 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1738C21F915B for ; Fri, 14 Jun 2013 05:09:58 -0700 (PDT) Received: (qmail 54293 invoked from network); 14 Jun 2013 12:09:58 -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:cleverness; s=d414.51bb0816.k1306; bh=mBAqjj2xVt1CJXp8RE+h80+ymwgSakptKLIjFCAOZYA=; b=RDcdb3kco/sqMlXSYbLV2w1PU4D+UcXZkMUKqtYhpz3Lq+jdDQ1gJo4xvAe2f3sEjNm+cOCnxa891oViqforiXP4OmTzfgg6vUIUoAMUzGZvR1y4hLPTb/pPk01gDI8/w2QkbasepfbFR9MIaY8TlqpOAs+VMIMkhs3Y37PsNa0ovCrnslXvIOEhDwgO6uBYyJb+T4H+Bx7attk6Lfm++DMLNRz6JosSvgf9peyROUpgsZ+mSH4XregCDLLPjh8O 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:cleverness; s=d414.51bb0816.k1306; bh=mBAqjj2xVt1CJXp8RE+h80+ymwgSakptKLIjFCAOZYA=; b=KFJAyKwiq2bGBrlafMdlpM8RYLu630Bwr9AL/JgIUi+Yw0abaKqB2Td8NyaI1oynAYTuUTtKHFyPoBP9p+xE9FRmlGGsr4I4umCsKbhunF43INTAy0mbfRZK8fbAx6ZViVlhqVwsomDlD0bOToFjOEszIXcXADsNCAwpDSto5nxFXCKAPKyH0Bae4L5DP1Wb6BtpF7bg3ap2KSarQhiSm2G9xqDZqj7fjwwvW/2sMmGdc2pqS85V11OKxZVs/dmk Received: (ofmipd 127.0.0.1); 14 Jun 2013 12:09:36 -0000 Date: 14 Jun 2013 08:09:57 -0400 Message-ID: From: "John R Levine" To: "Pieter Vandepitte" In-Reply-To: <51BAA74A.2040305@dnsbelgium.be> References: <20130613225800.71691.qmail@joyce.lan> <51BAA74A.2040305@dnsbelgium.be> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1407376829-1371211798=:79145" Cc: weirds@ietf.org Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 12:10:00 -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. --3825401791-1407376829-1371211798=:79145 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> You hard wire the scheme to be https on port 443. For the DNS lookups, >> DNSSEC is recommended where available. Problem solved. > > Me personal, i'm a https believer, so, great idea. not sure if we can > sell that to the rest of the community Unless someone offers a compelling reason that they cannot support https, I think we're OK there. >> For that matter, self-signed certificates are quite adequate to >> protect the channel, and if you want host verification, use DANE. > > DANE isn't currently supported in most browsers (in none so far i > think). Second, it's a very bad idea to have self signed certificates. No, it's not. As I said in the message you were responding to, self-signed certs handle the issue of snooping on the http traffic. If you want to authenticate the server, either you get a CA signed cert (which I really don't think is a big deal) or you nag your client provider to get with the program and implement DANE. John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1407376829-1371211798=:79145 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjE0MTIwOTU3WjAjBgkqhkiG 9w0BCQQxFgQUNt/anhwclozHMJYst9V2MgyTEZIweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAbcwL3mF7xUry Hg6APZ9aPIfQsYwgQxmivo9DzmynBF+6YAFlsJIjIugelkwZH0/dtRDuzKKP HcGPoSc43gGhfeHczjoPn+veVEZk0MWMjGIC7b7dR6FAO5fHREt6jcwD+Yr5 eEVMXWd+2cDPzvttxcS98+F6PsY6qlYUMEdb3nPxot6J1pgEDwvQncCJr6Ty sbH31noyVvr/M3OBBS1KDZrHU1/jzxlVtwuPp1/ldkSLOUSzwAp6MXgCdxTc FiCAWz/v088L9A1vuYqoOS4qgIKV7zEKb3fk8bpja4t06RT91r281ME0lU5z 3whkydyfAKbkVKCz0MdoygxQWRxrgA== --3825401791-1407376829-1371211798=:79145-- From presnick@qti.qualcomm.com Fri Jun 14 08:01:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA70F21F9944 for ; Fri, 14 Jun 2013 08:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7x2dVFoiJ2b for ; Fri, 14 Jun 2013 08:01:36 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 6887F21F9CD6 for ; Fri, 14 Jun 2013 08:01:36 -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=1371222096; x=1402758096; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=qt+HXD7xDoK7qQ1qtsrg0xO7J3N+XodEUl/8LYIXTk0=; b=veEMusPsKAyt5YaMOrEoPiKTA+D0j9ByIziu8VGvesbJp2+Xcz4WxB1j TeZQvdNhlRhf62iwq5j+B2oOK77DpdnFNa9yL4DzNRnYdxN/vFqbndqiS I3HHMgsZwFZudyv8FJH0nWtB5iLBTmCgDS5rw52JFRwT9khbiXEn9XlTM M=; X-IronPort-AV: E=Sophos;i="4.87,866,1363158000"; d="scan'208";a="45101096" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 14 Jun 2013 08:01:35 -0700 Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Jun 2013 08:01:35 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 14 Jun 2013 08:01:35 -0700 Message-ID: <51BB304C.8050304@qti.qualcomm.com> Date: Fri, 14 Jun 2013 10:01:32 -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: , Olaf Kolkman References: <51A618F4.8020802@qti.qualcomm.com> In-Reply-To: <51A618F4.8020802@qti.qualcomm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 15:01:40 -0000 So, where are we with this document? I think all of my questions were answered and it sounded like the WG was moving toward some changes, but I haven't seen a new version yet. I'm holding off on the Last Call for the -sec document (which is ready to go) so that I can send the two together. I'll mark this in the tracker as "Revised ID Needed" so that it reminds me when you create a new version. But let's move this along. Do you need anything else from me? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From andy@arin.net Fri Jun 14 08:58:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435EA21F9CEE for ; Fri, 14 Jun 2013 08:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.169 X-Spam-Level: X-Spam-Status: No, score=-4.169 tagged_above=-999 required=5 tests=[AWL=-1.570, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdEpURKkyiyU for ; Fri, 14 Jun 2013 08:58:08 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 49F7921F9CDE for ; Fri, 14 Jun 2013 08:58:08 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id B24A1213649; Fri, 14 Jun 2013 11:58:07 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id C513721364C; Fri, 14 Jun 2013 11:57:57 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 14 Jun 2013 11:57:57 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 14 Jun 2013 11:57:55 -0400 From: Andy Newton To: Pete Resnick , "weirds@ietf.org" , Olaf Kolkman Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 Thread-Index: AQHOXH3gY3KwLlQTlUSonTV+sXMu85k1qi4A///MsgA= Date: Fri, 14 Jun 2013 15:57:55 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF6937@CHAXCH01.corp.arin.net> In-Reply-To: <51BB304C.8050304@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.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <962C5CBF8DD36F4C960631A5820F201F@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 15:58:12 -0000 Thanks Pete. We'll get cracking on a new version of the draft. -andy On 6/14/13 11:01 AM, "Pete Resnick" wrote: >So, where are we with this document? I think all of my questions were >answered and it sounded like the WG was moving toward some changes, but >I haven't seen a new version yet. I'm holding off on the Last Call for >the -sec document (which is ready to go) so that I can send the two >together. > >I'll mark this in the tracker as "Revised ID Needed" so that it reminds >me when you create a new version. But let's move this along. Do you need >anything else from me? > >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 bje@apnic.net Sun Jun 16 19:30:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB8B21F859B for ; Sun, 16 Jun 2013 19:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.757 X-Spam-Level: * X-Spam-Status: No, score=1.757 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_44=0.6, J_CHICKENPOX_84=0.6, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPTI-8Gfg9ys for ; Sun, 16 Jun 2013 19:30:06 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id E0B5621F8ECE for ; Sun, 16 Jun 2013 19:30:04 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Mon, 17 Jun 2013 12:29:59 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a%19]) with mapi id 14.01.0421.002; Mon, 17 Jun 2013 12:30:00 +1000 From: Byron Ellacott To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Bootstrapping: performance issues make http bootstrap impossible Thread-Index: AQHOawKQQbbcMtEoo0exv8/GGIBIqQ== Date: Mon, 17 Jun 2013 02:29:59 +0000 Message-ID: In-Reply-To: <20130613225523.71669.qmail@joyce.lan> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.148] Content-Type: text/plain; charset="us-ascii" Content-ID: <75682ECCCA6DD941A926D318EDA4981F@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Bootstrapping: performance issues make http bootstrap impossible X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 02:30:10 -0000 Hi John, On 14/06/13 8:55 AM, "John Levine" wrote: >If we wave our hands and imagine against experience that gTLDs and >ccTLDs would cooperate closely enough to put different people's >servers behind some kind of load sharing system, please describe an >actual load sharing system that will split the work that >asymmetrically. If you think you'll do it with anycast, same >question, plus a bonus question about why you think that anycast works >with TCP. Bonus answer: dig +tcp txt chaos hostname.bind @k.root-servers.net ? The routing system is more stable than you may be giving it credit for :-) This is an irrelevant tangent; I agree with your point. >A DNS A/AAAA/CNAME bootstrap like .rdap.arpa is entirely >workable. Yes, it is a single point of failure, but I think it is >reasonable to assume that rdap.arpa would be hosted on the same >servers as in-addr.arpa which is served from six places around the >world, maybe more if they use anycast. Everybody I know thinks that >in-addr.arpa is plenty reliable. Thanks for the vote of confidence in our reliability! The current operators of ?.in-addr-servers.arpa are ICANN and the five RIRs. APNIC carries a peak of ~1,800 qps on e.in-addr-servers.arpa, anycast across three locations (tangentially, < 50qps on TCP) - I don't think serving ~1,000 qps for rdap.arpa bootstrap would be a problem for us, though I can't speak for ICANN or the other RIRs of course. You'd presumably be looking at an IANA process to maintain the zone file? Byron (Speaking predominantly for myself, but in my capacity as APNIC's Technical Director when stating that APNIC could handle rdap.arpa DNS queries) From johnl@taugh.com Sun Jun 16 20:21:49 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D504921F9DF6 for ; Sun, 16 Jun 2013 20:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX1sIzBUhh8K for ; Sun, 16 Jun 2013 20:21:47 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2185E21F9DF3 for ; Sun, 16 Jun 2013 20:21:46 -0700 (PDT) Received: (qmail 53366 invoked from network); 17 Jun 2013 03:21: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:cleverness; s=d074.51be80c8.k1306; bh=TsUh39G9ykWTb60XINL0+rE01onk0ykeVgp9VnzWFaQ=; b=juC7Cgk28u5O+00jFLQqW0IG4NXPt5WiR+1s5NXIzCSOjS3Y80BhhHgRqHEFL6W01/4WPAAKLJwhF2d8htFY1qY1+/c6T3fkqyyADOh1VuqQuyWM7QOcBR1zTpwfb2e3Y3DoTHzFLkmSA4W8fpt5ftdEobO5PL7C3adoYkrHoxYkTzRbvVL317KZmXUUf5uzS93ugVP+/ZXOHRUiQIjc+k/XVNhiE6mUyRgj2w7X6wA3YiLRjBST2LVK5oz94RO5 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:cleverness; s=d074.51be80c8.k1306; bh=TsUh39G9ykWTb60XINL0+rE01onk0ykeVgp9VnzWFaQ=; b=sB0/cs0gFYzLpMFP3akanCsM+sKY0IesJr9skcjsM9F56Y0HPc3elK3ZiGij9rpALUDOI83UCmN9q4Ggx/bMgBy8aO3Au9K2RMno50oByk68egbUoFzEtrHRAA/z62msnkaBY95+7W9GkIQSQycUfdh9zYmdJ7B/s64ins7x85cHt5R3bRL5Bmtb4S4ULwW4GKx8eaQaprCbnADfsc/a7YdhSioN1AiMRyaZNmaLqg+2fKGAiE9jnKG6EQBN0TLs Received: (ofmipd 127.0.0.1); 17 Jun 2013 03:21:22 -0000 Date: 16 Jun 2013 23:21:44 -0400 Message-ID: From: "John R Levine" To: "Byron Ellacott" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] Bootstrapping: performance issues make http bootstrap impossible X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 03:21:49 -0000 > The current operators of ?.in-addr-servers.arpa are ICANN and the five > RIRs. APNIC carries a peak of ~1,800 qps on e.in-addr-servers.arpa, > anycast across three locations (tangentially, < 50qps on TCP) - I don't > think serving ~1,000 qps for rdap.arpa bootstrap would be a problem for > us, though I can't speak for ICANN or the other RIRs of course. You'd > presumably be looking at an IANA process to maintain the zone file? I expect that ordinary DNS caches will make the DNS query rate considerably less than the 3000 whois/sec that .COM sees. It is my impression that most of the load comes from relatively few clients who send a lot of queries and so will get most of their DNS answers from their local cache. If someone from Verisign is listening, the DNS query rate for whois.verisign-grs.com would be a reasonable estimate of the load. All of the TLDs already have relationships with IANA to manage their name servers and contact info, and line 8b of the template already asks for the name of their WHOIS server. I'd expect the name (for CNAME) or addresses (A/AAAA) of the RDAP server could be another item added to the existing database. If you're hinting that it would be a good idea to check with IANA to ensure that this presents no unexpected administrative problems, I completely agree. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From ggm@algebras.org Sun Jun 16 21:24:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D54E21F9F2D for ; Sun, 16 Jun 2013 21:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoSJgS3QaSJe for ; Sun, 16 Jun 2013 21:24:34 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1F34721F9F2C for ; Sun, 16 Jun 2013 21:24:34 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro2so2345972pbb.13 for ; Sun, 16 Jun 2013 21:24:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZdLaXWP//Pq0T5AaQgcllscu2sbSVg3SIOUtVkLKfgc=; b=nFyNavmDTEkkAYUUWducLE6xbcFU5VvpRRcIPZwCCWaeqyJMbjkReXaM/RSE08aYXI CoOYDi5mmyQaJAipy/cQUwgCWo0yoxszBtIHsA0b6W8vzcp9lTFemlCrt600iYA6ULz3 zksCy9fzz2qE36BC86blip4r461Z3N8qOje8N2yIwimaylCp05YYClMYVsYmpHPnmyuC XDUK0EXvnmOGp8VzRTt97lOiiNXR1idbn9kvCZpyrxVDZHoLkclKMOadPeafsE3rEb+i E5uG212Hq3YBWnOHna9BuATYMP8xHg67Uvm7nft9uwwWW3/8pWEU70cfU5BVTNjoO55K rOzg== MIME-Version: 1.0 X-Received: by 10.66.121.202 with SMTP id lm10mr3626331pab.216.1371443073760; Sun, 16 Jun 2013 21:24:33 -0700 (PDT) Received: by 10.70.25.195 with HTTP; Sun, 16 Jun 2013 21:24:33 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:584e:1528:ba68:64c1] In-Reply-To: References: Date: Mon, 17 Jun 2013 14:24:33 +1000 Message-ID: From: George Michaelson To: John R Levine Content-Type: multipart/alternative; boundary=047d7b41b7ec3dd2bd04df51f9c9 X-Gm-Message-State: ALoCoQnF/4/HcLhHbdmE1YezNDSBHSt/IwqIIXcz+oq0H9b5Y17wjxG+9STVr3uVlUwVJcRO8QmN Cc: "weirds@ietf.org" Subject: Re: [weirds] Bootstrapping: performance issues make http bootstrap impossible X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 04:24:35 -0000 --047d7b41b7ec3dd2bd04df51f9c9 Content-Type: text/plain; charset=ISO-8859-1 I took Byron's comments in the sense that a discovery anchor which has to handle internet-wide load is a good fit for anycast services, which we already cooperate in as a delagete under IANA, alongside ICANN investment in an anycast mesh for in-addr.arpa. There is an investment in systems, and cooperation already in place. When you consider that the number space is a significant part of the RDAP information space, it makes sense for us to self-organize to manage this discovery load, and it seems like a reasonable place to ask: is this something we might do for wider community benefit, as a 'for the internet' type thing? -George On Mon, Jun 17, 2013 at 1:21 PM, John R Levine wrote: > The current operators of ?.in-addr-servers.arpa are ICANN and the five >> RIRs. APNIC carries a peak of ~1,800 qps on e.in-addr-servers.arpa, >> anycast across three locations (tangentially, < 50qps on TCP) - I don't >> think serving ~1,000 qps for rdap.arpa bootstrap would be a problem for >> us, though I can't speak for ICANN or the other RIRs of course. You'd >> presumably be looking at an IANA process to maintain the zone file? >> > > I expect that ordinary DNS caches will make the DNS query rate > considerably less than the 3000 whois/sec that .COM sees. It is my > impression that most of the load comes from relatively few clients who send > a lot of queries and so will get most of their DNS answers from their local > cache. If someone from Verisign is listening, the DNS query rate for > whois.verisign-grs.com would be a reasonable estimate of the load. > > All of the TLDs already have relationships with IANA to manage their name > servers and contact info, and line 8b of the template already asks for the > name of their WHOIS server. I'd expect the name (for CNAME) or addresses > (A/AAAA) of the RDAP server could be another item added to the existing > database. > > If you're hinting that it would be a good idea to check with IANA to > ensure that this presents no unexpected administrative problems, I > completely agree. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > > ______________________________**_________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/**listinfo/weirds > --047d7b41b7ec3dd2bd04df51f9c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I took Byron's comments in the sense that a discovery = anchor which has to handle internet-wide load is a good fit for anycast ser= vices, which we already cooperate in as a delagete under IANA, alongside IC= ANN investment in an anycast mesh for in-addr.arpa. There is an investment = in systems, and cooperation already in place.

When you consider that the number space is a significant part of the RD= AP information space, it makes sense for us to self-organize to manage this= discovery load, and it seems like a reasonable place to ask: is this somet= hing we might do for wider community benefit, as a 'for the internet= 9; type thing?

-George

On Mon, Jun 17, 2013 at 1:21 PM, John R Lev= ine <johnl@taugh.com> wrote:
The current operators of ?.in-addr-servers.arpa are ICANN and the five
RIRs. =A0APNIC carries a peak of ~1,800 qps on e.in-addr-servers.arpa,
anycast across three locations (tangentially, < 50qps on TCP) - I don= 9;t
think serving ~1,000 qps for rdap.arpa bootstrap would be a problem for
us, though I can't speak for ICANN or the other RIRs of course. =A0You&= #39;d
presumably be looking at an IANA process to maintain the zone file?

I expect that ordinary DNS caches will make the DNS query rate considerably= less than the 3000 whois/sec that .COM sees. =A0It is my impression that m= ost of the load comes from relatively few clients who send a lot of queries= and so will get most of their DNS answers from their local cache. =A0If so= meone from Verisign is listening, the DNS query rate for whois.verisign-grs.com would = be a reasonable estimate of the load.

All of the TLDs already have relationships with IANA to manage their name s= ervers and contact info, and line 8b of the template already asks for the n= ame of their WHOIS server. =A0I'd expect the name (for CNAME) or addres= ses (A/AAAA) of the RDAP server could be another item added to the existing= database.

If you're hinting that it would be a good idea to check with IANA to en= sure that this presents no unexpected administrative problems, I completely= agree.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

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

--047d7b41b7ec3dd2bd04df51f9c9-- From johnl@taugh.com Sun Jun 16 21:49:18 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE3821F99A0 for ; Sun, 16 Jun 2013 21:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d02HFMwbyZV2 for ; Sun, 16 Jun 2013 21:49:17 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 821BE21F999C for ; Sun, 16 Jun 2013 21:49:17 -0700 (PDT) Received: (qmail 68501 invoked from network); 17 Jun 2013 04:49:09 -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:cleverness; s=10b94.51be9545.k1306; bh=cn+u0wvlV/4dFaoKEZ2c79jNZsGdNZCIUaVRt+md05Q=; b=Gre3Kz3awH7PuH90OdDLk9ttVx95MujHyZF4aAjk6Wny9UXIliH2YHLCOkt62nHGG+kHmltWHpUmBT0TgNf72t6saqgr2cehi16vIWKvu9sIUVtYwU8nyIVL41cwVDpZ9YHSjqetetCxf26DdR0HlHMADs7eW0HjZu3ZJtrQa69tSdfgTKSRmcMDIYld7kxjSbXERbY8zuxSdx53NqCbiug+eKyV2T2isHOPHRGk6Q9aga8DH1UVPyOi21e2mcqk 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:cleverness; s=10b94.51be9545.k1306; bh=cn+u0wvlV/4dFaoKEZ2c79jNZsGdNZCIUaVRt+md05Q=; b=R6x/8yfaDfPskkYGMH54bZdgoSTckXahnWqBlqJlIwTrMVu1L2zU0SDBMRoQMGFcqtTpl5BDwraAExv/zxoNj9Zyw2dmttlK9TyoXc0V9NSWGC79tOWrjFnjqxWQwxfWZleP7SgsjTua6wWpBiO/JMcGqp7qy4Hb5ytLgQfthuue0YcLmmzLCQvccfIElruhvoyZz7xDBrVrNH2XFyzlrJVEDxkXNjKNPmRmECcb6cPv+uVjhlPi0BA912e0yB8z Received: (ofmipd 127.0.0.1); 17 Jun 2013 04:48:47 -0000 Date: 17 Jun 2013 00:49:09 -0400 Message-ID: From: "John R Levine" To: "George Michaelson" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "weirds@ietf.org" Subject: Re: [weirds] Bootstrapping: performance issues make http bootstrap impossible X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 04:49:18 -0000 > When you consider that the number space is a significant part of the RDAP > information space, it makes sense for us to self-organize to manage this > discovery load, and it seems like a reasonable place to ask: is this > something we might do for wider community benefit, as a 'for the internet' > type thing? I don't entirely understand what you're suggesting, but it seems to me that numbers can bootstrap from a pool of RIR RDAP servers, and names can boostrap from .domain.rdap.arpa, so there's no need for anything more complicated. If in-addr.arpa is anycasted and rdap.arpa can piggyback on that infrastructure, that's great, but please let's avoid the black hole of overgenerality. If you look around the IETF, you'll find that the graveyard is full of excessively general discovery mechanisms. The current webfinger effort is a good bad example, with what was supposed to be a lightweight way to autoconfigure mail clients now groaning under the weight of far too much stuff you can ask about via overgeneralized URLs. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From pieter.vandepitte@dnsbelgium.be Mon Jun 17 00:37:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B8B21F9AD1 for ; Mon, 17 Jun 2013 00:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6aAw9PguGIu for ; Mon, 17 Jun 2013 00:37:39 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 5348821F9AD7 for ; Mon, 17 Jun 2013 00:37:36 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 5B9784260063 for ; Mon, 17 Jun 2013 09:37:34 +0200 (CEST) Message-ID: <51BEBCBE.5070004@dnsbelgium.be> Date: Mon, 17 Jun 2013 09:37:34 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <20130613225800.71691.qmail@joyce.lan> <51BAA74A.2040305@dnsbelgium.be> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 07:37:44 -0000 Hi John, I 100% agree with you that DANE could provide a solution. But as i mentioned in a previous post, it isn't supported by browsers and it will take many years to be widely deployed, so it isn't a solution for those who want to write clients in-the-browser. Second, I feel some resistance to implement NAPTR in the clients because of complexity, but to be honest, I don't see any difference in complexity with DANE. So, this would disprove the argument that the A-record solution is a much simpler solution. Anyway, as I understand from you, CA's currently don't have business rules on the supported tld's, so anything above should be theoretical kr, Pieter On 06/14/2013 02:09 PM, John R Levine wrote: >>> You hard wire the scheme to be https on port 443. For the DNS lookups, >>> DNSSEC is recommended where available. Problem solved. >> >> Me personal, i'm a https believer, so, great idea. not sure if we can >> sell that to the rest of the community > > Unless someone offers a compelling reason that they cannot support > https, I think we're OK there. > >>> For that matter, self-signed certificates are quite adequate to >>> protect the channel, and if you want host verification, use DANE. >> >> DANE isn't currently supported in most browsers (in none so far i >> think). Second, it's a very bad idea to have self signed certificates. > > No, it's not. > > As I said in the message you were responding to, self-signed certs > handle the issue of snooping on the http traffic. If you want to > authenticate the server, either you get a CA signed cert (which I really > don't think is a big deal) or you nag your client provider to get with > the program and implement DANE. > > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. -- *Pieter Vandepitte* *Software Engineer* +32 16 29 89 27 *www.dnsbelgium.be* From andy@arin.net Mon Jun 17 03:06:25 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E10C21F9B9E for ; Mon, 17 Jun 2013 03:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.726 X-Spam-Level: X-Spam-Status: No, score=-3.726 tagged_above=-999 required=5 tests=[AWL=-1.727, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oRiW7Ipwz-a for ; Mon, 17 Jun 2013 03:06:20 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 062B921F9BA2 for ; Mon, 17 Jun 2013 03:06:20 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 74199213644; Mon, 17 Jun 2013 06:06:19 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id D380621360C; Mon, 17 Jun 2013 06:06:18 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 17 Jun 2013 06:05:53 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 06:05:52 -0400 From: Andy Newton To: John R Levine Thread-Topic: [weirds] Bootstrapping: performance issues make http bootstrap impossible Thread-Index: AQHOaxYJ/KaFWWRijEW+BUW8DYeQ1pk5rlMA Date: Mon, 17 Jun 2013 10:05:52 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF6EFB@CHAXCH01.corp.arin.net> 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.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <7A29CCAC8B55174CAA98A5271F3D8D4F@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Bootstrapping: performance issues make http bootstrap impossible X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 10:06:25 -0000 On 6/17/13 12:49 AM, "John R Levine" wrote: > >If you look around the IETF, you'll find that the graveyard is full of >excessively general discovery mechanisms. I couldn't agree more. That's why I think the IANA registries approach is the best solution. It is simple, and it can be the basis for the more complicated rdap.arpa or rdap-servers.org solution. And it allows those interested in writing higher performance clients to skip that first hop. -andy From shollenbeck@verisign.com Tue Jun 18 04:30:34 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DA221F9ECE for ; Tue, 18 Jun 2013 04:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR4+nOkSPZ1H for ; Tue, 18 Jun 2013 04:30:29 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id F282C21F9EA7 for ; Tue, 18 Jun 2013 04:30:28 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUcBE1NrBNum40N9o801zQvYejzVSGh3q@postini.com; Tue, 18 Jun 2013 04:30:29 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 r5IBUPw6000861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Jun 2013 07:30:28 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 18 Jun 2013 07:30:25 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: I-D Action: draft-hollenbeck-weirds-rdap-search-02.txt Thread-Index: AQHObBZ6RLT5ffHEY0yn9ro3IkSpN5k7ViNA Date: Tue, 18 Jun 2013 11:30:24 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243AD125@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130618112446.11902.20472.idtracker@ietfa.amsl.com> In-Reply-To: <20130618112446.11902.20472.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 Subject: [weirds] FW: I-D Action: draft-hollenbeck-weirds-rdap-search-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:30:34 -0000 This version adds Unicode processing text based on discussions that took pl= ace during and after IETF-86 in Orlando. Scott -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Tuesday, June 18, 2013 7:25 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-hollenbeck-weirds-rdap-search-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Registration Data Access Protocol Basic Search Processin= g Author(s) : Scott Hollenbeck Andrew Lee Newton Filename : draft-hollenbeck-weirds-rdap-search-02.txt Pages : 8 Date : 2013-06-18 Abstract: This document describes path segments and query parameters needed to construct HTTP URLs that may be used to search for and retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. It also describes a method of encoding responses using Javascript Object Notation (JSON). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-search There's also a htmlized version available at: http://tools.ietf.org/html/draft-hollenbeck-weirds-rdap-search-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-hollenbeck-weirds-rdap-search-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 internet-drafts@ietf.org Tue Jun 18 08:14:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E731921E8085; Tue, 18 Jun 2013 08:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ5+-kg5DsSz; Tue, 18 Jun 2013 08:14:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D6821E8087; Tue, 18 Jun 2013 08:14:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130618151437.14924.99781.idtracker@ietfa.amsl.com> Date: Tue, 18 Jun 2013 08:14:37 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-06.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 15:14:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : HTTP usage in the Registration Data Access Protocol (RDA= P) Author(s) : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-06.txt Pages : 16 Date : 2013-06-18 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). 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-using-http-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nkong@cnnic.cn Tue Jun 18 08:23:36 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D6A21F9BB4 for ; Tue, 18 Jun 2013 08:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[AWL=1.465, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCTZFXmlc0Xr for ; Tue, 18 Jun 2013 08:23:32 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id CE78821F9B99 for ; Tue, 18 Jun 2013 08:23:04 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [192.168.1.102]) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 18 Jun 2013 23:22:43 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ning Kong In-Reply-To: <51BB304C.8050304@qti.qualcomm.com> Date: Tue, 18 Jun 2013 23:22:42 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <97EE910A-5C83-451A-A2DF-EA990B25AD3F@cnnic.cn> References: <51A618F4.8020802@qti.qualcomm.com> <51BB304C.8050304@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1508) Cc: weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 15:23:36 -0000 Hi Pete, I just posted draft-ietf-weirds-using-http-06 to address your comments. = Any further comments are appreciated. Cheers, Ning > So, where are we with this document? I think all of my questions were = answered and it sounded like the WG was moving toward some changes, but = I haven't seen a new version yet. I'm holding off on the Last Call for = the -sec document (which is ready to go) so that I can send the two = together. >=20 > I'll mark this in the tracker as "Revised ID Needed" so that it = reminds me when you create a new version. But let's move this along. Do = you need anything else from me? >=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 presnick@qti.qualcomm.com Tue Jun 18 08:33:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2844E21E8083 for ; Tue, 18 Jun 2013 08:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vQnZAfk0VHW for ; Tue, 18 Jun 2013 08:33:04 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id F3EA721E8054 for ; Tue, 18 Jun 2013 08:33:03 -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=1371569583; x=1403105583; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FzTnkkdqxPAueLG5CA7l7RL6Isq0xAUUy5Mvs5TrCu8=; b=LsGfh8hnjbP/o+YDpdvtuB1WoVyOJTyhP9qYZa80buVmzlOsMyRKV/KX jgw+d3QdFgn1bckUrjAOrTkwN7Zt2nHKiyxX7377LTUdan9TjIwrpft7U jsZU97F8feTCK1BhQoRH332zTTwmZgtDdvq8K1YVbafa+H1Sqv58kknx+ M=; X-IronPort-AV: E=Sophos;i="4.87,890,1363158000"; d="scan'208";a="57424459" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 18 Jun 2013 08:33:03 -0700 X-IronPort-AV: E=Sophos;i="4.87,889,1363158000"; d="scan'208";a="466776030" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Jun 2013 08:33:03 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 18 Jun 2013 08:33:02 -0700 Message-ID: <51C07DAC.9080501@qti.qualcomm.com> Date: Tue, 18 Jun 2013 10:33:00 -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: Ning Kong References: <51A618F4.8020802@qti.qualcomm.com> <51BB304C.8050304@qti.qualcomm.com> <97EE910A-5C83-451A-A2DF-EA990B25AD3F@cnnic.cn> In-Reply-To: <97EE910A-5C83-451A-A2DF-EA990B25AD3F@cnnic.cn> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 15:33:08 -0000 On 6/18/13 10:22 AM, Ning Kong wrote: > I just posted draft-ietf-weirds-using-http-06 to address your comments. Any further comments are appreciated. > Two weeks ago, you sent the following message. On 6/5/13 9:18 PM, Ning Kong wrote: > We agree that this document should be a more generic HTTP draft. So we'd like to remove the MUSTs from section 4.1. > > If WG agree with that direction, we'd like to check and modify the wording of JSON in the whole draft soon. > I see that the new draft still has MUSTs for JSON in section 4.1, still defines the registry for JSON responses, and still has no normative reference to the -json-response document. The other changes look fine, but the genericizing activity does not seem done. Is there some reason for this? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nkong@cnnic.cn Tue Jun 18 09:24:47 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F310E21F9B05 for ; Tue, 18 Jun 2013 09:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=1.221, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cproYtbz6kjC for ; Tue, 18 Jun 2013 09:24:41 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 9599421E8091 for ; Tue, 18 Jun 2013 09:24:35 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [192.168.1.102]) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 19 Jun 2013 00:24:25 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ning Kong In-Reply-To: <51C07DAC.9080501@qti.qualcomm.com> Date: Wed, 19 Jun 2013 00:24:25 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51A618F4.8020802@qti.qualcomm.com> <51BB304C.8050304@qti.qualcomm.com> <97EE910A-5C83-451A-A2DF-EA990B25AD3F@cnnic.cn> <51C07DAC.9080501@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1508) Cc: weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 16:24:47 -0000 Hi Pete, > On 6/5/13 9:18 PM, Ning Kong wrote: >> We agree that this document should be a more generic HTTP draft. So = we'd like to remove the MUSTs from section 4.1. >>=20 >> If WG agree with that direction, we'd like to check and modify the = wording of JSON in the whole draft soon. >> =20 >=20 > I see that the new draft still has MUSTs for JSON in section 4.1, = still defines the registry for JSON responses, and still has no = normative reference to the -json-response document. The other changes = look fine, but the genericizing activity does not seem done. Is there = some reason for this? Sorry for not clarifying this issue in advance. Based on the recent discussions on this thread, there is a consensus = that the only response format is JSON. So we finally didn't modified the = section 4.1. We re-modified the wording in section 3 as follows. Second, the semantics of the request/response allow for future and/or non-standard response formats. In this document, only a JSON [RFC4627] response media type is defined, with the response contents to be described separately. This document only describes how RDAP is transported using HTTP with this format. This allows for future bis or other updates to obsolete or update this = document with additional MIME types, but otherwise simply locks it down = to JSON for now. Doing this we think resolves the conflict with 4.1 = without needing to change that section. IMHO, this document only focuses on how RDAP is transported using HTTP, = but doesn't cover the response data structure in JSON. So a normative = reference to the -json-response document is not necessary. Cheers, Ning From andy@arin.net Tue Jun 18 10:55:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA7211E80F1 for ; Tue, 18 Jun 2013 10:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.882 X-Spam-Level: X-Spam-Status: No, score=-3.882 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PW-IsgSZUelM for ; Tue, 18 Jun 2013 10:55:26 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 59FD911E80DF for ; Tue, 18 Jun 2013 10:55:26 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 9C1D11650D4; Tue, 18 Jun 2013 13:55:25 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 0F5901650CE; Tue, 18 Jun 2013 13:55:25 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 18 Jun 2013 13:55:00 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0342.003; Tue, 18 Jun 2013 13:54:59 -0400 From: Andy Newton To: Ning Kong , Pete Resnick Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 Thread-Index: AQHOXH3gY3KwLlQTlUSonTV+sXMu85k1qi4AgAZPPgCAAALgAIAADl6A///WPYA= Date: Tue, 18 Jun 2013 17:54:59 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7667@CHAXCH01.corp.arin.net> 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.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <76BB19C5CADFE741A071C10834EEF2D6@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:55:33 -0000 On 6/18/13 12:24 PM, "Ning Kong" wrote: > >Hi Pete, > >> On 6/5/13 9:18 PM, Ning Kong wrote: >>> We agree that this document should be a more generic HTTP draft. So >>>we'd like to remove the MUSTs from section 4.1. >>>=20 >>> If WG agree with that direction, we'd like to check and modify the >>>wording of JSON in the whole draft soon. >>> =20 >>=20 >> I see that the new draft still has MUSTs for JSON in section 4.1, still >>defines the registry for JSON responses, and still has no normative >>reference to the -json-response document. The other changes look fine, >>but the genericizing activity does not seem done. Is there some reason >>for this? > >Sorry for not clarifying this issue in advance. > >Based on the recent discussions on this thread, there is a consensus that >the only response format is JSON. So we finally didn't modified the >section 4.1. We re-modified the wording in section 3 as follows. > > Second, the semantics of the request/response allow for future and/or > non-standard response formats. In this document, only a JSON > [RFC4627] response media type is defined, with the response contents > to be described separately. This document only describes how RDAP is > transported using HTTP with this format. > >This allows for future bis or other updates to obsolete or update this >document with additional MIME types, but otherwise simply locks it down >to JSON for now. Doing this we think resolves the conflict with 4.1 >without needing to change that section. > >IMHO, this document only focuses on how RDAP is transported using HTTP, >but doesn't cover the response data structure in JSON. So a normative >reference to the -json-response document is not necessary. To build upon Ning's response, the registry for the JSON values was moved to this document from the json-response document by the working group. -andy From marc.blanchet@viagenie.ca Tue Jun 18 11:00:13 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CF021E8050 for ; Tue, 18 Jun 2013 11:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+dVSosbdMjh for ; Tue, 18 Jun 2013 11:00: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 A9C2D21E8097 for ; Tue, 18 Jun 2013 11:00:06 -0700 (PDT) Received: from h115.viagenie.ca (h115.viagenie.ca [206.123.31.115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 271D240391 for ; Tue, 18 Jun 2013 14:00:06 -0400 (EDT) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_75F5429B-13F1-44CB-8098-063B17C35042" Message-Id: <0BF9E7AC-7FC6-4988-A10C-49E6C6E7C85A@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Tue, 18 Jun 2013 14:00:05 -0400 References: <20130605204940.20845.36199.idtracker@ietfa.amsl.com> To: "weirds@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1508) Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:00:13 -0000 --Apple-Mail=_75F5429B-13F1-44CB-8098-063B17C35042 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 my current reading of the discussion about bootstrapping is the = following: - for names, do dns rdap.arpa, wildcards=20 - for addresses, use IANA registry. Which is essentially a merge of the two drafts I wrote into a combined = one. Looking to see agreement on the way forward and I'll update the draft = shortly. Marc. Le 2013-06-05 =E0 16:54, Marc Blanchet a = =E9crit : > Hello, > this is a draft on bootstrapping, but instead of using DNS as the = other draft I sent, this one uses IANA XML registries, as discussed. = That way we have two proposal on the table we can compare. At one time, = one of these two drafts will be dropped... ;-) >=20 > Please comment. >=20 > Regards, Marc. >=20 > D=E9but du message r=E9exp=E9di=E9 : >=20 >> De : internet-drafts@ietf.org >> Objet : I-D Action: = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt >> Date : 5 juin 2013 16:49:40 HAE >> =C0 : i-d-announce@ietf.org >> R=E9pondre =E0 : internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : Finding the Authoritative Registration Data = (RDAP) Service >> Author(s) : Marc Blanchet >> Filename : = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt >> Pages : 6 >> Date : 2013-06-05 >>=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, using data available in IANA registries. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-blanchet-weirds-bootstrap-ianaregis= tries >>=20 >> There's also a htmlized version available at: >> = http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregistries-= 00 >>=20 >>=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 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_75F5429B-13F1-44CB-8098-063B17C35042 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 my = current reading of the discussion about bootstrapping is the = following:
- for names, do dns rdap.arpa, = wildcards 
- for addresses, use IANA = registry.

Which is essentially a merge of the = two drafts I wrote into a combined one.

Looking = to see agreement on the way forward and I'll update the draft = shortly.

Marc.

Le = 2013-06-05 =E0 16:54, Marc Blanchet <marc.blanchet@viagenie.ca>= ; a =E9crit :

Objet : I-D Action: = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
=
Date : 5 juin 2013 16:49:40 HAE
R=E9pondre =E0 : internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.


Title =           : Finding = the Authoritative Registration Data (RDAP) Service
Author(s) =       : Marc Blanchet
Filename =        : = draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
Pages =           : 6
Date =            : = 2013-06-05

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, using data available in IANA = registries.


The IETF datatracker status page for this draft = is:
https://datatracker.ietf.org/doc/draft-blanchet-weirds-boot= strap-ianaregistries

There's also a htmlized version = available at:
http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ian= aregistries-00


Internet-Drafts are also available by = anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
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

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

= --Apple-Mail=_75F5429B-13F1-44CB-8098-063B17C35042-- From andy@arin.net Tue Jun 18 11:05:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC3921F9799 for ; Tue, 18 Jun 2013 11:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.784 X-Spam-Level: X-Spam-Status: No, score=-3.784 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERiz9Gp5Giz0 for ; Tue, 18 Jun 2013 11:05:51 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 556AC21F972E for ; Tue, 18 Jun 2013 11:05:51 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 07F32165252; Tue, 18 Jun 2013 14:05:51 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 9E7AA1651B1 for ; Tue, 18 Jun 2013 14:05:50 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 18 Jun 2013 14:05:26 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 18 Jun 2013 14:05:25 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: asEventActor with embedded entities Thread-Index: AQHObE5nmMGqOuKjAEGLLeJHGrqeAQ== Date: Tue, 18 Jun 2013 18:05:24 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF76BA@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] asEventActor with embedded entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:05:56 -0000 All, As I'm going through the NicInfo code to bring up to speed with the latest draft, I've discovered a slight problem with embedded entities (new with the latest draft). The asEventActor array allows an entity to be an event actor of a containing object. In the previous model for a domain or ip network, the event acting entity would be contained by the domain or ip network. However, it is now possible to have the event acting entity contained within another entity but still intend for it to be the event actor for the domain or ip network. A simple solution to his would be to have 'target' value inside asEventActor that could contain the self href of the object upon which the entity is an event actor. It would look like this: "asEventActor": [ { "eventAction": "last changed", "eventDate" : "2013-12-13T23:50:60Z", "target": "http://example.net/rdap/domain/foo.example" } ] That way an entity can target any object in the response, not just the one that contains it. Comments welcomed. :) -andy From andy@arin.net Tue Jun 18 11:23:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB5D21F9BCD for ; Tue, 18 Jun 2013 11:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-1.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7zpdozlN76L for ; Tue, 18 Jun 2013 11:23:08 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id D5F6121F9B83 for ; Tue, 18 Jun 2013 11:23:07 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 8536021364E; Tue, 18 Jun 2013 14:23:07 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id D00882135FF; Tue, 18 Jun 2013 14:23:06 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 18 Jun 2013 14:22:48 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0342.003; Tue, 18 Jun 2013 14:22:48 -0400 From: Andy Newton To: Marc Blanchet , "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHObFDVuSx848A1yk+UADo2VRvzHw== Date: Tue, 18 Jun 2013 18:22:47 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7703@CHAXCH01.corp.arin.net> In-Reply-To: <0BF9E7AC-7FC6-4988-A10C-49E6C6E7C85A@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.1.56] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7703CHAXCH01corpari_" MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:23:13 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7703CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Marc Blanchet > Date: Tuesday, June 18, 2013 2:00 PM To: "weirds@ietf.org" > Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregis= tries-00.txt my current reading of the discussion about bootstrapping is the following: - for names, do dns rdap.arpa, wildcards - for addresses, use IANA registry. Which is essentially a merge of the two drafts I wrote into a combined one. Looking to see agreement on the way forward and I'll update the draft short= ly. I don't like the hybrid approach given that the IANA registries approach wo= rks for both names and numbers. The issue for rdap.arpa for numbers are the ASNs. With a little creativity,= we might get that to work too. Perhaps zero padding and reversing the numb= ers with a different label for each digit might allow enough wiggle room fo= r the creating a zone file. So 199679 would become 9.7.6.9.9.1.0.0.0.0.as.r= dap.arpa. Just a thought. The downside to rdap.arpa is that we are forcing all registry operators to = support HTTPS. With an IANA registries model, each operator could register = their HTTP and/or HTTPS URLs. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7703CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
From: Marc Blanchet <marc.blanchet@viagenie.ca>
Date: Tuesday, June 18, 2013 2:00 P= M
To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: Re: [weirds] I-D Action: d= raft-blanchet-weirds-bootstrap-ianaregistries-00.txt

my current reading of the discussion about bootstrapping is the following:
- for names, do dns rdap.arpa, wildcards 
- for addresses, use IANA registry.

Which is essentially a merge of the two drafts I wrote into a combined= one.

Looking to see agreement on the way forward and I'll update the draft = shortly.

I don't like the hybrid approach given that the IANA registries approach wo= rks for both names and numbers.

The issue for rdap.arpa for numbers are the ASNs. With a little creati= vity, we might get that to work too. Perhaps zero padding and reversing the= numbers with a different label for each digit might allow enough wiggle ro= om for the creating a zone file. So 199679 would become 9.7.6.9.9.1.0.0.0.0.as.rdap.arpa. Just a thought.

The downside to rdap.arpa is that we are forcing all registry operator= s to support HTTPS. With an IANA registries model, each operator could regi= ster their HTTP and/or HTTPS URLs.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7703CHAXCH01corpari_-- From presnick@qti.qualcomm.com Tue Jun 18 13:42:46 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F611E8100 for ; Tue, 18 Jun 2013 13:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zsjlYrzAz4z for ; Tue, 18 Jun 2013 13:42:42 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0F611E80F1 for ; Tue, 18 Jun 2013 13:42: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=1371588162; x=1403124162; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LNz+RQpE/ujIqGQiUwtbCA1QwyrVMVI0T+jw6j4bLHU=; b=foQdFpnqP0chaKcRGg/sB6s8ZdVUuBbZbuapNKb1t/0D3oNOwKW7Bf4C RyHSyKchSYVhy1jHtHpjPLCZL0gfkNw3nYBwm1+ZW5kRM6PHkCA/mI+Sb UyNIRQ/uL75Dw9amy8X5hjl1FmH/OZfZ5ii9YdZ/5fvIVj22CvJcrxLff c=; X-IronPort-AV: E=Sophos;i="4.87,891,1363158000"; d="scan'208";a="45522729" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 18 Jun 2013 13:42:41 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Jun 2013 13:42:41 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 18 Jun 2013 13:42:40 -0700 Message-ID: <51C0C63D.7000704@qti.qualcomm.com> Date: Tue, 18 Jun 2013 15:42:37 -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: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7667@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7667@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:42:46 -0000 On 6/18/13 12:54 PM, Andy Newton wrote: > On 6/18/13 12:24 PM, "Ning Kong" wrote: > > >>> I see that the new draft still has MUSTs for JSON in section 4.1, still >>> defines the registry for JSON responses, and still has no normative >>> reference to the -json-response document. The other changes look fine, >>> but the genericizing activity does not seem done. Is there some reason >>> for this? >>> >> Sorry for not clarifying this issue in advance. >> >> Based on the recent discussions on this thread, there is a consensus that >> the only response format is JSON. So we finally didn't modified the >> section 4.1. That's fine, but that means that 4.1 is requiring something with a MUST (i.e., JSON responses) that this document does not define. That is, you cannot comply with all of the MUSTs in the document without reading the -json-response document. So: >> IMHO, this document only focuses on how RDAP is transported using HTTP, >> but doesn't cover the response data structure in JSON. So a normative >> reference to the -json-response document is not necessary. >> No, it is absolutely necessary if you make this choice. This document is unimplementable now without -json-response. > To build upon Ning's response, the registry for the JSON values was moved > to this document from the json-response document by the working group. > And now this is more problematic. The registration for the JSON values (especially the media type) presume a payload format that you have not defined in this document. Unless I am misunderstanding something, the registration of the media type is missing what goes in the payload. That can't be a legitimate registration. Please explain. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From johnl@iecc.com Tue Jun 18 14:55:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06B621E80B7 for ; Tue, 18 Jun 2013 14:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.439 X-Spam-Level: X-Spam-Status: No, score=-110.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_44=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRLDbYU9qXyM for ; Tue, 18 Jun 2013 14:55:25 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C24D121E80C1 for ; Tue, 18 Jun 2013 14:55:23 -0700 (PDT) Received: (qmail 1912 invoked from network); 18 Jun 2013 21:55:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Jun 2013 21:55:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c0d749.xn--3zv.k1306; i=johnl@user.iecc.com; bh=RtG9cNLE+SIE0NO6b7snug+hTyARezeXELZBFR2okKs=; b=QCAvltomVeZFFCMLSCk9x+rFUSzy+Gn/KpqdPTt8ith9UMs8yw7HujTTxtJ61uUsaBlOzOTIO+tadcBEbv//ObqUP4aeNyOpwCkTLhyppK8bFu9wVtRKYeNBAj/7m+a1titthBPvGpW9oMpNTBb7EL/q9usB//fQ9mBBAmFRWm9aS//Yf2+8GYJ7UEQLAed1LyPDTBdvKRdd21nmcOabDnA5Z22AP84RpvTdWov8mPWHJbT8wXZl222iRINDcXA7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c0d749.xn--3zv.k1306; olt=johnl@user.iecc.com; bh=RtG9cNLE+SIE0NO6b7snug+hTyARezeXELZBFR2okKs=; b=HufilxzB0cgyRcpNXcernHxBpa+bs/CKQ36ugFlVorESwMNqn1woxrh85pO1V/KgAPnsDomgHVBd9oTmIrXkOL3qX2MfYip+FFy6fDy/fLbVTOKN2OEmzMq2J3nP5PNW4L7j2F7ZKo75ZIyy6H7A38f22pp0iey0mbwz/DyBIBERGVqrZdMIsQ3A3uYF41L0f1nKDdVpTlJjVlzS3ZEsYfPsKZGCznPjEvUbtfldAkXiB1PiN0KZ77myl7G8x5P0 Date: 18 Jun 2013 21:54:59 -0000 Message-ID: <20130618215459.37383.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <0BF9E7AC-7FC6-4988-A10C-49E6C6E7C85A@viagenie.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:55:29 -0000 >my current reading of the discussion about bootstrapping is the following: >- for names, do dns rdap.arpa, wildcards Either wildcards, or just TLDs. >- for addresses, use IANA registry. The suggestions I've seen are to use the RIR servers as a pool of initial RDAP servers, since they already know about each other's allocations. The IANA registry might work, but I would want to be sure they were willing to have a potentially vast number of clients frequently fetching these pages: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml It appears that www.iana.org is just one web server, or perhaps a small set of them behind a load balancer, which doesn't strike me as appropriate for a critical resource. R's, John From carlosm3011@gmail.com Tue Jun 18 20:13:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F57821F9B1A for ; Tue, 18 Jun 2013 20:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmilH9mnN+6W for ; Tue, 18 Jun 2013 20:13:29 -0700 (PDT) Received: from mail-ye0-f170.google.com (mail-ye0-f170.google.com [209.85.213.170]) by ietfa.amsl.com (Postfix) with ESMTP id EB4C821F8FE5 for ; Tue, 18 Jun 2013 20:13:28 -0700 (PDT) Received: by mail-ye0-f170.google.com with SMTP id q3so1658055yen.29 for ; Tue, 18 Jun 2013 20:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Ep2DvW++sOsHxtgtqZur1BkQln3XyK995OW0Yc0FKFA=; b=u3HN20CDZUacplGLi+DU2WXReESFMcrKk/kKqzQCZXFAl/zSKmhy6UjFSjX0UKKcrH FsS/BBO2bFkB7mL85Jd7vAI8yNRueRHymTXLQSVYqjuzjQIGIWkQeWecq5Mi18PlhtZJ p0VRiA1IseUV7cLSZQ+po3KGYIanB2Z+j+rY/9xggECFwRWQv6x4Fs6a+VYcqEQlBJT7 0cTXWiemvUrxkz6jkyu7D4LPXo2jBTEmjj7l59we4tLVU8MX/6ceKsOzcboqDEDntrNW NA8zuGbMm2iYdqJG14uR5Wof6KnUw8qTtlE/0YCdPefJA/NypkjaKeUsy5mA9BETJs9Y pehQ== X-Received: by 10.236.14.231 with SMTP id d67mr430871yhd.244.1371611608251; Tue, 18 Jun 2013 20:13:28 -0700 (PDT) Received: from europa.local ([2001:470:d815:fe0:57d:9a2d:dc3b:3323]) by mx.google.com with ESMTPSA id w12sm34775219yhj.19.2013.06.18.20.13.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 20:13:27 -0700 (PDT) Message-ID: <51C121EE.4010202@gmail.com> Date: Wed, 19 Jun 2013 00:13:50 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 CC: weirds@ietf.org References: <20130618215459.37383.qmail@joyce.lan> In-Reply-To: <20130618215459.37383.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 03:13:35 -0000 Maybe my pool suggestion was a little misunderstood. My original suggestion about the pools made no assumptions on the bootstrap method for the servers. I was rather trying to address one of the underlying hypothesis about how RDAP will be used in the wild, namely by lots of rather simplistic clients, which unless convinced otherwise will always hit the same server (like they hit ARIN now). As this hypothesis goes, the RDAP client universe will be populated by clients which will have no incentive at all to bootstrap but will just get the first server in fixed list with a hammer. Warm regards, ~Carlos On 6/18/13 6:54 PM, John Levine wrote: >> my current reading of the discussion about bootstrapping is the following: >> - for names, do dns rdap.arpa, wildcards > > Either wildcards, or just TLDs. > >> - for addresses, use IANA registry. > > The suggestions I've seen are to use the RIR servers as a pool of > initial RDAP servers, since they already know about each other's > allocations. > > The IANA registry might work, but I would want to be sure they were > willing to have a potentially vast number of clients frequently > fetching these pages: > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml > http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml > > It appears that www.iana.org is just one web server, or perhaps a > small set of them behind a load balancer, which doesn't strike me as > appropriate for a critical resource. > > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From simon.perreault@viagenie.ca Wed Jun 19 01:29:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937E921F9F98 for ; Wed, 19 Jun 2013 01:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np7NKPHYuIA3 for ; Wed, 19 Jun 2013 01:29:21 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 79AB721F9F9A for ; Wed, 19 Jun 2013 01:29:16 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:84c5:867d:e648:8153]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C5C6B403D3 for ; Wed, 19 Jun 2013 04:29:15 -0400 (EDT) Message-ID: <51C16BDC.5050007@viagenie.ca> Date: Wed, 19 Jun 2013 10:29:16 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7703@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7703@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:29:21 -0000 Le 2013-06-18 20:22, Andy Newton a écrit : > The issue for rdap.arpa for numbers are the ASNs. With a little > creativity, we might get that to work too. Perhaps zero padding and > reversing the numbers with a different label for each digit might allow > enough wiggle room for the creating a zone file. So 199679 would become > 9.7.6.9.9.1.0.0.0.0.as.rdap.arpa. Just a thought. Maybe use hex? > The downside to rdap.arpa is that we are forcing all registry operators > to support HTTPS. Maybe clients could try HTTPS first and fallback on HTTP? Simon From pieter.vandepitte@dnsbelgium.be Wed Jun 19 01:55:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5AA21F9FAC for ; Wed, 19 Jun 2013 01:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwwxkcgeuN9J for ; Wed, 19 Jun 2013 01:55:25 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 6E60B21F9EBC for ; Wed, 19 Jun 2013 01:55:25 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 739AE4260089 for ; Wed, 19 Jun 2013 10:55:23 +0200 (CEST) Message-ID: <51C171FB.5020007@dnsbelgium.be> Date: Wed, 19 Jun 2013 10:55:23 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7703@CHAXCH01.corp.arin.net> <51C16BDC.5050007@viagenie.ca> In-Reply-To: <51C16BDC.5050007@viagenie.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:55:31 -0000 > >> The downside to rdap.arpa is that we are forcing all registry operators >> to support HTTPS. > > Maybe clients could try HTTPS first and fallback on HTTP? Seems a bad idea to me. It's sufficient for a mitm to block https and then grab credentials Pieter From andy@arin.net Wed Jun 19 03:19:34 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF8921F9F14 for ; Wed, 19 Jun 2013 03:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.606 X-Spam-Level: X-Spam-Status: No, score=-7.606 tagged_above=-999 required=5 tests=[AWL=2.993, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VINQwEXlzhth for ; Wed, 19 Jun 2013 03:19:28 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2EA21F9F13 for ; Wed, 19 Jun 2013 03:19:28 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 90EA021367A; Wed, 19 Jun 2013 06:18:57 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 058EC213660; Wed, 19 Jun 2013 06:18:57 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 19 Jun 2013 06:18:32 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 06:18:32 -0400 From: Andy Newton To: Pete Resnick , "weirds@ietf.org" Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 Thread-Index: AQHOXH3gY3KwLlQTlUSonTV+sXMu85k1qi4AgAZPPgCAAALgAIAADl6A///WPYCAAHHngIAAoOYA Date: Wed, 19 Jun 2013 10:18:32 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF79D9@CHAXCH01.corp.arin.net> In-Reply-To: <51C0C63D.7000704@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.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <86AC986BCE28A7409B490871BFB049B3@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 10:19:34 -0000 On 6/18/13 4:42 PM, "Pete Resnick" wrote: >And now this is more problematic. The registration for the JSON values >(especially the media type) presume a payload format that you have not >defined in this document. Unless I am misunderstanding something, the >registration of the media type is missing what goes in the payload. That >can't be a legitimate registration. Understood, and thanks Pete. The draft authors feel this question needs to be asked of the working group. There are two ways to proceed: 1. Move the media type to json-response and change of the subsequent requirements; or 2. Add a normative reference to json-response and accept the delay in publishing using-http. The draft authors are partial to #1, and in the absence of feedback will modify the draft in that respect. Does anybody in the working group have an opinion about either of these options? -andy From marc.blanchet@viagenie.ca Wed Jun 19 06:47:25 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEE421F9263 for ; Wed, 19 Jun 2013 06:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJUsoLgERKVL for ; Wed, 19 Jun 2013 06:47:24 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 92F6421F9B07 for ; Wed, 19 Jun 2013 06:47:23 -0700 (PDT) Received: from [IPv6:2620::230:c000:e0c1:b174:5d24:3099] (unknown [IPv6:2620:0:230:c000:e0c1:b174:5d24:3099]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E337F403D3; Wed, 19 Jun 2013 09:47:22 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <51C121EE.4010202@gmail.com> Date: Wed, 19 Jun 2013 09:47:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <67DB520F-B586-4BEB-A8EC-44A7C4E420DE@viagenie.ca> References: <20130618215459.37383.qmail@joyce.lan> <51C121EE.4010202@gmail.com> To: "weirds@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: "John R. Levine" , Carlos Martinez-Cagnazzo Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 13:47:25 -0000 about addresses: - having all RIR to redirect to each other is to me an operational = decision that implies they have a formal agreement between themselves = about this service. I'm not sure we can write this down in an RFC. Even = if we do, what happens if one of the RIR disagree next month and stop = redirecting? - so my take is the following: a) we need to define a reliable bootstrap method, reliable in the sense = that it implies the least amount of agreement between parties. b) we specify optional optimisations, such as connecting to one server = and hopefully it will redirect to the right one. If the optimisation = does not work anymore, the client can fallback to the "reliable" method. For a), I think it is either the IANA registries or a DNS-based = approach, each have been specified in a separate draft I published. Regarding IANA registries, they have a farm of servers and caching = infrastructure. They have already been doing some larger scale caching = for some registries that have been hit by large numbers, so they can do. = In any of the choices we have, IANA will be involved, so as soon as we = have concensus, I'll contact them to discuss the plan and pre-empt any = issue. Marc. Le 2013-06-18 =E0 23:13, "Carlos M. Martinez" a = =E9crit : > Maybe my pool suggestion was a little misunderstood. My original > suggestion about the pools made no assumptions on the bootstrap method > for the servers. >=20 > I was rather trying to address one of the underlying hypothesis about > how RDAP will be used in the wild, namely by lots of rather simplistic > clients, which unless convinced otherwise will always hit the same > server (like they hit ARIN now). >=20 > As this hypothesis goes, the RDAP client universe will be populated by > clients which will have no incentive at all to bootstrap but will just > get the first server in fixed list with a hammer. >=20 > Warm regards, >=20 > ~Carlos >=20 > On 6/18/13 6:54 PM, John Levine wrote: >>> my current reading of the discussion about bootstrapping is the = following: >>> - for names, do dns rdap.arpa, wildcards=20 >>=20 >> Either wildcards, or just TLDs. >>=20 >>> - for addresses, use IANA registry. >>=20 >> The suggestions I've seen are to use the RIR servers as a pool of >> initial RDAP servers, since they already know about each other's >> allocations. >>=20 >> The IANA registry might work, but I would want to be sure they were >> willing to have a potentially vast number of clients frequently >> fetching these pages: >> = http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml >> = http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unic= ast-address-assignments.xml >>=20 >> It appears that www.iana.org is just one web server, or perhaps a >> small set of them behind a load balancer, which doesn't strike me as >> appropriate for a critical resource. >>=20 >> R's, >> John >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >>=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From superuser@gmail.com Wed Jun 19 07:41:52 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1E021F9C41 for ; Wed, 19 Jun 2013 07:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSgdDgxjnb+x for ; Wed, 19 Jun 2013 07:41:51 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF2B21F9C39 for ; Wed, 19 Jun 2013 07:41:51 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so770764wiv.14 for ; Wed, 19 Jun 2013 07:41:50 -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=gwg+JtNLCz0qHRtEump12N61TCxnj65InOPHvF5qI7A=; b=XQD9K9mAguT402IICfyAZFpBlTenH1NJBbaXd/cXirhyF6Yk2ciI1nYyiVb1NLnwFE xO27thBx5V16Vv7/4J+U6RuSYWin6GfUBl9iYmLQ6tyHfDesFM089YOpE4xWAPisU7QG 2eCzv2M4Ip0D9hGZ2nDNbY+lOp9HDgiD7cGcfseFjxdRj2XTeZPU1xSU1f543XX5hWbE msw8/8ry7VoS9xlqUhLVz6FiXa4xapjZvDbEsXjAzv83Trxrm7bD6yS+4Km3eCbQsq+U n/F+Z1YZBqyQEjQCgFwCICnsGocu5puab79X7zupnx+U9KbcxpLVZ0VgOCNNFZSYNyCr F88Q== MIME-Version: 1.0 X-Received: by 10.194.122.71 with SMTP id lq7mr2433932wjb.77.1371652910594; Wed, 19 Jun 2013 07:41:50 -0700 (PDT) Received: by 10.180.126.97 with HTTP; Wed, 19 Jun 2013 07:41:50 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF79D9@CHAXCH01.corp.arin.net> References: <51C0C63D.7000704@qti.qualcomm.com> <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF79D9@CHAXCH01.corp.arin.net> Date: Wed, 19 Jun 2013 07:41:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=089e012297507dcf9904df82d445 Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:41:52 -0000 --089e012297507dcf9904df82d445 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 19, 2013 at 3:18 AM, Andy Newton wrote: > The draft authors feel this question needs to be asked of the working > group. There are two ways to proceed: > > 1. Move the media type to json-response and change of the subsequent > requirements; or > 2. Add a normative reference to json-response and accept the delay in > publishing using-http. > > The draft authors are partial to #1, and in the absence of feedback will > modify the draft in that respect. > > Does anybody in the working group have an opinion about either of these > options? > > No hat: I don't have a preference either way. I also don't think the delay identified in #2 is a big concern for me; is there some reason we should avoid it? -MSK --089e012297507dcf9904df82d445 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --089e012297507dcf9904df82d445-- From johnl@taugh.com Wed Jun 19 08:47:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBEC21F9D1F for ; Wed, 19 Jun 2013 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXElMbyeNLNz for ; Wed, 19 Jun 2013 08:47:29 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 150FE21F9D1B for ; Wed, 19 Jun 2013 08:47:28 -0700 (PDT) Received: (qmail 8179 invoked from network); 19 Jun 2013 15:47:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=1ff0.51c1d290.k1306; bh=FhKKiPOMVqX+GWOHbp6ia9SkqAiNlXh0yENwx+3HWaw=; b=vJiwWPNi5caVEGzzlDfMXyEokf2FQh55QuhfIcEbn9FvFGnZtkpAQPfSs9KMK0Z5utG0uQ5W00V1ACxB3Lxg/HwrkC8dfFeYTcYBi02LajDMr6wwDnB6YV6YQ9ZOypelxO5v0nEK3m+s7tSER7B9E0wQ0E2N0+dnyhG49qZoSo2JRPBVljHedIe99646iAxb4ZoaBfx9L+qeT7fkOVOVKr5Hi/CTKTdofU3/45wfWG7Mx5QYrYqpU+uNLJV4d8ti 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:cleverness; s=1ff0.51c1d290.k1306; bh=FhKKiPOMVqX+GWOHbp6ia9SkqAiNlXh0yENwx+3HWaw=; b=rkDaekKJFyVgpU1pXjSNgGTt49+yf5wHpRRHgofc/idBrzrQPkpai88kOkKGCzXboFSKKVGl2nPeSwPRIw05VqeTv7wGoHNvLBlPk80okoKvwa0EgcodbWljpdgONVT3WJgtyM1FNCJxpf0CS5r+Es0DRVQklorfQBsCXmHGgS+mUrIYJSKJ8xmQbxc30i8K2wloPlOt6ivPPSKbfoF30VpHePbBVEF1WC+ivUy4AOztkEnXhTYGRKODVfkXA3T9 Received: (ofmipd 127.0.0.1); 19 Jun 2013 15:47:05 -0000 Date: 19 Jun 2013 11:47:27 -0400 Message-ID: From: "John R Levine" To: "Marc Blanchet" In-Reply-To: <67DB520F-B586-4BEB-A8EC-44A7C4E420DE@viagenie.ca> References: <20130618215459.37383.qmail@joyce.lan> <51C121EE.4010202@gmail.com> <67DB520F-B586-4BEB-A8EC-44A7C4E420DE@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-121612555-1371656847=:38805" Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 15:47:30 -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. --3825401791-121612555-1371656847=:38805 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > - having all RIR to redirect to each other is to me an operational > decision that implies they have a formal agreement between themselves > about this service. I'm not sure we can write this down in an RFC. > Even if we do, what happens if one of the RIR disagree next month and > stop redirecting? We would have worse problems than bootstrapping if RIRs stopped returning referalls to each other, since there are a large number of IP blocks that have been transferred from one RIR to another over the past decades. A reasonable approach would be to put the RIR pool into a draft, then ask the RIRs whether they are willing to implement it. I would be happy to do the DNS approach if we could figure out a way to put the IPv6 allocations into a DNS zone that wouldn't require many thousands of records. The AS numbers are even worse in that regard. > Regarding IANA registries, they have a farm of servers and caching > infrastructure. They have already been doing some larger scale caching > for some registries that have been hit by large numbers, so they can do. Really? 3000 http queries per second is very large scale. > Le 2013-06-18 à 23:13, "Carlos M. Martinez" a écrit : >> As this hypothesis goes, the RDAP client universe will be populated by >> clients which will have no incentive at all to bootstrap but will just >> get the first server in fixed list with a hammer. The current suggestion is to make a pool of servers, e.g. numbers.rdap.arpa A 1.2.3.4 ; ARIN A 2.3.4.5 ; RIPE A 3.4.5.6 ; LACNIC A 4.5.6.7 ; APNIC A 5.6.7.8 ; AFRINIC This at least spreads the load around. I suppose as s minor optimization you could envision Akamai-style tricks that send DNS clients a server that is topologically close to them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-121612555-1371656847=:38805-- From edainow@afilias.info Wed Jun 19 09:14:51 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C566921F9DAC for ; Wed, 19 Jun 2013 09:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM7RbWe8bqTN for ; Wed, 19 Jun 2013 09:14:46 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9F65621F9DA6 for ; Wed, 19 Jun 2013 09:14:46 -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 1UpL1y-00077F-3V for weirds@ietf.org; Wed, 19 Jun 2013 16:14:46 +0000 Received: from mail-ob0-f179.google.com ([209.85.214.179]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UpL1x-0001R9-6O for weirds@ietf.org; Wed, 19 Jun 2013 16:14:46 +0000 Received: by mail-ob0-f179.google.com with SMTP id xk17so6188566obc.10 for ; Wed, 19 Jun 2013 09:14:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=fLtPFp761lDNfXJ39t8D1sH7uLnT1sXKF4IqhUOVXU8=; b=RAnSIUZZbZdPEl5vaP3bV0P59yyv1/8QVr/EpvmvchpXVZ/svpab0D4XdcSJTHZvJL h4RJznKmI4qHoDxazcGn009SF4++nSCL4FWMaoyk3xPBkHYETR0dYJqLEoojcqRurV5R Q+uB+UDq+yIl7dBwZCYYS+Jpf+e7fQMkYptn88Q0BPt8MKN2rvqcsuj4IobttA/FZsyC oA9vmzYfFFi86TtL0ti0hpgQIyJO0tnVP+Z1XMoC4DY74IQkj6FbiwnuXIF6By8vQ2qo cvORHkA5Y5rONOYn7orRYL7rCWb8rcttIRC1EQ/V2TdnAFiYW8HhaX7Nz7L2ldb/hhuz LbXA== X-Received: by 10.60.77.10 with SMTP id o10mr2446872oew.86.1371658480497; Wed, 19 Jun 2013 09:14:40 -0700 (PDT) X-Received: by 10.60.77.10 with SMTP id o10mr2446867oew.86.1371658480413; Wed, 19 Jun 2013 09:14:40 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id jt9sm25384396obc.0.2013.06.19.09.14.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 09:14:39 -0700 (PDT) Message-ID: <51C1D8DD.7080405@afilias.info> Date: Wed, 19 Jun 2013 12:14:21 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF76BA@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF76BA@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmpLweWjmwzOg/Nt04Q/Cuhhttd3QPogeYbGPMDjr+SWScaMzfTYOJRzaZBX7iDQZPKaQqIGskFNqT15h2PEdAY60G5G+qLLWiHwHSmgrMnxj6H4euBV/fTrL2HXIQZOq51/GdQ Cc: "weirds@ietf.org" Subject: Re: [weirds] asEventActor with embedded entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:14:51 -0000 Shouldn't "target" be a links structure, perhaps with a more appropriate name like "eventLink"? To be symmetrical with this, the events structure should also have a link. It is unclear what kind identifier is used for "eventActor" in an events array. Some examples in json-response-04 use an email address, some seem to be a handle. If it is not specifically a handle, then eventActor should have an optional link to be able to get to the entity from an event. -Ernie On 6/18/2013 2:05 PM, Andy Newton wrote: > All, > > As I'm going through the NicInfo code to bring up to speed with the latest > draft, I've discovered a slight problem with embedded entities (new with > the latest draft). > > The asEventActor array allows an entity to be an event actor of a > containing object. In the previous model for a domain or ip network, the > event acting entity would be contained by the domain or ip network. > However, it is now possible to have the event acting entity contained > within another entity but still intend for it to be the event actor for > the domain or ip network. > > A simple solution to his would be to have 'target' value inside > asEventActor that could contain the self href of the object upon which the > entity is an event actor. It would look like this: > > "asEventActor": > [ > { > "eventAction": "last changed", > "eventDate" : "2013-12-13T23:50:60Z", > "target": "http://example.net/rdap/domain/foo.example" > } > ] > > That way an entity can target any object in the response, not just the one > that contains it. > > Comments welcomed. :) > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From andy@arin.net Wed Jun 19 09:28:06 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BC321F9CB0 for ; Wed, 19 Jun 2013 09:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.793 X-Spam-Level: X-Spam-Status: No, score=-7.793 tagged_above=-999 required=5 tests=[AWL=2.806, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK9pTP32-h2Y for ; Wed, 19 Jun 2013 09:27:56 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0758121F9C89 for ; Wed, 19 Jun 2013 09:27:54 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 76EE82135FF; Wed, 19 Jun 2013 12:27:24 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 17BF321368A; Wed, 19 Jun 2013 12:27:23 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 19 Jun 2013 12:27:13 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 12:27:13 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] asEventActor with embedded entities Thread-Index: AQHObE5nmMGqOuKjAEGLLeJHGrqeAZk9eo6A///AhYA= Date: Wed, 19 Jun 2013 16:27:12 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D0E@CHAXCH01.corp.arin.net> In-Reply-To: <51C1D8DD.7080405@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <411369D58BF99C40B76768CDFCCDA10A@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] asEventActor with embedded entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:28:06 -0000 On 6/19/13 12:14 PM, "Ernie Dainow" wrote: >Shouldn't "target" be a links structure, perhaps with a more appropriate >name like "eventLink"? I'm fine with that. What would the relation type be? "related"? >To be symmetrical with this, the events structure should also have a >link. What purpose would that serve? The events structure is describing an event on the containing object. I suppose we could but I see no need for it. > It is unclear what kind identifier is used for "eventActor" in an >events array. Some examples in json-response-04 use an email address, >some seem to be a handle. If it is not specifically a handle, then >eventActor should have an optional link to be able to get to the entity >from an event. That's because in some registries it is an email address while in others it is a handle and in others it would be a full blown entity. The eventActor is simply an opaque identifier. There's no good way to normalize that. -andy From andy@arin.net Wed Jun 19 09:29:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9722E21F9D04 for ; Wed, 19 Jun 2013 09:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.957 X-Spam-Level: X-Spam-Status: No, score=-7.957 tagged_above=-999 required=5 tests=[AWL=2.641, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVk0zag3WLGo for ; Wed, 19 Jun 2013 09:29:31 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0048A21F9CB0 for ; Wed, 19 Jun 2013 09:29:27 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 93EB121368B; Wed, 19 Jun 2013 12:28:57 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 00AA62135FF; Wed, 19 Jun 2013 12:28:57 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 19 Jun 2013 12:28:56 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 12:28:56 -0400 From: Andy Newton To: "Murray S. Kucherawy" Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 Thread-Index: AQHOXH3gY3KwLlQTlUSonTV+sXMu85k1qi4AgAZPPgCAAALgAIAADl6A///WPYCAAHHngIAAoOYAgACMoQD//9rcAA== Date: Wed, 19 Jun 2013 16:28:55 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D2A@CHAXCH01.corp.arin.net> 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.4.130416 x-originating-ip: [10.1.1.56] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D2ACHAXCH01corpari_" MIME-Version: 1.0 Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:29:39 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D2ACHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "Murray S. Kucherawy" > Date: Wednesday, June 19, 2013 10:41 AM To: Andrew Newton > Cc: Pete Resnick >, "weirds@ietf.org" > Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 I don't have a preference either way. I also don't think the delay identif= ied in #2 is a big concern for me; is there some reason we should avoid it? If the publication of the draft is to be delayed, then why do we have a mil= estone for it so early? I think that is one of the drivers. I do think that #2 would keep the MUST language, which is contrary to the o= ther edits we just made=10. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D2ACHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <5D53E0EA0EDAF04598681EDFC447E821@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy&quo= t; <superuser@gmail.com> Date: Wednesday, June 19, 2013 10:4= 1 AM
To: Andrew Newton <andy@arin.net>
Cc: Pete Resnick <presnick@qti.qualcomm.com>, "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] AD Evaluation= of draft-ietf-weirds-using-http-05

I don't have a preference either way.  I also don't think the delay ide= ntified in #2 is a big concern for me; is there some reason we should avoid= it?

If the publication of the draft is to be delayed, then why do we have = a milestone for it so early? I think that is one of the drivers.

I do think that #2 would keep the MUST language, which is contrary to = the other edits we just made.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D2ACHAXCH01corpari_-- From andy@arin.net Wed Jun 19 09:31:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5BB21F9D03 for ; Wed, 19 Jun 2013 09:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.104 X-Spam-Level: X-Spam-Status: No, score=-4.104 tagged_above=-999 required=5 tests=[AWL=-1.506, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+unC86ksz8k for ; Wed, 19 Jun 2013 09:31:16 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 4277E21F9246 for ; Wed, 19 Jun 2013 09:31:16 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id EBC46164FC3; Wed, 19 Jun 2013 12:31:15 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 54E19164F87; Wed, 19 Jun 2013 12:31:15 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 19 Jun 2013 12:31:15 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 12:31:13 -0400 From: Andy Newton To: John R Levine , Marc Blanchet Thread-Topic: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHObQRQj3+DIt0bkkWeNpJJhQGriZk9OscA Date: Wed, 19 Jun 2013 16:31:12 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D55@CHAXCH01.corp.arin.net> 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.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D24CA98517E534CA6672373C9D62F44@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:31:21 -0000 On 6/19/13 11:47 AM, "John R Levine" wrote: >Really? 3000 http queries per second is very large scale. Aren't you mixing models? 3000 HTTP queries/sec would be for an HTTP bootstrap server, not for an IANA XML/JSON registry approach where the clients fetch the data once in a blue moon. -andy From presnick@qti.qualcomm.com Wed Jun 19 09:44:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B32E21F9D09 for ; Wed, 19 Jun 2013 09:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVJpEUWZNy6X for ; Wed, 19 Jun 2013 09:44:29 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id E001721F9CFB for ; Wed, 19 Jun 2013 09:44: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=1371660268; x=1403196268; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BBZr2L1Z8ctQEWQnbuAFaL2I1NDG1X2e4O4P4LB84B4=; b=yx9dPtuBb96MZTE9tCsyQ453neQTb9X7sWGywsuylf7mgi32IAOs6Tos 566Pv3qKxhukzla/Snb6yWmZjXL4xs3rItG57qoLRFEDNj+eFB+WjpQqp nvD8JrqiYpOMkdmAI3nqLhXTpEEQytiOYyOFjhO2KPFRLG+eerLB3amSQ U=; X-IronPort-AV: E=Sophos;i="4.87,898,1363158000"; d="scan'208";a="45709433" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 19 Jun 2013 09:44:28 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Jun 2013 09:44:28 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 19 Jun 2013 09:44:27 -0700 Message-ID: <51C1DFEA.9020703@qti.qualcomm.com> Date: Wed, 19 Jun 2013 11:44: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: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF79D9@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF79D9@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:44:33 -0000 On 6/19/13 5:18 AM, Andy Newton wrote: > The draft authors feel this question needs to be asked of the working > group. There are two ways to proceed: > > 1. Move the media type to json-response and change of the subsequent > requirements; or > 2. Add a normative reference to json-response and accept the delay in > publishing using-http. > And to be perfectly clear: I do not wish to express a preference on this; as AD, I am happy to bring either choice to Last Call and to the IESG. It's just that I can't figure out how the document is currently consistent with either of these two. So effectively is a third choice: 3. Explain why it is OK as it is. I'm assuming that you are only listing the above two choices because you agree with me that there is a problem. If you think there is not a problem (especially if the WG agrees), let's not spend time changing the document, but rather "getting Pete's head right." If, on the other hand, I've convinced you that there is a problem, I am fine with either of the two choices. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From edainow@afilias.info Wed Jun 19 10:48:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79D21F9AD9 for ; Wed, 19 Jun 2013 10:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIpAeLypmkuP for ; Wed, 19 Jun 2013 10:48:27 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2859421F9AE8 for ; Wed, 19 Jun 2013 10:48:27 -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 1UpMUX-0001on-3E for weirds@ietf.org; Wed, 19 Jun 2013 17:48:21 +0000 Received: from mail-oa0-f45.google.com ([209.85.219.45]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UpMUW-0006oh-6B for weirds@ietf.org; Wed, 19 Jun 2013 17:48:20 +0000 Received: by mail-oa0-f45.google.com with SMTP id j1so7017990oag.32 for ; Wed, 19 Jun 2013 10:48:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=FIxcsEIlOS0Vc752ICeoRGud15D6xQXAnObPpOYnFaw=; b=Jao03bRNiHnPBkU0CRiT0RwZride6h7eLeEW+QUhQBuNMM9NWq2jskfoFP+LPJ8GVn XKPJN9bXEZfmqLbKpdOobVQjMUoia/ElhFwNMLOQ0aAv3Te4nvNrbWFVwjcbY7M74//z cIT0UfLEr1GrlBtq/T58IHYUzIteKzysnycI6JehWHiGHc4lrHqiZcDy/8uH0HKHnicW yBhOYSVoQCf/+Hmq7e8Ynsdq+ko8N2L8qPiJL1R9ic63aRdC60+KVmyd3601GFVEhSe9 xb7pqARTt0JhOFUY9FVyl3N1SKN/GWKFPXdiqUmiIorzU2tYDtePnBmIzFycMOJNF9Rx nbUw== X-Received: by 10.60.35.136 with SMTP id h8mr2753385oej.129.1371664095431; Wed, 19 Jun 2013 10:48:15 -0700 (PDT) X-Received: by 10.60.35.136 with SMTP id h8mr2753381oej.129.1371664095347; Wed, 19 Jun 2013 10:48:15 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id h4sm26208972oel.2.2013.06.19.10.48.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 10:48:14 -0700 (PDT) Message-ID: <51C1EED9.7060808@afilias.info> Date: Wed, 19 Jun 2013 13:48:09 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D0E@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D0E@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmhx7S7Aoh9mA0OHzNddhGyQb6iBRj7QMZJTCTv8Wn3y/hG1IGxwYZCx+vzasTHwLi+3lCMD1nQ123qk6NNWSsdh4zMw9EFL4oymUrJx9KNXEUIU7OrnlNXlOXiQRMDCRyADrwE Cc: "weirds@ietf.org" Subject: Re: [weirds] asEventActor with embedded entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:48:33 -0000 On 6/19/2013 12:27 PM, Andy Newton wrote: > On 6/19/13 12:14 PM, "Ernie Dainow" wrote: > >> Shouldn't "target" be a links structure, perhaps with a more appropriate >> name like "eventLink"? > I'm fine with that. What would the relation type be? "related"? Seems to be the best fit from the IANA list. > >> To be symmetrical with this, the events structure should also have a >> link. > What purpose would that serve? The events structure is describing an event > on the containing object. I suppose we could but I see no need for it. An example is a domain object that has an event for the creation date by a registrar (eventActor), where the server can return the detailed entity for the eventActor if a link is provided. > >> It is unclear what kind identifier is used for "eventActor" in an >> events array. Some examples in json-response-04 use an email address, >> some seem to be a handle. If it is not specifically a handle, then >> eventActor should have an optional link to be able to get to the entity > >from an event. > > That's because in some registries it is an email address while in others > it is a handle and in others it would be a full blown entity. The > eventActor is simply an opaque identifier. There's no good way to > normalize that. OK, it might be worth adding a note to this effect to help distinguish among the many "identifiers" used in the document . -Ernie From carlosm3011@gmail.com Wed Jun 19 11:47:04 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7328321F9BA4 for ; Wed, 19 Jun 2013 11:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay6V1Mdz6Isf for ; Wed, 19 Jun 2013 11:47:03 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id B2FFC21F9B00 for ; Wed, 19 Jun 2013 11:47:03 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz10so4308097veb.22 for ; Wed, 19 Jun 2013 11:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=slVWtNg/MSuTiWeeYSbaIPsYFAERSsp2GUBfq1Kgmf8=; b=K+Qj1FEGHxblhfdRdR88Bf6RB/WDEisvJuhj3fDsxylmjsIjjfA1dnd5QlRumyUpDK tKq+5zS7VBrpjgkzvmWzhFTu/8pROUSna2H6pKEwDdAn0vg6E6zbhdh8eMM1SJb9c56S ExJ1uDf3vFBK1fl9wRI+B2reHJcv7tEjSU2BMt25ntugMdmDdbj+Y5ChDusrUqBq/buE oCMAxHkUopdwvPqEG//jFWjwK81sju10yJIIrX0B8WT5lDnOhlriHKrLEn0Mw+h0K/cB kVTbaN796C8DSbcjQxjdGlbQHb8g1tqKvWEFc3QKPayaH6JKUFiIYoyLYDH+hCCSAwdQ 7v2w== X-Received: by 10.52.163.46 with SMTP id yf14mr1136671vdb.58.1371667622980; Wed, 19 Jun 2013 11:47:02 -0700 (PDT) Received: from europa.local ([2001:470:d815:fe0:4581:d18d:514e:e02c]) by mx.google.com with ESMTPSA id hh9sm9581173vdb.7.2013.06.19.11.46.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 11:47:02 -0700 (PDT) Message-ID: <51C1FCA0.7090508@gmail.com> Date: Wed, 19 Jun 2013 15:46:56 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D55@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D55@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:47:04 -0000 Yes, methinks we're talking about two related, but different problems/aspects. On 6/19/13 1:31 PM, Andy Newton wrote: > On 6/19/13 11:47 AM, "John R Levine" wrote: > >> Really? 3000 http queries per second is very large scale. > > Aren't you mixing models? 3000 HTTP queries/sec would be for an HTTP > bootstrap server, not for an IANA XML/JSON registry approach where the > clients fetch the data once in a blue moon. > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Wed Jun 19 11:55:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80B421F9EBA for ; Wed, 19 Jun 2013 11:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.025 X-Spam-Level: X-Spam-Status: No, score=-4.025 tagged_above=-999 required=5 tests=[AWL=-1.426, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYZ64EA9oszh for ; Wed, 19 Jun 2013 11:55:21 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id B3C1F21F9EBB for ; Wed, 19 Jun 2013 11:55:21 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 2C7D221368A; Wed, 19 Jun 2013 14:55:21 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id A0EFC213663; Wed, 19 Jun 2013 14:55:20 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 19 Jun 2013 14:55:08 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 14:55:07 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] asEventActor with embedded entities Thread-Index: AQHObE5nmMGqOuKjAEGLLeJHGrqeAZk9eo6A///AhYCAAFmwgP//z6IA Date: Wed, 19 Jun 2013 18:55:07 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF8100@CHAXCH01.corp.arin.net> In-Reply-To: <51C1EED9.7060808@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <03422425FBB304428D87AFC3B11CE9C9@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] asEventActor with embedded entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:55:27 -0000 On 6/19/13 1:48 PM, "Ernie Dainow" wrote: > >On 6/19/2013 12:27 PM, Andy Newton wrote: >> On 6/19/13 12:14 PM, "Ernie Dainow" wrote: >> >>> Shouldn't "target" be a links structure, perhaps with a more >>>appropriate >>> name like "eventLink"? >> I'm fine with that. What would the relation type be? "related"? >Seems to be the best fit from the IANA list. Works for me! > >> >>> To be symmetrical with this, the events structure should also have a >>> link. >> What purpose would that serve? The events structure is describing an >>event >> on the containing object. I suppose we could but I see no need for it. >An example is a domain object that has an event for the creation date by >a registrar (eventActor), where the server can return the detailed >entity for the eventActor if a link is provided. In other words, a reference to an entity that can be fetched via the URL by an RDAP client but is not in the current response? Is that the use case? Or is the URL generic (as in, it doesn't necessarily point to an RDAP entity)? > >> >>> It is unclear what kind identifier is used for "eventActor" in an >>> events array. Some examples in json-response-04 use an email address, >>> some seem to be a handle. If it is not specifically a handle, then >>> eventActor should have an optional link to be able to get to the entity >> >from an event. >> >> That's because in some registries it is an email address while in others >> it is a handle and in others it would be a full blown entity. The >> eventActor is simply an opaque identifier. There's no good way to >> normalize that. >OK, it might be worth adding a note to this effect to help distinguish >among the many "identifiers" used in the document . Sounds like a good idea. -andy From edainow@afilias.info Wed Jun 19 12:32:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E84C21F9DBC for ; Wed, 19 Jun 2013 12:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEtmKCd337Qe for ; Wed, 19 Jun 2013 12:32:32 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id BEAC621F9FBC for ; Wed, 19 Jun 2013 12:32:29 -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 1UpO7J-00055h-3g for weirds@ietf.org; Wed, 19 Jun 2013 19:32:29 +0000 Received: from mail-oa0-f41.google.com ([209.85.219.41]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UpO7J-0004dt-3O for weirds@ietf.org; Wed, 19 Jun 2013 19:32:29 +0000 Received: by mail-oa0-f41.google.com with SMTP id n10so7134615oag.0 for ; Wed, 19 Jun 2013 12:32:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=Y/XoDLTLpYWxMsW96DYLGYdsHCBTm8AoN6xEwaMvk9Q=; b=XlNVK8dBPCYLQSd6mEoc60287rBefGFK3AmuEDk08WEF4m2HSAl1q33wCad5pcITWh lj1t9+ZuuoNUTQ1vsw/nzaXw/RfuvY9BNwx+wEDIgavx99FK01qqJ7Ksr7O6uA8eJboJ 0H7xjw/h8IhOxQpguWtJOKYcwcq5Vhu9O51vT8WXTY02csWf50IzvKmPfCqn2U06Au3s Yq3KReBqbtlO/h4wmqcSb3Ae+qH/LlwRvOZ4OGYeF+0mkhwC19VqVGXPccJEhE4A0/fY BvRmhK2K4g1WP/VQerKhIbbG8cH1jJJpw0HGlAHTHCB9hhrkEoYt+gSq+fMsq6Fpz0Aj lRGQ== X-Received: by 10.182.129.230 with SMTP id nz6mr87083obb.49.1371670343562; Wed, 19 Jun 2013 12:32:23 -0700 (PDT) X-Received: by 10.182.129.230 with SMTP id nz6mr87078obb.49.1371670343470; Wed, 19 Jun 2013 12:32:23 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id o4sm25581811obl.7.2013.06.19.12.32.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 12:32:22 -0700 (PDT) Message-ID: <51C20742.6000505@afilias.info> Date: Wed, 19 Jun 2013 15:32:18 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF8100@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF8100@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQncDUQXNBcGfqBg5vBYzegQScVIyqc9QlBk5ODpxjwvPe4/K0EL053zQVFqMz4AHeS030kn/RrOyNCPz8ILj3W1UiEC7K9Gr3wA/rJQeNk73UeHsycr8kyTHsb4U4zFi2TPIEjd Cc: "weirds@ietf.org" Subject: Re: [weirds] asEventActor with embedded entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 19:32:38 -0000 On 6/19/2013 2:55 PM, Andy Newton wrote: > On 6/19/13 1:48 PM, "Ernie Dainow" wrote: > >> On 6/19/2013 12:27 PM, Andy Newton wrote: >>> On 6/19/13 12:14 PM, "Ernie Dainow" wrote: >>> >>>> To be symmetrical with this, the events structure should also have a link. >>> What purpose would that serve? The events structure is describing an >>> event >>> on the containing object. I suppose we could but I see no need for it. >> An example is a domain object that has an event for the creation date by >> a registrar (eventActor), where the server can return the detailed >> entity for the eventActor if a link is provided. > > In other words, a reference to an entity that can be fetched via the URL > by an RDAP client but is not in the current response? Is that the use > case? Or is the URL generic (as in, it doesn't necessarily point to an > RDAP entity)? I was thinking of the first case. A url to an RDAP entity that is not in the response is kind of important. Perhaps both can be supported, the first is a "self" link, an external url to say a registrar web site could be an "about" or "service" link. -Ernie From johnl@iecc.com Wed Jun 19 13:07:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B3621F9FBA for ; Wed, 19 Jun 2013 13:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.77 X-Spam-Level: X-Spam-Status: No, score=-110.77 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTRaxgAzYWHE for ; Wed, 19 Jun 2013 13:07:52 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4678F21F9FD1 for ; Wed, 19 Jun 2013 13:07:48 -0700 (PDT) Received: (qmail 70078 invoked from network); 19 Jun 2013 20:07:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Jun 2013 20:07:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c20f91.xn--btvx9d.k1306; i=johnl@user.iecc.com; bh=AqY9mul2W74V9Og0b2NbIUtuoeStfIL4waUvVdQbbe8=; b=qkr5jFV1tzpAYBFUuNFJNjX4ElrpAB8p/5WtlFvsFkhYDpz25K/n6hiyyk/LSXkJcdZx8W6drOyGZl/n+J3mfpfpp/mEO3RRDRr7i/Wous8XEOgtFhUuI9/ZCAbYBefd3rvYjM4J40kcpNA6/vMTrAoaGOraXMbdjy1yzWisNuO6/xtJg7EFbKu9tYEp8A8BePibW336WyIH7NvO4yQ+hQMp6WMLiImTl/UTq+7/qWzlQM2UsZHFAmjPaB8ua+DS DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c20f91.xn--btvx9d.k1306; olt=johnl@user.iecc.com; bh=AqY9mul2W74V9Og0b2NbIUtuoeStfIL4waUvVdQbbe8=; b=qjdMxKmd3RJUV6NfPmdUwYivfXnA7Y6Nj2/Gsl+Piu7QMD5SJUcRJo5gRDDRQ+tq2XosxEmY7xxHvpQU4yoHzrHYOy7SG616M7Fiebg9JJxYSlu812JTgXy9xsM4tuoM/xGjc6xk97R26vqxODe5OXJ/kjVjmvkESwaQhth636iq3GKWdK5U/G3HDP3mtZSJfIcaILhlQgKDCBYMWzEeHo3Be1nm8iQDYFf51Nj2qBk0txb2Av5BIYl7XsUQwk34 Date: 19 Jun 2013 20:07:23 -0000 Message-ID: <20130619200723.49384.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D55@CHAXCH01.corp.arin.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 20:07:57 -0000 >>Really? 3000 http queries per second is very large scale. > >Aren't you mixing models? 3000 HTTP queries/sec would be for an HTTP >bootstrap server, not for an IANA XML/JSON registry approach where the >clients fetch the data once in a blue moon. Sort of, but speaking as a Lazy Programmer(TM), I don't think that the IANA registry approach will work the way you want it to. The assumption here appears to be that RDAP clients will fetch a document from the registry, spin up an XML parser (that's what it's in now), turn it into some internal database format, store the database in an atomic way (in case two clients decide to fetch it at the same time), then provide some way for that client and other clients on the same host to query the internal database, and to realize when the TTL on the internal database has expired and fetch it again. I can't help but note that this bootstrap process is considerably more complex than the RDAP queries it's supposed to precede. We Lazy Programmers will either fetch the file every time and throw it away, or more likely we will notice that even though there is no formal numbers bootstrap pool, in fact all of the RIRs know who's responsible for what, so we'll use one of them as a boostrap anyway. For the names, on the other hand, sticking the TLD or the whole domain into a DNS name as part of a wget or curl command is about two lines of shell script. R's, John From edainow@afilias.info Wed Jun 19 14:22:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6092411E80DF for ; Wed, 19 Jun 2013 14:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcKNHgIi5c6p for ; Wed, 19 Jun 2013 14:22:21 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB3111E80E9 for ; Wed, 19 Jun 2013 14:22:21 -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 1UpPpc-0001kU-5h for weirds@ietf.org; Wed, 19 Jun 2013 21:22:20 +0000 Received: from mail-oa0-f44.google.com ([209.85.219.44]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UpPpc-0002af-5Q for weirds@ietf.org; Wed, 19 Jun 2013 21:22:20 +0000 Received: by mail-oa0-f44.google.com with SMTP id l10so7222296oag.31 for ; Wed, 19 Jun 2013 14:22:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=ZCWKfOndNPCM+FPZWihO6gbpOkO1qS00CP3t7YAsdGA=; b=i3bARqcT8Z77RaKVNzYpVSzaQRW5jcesxit4+Jj4rd88de54w07qXxeew8KgaGtLqa AhUPLtCsE6Kdr4AGMR9hMfRrOvHElBt4u8oKOYZNhrUWnhiBDPV6aS1QOyQCqErL5ccu 8IvqC8oKBLqp7dVokbIQvsZgHiTr4Tq2THOl1Rob3Izt+Wik4VfgIJjJ/7n7tcVGmrdJ StC6IhPN/7zFNXri1ckDBwnRkUecYtsd4UHDb6/s0Au1M9RGRVcNdTdtBWuToTdzn25h DG1XzHyLcwssjP2iOPzgEOTazvgr6t+Ky6eXpF1yu4EVWSfGfGgLtEO8PDxLscXq/oPD T25Q== X-Received: by 10.182.165.232 with SMTP id zb8mr263950obb.101.1371676935126; Wed, 19 Jun 2013 14:22:15 -0700 (PDT) X-Received: by 10.182.165.232 with SMTP id zb8mr263944obb.101.1371676935013; Wed, 19 Jun 2013 14:22:15 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id c20sm26496357oez.4.2013.06.19.14.22.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 14:22:14 -0700 (PDT) Message-ID: <51C22101.7070903@afilias.info> Date: Wed, 19 Jun 2013 17:22:09 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Levine References: <20130619200723.49384.qmail@joyce.lan> In-Reply-To: <20130619200723.49384.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlPUHspwEKuqQkDv9HTR4X9rb1E5D+HUokcuq2PfPjGv1M+ul6R6dmuIbR2yuhLGtiVXRhlgDzMXiSffXjsgS1R9Aa1sE2EkrC+xZB+sxHyiU0EyNmgKFgCyZkDPZJ0FdneBVXS Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 21:22:26 -0000 Yes, the process you describe is complex. So an Extra Lazy Programmer, realizing that the IANA tables don't change very much (certainly not for Numbers or the major TLDs) would use a simple utility script once every month or so to pull the IANA tables for names and/or numbers, strip the XML and store them as two column text files (TLD or Number, URL). These text files (all relatively small) are read by client software for in memory lookups. The RDAP redirector (assuming it gets updated frequently) provides backup for the few outdated entries in the tables between local updates. The Super Extra Lazy Programmer, simply waits for IANA to publish the tables and someone on the mailing list to publish an open source utility script they can use to create their own local files. -Ernie On 6/19/2013 4:07 PM, John Levine wrote: >>> Really? 3000 http queries per second is very large scale. >> Aren't you mixing models? 3000 HTTP queries/sec would be for an HTTP >> bootstrap server, not for an IANA XML/JSON registry approach where the >> clients fetch the data once in a blue moon. > Sort of, but speaking as a Lazy Programmer(TM), I don't think that the > IANA registry approach will work the way you want it to. > > The assumption here appears to be that RDAP clients will fetch a > document from the registry, spin up an XML parser (that's what it's in > now), turn it into some internal database format, store the database > in an atomic way (in case two clients decide to fetch it at the same > time), then provide some way for that client and other clients on the > same host to query the internal database, and to realize when the TTL > on the internal database has expired and fetch it again. > > I can't help but note that this bootstrap process is considerably more > complex than the RDAP queries it's supposed to precede. We Lazy > Programmers will either fetch the file every time and throw it away, > or more likely we will notice that even though there is no formal > numbers bootstrap pool, in fact all of the RIRs know who's responsible > for what, so we'll use one of them as a boostrap anyway. > > For the names, on the other hand, sticking the TLD or the whole domain > into a DNS name as part of a wget or curl command is about two lines > of shell script. > > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@taugh.com Wed Jun 19 15:04:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872FC21F9D4D for ; Wed, 19 Jun 2013 15:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z3fKjnDKmew for ; Wed, 19 Jun 2013 15:04:23 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B1F1721F9DEF for ; Wed, 19 Jun 2013 15:03:59 -0700 (PDT) Received: (qmail 97068 invoked from network); 19 Jun 2013 22:03:56 -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:cleverness; s=17b2b.51c22acc.k1306; bh=pdl6Cw/yRkAhhVEEI3tWZICkPt6bQ+mRBIniB0XelOM=; b=GsQ4H9e/h8tqS1RwK9deYvaoSCyHIXUhiynfDKgRIb8pKZZxUp1gNLZvk3x6MoLx7x75WohqWd5pu7aQzzC8SQqQd1pQCWdRIDzIqtel0OtWbyp3vuuO+28mbbM3VKS23gzad57lPEmODsy2Qe/siu1So3rwqNipWxS6ynp0NONmjLLDmmiF1+LntvJa4LeCvfmRV2FCDeqVa68EXcSqDUY3X8Ilayx1PkGnh3rdEn1fWe0yskJvhSaaeARFxn0L 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:cleverness; s=17b2b.51c22acc.k1306; bh=pdl6Cw/yRkAhhVEEI3tWZICkPt6bQ+mRBIniB0XelOM=; b=jm7icDmMdgHLkX/p5ktIAdF5gXAOYsgZfq10skGIXvGn1B80l4cZhQhHzZDBPZwsTk7emxG0pw7uml0X/l5PZMMdKkubOVWZT2YeE+QQbTN+qXBbCYC0ntTr6DCsPZV9vL51KtpeokzSxntQT7e8hXPIunNZEGlb2/jNWtjGlW5wwE0vBliboM/ehyRHPkebWu1BHU92eq1RGpDDtwU1CUSOI9y4cJjAPtZOx04Zf+n6Fz/JvzlT4X9Sdl8jX/CH Received: (ofmipd 127.0.0.1); 19 Jun 2013 22:03:33 -0000 Date: 19 Jun 2013 18:03:55 -0400 Message-ID: From: "John R Levine" To: "Ernie Dainow" In-Reply-To: <51C22101.7070903@afilias.info> References: <20130619200723.49384.qmail@joyce.lan> <51C22101.7070903@afilias.info> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 22:04:24 -0000 > Yes, the process you describe is complex. So an Extra Lazy Programmer, > realizing that the IANA tables don't change very much (certainly not for > Numbers or the major TLDs) would use a simple utility script once every month > or so to pull the IANA tables for names and/or numbers, strip the XML and > store them as two column text files (TLD or Number, URL). You must know much more industrious lazy programmers than I do. Assuming you have such a file, could you show me how to splice the appropriate server name for an IPv6 address into a wget in a shell script in a reasonable number of lines of code? Keep in mind that the IANA IPv6 allocations range in length from /12 to /23, and you should't cheat, since there are adjacent /23's assigned to different RIRs. For some real life examples, look at the freeware WHOIS client that comes with FreeBSD. It has some flags to query specific WHOIS servers, and "-c foo" to query foo.whois-servers.net, but that's it. The linux client can use a config file of patterns and servers, but as far as I can tell, linux distros don't come with one (my Ubuntu doesn't). A few weenies use one that's maintained on a git site. Really, I'm not opposed to a reasonable bootstrap, but reasonable has to be something that isn't more work than the actual work. Do you really think that .domain.rdap.arpa is unworkable for names? It sure would be nice to be able to do something like this to look up a domain's abuse contact: dom=$1 wget http://$(echo "$dom"|sed -e 's/.*\.//').domain.rdap.arpa/contact/abuse Or assuming we do the numbers pool: ip=$1 wget http://pool.numbers.rdap.arpa/ip/$1/abuse Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From superuser@gmail.com Wed Jun 19 16:30:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3492E21F9ED2 for ; Wed, 19 Jun 2013 16:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrKa49dveHsG for ; Wed, 19 Jun 2013 16:30:37 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2A68B21F9ED0 for ; Wed, 19 Jun 2013 16:30:36 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so5136689wgh.24 for ; Wed, 19 Jun 2013 16:30:35 -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=PLbgtsIB09tMsA82cYpak/PsYaQ+FUWLzGOTQYC1Amk=; b=WFCxOCRUY1S8CiolqeMtQYxyN/zzHYkv/jo7Eq7KaMpoS8C3IlY8TYLYufm/eW8GH4 Hk0bkojTCtuh4DyW0QfWeSozwsDkpduz3tyKRiuef+4DY3lcKLc74Ml9RDBeg6kybdK3 t9TAN+lBoqB+pvrrBG74swtzeXMVirfPtKnSW6LtcFsBhvWvlqTx/qKF3P0RRHHjalbh VdEiIZ65F3BSPRDCIuwvkvypxeqS3xMUBDbSck9mW67zhSAHY7S6HroRGrmJf0N5NlF4 Kh5ezugb/av6TKC4dry8v/ePoSM/Uyaxvp5DE/WhZoh0O7rAJvagX9CuplqZYtLj0Rm+ mPlg== MIME-Version: 1.0 X-Received: by 10.180.102.37 with SMTP id fl5mr12657137wib.52.1371684635297; Wed, 19 Jun 2013 16:30:35 -0700 (PDT) Received: by 10.180.126.97 with HTTP; Wed, 19 Jun 2013 16:30:35 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D2A@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7D2A@CHAXCH01.corp.arin.net> Date: Wed, 19 Jun 2013 16:30:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=f46d044517f76e50b704df8a3739 Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 23:30:38 -0000 --f46d044517f76e50b704df8a3739 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2013 at 9:28 AM, Andy Newton wrote: > From: "Murray S. Kucherawy" > Date: Wednesday, June 19, 2013 10:41 AM > To: Andrew Newton > Cc: Pete Resnick , "weirds@ietf.org" < > weirds@ietf.org> > Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 > > I don't have a preference either way. I also don't think the delay > identified in #2 is a big concern for me; is there some reason we should > avoid it? > > > If the publication of the draft is to be delayed, then why do we have a > milestone for it so early? I think that is one of the drivers. > > I do think that #2 would keep the MUST language, which is contrary to > the other edits we just made=10. > > > The milestone says "to the IESG', not "published as an RFC". We have little enough control over the actual publication process that I would avoid including it in a time estimate. Barring some major problem discovered during IESG Evaluation, I consider the milestone reached when the document enters IESG Evaluation state. It may still have to wait for something else before the RFC Editor can publish it, but that doesn't mean the WG hasn't completed its work. -MSK, behatted --f46d044517f76e50b704df8a3739 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 19, 2013 at 9:28 AM, Andy Newton <andy@arin.net> wrote:
From: "Murray S. Kucherawy&quo= t; <superuser@g= mail.com>
Date: Wednesday, June 19, 2013 10:4= 1 AM
To: Andrew Newton <andy@arin.net>
Cc: Pete Resnick <presnick@qti.qualcomm.com<= /a>>, "weirds@= ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] AD Evaluation= of draft-ietf-weirds-using-http-05

I don't have a preference either way.=A0 I also don't think the dela= y identified in #2 is a big concern for me; is there some reason we should = avoid it?

If the publication of the draft is to be delayed, then why do we have = a milestone for it so early? I think that is one of the drivers.

I do think that #2 would keep the MUST language, which is contrary to = the other edits we just made=10.



The= milestone says "to the IESG', not "published as an RFC"= .=A0 We have little enough control over the actual publication process that= I would avoid including it in a time estimate.=A0 Barring some major probl= em discovered during IESG Evaluation, I consider the milestone reached when= the document enters IESG Evaluation state.=A0 It may still have to wait fo= r something else before the RFC Editor can publish it, but that doesn't= mean the WG hasn't completed its work.

-MSK, behatted

--f46d044517f76e50b704df8a3739-- From superuser@gmail.com Wed Jun 19 16:33:58 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F6E21F9DE4 for ; Wed, 19 Jun 2013 16:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cekPygjCnn5x for ; Wed, 19 Jun 2013 16:33:58 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9321F9DDF for ; Wed, 19 Jun 2013 16:33:57 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so4934017wes.37 for ; Wed, 19 Jun 2013 16:33:57 -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=aRWikLgmH4W+xBUEzOaBSWgkKXWAekc72gp54Rn3LeM=; b=UiS33N0e2mXSXB8Y2UJCjy3+BXNhJmMMbR+0Kg9tF66LdjeYymbK61s6YS76gbkpqu 9PDfiErp73zJ/XohATqZRh2tDorIoZP+cdsHU3F+HSzXkkzEqZNPPGoiqtKP+69umiuo aZLovqmnW8Usft6gv3lOlyvGhA2PKZlC/ZAMn0GtlxPnyC5XvJuw0nshowXhNHamfngj jM69CkZenbn/Zrjtg9GZt4G+F4FVYX8gl9j3nQDvpJq13Wv6AgCOeW2s4Nt7D7xenecD AAuSRhT9Bwbxw0ymoBKu7V5F587c6KA4qW3RAdCSHUT5GNjt8TErvupRGjrbnEmb/RGM 0mCg== MIME-Version: 1.0 X-Received: by 10.180.102.37 with SMTP id fl5mr12663027wib.52.1371684837068; Wed, 19 Jun 2013 16:33:57 -0700 (PDT) Received: by 10.180.126.97 with HTTP; Wed, 19 Jun 2013 16:33:56 -0700 (PDT) In-Reply-To: References: <20130619200723.49384.qmail@joyce.lan> <51C22101.7070903@afilias.info> Date: Wed, 19 Jun 2013 16:33:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=f46d044517f7766dc704df8a4338 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 23:33:59 -0000 --f46d044517f7766dc704df8a4338 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 19, 2013 at 3:03 PM, John R Levine wrote: > Do you really think that .domain.rdap.arpa is unworkable for names? > It sure would be nice to be able to do something like this to look up a > domain's abuse contact: > > Can you (or someone) point me/us at something that explains how .ARPA is administered? Is it an IANA project, and we would need to set up a registry in the usual way that results in updates to that zone? -MSK --f46d044517f7766dc704df8a4338 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 19, 2013 at 3:03 PM, John R Levine <johnl@tau= gh.com> wrote:
Do you really think that <tld>.domain.= rdap.arpa is unworkable for names? It sure would be nice to be able to do s= omething like this to look up a domain's abuse contact:


Can you (or someone) point me/us at so= mething that explains how .ARPA is administered?=A0 Is it an IANA project, = and we would need to set up a registry in the usual way that results in upd= ates to that zone?

-MSK

--f46d044517f7766dc704df8a4338-- From johnl@taugh.com Wed Jun 19 17:25:00 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1680A21F9DAE for ; Wed, 19 Jun 2013 17:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3tdWxQchRY1 for ; Wed, 19 Jun 2013 17:24:58 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 078F421F9D95 for ; Wed, 19 Jun 2013 17:24:54 -0700 (PDT) Received: (qmail 25784 invoked from network); 20 Jun 2013 00:24:54 -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:cleverness; s=64b7.51c24bd6.k1306; bh=iFDeMF5j6vQCBk8NRWQgV2Og37ujHed25aqQLELWlvw=; b=dFx9UfVOuPbeJcFT2zpi3FQy6YACeZlSMqNDUf7Mzi1iYWSvO/ACT+LXQLCpt/awuXoRGIBEGExHQ0lYmaF6cPPAZH69dT+9L6nhhEbXUbK0v5o0OGIRWaepDL+0emWyUYFHf9oOcBzR6gX+rlO5x8ABJ0SgAQ9hId2pGQWYABxGFG1kBLgPHkk/7oHb4wxAy0Ym7ENm1vEjvK0lUAczwoWMJO8Nsamlvwnm/JtOpZIkGhjNFtaYWxZEbCjMJtWg 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:cleverness; s=64b7.51c24bd6.k1306; bh=iFDeMF5j6vQCBk8NRWQgV2Og37ujHed25aqQLELWlvw=; b=mxXySMwI/YADPu+rsQBTybWF//VVvSG7CXKeEbINMmJ7LssUSgXzIlshw2+0PjtYnKUqWhT5ti8pJAhXg526dQCVS8EMlyXyv8EXyn2NG7Z2D0kMF6J+uWvB6sRjsbecmY7sDP1PXpyYL1Hk+F4hTcCb6VytV4pHSKFn6gyq8JaKiX0B+L7pCwLKWyjIzvdRhoGEmVrX1RCpSmo8EpMwkN6VPT+Z/mvTSYv6/V7PZYct+DpAOFi4IiCqCwQVQMUP Received: (ofmipd 127.0.0.1); 20 Jun 2013 00:24:32 -0000 Date: 19 Jun 2013 20:24:54 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20130619200723.49384.qmail@joyce.lan> <51C22101.7070903@afilias.info> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 00:25:00 -0000 > Can you (or someone) point me/us at something that explains how .ARPA is > administered? Is it an IANA project, and we would need to set up a > registry in the usual way that results in updates to that zone? RFC 3172 describes the operation of .ARPA. It roughly says that if the IESG approves a standards track document that adds something to .ARPA, then the IAB asks IANA to implement it. For the RDAP names, my proposal (which I can merge into Marc's I-D if people want) is to have a bootstrap per TLD, so the name or addresses of the RDAP bootstrap server is a field added to their existing TLD database, with no new registries needed. I expect the process of updating rdap.arpa would be similar to that for in-addr.arpa or ip6.arpa, but that'd be up to IANA. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From marc.blanchet@viagenie.ca Wed Jun 19 17:40:32 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CD921F9E73 for ; Wed, 19 Jun 2013 17:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SecCHNmbmz1k for ; Wed, 19 Jun 2013 17:40:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 930B921F9E41 for ; Wed, 19 Jun 2013 17:40:31 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D874C40446; Wed, 19 Jun 2013 20:40:30 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_38559ED0-E734-4FA4-86DE-B9ACABD795EA" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Wed, 19 Jun 2013 20:40:29 -0400 Message-Id: References: <20130619200723.49384.qmail@joyce.lan> <51C22101.7070903@afilias.info> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1508) Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 00:40:32 -0000 --Apple-Mail=_38559ED0-E734-4FA4-86DE-B9ACABD795EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2013-06-19 =E0 19:33, "Murray S. Kucherawy" a = =E9crit : > On Wed, Jun 19, 2013 at 3:03 PM, John R Levine = wrote: > Do you really think that .domain.rdap.arpa is unworkable for = names? It sure would be nice to be able to do something like this to = look up a domain's abuse contact: >=20 >=20 > Can you (or someone) point me/us at something that explains how .ARPA = is administered? http://www.iana.org/domains/arpa and RFC3172. > Is it an IANA project, and we would need to set up a registry in the = usual way that results in updates to that zone? if we go that route, then we will put some guidance in the RFC and IANA = will implement it. The details of this is not important at this point. = We need to first agree that this is the right approach. Marc (also IAB member shepherd for .arpa liaison to IANA) >=20 > -MSK=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_38559ED0-E734-4FA4-86DE-B9ACABD795EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 superuser@gmail.com> a =E9crit = :

On Wed, Jun 19, 2013 at 3:03 PM, John R = Levine <johnl@taugh.com> wrote:
Do you really think = that <tld>.domain.rdap.arpa is unworkable for names? It sure would = be nice to be able to do something like this to look up a domain's abuse = contact:


Can you (or someone) point me/us at = something that explains how .ARPA is = administered?


  Is it an IANA project, and we would = need to set up a registry in the usual way that results in updates to = that = zone?

if we = go that route, then we will put some guidance in the RFC and IANA will = implement it.  The details of this is not important at this point. = We need to first agree that this is the right = approach.

Marc (also IAB member shepherd for = .arpa liaison to IANA)



-MSK

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

= --Apple-Mail=_38559ED0-E734-4FA4-86DE-B9ACABD795EA-- From aservin@lacnic.net Wed Jun 19 20:11:19 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D3A21F9BC4 for ; Wed, 19 Jun 2013 20:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.376 X-Spam-Level: X-Spam-Status: No, score=0.376 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfuxOXwyOaDo for ; Wed, 19 Jun 2013 20:11:15 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id A9A6921F9BC9 for ; Wed, 19 Jun 2013 20:11:13 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (110-170-171-184.static.asianet.co.th [110.170.171.184]) by mail.lacnic.net.uy (Postfix) with ESMTP id 2AB9430845F for ; Thu, 20 Jun 2013 00:10:54 -0300 (UYT) Message-ID: <51C272CA.9050100@lacnic.net> Date: Thu, 20 Jun 2013 10:11:06 +0700 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <20130619200723.49384.qmail@joyce.lan> In-Reply-To: <20130619200723.49384.qmail@joyce.lan> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:11:19 -0000 I agree with the three (Andy, Carlos and John). This bootstraping would suppose to be once in a while, so we shouldn't need a large infrastructure. But as John said, we lazy programers can be a problem; and a big one. Regards, as On 6/20/13 3:07 AM, John Levine wrote: >>> Really? 3000 http queries per second is very large scale. >> Aren't you mixing models? 3000 HTTP queries/sec would be for an HTTP >> bootstrap server, not for an IANA XML/JSON registry approach where the >> clients fetch the data once in a blue moon. > Sort of, but speaking as a Lazy Programmer(TM), I don't think that the > IANA registry approach will work the way you want it to. > > The assumption here appears to be that RDAP clients will fetch a > document from the registry, spin up an XML parser (that's what it's in > now), turn it into some internal database format, store the database > in an atomic way (in case two clients decide to fetch it at the same > time), then provide some way for that client and other clients on the > same host to query the internal database, and to realize when the TTL > on the internal database has expired and fetch it again. > > I can't help but note that this bootstrap process is considerably more > complex than the RDAP queries it's supposed to precede. We Lazy > Programmers will either fetch the file every time and throw it away, > or more likely we will notice that even though there is no formal > numbers bootstrap pool, in fact all of the RIRs know who's responsible > for what, so we'll use one of them as a boostrap anyway. > > For the names, on the other hand, sticking the TLD or the whole domain > into a DNS name as part of a wget or curl command is about two lines > of shell script. > > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From aservin@lacnic.net Wed Jun 19 20:20:46 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506AF21E8088 for ; Wed, 19 Jun 2013 20:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h56wSt5V-sXx for ; Wed, 19 Jun 2013 20:20:41 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 74C3211E80CC for ; Wed, 19 Jun 2013 20:20:41 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (110-170-171-184.static.asianet.co.th [110.170.171.184]) by mail.lacnic.net.uy (Postfix) with ESMTP id 088AD308495 for ; Thu, 20 Jun 2013 00:20:16 -0300 (UYT) Message-ID: <51C274FC.6040207@lacnic.net> Date: Thu, 20 Jun 2013 10:20:28 +0700 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7703@CHAXCH01.corp.arin.net> <51C16BDC.5050007@viagenie.ca> In-Reply-To: <51C16BDC.5050007@viagenie.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:20:46 -0000 IPs have allocation hierarchy, that is why ip6 and in-addr are in the way the are. ASNs do not have it and the registry is a bit messy (at least the 2 bytes one). So, why not just use: 199679.as.rdap.arpa? It would be 4 billion zone though. On 6/19/13 3:29 PM, Simon Perreault wrote: > 9.7.6.9.9.1.0.0.0.0.as.rdap.arpa. Just a thought. regards, as From carlosm3011@gmail.com Wed Jun 19 20:43:49 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B0111E80F0 for ; Wed, 19 Jun 2013 20:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, NO_RELAYS=-0.001, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJtIYQ8C2Ju8 for ; Wed, 19 Jun 2013 20:43:49 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3E92C11E80EC for ; Wed, 19 Jun 2013 20:43:49 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so852972qab.1 for ; Wed, 19 Jun 2013 20:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DunbOBpRf6pmnjNjQXqLrAKllmMMZjujeNzdCo/M0gI=; b=VZ+nfO+cdOJIkz+STPSaFX4wqNFKKDdjt6gkli6eDAVhBJM1P0b7xwyidv6DTCBMsM uj3IxxTk5XenCidQ2bApVdrJ7IptsBpRNIGQTTCLozHjngPhaTVSjobrh7RfbMQRUL6C uhG3JbG24//Iw8S7SiY9/YWeWdWu5TbBu2pHwa+JZ1VEob89PDL6U3cRl4oEy4QJZQAz BckRMU60lOT9geT65shwF4T9W6h369GtDsZxiTOLEuJSkEHjdBtsL7nX4w847fjboo5w Pj3flSn9khPz5IseyKDUa7bdnwiGaUFCj69MtlJ7kXXfV7zVGtqgZbo/ANxrlVhhCvD7 XTiQ== X-Received: by 10.224.65.72 with SMTP id h8mr7042538qai.73.1371699828708; Wed, 19 Jun 2013 20:43:48 -0700 (PDT) Received: from europa.local ([2001:470:d815:fe0:424:48c:387d:c5d9]) by mx.google.com with ESMTPSA id 11sm38146590qek.1.2013.06.19.20.43.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 20:43:47 -0700 (PDT) Message-ID: <51C27A6F.8060603@gmail.com> Date: Thu, 20 Jun 2013 00:43:43 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Arturo Servin References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF7703@CHAXCH01.corp.arin.net> <51C16BDC.5050007@viagenie.ca> <51C274FC.6040207@lacnic.net> In-Reply-To: <51C274FC.6040207@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:43:49 -0000 Yup, the AS registry is flat. Reverse notation in this case does not help. One possibility is to have a flat zone with potentially 4billion records (although it would be closer to 40k-50k records today, not unmanageable at all). cheers, ~Carlos On 6/20/13 12:20 AM, Arturo Servin wrote: > > > IPs have allocation hierarchy, that is why ip6 and in-addr are in > the way the are. ASNs do not have it and the registry is a bit messy (at > least the 2 bytes one). > > So, why not just use: > > 199679.as.rdap.arpa? > > It would be 4 billion zone though. > > > On 6/19/13 3:29 PM, Simon Perreault wrote: >> 9.7.6.9.9.1.0.0.0.0.as.rdap.arpa. Just a thought. > > regards, > as > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Thu Jun 20 05:13:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30E021F9C31 for ; Thu, 20 Jun 2013 05:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.954 X-Spam-Level: X-Spam-Status: No, score=-3.954 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuknFKhe4boY for ; Thu, 20 Jun 2013 05:13:39 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id CF72821F9C35 for ; Thu, 20 Jun 2013 05:13:38 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 1A28D165117; Thu, 20 Jun 2013 08:13:38 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 5160D164F6C; Thu, 20 Jun 2013 08:13:37 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 20 Jun 2013 08:13:24 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 08:13:23 -0400 From: Andy Newton To: John R Levine , Ernie Dainow Thread-Topic: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHObTj5jigZPn1Hakq82dMxZSkzcZk+hKyA Date: Thu, 20 Jun 2013 12:13:23 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF826A@CHAXCH01.corp.arin.net> 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.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <5D34B22DE260C3449F8AC087BD091262@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 12:13:44 -0000 On 6/19/13 6:03 PM, "John R Levine" wrote: >> Yes, the process you describe is complex. So an Extra Lazy Programmer, >> realizing that the IANA tables don't change very much (certainly not >>for=20 >> Numbers or the major TLDs) would use a simple utility script once every >>month=20 >> or so to pull the IANA tables for names and/or numbers, strip the XML >>and=20 >> store them as two column text files (TLD or Number, URL). > >You must know much more industrious lazy programmers than I do. I agree with Ernie here. > Assuming=20 >you have such a file, could you show me how to splice the appropriate >server name for an IPv6 address into a wget in a shell script in a >reasonable number of lines of code? Keep in mind that the IANA IPv6 >allocations range in length from /12 to /23, and you should't cheat, >since=20 >there are adjacent /23's assigned to different RIRs. Code for that is in NicInfo. You can consult the source. It wasn't terribly difficult to write at all. I did it at the beach. > >For some real life examples, look at the freeware WHOIS client that comes >with FreeBSD. It has some flags to query specific WHOIS servers, and >"-c foo" to query foo.whois-servers.net, but that's it. > >The linux client can use a config file of patterns and servers, but as >far=20 >as I can tell, linux distros don't come with one (my Ubuntu doesn't). A >few weenies use one that's maintained on a git site. A lot of Linux distros use "jwhois", which has some quirks but attempts to figure out the first hop on its own. But even then it sends a lot of domain queries to ARIN and a lot of AS queries to VeriSign. A very large percentage of port 43 queries received by ARIN are not answerable by ARIN because they are domain queries. But we have to answer with something, and in the RDAP world answering with a redirect is just as cheap as answering with a 404. As a side note, a lot of lazy programmers hard code our server IP addresses. We can take an IP out of rotation and there will still be port 43 traffic hitting that IP a year later. >Really, I'm not opposed to a reasonable bootstrap, but reasonable has to >be something that isn't more work than the actual work. > >Do you really think that .domain.rdap.arpa is unworkable for names? >It sure would be nice to be able to do something like this to look up a >domain's abuse contact: > >dom=3D$1 >wget http://$(echo "$dom"|sed -e >'s/.*\.//').domain.rdap.arpa/contact/abuse /contact/abuse was taken out of the drafts sometime back. So I guess this provides some insight about programmers reading RFCs. :) > >Or assuming we do the numbers pool: > >ip=3D$1 >wget http://pool.numbers.rdap.arpa/ip/$1/abuse But you are suggesting a hybrid bootstrap approach. So it is also complex as there are two code paths. In this approach, a lazy programmer is just gonna hit one of the RIR servers and hope for a redirect. After all, that's what a lot of them do today even though there are no such things as redirects in Whois. -andy From andy@arin.net Thu Jun 20 05:16:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F39C21F99D3 for ; Thu, 20 Jun 2013 05:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.889 X-Spam-Level: X-Spam-Status: No, score=-3.889 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v88ov4loVn54 for ; Thu, 20 Jun 2013 05:16:34 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id A12DE21F99D6 for ; Thu, 20 Jun 2013 05:16:34 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 4F406165117; Thu, 20 Jun 2013 08:16:34 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id D4F54164F6F; Thu, 20 Jun 2013 08:16:33 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 20 Jun 2013 08:16:09 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.220]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 08:16:08 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] asEventActor with embedded entities Thread-Index: AQHObE5nmMGqOuKjAEGLLeJHGrqeAZk9eo6A///AhYCAAFmwgP//z6IAgABNdwCAANVqAA== Date: Thu, 20 Jun 2013 12:16:07 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF827F@CHAXCH01.corp.arin.net> In-Reply-To: <51C20742.6000505@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <3393E28E4BF35D4A86D5B7CA69094FCD@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] asEventActor with embedded entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 12:16:40 -0000 On 6/19/13 3:32 PM, "Ernie Dainow" wrote: >I was thinking of the first case. A url to an RDAP entity that is not in >the response is kind of important. > >Perhaps both can be supported, the first is a "self" link, an external >url to say a registrar web site could be an "about" or "service" link. As a client writer, I'm a little apprehensive about this but overall I agree that it makes sense. -andy From johnl@iecc.com Thu Jun 20 09:13:36 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CAF21F9DD1 for ; Thu, 20 Jun 2013 09:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.809 X-Spam-Level: X-Spam-Status: No, score=-110.809 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf7rGrNDI6g0 for ; Thu, 20 Jun 2013 09:13:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFFC21F9DCD for ; Thu, 20 Jun 2013 09:13:31 -0700 (PDT) Received: (qmail 20294 invoked from network); 20 Jun 2013 16:13:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Jun 2013 16:13:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c32a2b.xn--yuvv84g.k1306; i=johnl@user.iecc.com; bh=SCXufCwGH+zwGro23e8rYFhLuvs6t8VuHjenJ97Pcgo=; b=X+2l2uTy1/F3P7R3mijjal3gIptVNe0mE4xYwYpCScZ/T3ygNXSN0gFMCFzwsQ3gjF/9II+KEagxKGaNPX2ANx9Wea0/ppF14JV8AU9iRpQrts6v4ORYNvrF+GButcEqUI7YvCME+JKD2c6IjuQsblddUH5VkQApa9/xpNhCSSjgOJseCij8icGAvFQyDvtcnGuiJrFB8VBU/q7xOqHHAUc2NPdF3nx8oviGmisriM/xdK0bAuB0IbQ0VgUF24UH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c32a2b.xn--yuvv84g.k1306; olt=johnl@user.iecc.com; bh=SCXufCwGH+zwGro23e8rYFhLuvs6t8VuHjenJ97Pcgo=; b=sZonpaqOPXjYBVEnb3aC9ib07k/x6u8FPSauuVgOpZaz/MXIlDyMVYF1VZFYBIeDkuLtW6wE8o1+6yKS6AZ1d4V4FUi1ZACiyUQOgwQnXxb3r2q4UDyJij3NI+fpZY0gORzE0etD1hl2rFtLUIJ7LYsssuHMlXKJnQ2d2HvOBgzVook33dulBSDKV3jWcz/saEl15l0Uc0U0r+Hk0koivg/kNAJYNC/QXXZA3IQWbhAZYRVnq9WBIOdJyHwtFkAx Date: 20 Jun 2013 16:13:08 -0000 Message-ID: <20130620161308.61121.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF826A@CHAXCH01.corp.arin.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:13:36 -0000 >I agree with Ernie here. So I've been scratching my head, trying to channel my inner Lazy Programmer. It occurred to me that a key fact I was forgetting is that for numbers, the bootstrap information changes approximately never, certainly slower than the typical software revision cycle. The IPv4 list, assuming it's by /8, will never change. The IPv6 list hasn't changed since 2006 (other than deprecating old Teredo and 6bone space in 2008) and given how big those /12 allocations are, probably won't change for at least another five years. The ASN list actually changed last week with an assignment to LACNIC, but the previous assignment lasted six years. So in practice it would be workable to bake the bootstrap into numbers clients, with the advice to update your client every year or two. For names, the situation is considerably more fluid. There are several hundred TLDs, likely to increase soon to about 2000. I see that there are updates to the root zone, typically nameserver changes, several times a month which seems like a plausible rough proxy for how often RDAP servers would change, and ICANN is likely to be trickling out new TLDs monthly for the next couple of years. Hence I wouldn't want to bake in anything for names that didn't have a level of indirection to something that can be kept up to date, i.e., .names.rdap.arpa. R's, John From marc.blanchet@viagenie.ca Thu Jun 20 10:19:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2C21F9E6C for ; Thu, 20 Jun 2013 10:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt4Lw9u7o9cc for ; Thu, 20 Jun 2013 10:19:26 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2805821F9D98 for ; Thu, 20 Jun 2013 10:19:25 -0700 (PDT) Received: from h115.viagenie.ca (h115.viagenie.ca [206.123.31.115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 12C8846FA2; Thu, 20 Jun 2013 13:19:24 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <20130620161308.61121.qmail@joyce.lan> Date: Thu, 20 Jun 2013 13:10:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> References: <20130620161308.61121.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1508) Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:19:27 -0000 Le 2013-06-20 =E0 12:13, "John Levine" a =E9crit : >> I agree with Ernie here. >=20 > So I've been scratching my head, trying to channel my inner Lazy > Programmer. It occurred to me that a key fact I was forgetting is > that for numbers, the bootstrap information changes approximately > never, certainly slower than the typical software revision cycle. a) the allocations shall not change. b) therefore, a client that had saved the previous table could only go = back to fetch a new version of the table when a requested object is not = in the range of its current saved version. In this case, it would be = almost "on-demand", not everybody at the same time, etc... Marc. >=20 > The IPv4 list, assuming it's by /8, will never change. The IPv6 list > hasn't changed since 2006 (other than deprecating old Teredo and 6bone > space in 2008) and given how big those /12 allocations are, probably > won't change for at least another five years. The ASN list actually > changed last week with an assignment to LACNIC, but the previous > assignment lasted six years. >=20 > So in practice it would be workable to bake the bootstrap into numbers > clients, with the advice to update your client every year or two. >=20 > For names, the situation is considerably more fluid. There are > several hundred TLDs, likely to increase soon to about 2000. I see > that there are updates to the root zone, typically nameserver changes, > several times a month which seems like a plausible rough proxy for how > often RDAP servers would change, and ICANN is likely to be trickling > out new TLDs monthly for the next couple of years. >=20 > Hence I wouldn't want to bake in anything for names that didn't have a > level of indirection to something that can be kept up to date, i.e., > .names.rdap.arpa. >=20 > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@taugh.com Thu Jun 20 11:17:53 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363EB21F9C0C for ; Thu, 20 Jun 2013 11:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0j+fnPvBbtD for ; Thu, 20 Jun 2013 11:17:52 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 54ABC21F9C88 for ; Thu, 20 Jun 2013 11:17:52 -0700 (PDT) Received: (qmail 48684 invoked from network); 20 Jun 2013 18:17:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=be2b.51c3474f.k1306; bh=YRSZuWkm+PLGmKrfLfI3DAjaSlEbZ/lOWmW7czA00ws=; b=IgMLPiWVtmx0zw+6leJXLo/0I4ZQqDMjSJYWv9eTQKs2gcn/pBkeY1LEn1prEgNV8WR8AKo6TVPyKnpMo+J6c00t38yHq8epaRTmkY2I6/tpFAxQWTpsVfo5MhYFDZJKTpw0FI7ynjWxzeqollsimF2F4eyKSL14GJ2KaHaejtD/UWQwELr8u9WL3gBTl0XLdnlHgJudcbnhj8IvBzVOlNxiZ2Wk+tRv6mDi8F1M8PqYF0J/g7BrVcu+TfqDSJzk 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:cleverness; s=be2b.51c3474f.k1306; bh=YRSZuWkm+PLGmKrfLfI3DAjaSlEbZ/lOWmW7czA00ws=; b=p2Xdgg+HXU5g6gDiIv20WO9eIOMOLgPXzhpr7C8SggZdJsmIS7ys3Vgx0djGZzZ0q6g7ARPfFdXQcBg8e4xPQ3jar8Ckr1+ZhBHZQBccvyIiUMALFvsl8vtOC5YCTXcGSKJLrC3Nicn53BYWP2y0GPNzi/cp7j84gl/oKUbu8auimPCzW42ylaO3190xxUHgJrHyfwr5IM6KOyeBnoa5cK/8kvChhNKYshC1BD5zazqID++3wqmo/rnuow/rrHkw Received: (ofmipd 127.0.0.1); 20 Jun 2013 18:17:29 -0000 Date: 20 Jun 2013 14:17:50 -0400 Message-ID: From: "John R Levine" To: "Marc Blanchet" In-Reply-To: <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-1095898395-1371752271=:61276" Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 18:17:53 -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. --3825401791-1095898395-1371752271=:61276 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > b) therefore, a client that had saved the previous table could only go > back to fetch a new version of the table when a requested object is not > in the range of its current saved version. In this case, it would be > almost "on-demand", not everybody at the same time, etc... Holy DDoS, Batman!* The IPv6 and ASN spaces are both so large that IANA will never allocate more than a small fraction of either. Do you really want clients hammering on IANA every time someone or something accidentally tries to look up something in the unallocated range? Also, the point of the "baked in" was that the RDAP client need not include the ability to update the table. So in 2119-ese, RDAP clients SHOULD use a hints table to select an initial numbers server, with some way to update the table, which might be as crude as installing a new version of the RDAP client, clients MAY use pool.numbers.rdap.arpa as an initial server if there is no hints table available, or the target isn't in the table (they will whether or not we say they can, so we might as well provide a well known name for it), and clients MUST use .domain.rdap.arpa as an initial server for TLD. In each case, the protocol is https. Anyone who plans to run an RDAP server and won't be able to provide https should speak up now. R's, John * - Sacré ddsd, Homme-chauve-souris! --3825401791-1095898395-1371752271=:61276-- From marc.blanchet@viagenie.ca Thu Jun 20 12:22:00 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88BA21F9CE8 for ; Thu, 20 Jun 2013 12:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEHdE03M8Xiu for ; Thu, 20 Jun 2013 12:21:52 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD0D21F9C4D for ; Thu, 20 Jun 2013 12:21:51 -0700 (PDT) Received: from [IPv6:2620::230:c000:bc31:eb77:9cc4:2d9d] (unknown [IPv6:2620:0:230:c000:bc31:eb77:9cc4:2d9d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 726E44044E; Thu, 20 Jun 2013 15:21:50 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Thu, 20 Jun 2013 15:12:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> To: "John R Levine" X-Mailer: Apple Mail (2.1508) Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 19:22:01 -0000 Le 2013-06-20 =E0 14:17, "John R Levine" a =E9crit : >> b) therefore, a client that had saved the previous table could only = go back to fetch a new version of the table when a requested object is = not in the range of its current saved version. In this case, it would be = almost "on-demand", not everybody at the same time, etc... >=20 > Holy DDoS, Batman!* >=20 > The IPv6 and ASN spaces are both so large that IANA will never = allocate more than a small fraction of either. Do you really want = clients hammering on IANA every time someone or something accidentally = tries to look up something in the unallocated range? You are continually taking the point that that is hitting the IANA web = servers hard. Caching infrastructure are all available today for much = larger issues than we are discussing and as I wrote before, IANA is = already using caching infrastructure. So it is not as a big issue that = you are arguing. Obviously, it has to be planned with IANA, but this is = not a first. >=20 > Also, the point of the "baked in" was that the RDAP client need not = include the ability to update the table. >=20 > So in 2119-ese, >=20 > RDAP clients SHOULD use a hints table to select an initial numbers = server, with some way to update the table, which might be as crude as = installing a new version of the RDAP client, >=20 > clients MAY use pool.numbers.rdap.arpa as an initial server if there = is no hints table available, or the target isn't in the table (they will = whether or not we say they can, so we might as well provide a well known = name for it), and >=20 > clients MUST use .domain.rdap.arpa as an initial server for TLD. >=20 > In each case, the protocol is https. Anyone who plans to run an RDAP = server and won't be able to provide https should speak up now. >=20 > R's, > John >=20 > * - Sacr=E9 ddsd, Homme-chauve-souris! From johnl@taugh.com Thu Jun 20 12:34:06 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FAB21F9D4D for ; Thu, 20 Jun 2013 12:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1LHPMEgciKP for ; Thu, 20 Jun 2013 12:34:05 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2964821F9F16 for ; Thu, 20 Jun 2013 12:34:04 -0700 (PDT) Received: (qmail 68083 invoked from network); 20 Jun 2013 19:34:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=109f1.51c3592c.k1306; bh=1qwGpfaaINdmApSsjIY8LJHvlQsCuvhqxpX6e5fhYDs=; b=lPrE0hcPsl8hgxYNYP33qUw8gbypKkSIxybIkq9l5BFrM3/6azKPlcbQptwTiLL1XhShcTmeD9dUHVcnvN9CJdzpBv1k6neCCjDpmZGEhT7RpXZX3bxF6j/Uup6YddtkSdUI3s4SURi+TZvhMuEfFSCf9nEMJ1CfJH3EmtoZOtN2k0/ctYC+9U5Ubxlp09Jzi2NOMnbehof4d5D3rKdTIctLQ7dJ1mrTrjTJxloDg2Oy+gxSCTy2KBNcHwc+K3cX 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:cleverness; s=109f1.51c3592c.k1306; bh=1qwGpfaaINdmApSsjIY8LJHvlQsCuvhqxpX6e5fhYDs=; b=noOEeIVrBgYYPxfU3Yz0SPZWr4/s2h4DvOu/Jdabhes3bks4H6iKVFkLF0Q/EbOs/islR6/VJ3k2BpzLUtlZxwWDCNuEyWbzgFUzBeKP6W1tY15X5wcf0FW8L7gKrz2LteOsNE2e8t61mXaC28qe/bGP/KF6r0ACmv4x8h4NNIRz504tfnx99iUMI28XVLpMDtHa8oL6gVCiavkPgW8U8XIKb2pm+XO0TMXDopEBRWWthWbu+LK0PRIg093OFsJA Received: (ofmipd 127.0.0.1); 20 Jun 2013 19:33:41 -0000 Date: 20 Jun 2013 15:34:03 -0400 Message-ID: From: "John R Levine" To: "Marc Blanchet" In-Reply-To: References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 19:34:06 -0000 >> The IPv6 and ASN spaces are both so large that IANA will never allocate more than a small fraction of either. Do you really want clients hammering on IANA every time someone or something accidentally tries to look up something in the unallocated range? > > You are continually taking the point that that is hitting the IANA web servers hard. Caching infrastructure are all available today for much larger issues than we are discussing and as I wrote before, IANA is already using caching infrastructure. So it is not as a big issue that you are arguing. Obviously, it has to be planned with IANA, but this is not a first. I think you're missing two key points here. One is that this wouldn't just happen each time there's a change to the table (roughly never), it'd happen each time someone tries to check an address or ASN that's not in the table, which I expect will happen all the time. Unless you expect IANA to add table entries saying "This isn't allocated and won't be anytims soon", which would be a giant can of worms, there's no reverse caching to keep clients from hitting it on each query of an unallocated address or ASN, and there are a lot of unallocated addresses. >> Also, the point of the "baked in" was that the RDAP client need not >> include the ability to update the table. The Lazy Programmer in me is sure that even if we told people that every RDAP client has to include something to fire off a daemon and do a table update on demand, it's not going to happen. So please let's not tell them to. >> So in 2119-ese, >> >> RDAP clients SHOULD use a hints table to select an initial numbers server, with some way to update the table, which might be as crude as installing a new version of the RDAP client, >> >> clients MAY use pool.numbers.rdap.arpa as an initial server if there is no hints table available, or the target isn't in the table (they will whether or not we say they can, so we might as well provide a well known name for it), and >> >> clients MUST use .domain.rdap.arpa as an initial server for TLD. >> >> In each case, the protocol is https. Anyone who plans to run an RDAP server and won't be able to provide https should speak up now. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From edainow@afilias.info Thu Jun 20 12:42:45 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197B711E8127 for ; Thu, 20 Jun 2013 12:42:45 -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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKZL-4og+ebu for ; Thu, 20 Jun 2013 12:42:40 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1625C11E80A5 for ; Thu, 20 Jun 2013 12:42:40 -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 1Upkkh-0001X6-4S for weirds@ietf.org; Thu, 20 Jun 2013 19:42:39 +0000 Received: from mail-la0-f54.google.com ([209.85.215.54]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Upkkh-0003x6-3T for weirds@ietf.org; Thu, 20 Jun 2013 19:42:39 +0000 Received: by mail-la0-f54.google.com with SMTP id ec20so6088627lab.27 for ; Thu, 20 Jun 2013 12:42:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=j8SoP1gPakCHJk6JfN/457FikyooYECWdxe9mFhKalw=; b=DbCl3q8Jqyo0u3KQNX+mdaLfZSedFwxQ7jgWxTvcp9DzFiY3BVNJqmK5IQ9Ohxt6tI ZkF3NvRI8k5zpGCUUYKe9WDjj6Eiik7QVIcPVVMOm2Ie5uzgUWc1T0BJ7c/xfrrut8zC QE+oG36MmdJ1lORBLqnNXfgkMo43uC4QjRpAmWLAHB0IV8xVbiHFW+tu2ugCk8t2AKEG erIX3BHw1uw6NprhDp0X6WQJRdzKpMnuICehPhcXTUizAzxDWhdNGgIapMaC6/u05W2e CvJH7EF1V1PBJpqWeUbBQFKdcG3wJUQyP5axkn0Fj/MM2LVns7s2HsKkDZqnGdFaEIu2 /+XA== X-Received: by 10.112.169.71 with SMTP id ac7mr6221238lbc.42.1371757352767; Thu, 20 Jun 2013 12:42:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.169.71 with SMTP id ac7mr6221233lbc.42.1371757352609; Thu, 20 Jun 2013 12:42:32 -0700 (PDT) Received: by 10.112.79.137 with HTTP; Thu, 20 Jun 2013 12:42:32 -0700 (PDT) In-Reply-To: References: <20130619200723.49384.qmail@joyce.lan> <51C22101.7070903@afilias.info> Date: Thu, 20 Jun 2013 15:42:32 -0400 Message-ID: From: Ernie Dainow To: John R Levine Content-Type: multipart/alternative; boundary=001a11c34484b8767f04df9b25dd X-Gm-Message-State: ALoCoQn+5y9GtNsfP8G/UFQDz8Jgki7NooYqe7+BgorNqiX893JF9iKErLbfmWwXHtDgY1ic71zEhW7dzjs5qtX04uhxH81QvywYZcN3kLznGqpZdO3pM177hV8Y6eZo3FwmWQ01xCiv Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 19:42:45 -0000 --001a11c34484b8767f04df9b25dd Content-Type: text/plain; charset=ISO-8859-1 There seems to be a big difference in opinion about what is a lot of work or not. Managing an IANA table and using it for lookup of names and numbers is not difficult in python, ruby, php and several other environments. Granted it may not be so easy to do in a shell script. But then lots of things are not done easily in a shell script. Should the decision on whether to use IANA tables or DNS for bootstrapping depend on how easy it is to use in a shell script? -Ernie On Wed, Jun 19, 2013 at 6:03 PM, John R Levine wrote: > Yes, the process you describe is complex. So an Extra Lazy Programmer, >> realizing that the IANA tables don't change very much (certainly not for >> Numbers or the major TLDs) would use a simple utility script once every >> month or so to pull the IANA tables for names and/or numbers, strip the XML >> and store them as two column text files (TLD or Number, URL). >> > > You must know much more industrious lazy programmers than I do. Assuming > you have such a file, could you show me how to splice the appropriate > server name for an IPv6 address into a wget in a shell script in a > reasonable number of lines of code? Keep in mind that the IANA IPv6 > allocations range in length from /12 to /23, and you should't cheat, since > there are adjacent /23's assigned to different RIRs. > > For some real life examples, look at the freeware WHOIS client that comes > with FreeBSD. It has some flags to query specific WHOIS servers, and > "-c foo" to query foo.whois-servers.net, but that's it. > > The linux client can use a config file of patterns and servers, but as far > as I can tell, linux distros don't come with one (my Ubuntu doesn't). A few > weenies use one that's maintained on a git site. > > Really, I'm not opposed to a reasonable bootstrap, but reasonable has to > be something that isn't more work than the actual work. > > Do you really think that .domain.rdap.arpa is unworkable for names? > It sure would be nice to be able to do something like this to look up a > domain's abuse contact: > > dom=$1 > wget http://$(echo "$dom"|sed -e 's/.*\.//').domain.rdap.arpa/** > contact/abuse > > Or assuming we do the numbers pool: > > ip=$1 > wget http://pool.numbers.rdap.arpa/**ip/$1/abuse > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > --001a11c34484b8767f04df9b25dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There seems to be a big difference in opinion about w= hat is a lot of work or not. Managing an IANA table and using it for lookup= of names and numbers is not difficult in python, ruby, php and several oth= er environments. Granted it may not be so easy to do in a shell script. But= then lots of things are not done=A0easily=A0in a shell script. Should the = decision on whether to use IANA tables or DNS for bootstrapping depend on h= ow easy it is to use in a shell script?

-Ernie


On Wed, Jun 19, 2013 at 6:03 PM, John R Levine <joh= nl@taugh.com> wrote:
Yes, the process you describe is complex. So an Extra Lazy Programmer, real= izing that the IANA tables don't change very much (certainly not for Nu= mbers or the major TLDs) would use a simple utility script once every month= or so to pull the IANA tables for names and/or numbers, strip the XML and = store them as two column text files (TLD or Number, URL).

You must know much more industrious lazy programmers than I do. =A0Assuming= you have such a file, could you show me how to splice the appropriate serv= er name for an IPv6 address into a wget in a shell script in a reasonable n= umber of lines of code? =A0Keep in mind that the IANA IPv6 allocations rang= e in length from /12 to /23, and you should't cheat, since there are ad= jacent /23's assigned to different RIRs.

For some real life examples, look at the freeware WHOIS client that comes w= ith FreeBSD. =A0It has some flags to query specific WHOIS servers, and
"-c foo" to query foo.whois-servers.net, but that's it.

The linux client can use a config file of patterns and servers, but as far = as I can tell, linux distros don't come with one (my Ubuntu doesn't= ). A few weenies use one that's maintained on a git site.

Really, I'm not opposed to a reasonable bootstrap, but reasonable has t= o be something that isn't more work than the actual work.

Do you really think that <tld>.domain.rdap.arpa is unworkable for nam= es? It sure would be nice to be able to do something like this to look up a= domain's abuse contact:

dom=3D$1
wget http://$(echo "$dom"|sed -e 's/.*\.//').domain.rdap.= arpa/contact/abuse

Or assuming we do the numbers pool:

ip=3D$1
wget http://pool.numbers.rdap.arpa/ip/$1/abuse


Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

--001a11c34484b8767f04df9b25dd-- From johnl@taugh.com Thu Jun 20 13:22:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA9F21F9DE0 for ; Thu, 20 Jun 2013 13:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2vZYUQXZv8m for ; Thu, 20 Jun 2013 13:22:19 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E092221F9E06 for ; Thu, 20 Jun 2013 13:22:17 -0700 (PDT) Received: (qmail 79590 invoked from network); 20 Jun 2013 20:22:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=136e5.51c36474.k1306; bh=KZIFMk85PvdyOldUyut80NMUpXdL0P46l1/+1RkzHho=; b=JnmDN2jiNEPSnFYB2vqBXKP0+Eg+ktujd0oVZDNJkOpPYW8fpF7YHrTt9Fenwxny5dmAQmk/tTijvgZR4z6M9i2udfpU+k1r7OftF8ZOlyv0SvtXhVvUooPEp/twE0oxBHouYqZrDefQiGnjM+zAyCRepbWDmzKkXwlQGAg33XS3VGvp6pk0ZwsZw4X6a3qAqaqBJIlqmaP6mwnlTjOTRJwX/0BRn/lr1WKFkOMmOR6rAyQLnuXDJSKCtr4be3PM 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:cleverness; s=136e5.51c36474.k1306; bh=KZIFMk85PvdyOldUyut80NMUpXdL0P46l1/+1RkzHho=; b=MwksPag+srSDSRoixSC2sLafG7rSRs965Ofvel3DNsUdp4p30XuDM38NjRZp9j/uk7bVoaCcL7+cV6Tv61vAPjVCp9nb9akLitxIpPcEJXP9lXyKB+dM2mFF+ReXAdYh89EzbxaYCqF3nfrmOmPHN49hvs19dbQ5IsCgAdJTSXtQj9AOFmZ5DvEk0t0H9UjgDfkD7gIpkduSkge//GdUO7kDeR9Xi+lnFWWSgGgg+a8mdkEj02jjiNFlZweWklCj Received: (ofmipd 127.0.0.1); 20 Jun 2013 20:21:50 -0000 Date: 20 Jun 2013 16:22:12 -0400 Message-ID: From: "John R Levine" To: "Ernie Dainow" In-Reply-To: References: <20130619200723.49384.qmail@joyce.lan> <51C22101.7070903@afilias.info> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:22:20 -0000 > Granted it may not be so easy to do in a shell script. But then lots of > things are not done easily in a shell script. Should the decision on > whether to use IANA tables or DNS for bootstrapping depend on how easy it > is to use in a shell script? Remember that the IETF can't dictate to people what to do. We can only tell them how to interoperate. It seems rather likely that people will be doing RDAP from shell scripts, since we certainly do WHOIS from shell scripts. So if we dictate something too hard to do in a shell script, the Lazy Programmers will do something else, with consequent interop problems. What do you think of the suggestion that the numbers bootstrap be baked into the clients, with occasional updates via unspecified means since it changes so rarely, and the names use .domain.rdap.arpa? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From carlosm3011@gmail.com Thu Jun 20 14:06:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6E621F9ADF for ; Thu, 20 Jun 2013 14:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G30mMplQNo+B for ; Thu, 20 Jun 2013 14:06:37 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id B170A21F99B0 for ; Thu, 20 Jun 2013 14:06:23 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so1507qab.7 for ; Thu, 20 Jun 2013 14:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SD2I3ErDzuXy/lSWrMhkof8UWGKbYlXXHpQ75feIPN4=; b=tCNOV7EU0X38LQdwRK1rrm3Az8wNEWuGNPrW3d0/VxI/WweIySfbTb3WxZpS06Nu0s hXg5UhWLTkfAKmLeE1NL9e3S7hQCcc7EbAbVDfpkgteqvlOe0R95AKDWIXeLLwDvsflY KTHHvi1PdmyfggmkLtENVcnGAdWPBkwCcDJi7YhB6gOI0UYmy87NskWMOm7/asxLPKG2 EJeFzBuSxcHDxHhSeQWwqtsFuHQ/SloT1TUg0l8eTmWemJoXPzu2pm7jv8NZ4DTkSXRN 08984Rn8LrvsLEDsnIA6VCvJtIR/4Kx5OysoSaYR9gsHj2fwS8+DCQMA1H/xT4eE9ZbN Yrag== X-Received: by 10.49.103.136 with SMTP id fw8mr11173109qeb.65.1371762383125; Thu, 20 Jun 2013 14:06:23 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([200.7.87.57]) by mx.google.com with ESMTPSA id s8sm3068087qat.4.2013.06.20.14.06.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 14:06:22 -0700 (PDT) Message-ID: <51C36ECE.2020209@gmail.com> Date: Thu, 20 Jun 2013 18:06:22 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John R Levine References: <20130619200723.49384.qmail@joyce.lan> <51C22101.7070903@afilias.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 21:06:38 -0000 But we the IETF can try to help people do the 'right' (or the less harmful) thing. People who hardcode addresses are hopeless, but I tend to believe that there is a majority of mostly well intended, although a bit clueless, pool of programmers out there. This is where the idea of the pool comes in. Again, I'd like to stress that the pooling would work in addition to any bootstrapping mechanisms that we settle on, plural intended. I see from the numbers John shared that pooling for names would result in either smaller TLDs sharing an disproportionate portion of .com's query load or .com's servers appearing anywhere. regards, Carlos On 6/20/13 5:22 PM, John R Levine wrote: >> Granted it may not be so easy to do in a shell script. But then lots of >> things are not done easily in a shell script. Should the decision on >> whether to use IANA tables or DNS for bootstrapping depend on how easy it >> is to use in a shell script? > > Remember that the IETF can't dictate to people what to do. We can only > tell them how to interoperate. It seems rather likely that people will > be doing RDAP from shell scripts, since we certainly do WHOIS from shell > scripts. So if we dictate something too hard to do in a shell script, > the Lazy Programmers will do something else, with consequent interop > problems. > > What do you think of the suggestion that the numbers bootstrap be baked > into the clients, with occasional updates via unspecified means since it > changes so rarely, and the names use .domain.rdap.arpa? > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From marc.blanchet@viagenie.ca Thu Jun 20 14:10:45 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1A421E80C4 for ; Thu, 20 Jun 2013 14:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyR9ZVaizYX3 for ; Thu, 20 Jun 2013 14:10: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 571F221E80C3 for ; Thu, 20 Jun 2013 14:10:44 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 64DBC4159D; Thu, 20 Jun 2013 17:10:43 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Thu, 20 Jun 2013 17:10:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130619200723.49384.qmail@joyce.lan> <51C22101.7070903@afilias.info> To: "John R Levine" X-Mailer: Apple Mail (2.1508) Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 21:10:45 -0000 Le 2013-06-20 =E0 16:22, "John R Levine" a =E9crit : >> Granted it may not be so easy to do in a shell script. But then lots = of >> things are not done easily in a shell script. Should the decision on >> whether to use IANA tables or DNS for bootstrapping depend on how = easy it >> is to use in a shell script? I'm also in the opinion that the lazy programmer argument is not very = useful, and I don't agree with it. I'm sensible to complexity, but there = is a limit to that argument. Marc. >=20 > Remember that the IETF can't dictate to people what to do. We can = only tell them how to interoperate. It seems rather likely that people = will be doing RDAP from shell scripts, since we certainly do WHOIS from = shell scripts. So if we dictate something too hard to do in a shell = script, the Lazy Programmers will do something else, with consequent = interop problems. >=20 > What do you think of the suggestion that the numbers bootstrap be = baked into the clients, with occasional updates via unspecified means = since it changes so rarely, and the names use .domain.rdap.arpa? >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@iecc.com Thu Jun 20 14:31:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB01721F9DC3 for ; Thu, 20 Jun 2013 14:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.766 X-Spam-Level: X-Spam-Status: No, score=-110.766 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH3NH6w5kkij for ; Thu, 20 Jun 2013 14:31:22 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EF47221F99F0 for ; Thu, 20 Jun 2013 14:31:15 -0700 (PDT) Received: (qmail 95383 invoked from network); 20 Jun 2013 21:31:14 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Jun 2013 21:31:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c374a2.xn--hew.k1306; i=johnl@user.iecc.com; bh=cltoHzKEmkpup2ruEwNqiOtVZ8f7n2rjdw9d6r2mtJ8=; b=jawrE7/qcoke3BL6B1rGA/obPyoM477XfZ4npQH3r1hM0cVBin14G849qp/QN9a4/wBahDMy5DWfKfN1B8uZXHzEKqyB/I4AXB+FjE6rzFA9e4oXEQa/PvZjr84OJO6LQD35OEc8vdWteFKjIMttljGt1K2IczDPX7JFvH7MrUdzjO6qCc9FLUwtais1wJ8IaRAYMAzP0ZJ2IyI1nIQVx/Q1EatVX0iEzk49Vuged6T8ZqBRGdwM5HptmWkty0Qi DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c374a2.xn--hew.k1306; olt=johnl@user.iecc.com; bh=cltoHzKEmkpup2ruEwNqiOtVZ8f7n2rjdw9d6r2mtJ8=; b=DAFYVYEaK5J9xaArRHvKggek8c/EYaBKLoVK9+P6jt5lwBPqg553eTEuhcLKfCYSjVkJqQLNzpIYD37FNqFGnimF2fGQlUtgo9Q2sBuFu9Hn9+t4WbisbP2bIB1Zr9p/Fd1nN+4uaMcYoZAUEQZMm3oS+Rde7N2FA5SdxNLcszKseOk99m9EgW0G90zkxZG1ItpQi41JUwRWMZswjiJzD50hDHhcEBNzfWST0QNQIlBxFERn5kZ0sf4C4Xa/FNqF Date: 20 Jun 2013 21:30:52 -0000 Message-ID: <20130620213052.62323.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <51C36ECE.2020209@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: carlos@lacnic.net Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 21:31:28 -0000 >This is where the idea of the pool comes in. Again, I'd like to stress >that the pooling would work in addition to any bootstrapping mechanisms >that we settle on, plural intended. People use fixed WHOIS server addresses because there is a lot of crufty old code dating back to the early days when there only was one WHOIS server. There are no legacy RDAP clients, so a simple and effective way to ensure that even the Lazy Programmers write their name clients to use .domain.rdap.arpa is to make it never work if they don't. Numbers are different because no matter how excellent the bootstrap is, there will always be referrals for things that have been moved from one RIR to another, so the RIRs will always have a pretty good idea of who is responsible for what. Also, please keep in mind that LPs will be lazy whether you like it or not, and there is no plausible numbers bootstrap as simple as plugging the TLD into a fixed name. No matter how vigorously we wag our fingers and write MUST MUST MUST MUST, some numbers clients will take lame-o approaches like a fixed starting server or a built-in bootstrap list. I don't see any merit in denying the inevitable reality. R's, John From marc.blanchet@viagenie.ca Thu Jun 20 14:32:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B86D21F9DEC for ; Thu, 20 Jun 2013 14:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMRg281-fmca for ; Thu, 20 Jun 2013 14:32: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 E53CE21F9DF7 for ; Thu, 20 Jun 2013 14:32:17 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 590794159D; Thu, 20 Jun 2013 17:32:17 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Thu, 20 Jun 2013 17:20:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <104DDCFC-DC19-47FC-8353-E1A43837F279@viagenie.ca> References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> To: "John R Levine" X-Mailer: Apple Mail (2.1508) Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 21:32:22 -0000 Le 2013-06-20 =E0 15:34, "John R Levine" a =E9crit : >>> The IPv6 and ASN spaces are both so large that IANA will never = allocate more than a small fraction of either. Do you really want = clients hammering on IANA every time someone or something accidentally = tries to look up something in the unallocated range? >>=20 >> You are continually taking the point that that is hitting the IANA = web servers hard. Caching infrastructure are all available today for = much larger issues than we are discussing and as I wrote before, IANA is = already using caching infrastructure. So it is not as a big issue that = you are arguing. Obviously, it has to be planned with IANA, but this is = not a first. >=20 > I think you're missing two key points here. >=20 > One is that this wouldn't just happen each time there's a change to = the table (roughly never), it'd happen each time someone tries to check = an address or ASN that's not in the table, which I expect will happen = all the time. Unless you expect IANA to add table entries saying "This = isn't allocated and won't be anytims soon", which would be a giant can = of worms, there's no reverse caching to keep clients from hitting it on = each query of an unallocated address or ASN, and there are a lot of = unallocated addresses. an XML file is just a small file on the Internet. Cached, there is a = copy everywhere. It is one http request to get the file. As simple and = resource consuming as fetching an html file =3D 0. If the file is in the = "Internet caching infrastructure" (using that term to avoid naming = specific caching providers), then it could handle zillions of queries. =20= What I'm saying is that we want to tell the developers to be "clever" to = minimize these requests, given that the likelihood that the data change = is low. In the worst case, if they fetch every time, then no big deal if = the file is in the cache infrastructure. and they have an incentive to = be clever because fetching every time will take some time for them to = get the data, to rely on the data, to parse the data. But again, worst = case, they fetch every time. their problem. Marc. >=20 >>> Also, the point of the "baked in" was that the RDAP client need not = include the ability to update the table. >=20 > The Lazy Programmer in me is sure that even if we told people that = every RDAP client has to include something to fire off a daemon and do a = table update on demand, it's not going to happen. So please let's not = tell them to. >=20 >>> So in 2119-ese, >>>=20 >>> RDAP clients SHOULD use a hints table to select an initial numbers = server, with some way to update the table, which might be as crude as = installing a new version of the RDAP client, >>>=20 >>> clients MAY use pool.numbers.rdap.arpa as an initial server if there = is no hints table available, or the target isn't in the table (they will = whether or not we say they can, so we might as well provide a well known = name for it), and >>>=20 >>> clients MUST use .domain.rdap.arpa as an initial server for = TLD. >>>=20 >>> In each case, the protocol is https. Anyone who plans to run an = RDAP server and won't be able to provide https should speak up now. >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. From marc.blanchet@viagenie.ca Thu Jun 20 14:40:25 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A453C11E8121 for ; Thu, 20 Jun 2013 14:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WS5nA-isnPx for ; Thu, 20 Jun 2013 14:40: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 2CA4E11E80E4 for ; Thu, 20 Jun 2013 14:40:25 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5FB524159D; Thu, 20 Jun 2013 17:40:24 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Thu, 20 Jun 2013 17:22:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <86F44499-5502-4788-995B-7B5F646616C1@viagenie.ca> References: <20130619200723.49384.qmail@joyce.lan> <51C22101.7070903@afilias.info> To: "John R Levine" X-Mailer: Apple Mail (2.1508) Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 21:40:25 -0000 Le 2013-06-20 =E0 16:22, "John R Levine" a =E9crit : >> Granted it may not be so easy to do in a shell script. But then lots = of >> things are not done easily in a shell script. Should the decision on >> whether to use IANA tables or DNS for bootstrapping depend on how = easy it >> is to use in a shell script? >=20 > Remember that the IETF can't dictate to people what to do. We can = only tell them how to interoperate. It seems rather likely that people = will be doing RDAP from shell scripts, since we certainly do WHOIS from = shell scripts. So if we dictate something too hard to do in a shell = script, the Lazy Programmers will do something else, with consequent = interop problems. >=20 > What do you think of the suggestion that the numbers bootstrap be = baked into the clients, with occasional updates via unspecified means = since it changes so rarely, and the names use .domain.rdap.arpa? The new update of my draft being written is saying: - numbers: get data from IANA. - names: use DNS. (a combination of the two drafts I wrote). will see where it goes. Marc. >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@taugh.com Thu Jun 20 15:03:32 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787A521E808D for ; Thu, 20 Jun 2013 15:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpU6q1Y3dWMd for ; Thu, 20 Jun 2013 15:03:30 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CEC4221F9FEC for ; Thu, 20 Jun 2013 15:03:29 -0700 (PDT) Received: (qmail 2653 invoked from network); 20 Jun 2013 22:03:25 -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:cleverness; s=a59.51c37c2d.k1306; bh=nW/Yw5ZkrSzo5rVGEZqLNWPI+ordEyYgWYjIuPo+B6U=; b=hfTgu9162Tal0WpviPJo8uV+HxuMPSg59vzIoL73n1EZoBV3ipUCQIDWcABSAtV8UodcP8EWGc2LU8yhujrJ4yYHHaRAWj8T/sC7Y2cnAooc40yELMUuM8ubIENZ+gWRQSTXxJ0L1aEVx9RAwrQapfdSHq3L8T8cyjam1eh7RjUOay1Fv3U1/GhD2A4ZpuwaRO6i+yvKm1sYoCaPFfbTi7Un883Px8hmZQGa1/5lXDmSM9hA/gAhK81UisIrooTF 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:cleverness; s=a59.51c37c2d.k1306; bh=nW/Yw5ZkrSzo5rVGEZqLNWPI+ordEyYgWYjIuPo+B6U=; b=TC7b5QqYRVi3VZletXULSyqeiYLqfXMbcXDj60rn4Stj+s3S6/dgekQq9K7/HNLc/Fm0FkRdLcKVSgAJge83hKYqmBZdYfB4i/qK/O2uiVuZcrXlHADoMAafOQcYJ9ZD17rJcLdtx07zj6XeGK4b5ONlM3JK70N29f6v9wVqqlEqlD1YyGvhCWBAVnnabMVYAL50p7EKUbye+RPmJC44/jpsNWsuc0Fwe+i0/HAF4IVi+rAq7eyPiiTfrXHrU7x4 Received: (ofmipd 127.0.0.1); 20 Jun 2013 22:03:03 -0000 Date: 20 Jun 2013 18:03:24 -0400 Message-ID: From: "John R Levine" To: "Marc Blanchet" In-Reply-To: <104DDCFC-DC19-47FC-8353-E1A43837F279@viagenie.ca> References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> <104DDCFC-DC19-47FC-8353-E1A43837F279@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:03:32 -0000 > an XML file is just a small file on the Internet. Cached, there is a > copy everywhere. I have a physical server in a nearby hosting center and some VPSes in Pennsylvania. I'm fairly sure there are no http caches in front of any of them and even more sure there are no https caches. IANA's web servers appear to be on a single physical network in California, not mirrored using Akamai or the like. The RDAP clients I expect to use won't be full web browsers, and they're not on consumer ISPs with awful "transparent" web caches. I also have no interest in dragging a big XML parser into a tiny JSON application. You know, if we assume that the TTL on the IANA file is a year or two, my baked-in+upgrade approach is functionally equivalent to yours and depends less on third parties who may not want to be volunteered. R's, John >> So in 2119-ese, >> >> RDAP clients SHOULD use a hints table to select an initial numbers server, with some way to update the table, which might be as crude as installing a new version of the RDAP client, >> >> clients MAY use pool.numbers.rdap.arpa as an initial server if there is no hints table available, or the target isn't in the table (they will whether or not we say they can, so we might as well provide a well known name for it), and >> >> clients MUST use .domain.rdap.arpa as an initial server for TLD. >> >> In each case, the protocol is https. Anyone who plans to run an RDAP server and won't be able to provide https should speak up now. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From marc.blanchet@viagenie.ca Thu Jun 20 15:40:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CAE11E8121 for ; Thu, 20 Jun 2013 15:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6fhNrWIzqNB for ; Thu, 20 Jun 2013 15:40:20 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C608B11E80E3 for ; Thu, 20 Jun 2013 15:40:20 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3467B4159D; Thu, 20 Jun 2013 18:40:20 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Thu, 20 Jun 2013 18:40:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> <104DDCFC-DC19-47FC-8353-E1A43837F279@viagenie.ca> To: "John R Levine" X-Mailer: Apple Mail (2.1508) Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:40:21 -0000 Le 2013-06-20 =E0 18:03, "John R Levine" a =E9crit : >> an XML file is just a small file on the Internet. Cached, there is a = copy everywhere. >=20 > I have a physical server in a nearby hosting center and some VPSes in = Pennsylvania. I'm fairly sure there are no http caches in front of any = of them and even more sure there are no https caches. IANA's web = servers appear to be on a single physical network in California, not = mirrored using Akamai or the like. ok. I think we are getting way too deep here and becomes completly = irrelevant.=20 >=20 > The RDAP clients I expect to use won't be full web browsers, don't need to. > and they're not on consumer ISPs with awful "transparent" web caches. = I also have no interest in dragging a big XML parser into a tiny JSON = application. then, I'm against that argument. This is pretty straightforward parsing. >=20 > You know, if we assume that the TTL on the IANA file is a year or two, = my baked-in+upgrade approach is functionally equivalent to yours and = depends less on third parties who may not want to be volunteered. there is implementation specificities (that are outside of the scope of = the IETF) and there are interop stuff. What I'm saying is that the client should get the data from the IANA = registry. Does it do it often, not often, upgrade, etc... is not in IETF = document. However, we should provide some guidance about what to do. The = implementor may decide to use or not use the guidance. Therefore, = baked-in+upgrade or whatever is irrelevant to me, as long as they use = the same source, which is what I care. marc. >=20 > R's, > John >=20 >>> So in 2119-ese, >>>=20 >>> RDAP clients SHOULD use a hints table to select an initial numbers = server, with some way to update the table, which might be as crude as = installing a new version of the RDAP client, >>>=20 >>> clients MAY use pool.numbers.rdap.arpa as an initial server if there = is no hints table available, or the target isn't in the table (they will = whether or not we say they can, so we might as well provide a well known = name for it), and >>>=20 >>> clients MUST use .domain.rdap.arpa as an initial server for = TLD. >>>=20 >>> In each case, the protocol is https. Anyone who plans to run an = RDAP server and won't be able to provide https should speak up now. >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. From bje@apnic.net Thu Jun 20 22:45:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96A111E80F8 for ; Thu, 20 Jun 2013 22:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.157 X-Spam-Level: * X-Spam-Status: No, score=1.157 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvdAgRC8-Wy1 for ; Thu, 20 Jun 2013 22:45:20 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 3936F11E80F1 for ; Thu, 20 Jun 2013 22:45:19 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Fri, 21 Jun 2013 15:45:13 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a%19]) with mapi id 14.01.0421.002; Fri, 21 Jun 2013 15:45:13 +1000 From: Byron Ellacott To: Marc Blanchet Thread-Topic: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHObkJ/CKwlwoI/TUWBWggKk/ArmQ== Date: Fri, 21 Jun 2013 05:45:12 +0000 Message-ID: In-Reply-To: <86F44499-5502-4788-995B-7B5F646616C1@viagenie.ca> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5C38A6EB56846F49863B04E993A4DAF3@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 05:45:24 -0000 Hi Marc, On 21/06/13 7:22 AM, "Marc Blanchet" wrote: >Le 2013-06-20 =E0 16:22, "John R Levine" a =E9crit : > >The new update of my draft being written is saying: >- numbers: get data from IANA. >- names: use DNS. >(a combination of the two drafts I wrote). How would a client bootstrap a query for 29.12.202.in-addr.arpa ? If I am querying for IP network 2001:0400::/22, which server would I contact? [0] I would prefer to see an approach that minimises variance in bootstrap complexity between names and numbers: making numbers bootstrap too complex increases the likelihood of an unofficial solution arising, such as an HTTP(S) request to rdap.org or rdap.arin.net. Byron [0] To save you the time, here are the relevant entries in the IANA IPv6 registry: 2001:0400::/23 ARIN 1999-07-01 whois.arin.net ALLOCATED 2001:0600::/23 RIPE NCC 1999-07-01 whois.ripe.net ALLOCATED (You might see 0::/0, 2000::/3, or a 404 for this query, but the bootstrapping client shouldn't be the place where the final answer is determined). Byron From aservin@lacnic.net Fri Jun 21 01:20:59 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F061321E80BB for ; Fri, 21 Jun 2013 01:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.985 X-Spam-Level: * X-Spam-Status: No, score=1.985 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+Vm4lKqy2yy for ; Fri, 21 Jun 2013 01:20:50 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id BE7B821F9FD7 for ; Fri, 21 Jun 2013 01:20:45 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [202.183.168.2]) by mail.lacnic.net.uy (Postfix) with ESMTP id 8842C308495 for ; Fri, 21 Jun 2013 05:20:20 -0300 (UYT) Message-ID: <51C40CD0.4030008@lacnic.net> Date: Fri, 21 Jun 2013 15:20:32 +0700 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <20130619200723.49384.qmail@joyce.lan> <51C22101.7070903@afilias.info> <86F44499-5502-4788-995B-7B5F646616C1@viagenie.ca> In-Reply-To: <86F44499-5502-4788-995B-7B5F646616C1@viagenie.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 08:20:59 -0000 I would prefer all DNS. Byron made good points. .as On 6/21/13 4:22 AM, Marc Blanchet wrote: > The new update of my draft being written is saying: > - numbers: get data from IANA. > - names: use DNS. > (a combination of the two drafts I wrote). > > will see where it goes. > > Marc. From aservin@lacnic.net Fri Jun 21 01:31:50 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5E111E8171 for ; Fri, 21 Jun 2013 01:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.985 X-Spam-Level: * X-Spam-Status: No, score=1.985 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4sOrAU38sBu for ; Fri, 21 Jun 2013 01:31:46 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF9F11E810C for ; Fri, 21 Jun 2013 01:31:45 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [202.183.168.2]) by mail.lacnic.net.uy (Postfix) with ESMTP id A330F308456 for ; Fri, 21 Jun 2013 05:31:23 -0300 (UYT) Message-ID: <51C40F67.9090701@lacnic.net> Date: Fri, 21 Jun 2013 15:31:35 +0700 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> <104DDCFC-DC19-47FC-8353-E1A43837F279@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 08:31:50 -0000 Marc, It seems that you are focusing too much in that "an XML is very easy to parse" but you are forgeting the scalability issues that lazy programers may be. As John said in other email we could use all the MUST, MUST NOT that we can imagine and even though there is no guarantee that those guidelines would be follow. I am not saying that we should not use XML in IANA, just saying that we must not minimize the operational impact that it could be to IANA. Regards, as On 6/21/13 5:40 AM, Marc Blanchet wrote: > Le 2013-06-20 à 18:03, "John R Levine" a écrit : > >>> an XML file is just a small file on the Internet. Cached, there is a copy everywhere. >> I have a physical server in a nearby hosting center and some VPSes in Pennsylvania. I'm fairly sure there are no http caches in front of any of them and even more sure there are no https caches. IANA's web servers appear to be on a single physical network in California, not mirrored using Akamai or the like. > ok. I think we are getting way too deep here and becomes completly irrelevant. > >> The RDAP clients I expect to use won't be full web browsers, > don't need to. > >> and they're not on consumer ISPs with awful "transparent" web caches. I also have no interest in dragging a big XML parser into a tiny JSON application. > then, I'm against that argument. This is pretty straightforward parsing. > >> You know, if we assume that the TTL on the IANA file is a year or two, my baked-in+upgrade approach is functionally equivalent to yours and depends less on third parties who may not want to be volunteered. > there is implementation specificities (that are outside of the scope of the IETF) and there are interop stuff. > > What I'm saying is that the client should get the data from the IANA registry. Does it do it often, not often, upgrade, etc... is not in IETF document. However, we should provide some guidance about what to do. The implementor may decide to use or not use the guidance. Therefore, baked-in+upgrade or whatever is irrelevant to me, as long as they use the same source, which is what I care. > > marc. > > > >> R's, >> John >> >>>> So in 2119-ese, >>>> >>>> RDAP clients SHOULD use a hints table to select an initial numbers server, with some way to update the table, which might be as crude as installing a new version of the RDAP client, >>>> >>>> clients MAY use pool.numbers.rdap.arpa as an initial server if there is no hints table available, or the target isn't in the table (they will whether or not we say they can, so we might as well provide a well known name for it), and >>>> >>>> clients MUST use .domain.rdap.arpa as an initial server for TLD. >>>> >>>> In each case, the protocol is https. Anyone who plans to run an RDAP server and won't be able to provide https should speak up now. >> Regards, >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >> "I dropped the toothpaste", said Tom, crestfallenly. > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From tony@att.com Fri Jun 21 06:15:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4904511E818C for ; Fri, 21 Jun 2013 06:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKpPZoM6bIjd for ; Fri, 21 Jun 2013 06:15:32 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 27CB511E8189 for ; Fri, 21 Jun 2013 06:15:32 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 3f154c15.0.738340.00-309.2063249.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 21 Jun 2013 13:15:32 +0000 (UTC) X-MXL-Hash: 51c451f43357bd2c-22e9e769be6ba2565fd564aaebe3978437fc9976 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5LDFTr5032404 for ; Fri, 21 Jun 2013 09:15:30 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5LDFQgM032385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Jun 2013 09:15:27 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Fri, 21 Jun 2013 13:15:09 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r5LDF8EA027936 for ; Fri, 21 Jun 2013 09:15:09 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r5LDF2V4027709 for ; Fri, 21 Jun 2013 09:15:04 -0400 Received: from [130.10.106.165] (vpn-130-10-106-165.vpn.swst.att.com[130.10.106.165]) by maillennium.att.com (mailgw1) with ESMTP id <20130621131458gw100bhh9oe> (Authid: tony); Fri, 21 Jun 2013 13:15:02 +0000 X-Originating-IP: [130.10.106.165] Message-ID: <51C451D5.3040004@att.com> Date: Fri, 21 Jun 2013 09:15:01 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Arturo Servin References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> <104DDCFC-DC19-47FC-8353-E1A43837F279@viagenie.ca> <51C40F67.9090701@lacnic.net> In-Reply-To: <51C40F67.9090701@lacnic.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=R92076tX c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=20MA4zBkdEYA:10 a=bfzWQn4VrGAA:10 a=eJdLM9URqkwA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=n-OV9Ke0s5gA:10 a=vA8jAMod6OqkC0TJshkA:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10] Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 13:15:39 -0000 On 6/21/2013 4:31 AM, Arturo Servin wrote: > I am not saying that we should not use XML in IANA, just saying that > we must not minimize the operational impact that it could be to IANA. IANA already uses XML in many many places on their web site, particularly in their protocol registries. Tony Hansen From aservin@lacnic.net Fri Jun 21 07:08:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6E21E8112 for ; Fri, 21 Jun 2013 07:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.985 X-Spam-Level: * X-Spam-Status: No, score=1.985 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaHxMYV04QWe for ; Fri, 21 Jun 2013 07:08:07 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 71D4E21E8106 for ; Fri, 21 Jun 2013 07:08:07 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [202.183.168.2]) by mail.lacnic.net.uy (Postfix) with ESMTP id AB1F530849D; Fri, 21 Jun 2013 11:07:38 -0300 (UYT) Message-ID: <51C45E35.1000403@lacnic.net> Date: Fri, 21 Jun 2013 21:07:49 +0700 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tony Hansen References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> <104DDCFC-DC19-47FC-8353-E1A43837F279@viagenie.ca> <51C40F67.9090701@lacnic.net> <51C451D5.3040004@att.com> In-Reply-To: <51C451D5.3040004@att.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:08:13 -0000 Yes, but now they are not hit by many requests as it may be with rdap. /as On 6/21/13 8:15 PM, Tony Hansen wrote: > On 6/21/2013 4:31 AM, Arturo Servin wrote: >> I am not saying that we should not use XML in IANA, just saying that >> we must not minimize the operational impact that it could be to IANA. > IANA already uses XML in many many places on their web site, > particularly in their protocol registries. > > Tony Hansen From kim.davies@icann.org Fri Jun 21 08:26:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D1421E812F for ; Fri, 21 Jun 2013 08:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTnKg6+CDQE2 for ; Fri, 21 Jun 2013 08:26:02 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80B21E812A for ; Fri, 21 Jun 2013 08:26:02 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Fri, 21 Jun 2013 08:26:01 -0700 From: Kim Davies To: Arturo Servin Date: Fri, 21 Jun 2013 08:26:01 -0700 Thread-Topic: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: Ac5uk6J9g1lo4hZfRMGcuor3Ehf5eg== Message-ID: <4B6942F9-81F8-4BE2-B4E6-1708EC597FE7@icann.org> References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> <104DDCFC-DC19-47FC-8353-E1A43837F279@viagenie.ca> <51C40F67.9090701@lacnic.net> <51C451D5.3040004@att.com> <51C45E35.1000403@lacnic.net> In-Reply-To: <51C45E35.1000403@lacnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:26:15 -0000 On Jun 21, 2013, at 7:07 AM, Arturo Servin wrote: >=20 > Yes, but now they are not hit by many requests as it may be with rdap. At least one of IANA's registries is hit with around a billion requests per= month over HTTP/HTTPS. We deploy data that we serve that has high utilisat= ion via a content delivery network with points of presence around the world= , and the remainder of the website is across two fully redundant sites. We = can expand our infrastructure if the IETF produces a new protocol requireme= nt that we can not currently satisfy. I would suggest choosing the right solution based on all the factors, but I= wouldn't necessarily veto a particular approach if it was otherwise consid= ered the right one, solely on the basis that IANA would not be able to host= it. In sum, if there is a reason for IANA to maintain a data set with high util= isation expectations, we will take steps to support it with a robust infras= tructure.=20 kim= From johnl@iecc.com Fri Jun 21 10:21:00 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0340B21E8112 for ; Fri, 21 Jun 2013 10:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.782 X-Spam-Level: X-Spam-Status: No, score=-110.782 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOK+CzavqmrU for ; Fri, 21 Jun 2013 10:20:56 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 95ACD21F9FEA for ; Fri, 21 Jun 2013 10:20:54 -0700 (PDT) Received: (qmail 2575 invoked from network); 21 Jun 2013 17:20:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Jun 2013 17:20:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c48b73.xn--i8sz2z.k1306; i=johnl@user.iecc.com; bh=UGqHpF5Bq0Z2Ebr+qOynwWc/pDSVBLDxHHSVGgZFzdw=; b=a9vUhRuMZUm5YgkkBC6qYU3bde0kg4Ou65mxJGZlMAt4VnRhYCjAHIzx22DiW+3zA90N4We/n4vWJHWUiLiIc8TFZKkoNLYuftZQpj6BtUjKpjg3stjnRCkF2X+sVOpj7/Vf2ktDtE2oBSxgoYnIojrEtlWLlucGb79s6IGOXRtcfH1zuEauVdy874Rd9qQgW/896EcK9//dEZ1lFnUf60kOtC0tpUufBAcdqwRnUguwSgBbmXi3scilUcTKdszb DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c48b73.xn--i8sz2z.k1306; olt=johnl@user.iecc.com; bh=UGqHpF5Bq0Z2Ebr+qOynwWc/pDSVBLDxHHSVGgZFzdw=; b=M2rsCoOwDGHNEMzKbohCE+H8RwyehhfYGcckCH9h3Wie85J9AzZ/ZCXo4NKd1bQwDkP//ZFpj2ENWMlzjw3YqlqMIkV/wwbi/kya2rZhl6cweC8IBY08KsjL61FFQMyO1FrUl32Xk1N9UDGjiYTgXmKBQKs/l6xEqSR7tK4rFoh//geNejym/iLy+AbczmGNqGoDsx+NxY69bjahmvumUZFDGj226uYEs6WGb1AiD1tgz2WjFs9gAnhuz8VfCRRb Date: 21 Jun 2013 17:20:28 -0000 Message-ID: <20130621172028.93308.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:21:00 -0000 >How would a client bootstrap a query for 29.12.202.in-addr.arpa ? It would look at arpa.domains.rdap.arpa to get the name of the RDAP server for .arpa, if there were one. I expect that's not the answer to the question you meant to ask. If you're asking how to bootstrap a query for 202.12.29.0/24, or 2001:0400::/22, my proposal is that the numbers bootstraps are built into the clients, with informal advice to update them every year or two, sort of like the root zone hints in a DNS cache. Given how slowly the IANA numbers tables change, I think that's more workable than something that tries to boostrap the rather irregular numbers assignments on the fly. >I would prefer to see an approach that minimises variance in bootstrap >complexity between names and numbers: making numbers bootstrap too complex >increases the likelihood of an unofficial solution arising, such as an >HTTP(S) request to rdap.org or rdap.arin.net. Indeed. But do keep in mind that there are some rather basic operational differences between names and numbers that won't change. * Numbers assignments move among RIRs, so the RIRs have a history of cooperation and awareness of each other's assignments. * Names never move from one TLD to another, and there's no need for operational cooperation between different TLDs. R's, John From johnl@iecc.com Fri Jun 21 10:28:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AB821E812C for ; Fri, 21 Jun 2013 10:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.798 X-Spam-Level: X-Spam-Status: No, score=-110.798 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqPuPpsOef1Z for ; Fri, 21 Jun 2013 10:28:31 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E2B2E21E812A for ; Fri, 21 Jun 2013 10:28:30 -0700 (PDT) Received: (qmail 4974 invoked from network); 21 Jun 2013 17:28:30 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Jun 2013 17:28:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c48d3e.xn--3zv.k1306; i=johnl@user.iecc.com; bh=zpZpD+fuNJDxBAiGpiWeH2eijqG2OLMLV3t3Ph7Dr5I=; b=uXAdfdvZpljCLn24bmceCohCtoaGgEdt9yKi6zQwln0RekzZmJvHfDG9QffBtk4yLE0AiJ1rae53yov3BZjo5KtKoT6WQMXOJtwPz8O0efDnUZczpHbnK+hOxEbXVz2e0wJ7gtmL3EvnMNGbZ1xIL3RntQ9jSettczUSYxzTAin+xH4ZXKRegzgEHkBWd4COsElRLiyXSb55HRN0H4mFaoJgAN2irNf3BgvfHcmCikldeJI/dwcXj/yBEM/MFJcw DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c48d3e.xn--3zv.k1306; olt=johnl@user.iecc.com; bh=zpZpD+fuNJDxBAiGpiWeH2eijqG2OLMLV3t3Ph7Dr5I=; b=iVj2VdvWwk5SHJPs3ZyFz879PBNckcY0Fcrew9lPF/21Sr+j5sctydlyh7zuk+cLxC4bqSmqpcZqhibxHsWKZv5FRn88V+POzBStU9KrZwRpldRC5+jvLhLGdDsvHSuUbxenc+XQ94VeDkadxWUuEIjZadgV6N28aRWjvhlrVkGJ9REZCP2fpHP/3yR2D/cFwAMDbTo4EzUwSDo4OmP1AHuilJEOlPd+uL1Ss8m4rKQlqRKFH0GsSwCwyhGX0s5a Date: 21 Jun 2013 17:28:07 -0000 Message-ID: <20130621172807.93376.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <4B6942F9-81F8-4BE2-B4E6-1708EC597FE7@icann.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:28:35 -0000 >In sum, if there is a reason for IANA to maintain a data set with high utilisation >expectations, we will take steps to support it with a robust infrastructure. Thanks. While we have your attention, do you see problems with the current name bootstrap proposal? Each TLD is requested to provide the name or IP addresses of an RDAP server, sort of like they provide the name of a WHOIS server now, and you publish them as CNAME or A/AAAA records in .domain.rdap.arpa. R's, John From bje@apnic.net Sun Jun 23 18:32:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9678B21F9FE6 for ; Sun, 23 Jun 2013 18:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.857 X-Spam-Level: X-Spam-Status: No, score=0.857 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW-wgxuKKnXV for ; Sun, 23 Jun 2013 18:32:34 -0700 (PDT) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id 9DF6421F9A04 for ; Sun, 23 Jun 2013 18:32:32 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Mon, 24 Jun 2013 11:32:24 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a%19]) with mapi id 14.01.0421.002; Mon, 24 Jun 2013 11:32:25 +1000 From: Byron Ellacott To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHObkJ/CKwlwoI/TUWBWggKk/ArmZk/wxcAgARVu4A= Date: Mon, 24 Jun 2013 01:32:24 +0000 Message-ID: In-Reply-To: <20130621172028.93308.qmail@joyce.lan> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <07FE399BA3D7244B956EB0F81E0C1384@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 01:32:38 -0000 On 22/06/13 3:20 AM, "John Levine" wrote: >>How would a client bootstrap a query for 29.12.202.in-addr.arpa ? > >It would look at arpa.domains.rdap.arpa to get the name of the RDAP >server for .arpa, if there were one. I expect that's not the answer >to the question you meant to ask. Presumably, the server for .arpa is then going to redirect the client to the appropriate RDAP server for the specific resource associated with the reverse domain being queried. The implicit questions are: how the server for .arpa is going to do that; and why wouldn't a client skip all the bothersome XML parsing stuff and just ask arpa.domains.rdap.arpa? >If you're asking how to bootstrap a query for 202.12.29.0/24, or >2001:0400::/22, my proposal is that the numbers bootstraps are built >into the clients, with informal advice to update them every year or >two, sort of like the root zone hints in a DNS cache. Given how >slowly the IANA numbers tables change, I think that's more workable >than something that tries to boostrap the rather irregular numbers >assignments on the fly. I don't mind this approach; is there suitable RFC wording that would allow clients to have confidence that asking one of the numbers bootstrap servers will get you to the right place for the answer you seek? (ie, the RIRs will redirect to each other, but should that information go into an RFC, and if so, how?) >* Numbers assignments move among RIRs, so the RIRs have a history of >cooperation and awareness of each other's assignments. As you pointed out a few messages ago, numbers query clients are going to rely on the RIRs cooperating for redirection no matter what bootstrap method is used. Byron From johnl@taugh.com Sun Jun 23 18:47:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A064321E8088 for ; Sun, 23 Jun 2013 18:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPsFPXTgFy3x for ; Sun, 23 Jun 2013 18:47:21 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7994F21E804C for ; Sun, 23 Jun 2013 18:47:20 -0700 (PDT) Received: (qmail 73333 invoked from network); 24 Jun 2013 01:47:13 -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:cleverness; s=11e74.51c7a521.k1306; bh=BPgi4Qh0NKQ95cmQJnyn1o5cbfPO+kNMrukPZg6WlsA=; b=oAV2o6QjOFUTcuS+Vdx9ty306JbYamuIIhgzwMmbilUnjeRVzjDUwV2or9Rd8L9rOgEWTLICdfXQEskDp6JReuNhK/Ph+xwm/J1nKpIrtsTpR5K4ju1WZj9wyBOUdCJ4LehKzYDqS+9MGdOb60WqvKcTS+3FKmKn9qhDWuzE3OSEcKUiJbFcrx8GfNJ5w/G/x5pPqompsVen5+UtoI3v3fvGCtEmyf2uEhBn/suA/aWELFG7t214CfDqpC6a+184 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:cleverness; s=11e74.51c7a521.k1306; bh=BPgi4Qh0NKQ95cmQJnyn1o5cbfPO+kNMrukPZg6WlsA=; b=t3zldO2CFFH5UbTx0/ZYeqS4YeRmUqJNXMMZ6rn1JJ/MkxSh62UhyHUyMhK4h32fGc/zKwiw8eL7sDSiGZiKYI5AbdvxPLedD8D+0cB5UcDEDfxUX/EURhqOCWsZVdg4Wk1Zk10jFFWWgMP0p2tg0Z3typr3T2vnKC+qw+dLmpryT6p4PeFCr6iis82vPxg31W49YQceBOLzMbiFJ7N/3h0pQrx8NZh4NNZTN9pU0URkp2YF8pwKV+U5XIDJOizj Received: (ofmipd 127.0.0.1); 24 Jun 2013 01:46:51 -0000 Date: 23 Jun 2013 21:47:13 -0400 Message-ID: From: "John R Levine" To: "Byron Ellacott" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-727333866-1372038433=:16280" Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 01:47:21 -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. --3825401791-727333866-1372038433=:16280 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >>> How would a client bootstrap a query for 29.12.202.in-addr.arpa ? >> >> It would look at arpa.domains.rdap.arpa to get the name of the RDAP >> server for .arpa, if there were one. I expect that's not the answer >> to the question you meant to ask. > > Presumably, the server for .arpa is then going to redirect the client to > the appropriate RDAP server for the specific resource associated with the > reverse domain being queried. Uh, no. Since arpa is a TLD, it'll find you the RDAP server for the .arpa TLD, which will tell you something about the people at IANA who manage it. As I said, this is probably not the question you meant to ask. It's worth noting somewhere that asking about the rDNS name associated with an IP address is not the same as asking about that IP address. Name and number queries are different, different question syntax and different answer syntax. >> If you're asking how to bootstrap a query for 202.12.29.0/24, or >> 2001:0400::/22, my proposal is that the numbers bootstraps are built >> into the clients, with informal advice to update them every year or >> two, sort of like the root zone hints in a DNS cache. ... > I don't mind this approach; is there suitable RFC wording that would allow > clients to have confidence that asking one of the numbers bootstrap > servers will get you to the right place for the answer you seek? This is the IETF, so we can't force anyone to do anything. But assuming the RIRs are willing, we could put in language along the lines of what I suggested a couple of messages ago. R's, John --3825401791-727333866-1372038433=:16280 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI0MDE0NzEzWjAjBgkqhkiG 9w0BCQQxFgQUhmwbpVslfxcvK9A4VGPLyc+Y+nsweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAIznzdhfIZNho xqrcH2Y04xwJuCGo5KODr7mujPRlBI0tgSHnENq28RbDyTSEw6Hu5voVHEcw SOdUnq79CSK1ipCcuot+kRTsYTvWadWGFtFFjZz3AWbMg0ZXYin4CPhZBzj3 XNTvrA3XI/McTMGjLJNlgE7bR7lVdzxHJ7MSYO5NSjFpxLzuwS/b6TkghQf5 kwX7dfAFJsb6K5G5j6yjSC20AGNPiIJUE9hPjFH9rWuEoeYUgK8xQ6KTMsih GcYOrbdhTOm0iyC4nqgi1J6BQcQGlzdjJamfpfMdJWnKbESD58ogjjPGT2Wz e0R/hNtE6TobwsV0MLWP4v84vn4quw== --3825401791-727333866-1372038433=:16280-- From bje@apnic.net Sun Jun 23 20:45:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154FB21E80A9 for ; Sun, 23 Jun 2013 20:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.757 X-Spam-Level: X-Spam-Status: No, score=0.757 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi9gyryX-ytf for ; Sun, 23 Jun 2013 20:44:57 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 3AED521E809D for ; Sun, 23 Jun 2013 20:44:56 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Mon, 24 Jun 2013 13:36:20 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by IAMDA1.org.apnic.net (2001:dd8:a:852:f9ce:d66e:c64d:3db2) with Microsoft SMTP Server (TLS) id 14.1.421.2; Mon, 24 Jun 2013 13:44:45 +1000 Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA2.org.apnic.net ([fe80::c75:3639:c2fb:c053%15]) with mapi id 14.01.0438.000; Mon, 24 Jun 2013 13:44:45 +1000 From: Byron Ellacott To: John R Levine Thread-Topic: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHObkJ/CKwlwoI/TUWBWggKk/ArmZk/wxcAgARVu4D//1yEgIAAyHYA Date: Mon, 24 Jun 2013 03:44:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <8B73068B69699E44AC0CEB2B0098295A@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 03:45:02 -0000 Hi John, On 24/06/13 11:47 AM, "John R Levine" wrote: >>>> How would a client bootstrap a query for 29.12.202.in-addr.arpa ? >>> >>> It would look at arpa.domains.rdap.arpa to get the name of the RDAP >>> server for .arpa, if there were one. I expect that's not the answer >>> to the question you meant to ask. >> >> Presumably, the server for .arpa is then going to redirect the client to >> the appropriate RDAP server for the specific resource associated with >>the >> reverse domain being queried. > >Uh, no. Since arpa is a TLD, it'll find you the RDAP server for the >.arpa=20 >TLD, which will tell you something about the people at IANA who manage >it.=20 >As I said, this is probably not the question you meant to ask. It's >worth=20 >noting somewhere that asking about the rDNS name associated with an IP >address is not the same as asking about that IP address. Name and number >queries are different, different question syntax and different answer >syntax. My point is that when querying for the reverse domain, you will eventually get to: https://rdap.apnic.net/domain/29.12.202.in-addr.arpa And if you're querying for the equivalent /24, you will eventually get to: https://rdap.apnic.net/ip/202.12.29.0/24 The steps followed might be a little different given slightly different hierarchies between reverse DNS and allocations, but the key difference is only the expected query load. If bootstrapping via DNS is sufficient for the reverse DNS domain queries, is query load the main reason it isn't also sufficient for IP network queries? (Given we broadly agree on bootstrapping approach, I'm not sure this line of discussion is all that relevant.) Byron From bje@apnic.net Sun Jun 23 23:18:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2169421E80B7 for ; Sun, 23 Jun 2013 23:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.707 X-Spam-Level: X-Spam-Status: No, score=0.707 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVxAnfZggWWj for ; Sun, 23 Jun 2013 23:18:28 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 2AAA311E80E0 for ; Sun, 23 Jun 2013 23:18:26 -0700 (PDT) Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Mon, 24 Jun 2013 16:18:22 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by NXMDA1.org.apnic.net (2001:dd8:9:802:90fc:97c2:1a5f:d67d) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 24 Jun 2013 16:18:22 +1000 Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA2.org.apnic.net ([fe80::c75:3639:c2fb:c053%15]) with mapi id 14.01.0438.000; Mon, 24 Jun 2013 16:18:22 +1000 From: Byron Ellacott To: "John R. Levine" Thread-Topic: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt Thread-Index: AQHObkJ/CKwlwoI/TUWBWggKk/ArmZk/wxcAgARVu4D//1yEgIAAyHYA//9u2ACAALwQAA== Date: Mon, 24 Jun 2013 06:18:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <9BDF8B1B5716294F82CB7C8A2ABD34CA@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 06:18:33 -0000 Hi John, On 24/06/13 3:05 PM, "John R. Levine" wrote: >> If bootstrapping via DNS is sufficient for the reverse DNS domain >> queries, is query load the main reason it isn't also sufficient for IP >> network queries? > >Numbers are different. For IPv4 you could fake it by using the top octet >of the address, but for IPv6 and ASNs the allocation structure is >extremely irregular and I don't see any way to represent it in the DNS >with reasonable performance. Right, I agree, but I'm not suggesting that bootstrap should start by trying to find the best server directly by picking some part of the address and looking that up in the DNS. I am suggesting that if arpa.domain.rdap.arpa is capable of redirecting a querying client to the correct server for 2.0.192.in-addr.arpa, then something.rdap.arpa is capable of redirecting a querying client to the correct server for 192.0.2/24. >It's perfectly possible to represent the allocation information in a >compact and efficiently searchable form (it is, after all, on three pages >at IANA), but not by using the formats that the DNS provides. The number >bootstrap data changes very rarely, like once a year or less, so it's OK >for the update not to be automatic. Hence the per-TLD DNS lookup for the >regularly named but frequently updated and uncoordinated DNS registries, >and the vague baked-in bootstrap hack for the irregularly named, but >rarely updated and well coordinated RIRs. And something.rdap.arpa could quite easily be a set of servers where a client can select a good reasonable starting server from that set based on an internal hints table, but where any of the set of servers will do the appropriate redirection. What I don't want to see is that the bootstrap process for numbers involves fetching that table as the first step in the bootstrap, plus or minus caching, because that sort of fetch-and-parse significantly increases the complexity of doing a query for an IP network. (And I don't think you've suggested this.) Byron From johnl@taugh.com Mon Jun 24 07:22:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0129E21E80F2 for ; Mon, 24 Jun 2013 07:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzFKf-zpqQdG for ; Mon, 24 Jun 2013 07:22:27 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2FD21F9ADF for ; Mon, 24 Jun 2013 07:22:01 -0700 (PDT) Received: (qmail 18974 invoked from network); 24 Jun 2013 14:22:00 -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:cleverness; s=4a1c.51c85608.k1306; bh=BaLoz4MVBiIlN5E+r7a1fPnN1BK4i1XZTBmRFqdaOWA=; b=UfLRMkMsrd+/MekDe2T7JRX76LFlYxlgUsJsnXW+/BdqWCtBw/eB7Iz/cgnicgMjcNkz//O/40fmOXkOElEW6+3RbWHTtRGyTLeg68NZTe2K4L0RIGzHmUmpV58wraAkz44vaLeQ0HFLpEBmIe66+wd7M8rERQFAAWpXq5M/hB1fhkAvgUfkialjDIm1mjnzjNtvG9dsU+a85g4yvlaXOcCW2V6/XysJ/ObJzeyLC4YeLB2wKQIHRm0uW40Y3UOg 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:cleverness; s=4a1c.51c85608.k1306; bh=BaLoz4MVBiIlN5E+r7a1fPnN1BK4i1XZTBmRFqdaOWA=; b=Op+z3T/A6iWHpDXoQdsubR2LUY/1Vr3OfQqe+lbI7oxH3VK99sdfBPChcHuKmkEAdY+f/qY7aKNpJP071Sh+wgcT/Ero9rT0FPDdCZ452tvoHbOsg6rZVCJEZYtPb/E1mwsf670mqF0HsNCcXejKjVjFGUXZByxayxLvzRDTRm6OkEeAW2MhmFn1Xax4eF1L5r0CnesT6S41xggE/Lf5/G6HEjllAXSnLfLg5TloYB1HRylmHSuOTXgUtE576TdV Received: (ofmipd 127.0.0.1); 24 Jun 2013 14:21:38 -0000 Date: 24 Jun 2013 10:22:00 -0400 Message-ID: From: "John R Levine" To: "Byron Ellacott" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:22:30 -0000 > I am suggesting that if arpa.domain.rdap.arpa is capable of redirecting > a querying client to the correct server for 2.0.192.in-addr.arpa, then > something.rdap.arpa is capable of redirecting a querying client to the > correct server for 192.0.2/24. I don't know anyone who expects that IANA would run a high performance RDAP server on .ARPA. It seems unlikely that they they would run any RDAP server other than perhaps a small one for .INT and the root database. > And something.rdap.arpa could quite easily be a set of servers where a > client can select a good reasonable starting server from that set ... That's basically the pool approach. > What I don't want to see is that the bootstrap process for numbers > involves fetching that table as the first step in the bootstrap, plus or > minus caching, because that sort of fetch-and-parse significantly > increases the complexity of doing a query for an IP network. (And I don't > think you've suggested this.) Again, right. My idea is that the numbers bootstrap is built into the client or a local table, with no automatic fetching or updates. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From johnl@iecc.com Sun Jun 23 22:05:13 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7DD21F9FBD for ; Sun, 23 Jun 2013 22:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.3 X-Spam-Level: X-Spam-Status: No, score=-103.3 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fCyXq9moaMr for ; Sun, 23 Jun 2013 22:05:12 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5563A21F9D55 for ; Sun, 23 Jun 2013 22:05:12 -0700 (PDT) Received: (qmail 9308 invoked from network); 24 Jun 2013 05:05:10 -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:cleverness; s=245b.51c7d386.k1306; bh=YiKfOEd6hHntG7FtC9AhPKjM+9dU7gpFXE34h1Vl+oE=; b=A9G550lw1cHQZgHGj1MJF2AR6W8X9BaSpMBk/mC2m9yuGGsyx9k90rgWtPrujE0A4w8TPrOMKTxpnfeMdQ/tfCq0dTbQcO5Kic+GVYjQur5KkfsGv7mARfAqiIigBVb+Y5IMdizqBd3d60CMZZY/jznNxI2cegJD4fJ/2WnWnA/5Mq5RuCPdL6MRIVaodQQKu7PBX6wGvi+f4z1EIZO9D596wqUhaVtBNNKxQ3EQWGsoku5AeiEVI6OZudhcT/n6 Received: (ofmipd 127.0.0.1); 24 Jun 2013 05:04:48 -0000 Date: 24 Jun 2013 01:05:10 -0400 Message-ID: From: "John R. Levine" To: "Byron Ellacott" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 24 Jun 2013 10:57:18 -0700 Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 05:05:13 -0000 > If bootstrapping via DNS is sufficient for the reverse DNS domain > queries, is query load the main reason it isn't also sufficient for IP > network queries? I could have sworn we went over all this last week, but anyway, ... Query load is only part of the reason. Domain names are allocated a TLD at a time, so a reasonable boostrap is to use the TLD name as the handle. It doesn't matter that the .COM server gets 3000 queries/sec, since the vast majority of bootstrap queries for com.domain.rdap.arpa will be satisfied from local caches. Due to both the ICANN new TLD program and the number of existing TLDs, it seems likely that the bootstrap data will change fairly often, so we need something that automatically updates clients when there's a change, hence DNS. Marc's draft says "longest match", but in fact the IANA domain registry is all TLDs so just doing the TLD lookup rather than the whole name is adequate and makes the DNS caches work. Numbers are different. For IPv4 you could fake it by using the top octet of the address, but for IPv6 and ASNs the allocation structure is extremely irregular and I don't see any way to represent it in the DNS with reasonable performance. If you do the obvious thing for IPv4 and IPv6 and use something that looks like rDNS, e.g. 4.3.2.1.ip4.rdap.arpa. or f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.ip6.rdap.arpa, and cover the DNS namespace with DNS wildcards, you get pessimal DNS cache behavior, i.e., none at all. Each query for a different address goes back to the bootstrap server which synthesizes a unique response per address, which means vast traffic on the rdap.arpa servers, and DNS caches filling up with useless junk, since a cache entry is only reused if it exactly matches a previous query. The longest allocated IPv6 prefix is a /23, but even if you truncate the bootstrap queries to 24 bits (for 4 bit rDNS boundaries) you're still going to need 4096 real or synthesized entries for each allocated /12, with basically the same problems. Even worse, the ASN space is flat, with allocated numbers ranging from 1 to 394,239 with some large unallocated holes. A DNS zone of that size is not going to make DNS servers or DNS caches happy. Even if we invented a rDNS like representation to make it easier to cover ranges with wildcards, it'd have the same performance problems. It's perfectly possible to represent the allocation information in a compact and efficiently searchable form (it is, after all, on three pages at IANA), but not by using the formats that the DNS provides. The number bootstrap data changes very rarely, like once a year or less, so it's OK for the update not to be automatic. Hence the per-TLD DNS lookup for the regularly named but frequently updated and uncoordinated DNS registries, and the vague baked-in bootstrap hack for the irregularly named, but rarely updated and well coordinated RIRs. Does that make more sense? R's, John From stpeter@stpeter.im Mon Jun 24 16:38:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE22221F9F05 for ; Mon, 24 Jun 2013 16:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbb9MTIF8Suw for ; Mon, 24 Jun 2013 16:38:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8B61E21F9EFC for ; Mon, 24 Jun 2013 16:38:29 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8B5BC412C3; Mon, 24 Jun 2013 17:38:44 -0600 (MDT) Message-ID: <51C8D872.5030606@stpeter.im> Date: Mon, 24 Jun 2013 17:38:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [weirds] JSON vCard reference X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 23:38:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The latest version of draft-ietf-weirds-json-response still references draft-kewisch-vcard-in-json. Please note that draft-kewisch-vcard-in-json has been superseded by draft-ietf-jcardcal-jcard. (Also, the latter specification has been submitted to the IESG for publication, so if you have feedback please send it as soon as possible.) Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRyNhyAAoJEOoGpJErxa2pso4P/3xjilZAMiYUmqGLqfjSjxMs dpiYsNwiWdnPdiO5mUcLdekSlu/OncXByuthcDMQ9HJcLBwB9j6vcY2I/xTOPqxm Woj26afUmArhhCEMU1B5BlM4kEKC43SIq3LIyJjpK3Rf8+XImwu01LeaPUjGXnoz 85+WRSuijXkToIe9/e1ynw4oNb1gty5UNHX6h1hwGZszt6h5gZTcuVNpDeZ7tqYu f1y1vMj+lfmaoNDzThr73vri/gNnFM+FrP2c2XyA5ejWZT96eE+x5sOo3X24JUcz EzXKXqZPahGOJ+oUAESExzR7b4ryOLmK2VSLNnOmfGlUg0uk4k5HoNEo3swibqZE NTGlC0n+2syuOV0au5OEh6gaH21JGl75f0hq+JoBiV9tIMilFbZ4/KyrFpqnvPsr ZJqmMi2//91z62YkWYTyMnUGxSAFzGzUgmvhdiS1pCN6qQrmQ51Tk/kpcT/WFBY3 EZpOo35XW8F+VCDMN9L9aq4TUHggozko0cPOKpMN6Df4ysQhxYESiB8uFjSIf/wS v0r2WcecAIuiJGNi8YLZL4dCBxQShR77+ToB/zTY+Bx+ZDimfgnY9yY61zQOsrwY EkzPnDYspBOnRREsgk81OEN22kB/3nY3GXLmdOTepuuKtl4IxGQz3Bf2LP0u7D1k YWfaQo5DxoeHGkWReBid =+jWM -----END PGP SIGNATURE----- From andy@arin.net Mon Jun 24 17:05:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D51B21E8132 for ; Mon, 24 Jun 2013 17:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.831 X-Spam-Level: X-Spam-Status: No, score=-3.831 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9COm5+GN+gh for ; Mon, 24 Jun 2013 17:05:36 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 82FD621E8162 for ; Mon, 24 Jun 2013 17:05:35 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 37051165148; Mon, 24 Jun 2013 20:05:35 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 7A455165138; Mon, 24 Jun 2013 20:05:34 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 24 Jun 2013 20:05:15 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.237]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 20:05:15 -0400 From: Andy Newton To: Peter Saint-Andre , "weirds@ietf.org" Thread-Topic: [weirds] JSON vCard reference Thread-Index: AQHOcTP/PdTpco85k0eKvFe8z84AZplFjOoA Date: Tue, 25 Jun 2013 00:05:14 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E4EA0DA1@CHAXCH01.corp.arin.net> In-Reply-To: <51C8D872.5030606@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <54C4954441862441AB3378A97666C584@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] JSON vCard reference X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 00:05:40 -0000 Thanks. I just put that on the todo list. -andy On 6/24/13 7:38 PM, "Peter Saint-Andre" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >The latest version of draft-ietf-weirds-json-response still references >draft-kewisch-vcard-in-json. Please note that >draft-kewisch-vcard-in-json has been superseded by >draft-ietf-jcardcal-jcard. (Also, the latter specification has been >submitted to the IESG for publication, so if you have feedback please >send it as soon as possible.) > >Thanks! > >Peter > >- --=20 >Peter Saint-Andre >https://stpeter.im/ > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >Comment: GPGTools - http://gpgtools.org >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iQIcBAEBAgAGBQJRyNhyAAoJEOoGpJErxa2pso4P/3xjilZAMiYUmqGLqfjSjxMs >dpiYsNwiWdnPdiO5mUcLdekSlu/OncXByuthcDMQ9HJcLBwB9j6vcY2I/xTOPqxm >Woj26afUmArhhCEMU1B5BlM4kEKC43SIq3LIyJjpK3Rf8+XImwu01LeaPUjGXnoz >85+WRSuijXkToIe9/e1ynw4oNb1gty5UNHX6h1hwGZszt6h5gZTcuVNpDeZ7tqYu >f1y1vMj+lfmaoNDzThr73vri/gNnFM+FrP2c2XyA5ejWZT96eE+x5sOo3X24JUcz >EzXKXqZPahGOJ+oUAESExzR7b4ryOLmK2VSLNnOmfGlUg0uk4k5HoNEo3swibqZE >NTGlC0n+2syuOV0au5OEh6gaH21JGl75f0hq+JoBiV9tIMilFbZ4/KyrFpqnvPsr >ZJqmMi2//91z62YkWYTyMnUGxSAFzGzUgmvhdiS1pCN6qQrmQ51Tk/kpcT/WFBY3 >EZpOo35XW8F+VCDMN9L9aq4TUHggozko0cPOKpMN6Df4ysQhxYESiB8uFjSIf/wS >v0r2WcecAIuiJGNi8YLZL4dCBxQShR77+ToB/zTY+Bx+ZDimfgnY9yY61zQOsrwY >EkzPnDYspBOnRREsgk81OEN22kB/3nY3GXLmdOTepuuKtl4IxGQz3Bf2LP0u7D1k >YWfaQo5DxoeHGkWReBid >=3D+jWM >-----END PGP SIGNATURE----- >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds > From zhoulinlin@cnnic.cn Mon Jun 24 19:30:36 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A12411E80F6 for ; Mon, 24 Jun 2013 19:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBUlBdIsXTFl for ; Mon, 24 Jun 2013 19:30:31 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id A3C1711E80F1 for ; Mon, 24 Jun 2013 19:30:29 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 25 Jun 2013 10:30:15 +0800 From: "Linlin Zhou" To: "'John R. Levine'" , "'Byron Ellacott'" References: In-Reply-To: Date: Tue, 25 Jun 2013 10:30:15 +0800 Message-ID: <011901ce714b$ed4dfc40$c7e9f4c0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5xBE094Pc6LrUIQb2wKpNuJnVrlQARCurg Content-Language: zh-cn Cc: 'John R Levine' , weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 02:30:36 -0000 > > It's perfectly possible to represent the allocation information in a compact and > efficiently searchable form (it is, after all, on three pages at IANA), but not by > using the formats that the DNS provides. The number bootstrap data > changes very rarely, like once a year or less, so it's OK for the update not to be > automatic. Hence the per-TLD DNS lookup for the regularly named but > frequently updated and uncoordinated DNS registries, and the vague baked-in > bootstrap hack for the irregularly named, but rarely updated and well > coordinated RIRs. > I agree with John. I think it is better to use a local table or file for numbers bootstrap and update when necessary. We've already adopted this method. > Does that make more sense? > > R's, > John From johnl@taugh.com Mon Jun 24 21:11:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09ED121F8EFE for ; Mon, 24 Jun 2013 21:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kqpAcLvsejU for ; Mon, 24 Jun 2013 21:11:43 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D6F4421E8095 for ; Mon, 24 Jun 2013 21:11:42 -0700 (PDT) Received: (qmail 71780 invoked from network); 25 Jun 2013 04:11:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-id:user-agent:cleverness; s=11862.51c9187d.k1306; bh=4l8wR1dYyniwDiNtM6rbr1EWGAk3ZSBQH4uCpzbToLg=; b=ipkcLtcTt2qFfjAR12+O4//cpcL73BE06D+9fX/kw1HbnjkEaBfhAUwVysf+oCNvFWAPkc06eTfgA1kYyPglcVrln6qKtV2LiB8Pz3lniLREwFQww/cXk3UfupFBdxahRuJOYRJlntnxvZKgTI/bhy55gkD0Xm+KY8dkhyiWKxepuX3H772xBOd6wU0kue4m0O6bCzYxP+Cxn302hTYX8JpwwhraS3SrldWJqWlAjrTz7Q7UHsJl1odPjrEJ3zu0 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-id:user-agent:cleverness; s=11862.51c9187d.k1306; bh=4l8wR1dYyniwDiNtM6rbr1EWGAk3ZSBQH4uCpzbToLg=; b=dbZX2Qaio2zDtQxf9ovZ0DJxChKJZg/EsEe9wtBLZvb2gwSwYt99q/ui6ZORbuv4io2TwgWeisL7kv9LhBKbJ0zfVHDHEnmSlejfeQBbJSA78R9uiNnD+baexEVz49Ne2+hcxnzA+NwTZCOgGYdHnt74U+6BVr5befGnShTem0/6aVP8rKKdMQ9uk19pWhzvDt3EZTPHemqyZKMKxDhzk7fNu7wyupcFA9T9o45dMs8sySTnXwBxBoUOdzcaHr9U Received: (ofmipd 127.0.0.1); 25 Jun 2013 04:11:19 -0000 Date: 25 Jun 2013 00:11:41 -0400 Message-ID: From: "John R Levine" To: weirds@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="3825401791-1009487216-1372133267=:25627" Content-ID: Subject: [weirds] ICANN News Alert -- Explore the Draft Next Generation gTLD Directory Services Model X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 04:11:44 -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. --3825401791-1009487216-1372133267=:25627 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: An ICANN working group recommends replacing WHOIS with a giant centralized database of registrant contact information. Scott Hollenbeck was one of the group members; I realize the group isn't done so there's doubtless confidentiality issues but perhaps he can give some pointers to where to look for more info beyond the draft report linked below. R's, John ---------- Forwarded message ---------- Date: Mon, 24 Jun 2013 22:47:17 From: ICANN At-Large Staff Subject: [ALAC-Announce] ICANN News Alert -- Explore the Draft Next Generation gTLD Directory Services Model http://www.icann.org/en/news/announcements/announcement-3-24jun13-en.htm ________________________________ Explore the Draft Next Generation gTLD Directory Services Model 24 June 2013 ICANN has embarked on an effort to reinvent today's WHOIS system. Be part of the solution and join the discussion...online and at ICANN's Durban meeting. As the Expert Working Group on gTLD Directory Services (EWG), we have proposed a paradigm shift – a new system in which gTLD registration data is collected, validated and disclosed for permissible purposes only, with some data elements being accessible only to authenticated requestors that are then held accountable for appropriate use. Our objective is to reexamine and define the purpose of collecting and maintaining gTLD directory data, consider how to safeguard the data, and propose a next generation solution that will better serve the needs of the global Internet community. In our Initial Report [PDF, 1.7 MB], we identify the design features and principles that we think are essential in this new system, and a proposed Model for the next generation data directory services to replace WHOIS. Help shape this paradigm shift by sharing your reaction to our recommendations [PDF, 1.7 MB] and answering the questions linked below (click on "Share Your Thoughts"). Did we meet our objective? Do the recommendations address your concerns? How can we make them better? Share Your Thoughts There are different ways to share your perspective with us: * A webinar on Monday, 8 July at 15:00-16:30 UTC: we will walk you through our proposal and invite you to share your views and input. * A consultation in Durban on Monday, 15 July: we will present the outcome of our work and open the floor for any questions or feedback you may have. A recording of the session will be made available shortly after the meeting; * Submit comments by email: input-to-ewg@icann.org. All input received by August 12 will be carefully considered as we finalize our recommendations and bring our work to a conclusion. To help focus your attention, we request your feedback on a set of questions, although you are free to comment on any aspect of the Initial Report. Sincerely, Members of the Expert Working Group on gTLD Directory Services (EWG) More Information Our work stems from the Board's directive to redefine the purpose and provision of gTLD registration data, while balancing data accuracy and access issues with safeguards for protecting data. We considered the important community work done over the last decade by the GNSO, the SSAC, the WHOIS Review Team, the GAC and others. Our Initial Report [PDF, 1.7 MB] reflects our consensus view of the design principles and features needed for a new system. Our proposed Model highlights how these design principles and features could be fulfilled in the ICANN domain ecosystem. What's Next? We will consider your input and present a final report containing our recommended design principles, features, and suggested Model to ICANN's CEO and Board when our work is concluded. This output will feed into a Board-initiated GNSO policy development process to serve as a foundation for the GNSO's creation of new consensus policy, and contractual negotiations, as appropriate. --3825401791-1009487216-1372133267=:25627-- From fobispo@isc.org Mon Jun 24 21:13:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E5321F9926 for ; Mon, 24 Jun 2013 21:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4NNmG6AWMMH for ; Mon, 24 Jun 2013 21:13:16 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F1B6921F926E for ; Mon, 24 Jun 2013 21:13:15 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 4DB89C9423; Tue, 25 Jun 2013 04:13:09 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372133595; bh=+PH6qv2VSoVNEBNYJO+aUGMoD5OriY/AnS1pR7WdXSQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=R9F8teizcnsndH3ZSVAk9GHeTcFLG0ARvhsukiaIUbaIIXz4KPt8a2qlqfjTmpFw6 s1/k1qOtjrG0gD2LEEi2rGfM4yNZPvCszDJ7HXtN1tS8PgKJr8IqMaE49L1YDObYYF mgna2dawxbUqHOBfd3AVWeOiy6QYi5NmraGeqZcc= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 25 Jun 2013 04:13:09 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [10.0.1.4] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 314D9216C3D; Tue, 25 Jun 2013 04:13:09 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Francisco Obispo In-Reply-To: Date: Mon, 24 Jun 2013 21:13:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John R Levine X-Mailer: Apple Mail (2.1508) X-DCC--Metrics: post.isc.org; whitelist Cc: weirds@ietf.org Subject: Re: [weirds] ICANN News Alert -- Explore the Draft Next Generation gTLD Directory Services Model X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 04:13:16 -0000 It kind of surprised me as well, specially since we've been all busy = working on WEIRDs and it seems like a different approach? On Jun 24, 2013, at 9:11 PM, John R Levine wrote: > An ICANN working group recommends replacing WHOIS with a giant = centralized database of registrant contact information. >=20 > Scott Hollenbeck was one of the group members; I realize the group = isn't done so there's doubtless confidentiality issues but perhaps he = can give some pointers to where to look for more info beyond the draft = report linked below. >=20 > R's, > John Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From johnl@taugh.com Mon Jun 24 21:25:01 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BD621F9CC7 for ; Mon, 24 Jun 2013 21:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwGGuRCjPOws for ; Mon, 24 Jun 2013 21:25:00 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4B55B21F9CC5 for ; Mon, 24 Jun 2013 21:24:59 -0700 (PDT) Received: (qmail 74148 invoked from network); 25 Jun 2013 04:24:57 -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:cleverness; s=121a3.51c91b99.k1306; bh=AHAfaR3AJ3o/+up8bKPaaufEk0sSdd4zzIGHU3NbJSI=; b=DEHH4M2AuauSWqPkJDUM5ZthOtrIs7tGjoolyA12wOujZ1RSgSAvzGX8dJw/0WqAQtrmWYBalK8zAwAYJiYM4RZ4ajOyctsT6XBfqLm7NySTcs7xfpy/w4WisLq4m4d/wY8T7uFXH/fsHnN7JNWdym8UmICYshmhf0GoFeul9ds4HSoSqlwDHD0sVOUEejAfz1iWgNeE3r/NlKIbgkZBj8Wl8xXmobxgNMxaRS6TeddI4RcznZlEPmNgHW4sFUJp 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:cleverness; s=121a3.51c91b99.k1306; bh=AHAfaR3AJ3o/+up8bKPaaufEk0sSdd4zzIGHU3NbJSI=; b=bPOCIdwfjsAczyqPaE7MgNwXBGwpr9J+cZjeaN2IcnhdLiJo8zFtvErXEG6/4COnj0b1SWD0lSdYIxZmET5fIRP3v7OqsNRS5sWS5dXsxg1KkaDrvo/k+gDMkQi7eZKG5/uCcVSre8z1lie88+osUHepCOdu93ZeWnxs9f+KyLTuNjqUAB6slx/KGWfto81FSGNWltjOVl/tjhKKIpF2p9g4vrtIiOmGGr/NVWKfdkeSE63Dz7tDju9RhHi/QAVq Received: (ofmipd 127.0.0.1); 25 Jun 2013 04:24:34 -0000 Date: 25 Jun 2013 00:24:56 -0400 Message-ID: From: "John R Levine" To: "Francisco Obispo" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] ICANN News Alert -- Explore the Draft Next Generation gTLD Directory Services Model X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 04:25:01 -0000 > It kind of surprised me as well, specially since we've been all busy > working on WEIRDs and it seems like a different approach? Well, do remember that the original plan was for WEIRDS to deal with number data, and the names part was added to mollify a mob of people demanding that we handle names, most of whom (with you and Scott as notable exceptions) promptly disappeared. It seems to me that WEIRDS-name is as good an approach as any to query whatever the EWG comes up with, give or take what goes where in its tiered access model. It also seems unlikely that this will affect ccTLDs who are much more likely to hold onto their own data and provide their own WEIRDS servers. And if history is any guide, it will be a very long time if ever before the EWG's report is accepted and implemented, so in the intervening decade it would be nice to have a better way to query the existing registries for the existing crud. R's, John > On Jun 24, 2013, at 9:11 PM, John R Levine wrote: > >> An ICANN working group recommends replacing WHOIS with a giant centralized database of registrant contact information. >> >> Scott Hollenbeck was one of the group members; I realize the group isn't done so there's doubtless confidentiality issues but perhaps he can give some pointers to where to look for more info beyond the draft report linked below. From shollenbeck@verisign.com Tue Jun 25 04:11:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629AA21F9A00 for ; Tue, 25 Jun 2013 04:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r67dL41xqPlG for ; Tue, 25 Jun 2013 04:11:42 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6A421E809E for ; Tue, 25 Jun 2013 04:11:21 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUcl62NDmhZxy5uPB0I/thigtqGHazl15@postini.com; Tue, 25 Jun 2013 04:11:23 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 r5PBBGiG028909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Jun 2013 07:11:17 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 07:11:16 -0400 From: "Hollenbeck, Scott" To: John R Levine , "weirds@ietf.org" Thread-Topic: [weirds] ICANN News Alert -- Explore the Draft Next Generation gTLD Directory Services Model Thread-Index: AQHOcVoeh5+ELkh1PUuc3uhptrRNtZlGQ22g Date: Tue, 25 Jun 2013 11:11:15 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F36AD817B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [weirds] ICANN News Alert -- Explore the Draft Next Generation gTLD Directory Services Model X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:11:48 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB3ZWlyZHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOndlaXJkcy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgSm9o biBSIExldmluZQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDI1LCAyMDEzIDEyOjEyIEFNDQo+IFRv OiB3ZWlyZHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3dlaXJkc10gSUNBTk4gTmV3cyBBbGVydCAt LSBFeHBsb3JlIHRoZSBEcmFmdCBOZXh0IEdlbmVyYXRpb24NCj4gZ1RMRCBEaXJlY3RvcnkgU2Vy dmljZXMgTW9kZWwNCj4gDQo+IEFuIElDQU5OIHdvcmtpbmcgZ3JvdXAgcmVjb21tZW5kcyByZXBs YWNpbmcgV0hPSVMgd2l0aCBhIGdpYW50DQo+IGNlbnRyYWxpemVkDQo+IGRhdGFiYXNlIG9mIHJl Z2lzdHJhbnQgY29udGFjdCBpbmZvcm1hdGlvbi4NCj4gDQo+IFNjb3R0IEhvbGxlbmJlY2sgd2Fz IG9uZSBvZiB0aGUgZ3JvdXAgbWVtYmVyczsgSSByZWFsaXplIHRoZSBncm91cA0KPiBpc24ndCBk b25lDQo+IHNvIHRoZXJlJ3MgZG91YnRsZXNzIGNvbmZpZGVudGlhbGl0eSBpc3N1ZXMgYnV0IHBl cmhhcHMgaGUgY2FuIGdpdmUNCj4gc29tZQ0KPiBwb2ludGVycyB0byB3aGVyZSB0byBsb29rIGZv ciBtb3JlIGluZm8gYmV5b25kIHRoZSBkcmFmdCByZXBvcnQgbGlua2VkDQo+IGJlbG93Lg0KDQpU aGVyZSdzIG5vdGhpbmcgZWxzZSB0aGF0J3MgYXZhaWxhYmxlIHRvIHRoZSBnZW5lcmFsIHB1Ymxp Yy4NCg0KVGhpcyBJQ0FOTiBlZmZvcnQgZG9lcyBub3QgaW4gYW55IHdheSBjb25mbGljdCB3aXRo IG9yIGNvbnRyYWRpY3Qgb3VyIHdvcmsgaW4gV0VJUkRTLiBOb3RlIHRoYXQgdGhlIHByZWxpbWlu YXJ5IHJlcG9ydCBkb2Vzbid0IHNheSBhbnl0aGluZyBhYm91dCB0aGUgYWNjZXNzIHByb3RvY29s LCBidXQgaXQgY291bGQgdmVyeSB3ZWxsIGJlIFJEQVAuDQoNCkFzIG5vdGVkIGluIGFub3RoZXIg cmVwbHkgdG8gdGhpcyB0aHJlYWQsIHdoYXRldmVyIGFjdGlvbiBpcyB0YWtlbiB3aXRoIHJlc3Bl Y3QgdG8gdGhlIHJlcG9ydCBpcyB5ZWFycyBhd2F5LiBJZiBSREFQIGdldHMgdHJhY3Rpb24gdGhl cmUncyBubyByZWFzb24gaXQgY2FuJ3QgYmUgdXNlZC4gSSBjYW4ndCB0ZWxsIHlvdSBob3cgbWFu eSB0aW1lcyBJIGV4cGxhaW5lZCB0byB0aGUgZ3JvdXAgaG93IFJEQVAgY291bGQgKG9yIGNvdWxk bid0KSBzdXBwb3J0IHRoZSByZWNvbW1lbmRhdGlvbnMgd2Ugd2VyZSBkZWJhdGluZy4NCg0KU2Nv dHQNCg== From dave.piscitello@icann.org Tue Jun 25 05:09:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB6421E804B for ; Tue, 25 Jun 2013 05:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISsUbg0vvd5j for ; Tue, 25 Jun 2013 05:09:38 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id B52E621F9F04 for ; Tue, 25 Jun 2013 05:09:38 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 25 Jun 2013 05:09:33 -0700 From: Dave Piscitello To: "Hollenbeck, Scott" Date: Tue, 25 Jun 2013 05:09:27 -0700 Thread-Topic: [weirds] ICANN News Alert -- Explore the Draft Next Generation gTLD Directory Services Model Thread-Index: Ac5xnNp7mTtGSeDTRYOhoNdtVSjFJQ== Message-ID: <482E6690-3D32-457B-9950-D70BABB93AC9@icann.org> References: <831693C2CDA2E849A7D7A712B24E257F36AD817B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F36AD817B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] ICANN News Alert -- Explore the Draft Next Generation gTLD Directory Services Model X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:09:43 -0000 +1 I think weirds would be an essential component of this proposed solution. I= also suggest you speak with Rod Rasmussen for addl info Sent from my iPhone On Jun 25, 2013, at 7:12 AM, "Hollenbeck, Scott" = wrote: >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of John R Levine >> Sent: Tuesday, June 25, 2013 12:12 AM >> To: weirds@ietf.org >> Subject: [weirds] ICANN News Alert -- Explore the Draft Next Generation >> gTLD Directory Services Model >>=20 >> An ICANN working group recommends replacing WHOIS with a giant >> centralized >> database of registrant contact information. >>=20 >> Scott Hollenbeck was one of the group members; I realize the group >> isn't done >> so there's doubtless confidentiality issues but perhaps he can give >> some >> pointers to where to look for more info beyond the draft report linked >> below. >=20 > There's nothing else that's available to the general public. >=20 > This ICANN effort does not in any way conflict with or contradict our wor= k in WEIRDS. Note that the preliminary report doesn't say anything about th= e access protocol, but it could very well be RDAP. >=20 > As noted in another reply to this thread, whatever action is taken with r= espect to the report is years away. If RDAP gets traction there's no reason= it can't be used. I can't tell you how many times I explained to the group= how RDAP could (or couldn't) support the recommendations we were debating. >=20 > Scott > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From olaf@NLnetLabs.nl Tue Jun 25 05:38:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681C821E8063 for ; Tue, 25 Jun 2013 05:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTAJmuT3NHz1 for ; Tue, 25 Jun 2013 05:38:19 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D0C11E80EA for ; Tue, 25 Jun 2013 05:38:19 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a] ([IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r5PCcHVH089464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 25 Jun 2013 14:38:18 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.2 open.nlnetlabs.nl r5PCcHVH089464 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1372163898; bh=d9BR0n6AZhyVm5NQpuLLlUHDadk+fnDGz0ZTtS8smLg=; h=From:Subject:Date:To; b=VmKjPUpXe+qbWr51VO92jg/qq3YiHIwOihPOLl41ZSwGJVm0HrWJFKRiKHdpMJS2J JeGT9Cd0EMozkeZvnwBHjkLUyMhcX1QvW88giw/qfQmDZTIVDdD6K74SUN8L2L73Lm E37/K/L6ccj5mwQqSXqMg84yLkdtn0bXYZaSHvpw= From: Olaf Kolkman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <462E855B-71B9-45DA-8124-656BD6149234@NLnetLabs.nl> Date: Tue, 25 Jun 2013 14:38:16 +0200 To: "weirds@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 25 Jun 2013 14:38:18 +0200 (CEST) Subject: [weirds] WGLC: draft-ietf-weirds-rdap-query-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:38:20 -0000 Colleagues, It's time for a WGLC for de rdap-query document. We'll put the Last call = up for two weeks, ending July 10. The document can be found at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-05 I will be the shepherd for this document. Which in this case brings a = small logistical problem. When the WGLC terminates I will be on = vacation, and not resurface before Berlin. That said, please send in = your comments before July 10 so that editors can process your feedback. --Olaf From marc.blanchet@viagenie.ca Tue Jun 25 06:16:45 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2279321F9B84 for ; Tue, 25 Jun 2013 06:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQgGyHEyiZtF for ; Tue, 25 Jun 2013 06:16: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 90D9121F9A95 for ; Tue, 25 Jun 2013 06:16:44 -0700 (PDT) Received: from [IPv6:2620:0:230:2002::1001] (unknown [IPv6:2620:0:230:2002::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 88EFA40425; Tue, 25 Jun 2013 09:16:42 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <011901ce714b$ed4dfc40$c7e9f4c0$@cn> Date: Tue, 25 Jun 2013 09:16:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <529D1301-BF28-41E6-951A-757AAC8EAAC9@viagenie.ca> References: <011901ce714b$ed4dfc40$c7e9f4c0$@cn> To: "Linlin Zhou" X-Mailer: Apple Mail (2.1508) Cc: "'John R. Levine'" , 'John R Levine' , weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:16:45 -0000 Le 2013-06-24 =E0 22:30, "Linlin Zhou" a =E9crit : >>=20 >> It's perfectly possible to represent the allocation information in a > compact and >> efficiently searchable form (it is, after all, on three pages at = IANA), > but not by >> using the formats that the DNS provides. The number bootstrap data >> changes very rarely, like once a year or less, so it's OK for the = update > not to be >> automatic. Hence the per-TLD DNS lookup for the regularly named but >> frequently updated and uncoordinated DNS registries, and the vague > baked-in >> bootstrap hack for the irregularly named, but rarely updated and well >> coordinated RIRs. >>=20 > I agree with John. I think it is better to use a local table or file = for > numbers bootstrap and update when necessary. We've already adopted = this > method. The "local table or file" has to come from somewhere. And the right = place is IANA registry. So the specification should tell you where to = get the data. The implementation may decide to fetch it more or less = frequently, such as software updates or more frequently. THis is = implementation choice. So the whole point of using the IANA registry is = to ensure that everybody is taking the right source of information at = the right place. Marc. >=20 >> Does that make more sense? >>=20 >> R's, >> John >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@taugh.com Tue Jun 25 06:45:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7D711E8110 for ; Tue, 25 Jun 2013 06:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1Suf85hMYda for ; Tue, 25 Jun 2013 06:45:11 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B20A91F0D1B for ; Tue, 25 Jun 2013 06:45:10 -0700 (PDT) Received: (qmail 90227 invoked from network); 25 Jun 2013 13:45:09 -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:cleverness; s=16072.51c99ee5.k1306; bh=GsfwlZ7qtWhwUzhs2djLl9Re2Okw6bNB5ZbyGEOw0Sk=; b=kMhKhQQ2yS6CNbYI/MVxTCkUzsutJ09M8ozfO7hXv7WfLc32KUbhbv6v4kdF0mr9VIIHGqYjsDX5fvcwmIlI8zj4wYvIjE6wUDmMoY+mCpZ7VAA0ppXSJ3ZKnfI93TWt6fJgFTaTs0SsovlW/u1aPyzD1pM1EoZcRsZCfaZ5RIefDcW3//85obsOUO3Df+gFex90Zp1FP0h8nvX/yZZlxLaqPjdPuwRdzrqj9hCpOjQtK48PgP3/okDvn2mqAZd4 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:cleverness; s=16072.51c99ee5.k1306; bh=GsfwlZ7qtWhwUzhs2djLl9Re2Okw6bNB5ZbyGEOw0Sk=; b=rw3SlO47kAfgbhQdYm1shlqsKVZBNP+mc6IGKyKe04DZHx+qsg1Aul/LvhYyEzWLQo8/24EW/xEvQ3HOaEUHgIAkkIh4wP1Hya2iwrcDMxmlFh6Gyvwx8b25uTNJGYfB0LKDlLExp5tPWNIM2bG8z9ZAWHSEYLYfA+Bkk3mpHSsmGJ6eWBWZAEwa9ybaTwMjtSOP6l2XPz7L7OEAoAoEYbBadkgB7uhvtY9O9hSOyFviYn75Uldn3976SRSCTyli Received: (ofmipd 127.0.0.1); 25 Jun 2013 13:44:47 -0000 Date: 25 Jun 2013 09:45:09 -0400 Message-ID: From: "John R Levine" To: "Marc Blanchet" In-Reply-To: <529D1301-BF28-41E6-951A-757AAC8EAAC9@viagenie.ca> References: <011901ce714b$ed4dfc40$c7e9f4c0$@cn> <529D1301-BF28-41E6-951A-757AAC8EAAC9@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-789573453-1372167909=:31466" Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:45:11 -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. --3825401791-789573453-1372167909=:31466 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> I agree with John. I think it is better to use a local table or file for >> numbers bootstrap and update when necessary. We've already adopted this >> method. > > The "local table or file" has to come from somewhere. And the right place is IANA registry. So the specification should tell you where to get the data. The implementation may decide to fetch it more or less frequently, such as software updates or more frequently. THis is implementation choice. So the whole point of using the IANA registry is to ensure that everybody is taking the right source of information at the right place. That's fine so long as we also make it abundantly clear that the bootstrap information changes very slowly so that clients MUST NOT fetch it on every run and SHOULD NOT fetch it every day, or even every week or every month. R's, John --3825401791-789573453-1372167909=:31466 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI1MTM0NTA5WjAjBgkqhkiG 9w0BCQQxFgQU9pwE+U2GPposeRsYWL7dcbov5/AweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAuoEu9aAzusCK qjtA3kxbfDKKmgJJEirE38/DoCaosa8EzplpDtQO4cDkPTv8SSfHKD7QqXsn pirGlGtXmbJq+N6XkeD4rSw2Bw1OuJU+oEM8uVSsGaJfxi0nzfuvnEUk3xJK 2vdANKWKaxcg7bWacpGSmnOJJvlQMtgDqF2tOffiH6i56SHPZF0RLaJH0HKb LlUEEGeM33a+8Fh69QPGEd2jh3y0yjaDLnXcWY8hSnDW4gnI1uR6ZSGfPHf2 1VnEpHcjcn+wHcTZ64Z1k5xuIUcw4O3Ss2p/4zVMUQgmUONsDgx0YoKw7R9D WJFyrXvPRrcZk17o3iD/yWDMnVGArA== --3825401791-789573453-1372167909=:31466-- From johnl@iecc.com Tue Jun 25 08:26:58 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE4E21F99AC for ; Tue, 25 Jun 2013 08:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.845 X-Spam-Level: X-Spam-Status: No, score=-110.845 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQKvR1u-CLNW for ; Tue, 25 Jun 2013 08:26:54 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 028E321F946C for ; Tue, 25 Jun 2013 08:26:53 -0700 (PDT) Received: (qmail 15981 invoked from network); 25 Jun 2013 15:26:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Jun 2013 15:26:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c9b6bc.xn--yuvv84g.k1306; i=johnl@user.iecc.com; bh=eV2ZTRqchvtl3RElddnzeKJXr0vxB4r167iMG78xjYc=; b=kpFOkCdA6Wk5gIOC42mZo48B00ePrZXXnyhsmBHyCWX/p4WQIeFgG28xRdBCOdMzb74sWz26W7UzmO2wCvYGGAfaVts6fTORLVxUpNGjDk6gLZWMnc86Cb5aw83jAGwHpTj/1SyZbXwTiswJpt0GI+Kwvlv+ocyr3TBYwvQY8IxWrb61RARtmkgXgpICIVsLVgAEaJYhOfifs+vEqcVKqzmcJD/1/CTYf77Uyh5UiZepFndmOOGS/HLFy6Fw7XbO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c9b6bc.xn--yuvv84g.k1306; olt=johnl@user.iecc.com; bh=eV2ZTRqchvtl3RElddnzeKJXr0vxB4r167iMG78xjYc=; b=P+Z/vd5rBrPr4d0eY96cIH1emrbdANAoBbiIdktlSwYB6r8zpHlX4LR2kyqoe/MtkIibwkg7sfIWdaYoialDPA65XqWQm+mmfhLmlZR0E6j67YE/oBaB/uujV0vrqZSwZwCmtwa1htWROYBvGBby7Q4/XtdkvG3VG+zugtJoe56Yp/A/Vs3olkwKxwcfxDELZarkWVzqdwfuIEhKEWeas8/+1rgoSdjwQBCg9i+2L0nA7+RieYV92+FezBHDxK1R Date: 25 Jun 2013 15:26:29 -0000 Message-ID: <20130625152629.32141.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:26:58 -0000 >> The "local table or file" has to come from somewhere. And the right place is IANA registry. So >the specification should tell you where to get the data. The implementation may decide to fetch it >more or less frequently, such as software updates or more frequently. THis is implementation >choice. So the whole point of using the IANA registry is to ensure that everybody is taking the >right source of information at the right place. > >That's fine so long as we also make it abundantly clear that the bootstrap >information changes very slowly so that clients MUST NOT fetch it on every >run and SHOULD NOT fetch it every day, or even every week or every month. It occurs to me that this is like the bootstrap file in your DNS cache. The authoritative copy comes from IANA, but it changes very slowly, and the penalty for being slightly out of date is low, so you don't need to be able to update it automatically. R's, John From michele@blacknight.com Tue Jun 25 09:37:31 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79DC21E80B9 for ; Tue, 25 Jun 2013 09:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGNUNhFXuZWW for ; Tue, 25 Jun 2013 09:37:28 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 958B121E80A9 for ; Tue, 25 Jun 2013 09:37:24 -0700 (PDT) Received: from bkexchmbx02.blacknight.local ([fe80::7969:977c:ecda:9a91]) by bkexchhubcas01.blacknight.local ([fe80::994e:1bb8:df56:f591%15]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 17:37:19 +0100 From: "Michele Neylon :: Blacknight" To: Dave Piscitello Thread-Topic: [weirds] ICANN News Alert -- Explore the Draft Next Generation gTLD Directory Services Model Thread-Index: Ac5xnNp7oouJ++Vgb02VMXNTMmuH2wAHQTaA Date: Tue, 25 Jun 2013 16:37:17 +0000 Message-ID: References: <831693C2CDA2E849A7D7A712B24E257F36AD817B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130625120810.710345A4010@merlin.blacknight.ie> In-Reply-To: <20130625120810.710345A4010@merlin.blacknight.ie> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a01:a8:ff01:0:cabc:c8ff:fea6:ee0b] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] ICANN News Alert -- Explore the Draft Next Generation gTLD Directory Services Model X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:37:31 -0000 RGF2ZSAvIEpvaG4gZXQgYWwNCg0KSSdtIGFsc28gb24gdGhlIGdyb3VwIHdpdGggU2NvdHQgYW5k IFJvZA0KDQpXZSdyZSBub3QgdGFza2VkIHdpdGggZ2V0dGluZyBpbnRvIHRoZSBzcGVjaWZpY3Mg b2YgaG93IHRoaXMgd291bGQgYWxsIHdvcmsgaWUuIGFjY2VzcyBwcm90b2NvbHMgZXRjLiwNCg0K U28gdGhlcmUncyBubyBvYnZpb3VzIHJlYXNvbiB3aHkgV0VJUkRTJyAgY2Fubm90IGJlIHVzZWQN Cg0KUmVnYXJkcw0KDQpNaWNoZWxlDQoNCg0KT24gMjUgSnVuIDIwMTMsIGF0IDEzOjA5LCBEYXZl IFBpc2NpdGVsbG8gPGRhdmUucGlzY2l0ZWxsb0BpY2Fubi5vcmc+IHdyb3RlOg0KDQo+ICsxDQo+ IA0KPiBJIHRoaW5rIHdlaXJkcyB3b3VsZCBiZSBhbiBlc3NlbnRpYWwgY29tcG9uZW50IG9mIHRo aXMgcHJvcG9zZWQgc29sdXRpb24uIEkgYWxzbyBzdWdnZXN0IHlvdSBzcGVhayB3aXRoIFJvZCBS YXNtdXNzZW4gZm9yIGFkZGwgaW5mbw0KPiANCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiANCj4g T24gSnVuIDI1LCAyMDEzLCBhdCA3OjEyIEFNLCAiSG9sbGVuYmVjaywgU2NvdHQiIDxzaG9sbGVu YmVja0B2ZXJpc2lnbi5jb20+IHdyb3RlOg0KPiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4+IEZyb206IHdlaXJkcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86d2VpcmRzLWJv dW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4gQmVoYWxmIE9mIEpvaG4gUiBMZXZpbmUNCj4+PiBTZW50 OiBUdWVzZGF5LCBKdW5lIDI1LCAyMDEzIDEyOjEyIEFNDQo+Pj4gVG86IHdlaXJkc0BpZXRmLm9y Zw0KPj4+IFN1YmplY3Q6IFt3ZWlyZHNdIElDQU5OIE5ld3MgQWxlcnQgLS0gRXhwbG9yZSB0aGUg RHJhZnQgTmV4dCBHZW5lcmF0aW9uDQo+Pj4gZ1RMRCBEaXJlY3RvcnkgU2VydmljZXMgTW9kZWwN Cj4+PiANCj4+PiBBbiBJQ0FOTiB3b3JraW5nIGdyb3VwIHJlY29tbWVuZHMgcmVwbGFjaW5nIFdI T0lTIHdpdGggYSBnaWFudA0KPj4+IGNlbnRyYWxpemVkDQo+Pj4gZGF0YWJhc2Ugb2YgcmVnaXN0 cmFudCBjb250YWN0IGluZm9ybWF0aW9uLg0KPj4+IA0KPj4+IFNjb3R0IEhvbGxlbmJlY2sgd2Fz IG9uZSBvZiB0aGUgZ3JvdXAgbWVtYmVyczsgSSByZWFsaXplIHRoZSBncm91cA0KPj4+IGlzbid0 IGRvbmUNCj4+PiBzbyB0aGVyZSdzIGRvdWJ0bGVzcyBjb25maWRlbnRpYWxpdHkgaXNzdWVzIGJ1 dCBwZXJoYXBzIGhlIGNhbiBnaXZlDQo+Pj4gc29tZQ0KPj4+IHBvaW50ZXJzIHRvIHdoZXJlIHRv IGxvb2sgZm9yIG1vcmUgaW5mbyBiZXlvbmQgdGhlIGRyYWZ0IHJlcG9ydCBsaW5rZWQNCj4+PiBi ZWxvdy4NCj4+IA0KPj4gVGhlcmUncyBub3RoaW5nIGVsc2UgdGhhdCdzIGF2YWlsYWJsZSB0byB0 aGUgZ2VuZXJhbCBwdWJsaWMuDQo+PiANCj4+IFRoaXMgSUNBTk4gZWZmb3J0IGRvZXMgbm90IGlu IGFueSB3YXkgY29uZmxpY3Qgd2l0aCBvciBjb250cmFkaWN0IG91ciB3b3JrIGluIFdFSVJEUy4g Tm90ZSB0aGF0IHRoZSBwcmVsaW1pbmFyeSByZXBvcnQgZG9lc24ndCBzYXkgYW55dGhpbmcgYWJv dXQgdGhlIGFjY2VzcyBwcm90b2NvbCwgYnV0IGl0IGNvdWxkIHZlcnkgd2VsbCBiZSBSREFQLg0K Pj4gDQo+PiBBcyBub3RlZCBpbiBhbm90aGVyIHJlcGx5IHRvIHRoaXMgdGhyZWFkLCB3aGF0ZXZl ciBhY3Rpb24gaXMgdGFrZW4gd2l0aCByZXNwZWN0IHRvIHRoZSByZXBvcnQgaXMgeWVhcnMgYXdh eS4gSWYgUkRBUCBnZXRzIHRyYWN0aW9uIHRoZXJlJ3Mgbm8gcmVhc29uIGl0IGNhbid0IGJlIHVz ZWQuIEkgY2FuJ3QgdGVsbCB5b3UgaG93IG1hbnkgdGltZXMgSSBleHBsYWluZWQgdG8gdGhlIGdy b3VwIGhvdyBSREFQIGNvdWxkIChvciBjb3VsZG4ndCkgc3VwcG9ydCB0aGUgcmVjb21tZW5kYXRp b25zIHdlIHdlcmUgZGViYXRpbmcuDQo+PiANCj4+IFNjb3R0DQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gd2VpcmRzIG1haWxpbmcgbGlzdA0K Pj4gd2VpcmRzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3dlaXJkcw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiB3ZWlyZHMgbWFpbGluZyBsaXN0DQo+IHdlaXJkc0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlaXJkcw0KDQpNciBNaWNoZWxlIE5leWxv bg0KQmxhY2tuaWdodCBTb2x1dGlvbnMg4pmeDQpIb3N0aW5nICYgRG9tYWlucw0KSUNBTk4gQWNj cmVkaXRlZCBSZWdpc3RyYXINCmh0dHA6Ly93d3cuYmxhY2tuaWdodC5jbw0KaHR0cDovL2Jsb2cu YmxhY2tuaWdodC5jb20vDQpJbnRsLiArMzUzICgwKSA1OSAgOTE4MzA3Mg0KVVM6IDIxMy0yMzMt MTYxMiANCkxvY2FsbDogMTg1MCA5MjkgOTI5DQpEaXJlY3QgRGlhbDogKzM1MyAoMCk1OSA5MTgz MDkwDQpGYWNlYm9vazogaHR0cDovL2ZiLm1lL2JsYWNrbmlnaHQNClR3aXR0ZXI6IGh0dHA6Ly90 d2l0dGVyLmNvbS9tbmV5bG9uDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpCbGFj a25pZ2h0IEludGVybmV0IFNvbHV0aW9ucyBMdGQsIFVuaXQgMTJBLEJhcnJvd3NpZGUgQnVzaW5l c3MgUGFyayxTbGVhdHkNClJvYWQsR3JhaWd1ZWN1bGxlbixDYXJsb3csSXJlbGFuZCAgQ29tcGFu eSBOby46IDM3MDg0NQ0KDQo= From edainow@afilias.info Tue Jun 25 10:21:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA2321F9BAA for ; Tue, 25 Jun 2013 10:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrOh8ZiArYpP for ; Tue, 25 Jun 2013 10:21:33 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 912DD11E812B for ; Tue, 25 Jun 2013 10:21:33 -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 1UrWvt-00044O-3F for weirds@ietf.org; Tue, 25 Jun 2013 17:21:33 +0000 Received: from mail-ob0-f178.google.com ([209.85.214.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UrWvs-0001dV-6D for weirds@ietf.org; Tue, 25 Jun 2013 17:21:32 +0000 Received: by mail-ob0-f178.google.com with SMTP id fb19so12125191obc.23 for ; Tue, 25 Jun 2013 10:21:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=z2TiETyUhjqWiwgnA2cklDLKppXrvxMdw1X1M1vZWlc=; b=kc5JP6FK9qzMtNVmoOgcv79eWHxxQZDiU9/Vi8sfVcz1hqdoBFvGDzyWF5fPXe9VA/ 4YxX2omFqY/VTLKWFnCuzRo7JIRgxzriVclWzBx+YkUz+i2d4ffmlvKRquoWU56BWvFI cfdNwLGcpfruSGIDh04J4UxEAtLDO/cJYdPDluZf8Z4MMeijlnd8BS8Coa3XKnQ3kT/0 PogZUMcFO9TFqWRhGDPQAGkdj/v/DMVBxZj9XbAnkuSpG+MpqYJQyRq0o2W/leEzA/TK wxE21Ift8l2N7FygyArwt7TpNhlmDnqSUkuCr2+ipOtqRKmKkfmJcLeBKEysxrnRf7G+ 5/Rg== X-Received: by 10.60.97.230 with SMTP id ed6mr7853780oeb.97.1372180887431; Tue, 25 Jun 2013 10:21:27 -0700 (PDT) X-Received: by 10.60.97.230 with SMTP id ed6mr7853779oeb.97.1372180887347; Tue, 25 Jun 2013 10:21:27 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id b7sm6731101oby.5.2013.06.25.10.21.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 10:21:26 -0700 (PDT) Message-ID: <51C9D193.6010204@afilias.info> Date: Tue, 25 Jun 2013 13:21:23 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQleFSAzZ8cnm72PB//L+pNJqieO9JhrEtqAGn4VjBz+d3c8pd+fIl2lMLtsrYvg1wK/3HVXrNgQtmIYWneHkDZrt86cmkfzzoNUhIxVt8+0kuqFClBzjCJWIz/7KVZQG4mwjiWJ Subject: [weirds] links type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:21:42 -0000 The links type field is currently specified as optional (json-response-04, p.8). If the link is to an RDAP object and the client uses it without the correct media type, it may not get a json response. A client can generally assume a "self" link is to an RDAP object and include an Accept: header field with application/rdap+json, but wouldn't it minimize inter-op problems to require the type on links to RDAP objects, if not on all links. -Ernie From superuser@gmail.com Tue Jun 25 11:26:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F2121F855F for ; Tue, 25 Jun 2013 11:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD2Fa0b+0HJz for ; Tue, 25 Jun 2013 11:26:35 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id A084911E8127 for ; Tue, 25 Jun 2013 11:26:23 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so9643766wgh.27 for ; Tue, 25 Jun 2013 11:26: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=sMPw9Wk2zOKCWC1VamQA3FiZXLKFgYEvw+0rA3nTIEk=; b=Ca0wBn+7p3dKq2rkyWGch02UaRCU+RwgFYJ7Sm3CUZcJjBgixsMlXtLGEbttKjESIL yKrDYnvJZgdFQsvLZcjw3Mn16dvoCFn+FqxiBABbWjB0tdjDajBCG3owSzd6L3YbFQKT OGDOdWOzCqX/FhkHqhmEV778ICwmrB+KNbyw1D7OhuYgSbJ0PYfEp6tNodJ6XcjqH7RF lmEtkdNitl5RjHzqsVTQ9n+B5giivHsBme19hW0Wg4N7fJqbZIHUVW7t0pK9gk29LVM/ 6WqKubRM5JndZ+Lyj9f2Vv+3GzbUmBCgaledZ66+SPnen7H6qXuTfe0WWpkGAwqEOugJ z6lg== MIME-Version: 1.0 X-Received: by 10.180.187.209 with SMTP id fu17mr136510wic.52.1372184782361; Tue, 25 Jun 2013 11:26:22 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Tue, 25 Jun 2013 11:26:22 -0700 (PDT) In-Reply-To: <20130625152629.32141.qmail@joyce.lan> References: <20130625152629.32141.qmail@joyce.lan> Date: Tue, 25 Jun 2013 11:26:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a11c269ac84dd2504dffeaa3d Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 18:26:40 -0000 --001a11c269ac84dd2504dffeaa3d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 25, 2013 at 8:26 AM, John Levine wrote: > It occurs to me that this is like the bootstrap file in your DNS > cache. The authoritative copy comes from IANA, but it changes very > slowly, and the penalty for being slightly out of date is low, so you > don't need to be able to update it automatically. > > I'm a little uncomfortable with the assumption that the numbers list will never change ever amen, so I'd prefer this sort of approach versus expecting clients to compile the list in. -MSK, participatorially --001a11c269ac84dd2504dffeaa3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 25, 2013 at 8:26 AM, John Levine <johnl@taugh.c= om> wrote:
It occurs to me that this is like the bootstrap file in your DNS
cache. =A0The authoritative copy comes from IANA, but it changes very
slowly, and the penalty for being slightly out of date is low, so you
don't need to be able to update it automatically.

<= br>
I'm a little uncomfortable with the assumption that t= he numbers list will never change ever amen, so I'd prefer this sort of= approach versus expecting clients to compile the list in.

-MSK, participatorially

--001a11c269ac84dd2504dffeaa3d-- From edainow@afilias.info Tue Jun 25 12:36:50 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FBC11E8103 for ; Tue, 25 Jun 2013 12:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tql-ybboQxZO for ; Tue, 25 Jun 2013 12:36:44 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id E4D4C21F9808 for ; Tue, 25 Jun 2013 12:36:43 -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 1UrZ2g-00013H-4R for weirds@ietf.org; Tue, 25 Jun 2013 19:36:42 +0000 Received: from mail-ob0-f179.google.com ([209.85.214.179]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UrZ2g-0000eu-4B for weirds@ietf.org; Tue, 25 Jun 2013 19:36:42 +0000 Received: by mail-ob0-f179.google.com with SMTP id xk17so12560801obc.10 for ; Tue, 25 Jun 2013 12:36:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=+R+WADfV9pXt2stPzXlDJK8tpPor2xVOuC7Fw876DTg=; b=YVJ0TeHFGcXGlUI8Xl4XeQnzB0KqlrEMH/zPrF0CPf9zPtOVZsM2C0LE2D+ZuktD9r wfAnsHsooWQQPaV7URlH/v5UEHDkx9eU25D/DNhWIAyni3Wd3NBLU8YXc/8l962CPmzS FBo0xPjHhTHdaajEt7m6S/FB3YWwZxX5rGuKJV/xYw4a1IDjx56nsDfYFyGmNEGHgtCK pGPZYGtoPJPUlfLZH4e83rBSf14fsTnnr2G8Bo1HwP2S3yoPDDSWCkdeGvT2v6AWtCj/ 44OPc9vR6u+QvzSXeoioCCzWwaLGyRF80ptHjuyM05tuQFqP3p8mzrxy40S3+IZHcU3k 31Iw== X-Received: by 10.182.33.4 with SMTP id n4mr275433obi.19.1372188996818; Tue, 25 Jun 2013 12:36:36 -0700 (PDT) X-Received: by 10.182.33.4 with SMTP id n4mr275432obi.19.1372188996739; Tue, 25 Jun 2013 12:36:36 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id el16sm4540354oeb.2.2013.06.25.12.36.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 12:36:35 -0700 (PDT) Message-ID: <51C9F140.70206@afilias.info> Date: Tue, 25 Jun 2013 15:36:32 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 CC: weirds@ietf.org References: <20130613225800.71691.qmail@joyce.lan> <51BAA74A.2040305@dnsbelgium.be> <51BEBCBE.5070004@dnsbelgium.be> In-Reply-To: <51BEBCBE.5070004@dnsbelgium.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQncSPOtoK6zNRG+7c/Y1Z4aFwH3Sdd80t9XWfpzANR/XF8CVJPZKCwO/Ewqexj/YQB7NJBXqko6Dtw/KEU3XIRwpUo/LGvfJoGOZhzRwpz2j+lvhT76pLPgcpj8utSDybF/gJCW Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 19:36:50 -0000 While the DNS bootstrap proposal for domain names is a very nice, even elegant solution for the client, I had some concerns about the limitations: DNS mapping versus url mapping and https required for all RDAP servers. In a review with our operations people, they have no problem with DNS mapping; it can provide sufficient configuration flexibility via virtual hosting, if arpa name registration can be done with a CNAME (which has been assumed in some discussions but should explicitly be specified in the bootstrap draft). However, there is a strong objection to requiring HTTPS if the server is only providing public data. In their experience, there is no graceful way to make certificates work without spending a lot of unnecessary money (self-signed certs are out, DANE depends on DNSSEC in the resolver and both are too far off in the future for widespread use). Is there any feasible way to specify either http or https or both with the DNS bootstrap approach? -Ernie On 6/17/2013 3:37 AM, Pieter Vandepitte wrote: > Hi John, > > I 100% agree with you that DANE could provide a solution. But as i > mentioned in a previous post, it isn't supported by browsers and it will > take many years to be widely deployed, so it isn't a solution for those > who want to write clients in-the-browser. > > Second, I feel some resistance to implement NAPTR in the clients because > of complexity, but to be honest, I don't see any difference in > complexity with DANE. So, this would disprove the argument that the > A-record solution is a much simpler solution. > > Anyway, as I understand from you, CA's currently don't have business > rules on the supported tld's, so anything above should be theoretical > > kr, > > Pieter > > On 06/14/2013 02:09 PM, John R Levine wrote: >>>> You hard wire the scheme to be https on port 443. For the DNS lookups, >>>> DNSSEC is recommended where available. Problem solved. >>> Me personal, i'm a https believer, so, great idea. not sure if we can >>> sell that to the rest of the community >> Unless someone offers a compelling reason that they cannot support >> https, I think we're OK there. >> >>>> For that matter, self-signed certificates are quite adequate to >>>> protect the channel, and if you want host verification, use DANE. >>> DANE isn't currently supported in most browsers (in none so far i >>> think). Second, it's a very bad idea to have self signed certificates. >> No, it's not. >> >> As I said in the message you were responding to, self-signed certs >> handle the issue of snooping on the http traffic. If you want to >> authenticate the server, either you get a CA signed cert (which I really >> don't think is a big deal) or you nag your client provider to get with >> the program and implement DANE. >> >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >> "I dropped the toothpaste", said Tom, crestfallenly. From marc.blanchet@viagenie.ca Tue Jun 25 12:52:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAEF11E8142 for ; Tue, 25 Jun 2013 12:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWicYOXNWYuE for ; Tue, 25 Jun 2013 12:52: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 9CF4711E80D7 for ; Tue, 25 Jun 2013 12:52:15 -0700 (PDT) Received: from h115.viagenie.ca (h115.viagenie.ca [206.123.31.115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 55CF540418; Tue, 25 Jun 2013 15:52:07 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <51C9F140.70206@afilias.info> Date: Tue, 25 Jun 2013 15:52:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130613225800.71691.qmail@joyce.lan> <51BAA74A.2040305@dnsbelgium.be> <51BEBCBE.5070004@dnsbelgium.be> <51C9F140.70206@afilias.info> To: Ernie Dainow X-Mailer: Apple Mail (2.1508) Cc: weirds@ietf.org Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 19:52:18 -0000 Le 2013-06-25 =E0 15:36, Ernie Dainow a =E9crit : > While the DNS bootstrap proposal for domain names is a very nice, even = elegant solution for the client, I had some concerns about the = limitations: DNS mapping versus url mapping and https required for all = RDAP servers. I knew when I wrote it... I guess you are talking about domain names usage (compared to address = registries). correct? > In a review with our operations people, they have no problem with DNS = mapping; it can provide sufficient configuration flexibility via virtual = hosting, if arpa name registration can be done with a CNAME (which has = been assumed in some discussions but should explicitly be specified in = the bootstrap draft). to my knowledge, CNAME and wildcards have been subject to issues in = implementations, which brought RFC4592.=20 >=20 > However, there is a strong objection to requiring HTTPS if the server = is only providing public data. In their experience, there is no graceful = way to make certificates work without spending a lot of unnecessary = money (self-signed certs are out, DANE depends on DNSSEC in the resolver = and both are too far off in the future for widespread use). >=20 > Is there any feasible way to specify either http or https or both with = the DNS bootstrap approach? one way I was thinking about was to specify it at the http redirect = level: i.e. default is http, but operator can do http redirect to https, = when desired. However, this method has his drawbacks. Marc. >=20 > -Ernie >=20 >=20 > On 6/17/2013 3:37 AM, Pieter Vandepitte wrote: >> Hi John, >>=20 >> I 100% agree with you that DANE could provide a solution. But as i >> mentioned in a previous post, it isn't supported by browsers and it = will >> take many years to be widely deployed, so it isn't a solution for = those >> who want to write clients in-the-browser. >>=20 >> Second, I feel some resistance to implement NAPTR in the clients = because >> of complexity, but to be honest, I don't see any difference in >> complexity with DANE. So, this would disprove the argument that the >> A-record solution is a much simpler solution. >>=20 >> Anyway, as I understand from you, CA's currently don't have business >> rules on the supported tld's, so anything above should be theoretical >>=20 >> kr, >>=20 >> Pieter >>=20 >> On 06/14/2013 02:09 PM, John R Levine wrote: >>>>> You hard wire the scheme to be https on port 443. For the DNS = lookups, >>>>> DNSSEC is recommended where available. Problem solved. >>>> Me personal, i'm a https believer, so, great idea. not sure if we = can >>>> sell that to the rest of the community >>> Unless someone offers a compelling reason that they cannot support >>> https, I think we're OK there. >>>=20 >>>>> For that matter, self-signed certificates are quite adequate to >>>>> protect the channel, and if you want host verification, use DANE. >>>> DANE isn't currently supported in most browsers (in none so far i >>>> think). Second, it's a very bad idea to have self signed = certificates. >>> No, it's not. >>>=20 >>> As I said in the message you were responding to, self-signed certs >>> handle the issue of snooping on the http traffic. If you want to >>> authenticate the server, either you get a CA signed cert (which I = really >>> don't think is a big deal) or you nag your client provider to get = with >>> the program and implement DANE. >>>=20 >>> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >>> "I dropped the toothpaste", said Tom, crestfallenly. >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@taugh.com Tue Jun 25 13:00:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D49D21F8C9F for ; Tue, 25 Jun 2013 13:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwpRDh7fO5NM for ; Tue, 25 Jun 2013 13:00:39 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DF76821F8BB7 for ; Tue, 25 Jun 2013 13:00:38 -0700 (PDT) Received: (qmail 76870 invoked from network); 25 Jun 2013 20:00:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12c45.51c9f6e5.k1306; bh=1yenh+DDapG4wfIzlnqFJB6JCIvbrGmt/A/xQEiYdJY=; b=pEUF/NRZoFpsohkTK1fQ8aq/PLS4IVqJ1jsKgUDxPz2/b7yu/K+Dn8lpasAbigHkO2L5ag1hCjOtEF/kl3zfZfVF1kagFdMmseR0+f053ASyQAS/LgvHJcnX6Felj0mOIbPtT90Cy09XFQvbWDmuPdKx/6AB+ux+fi0qVs+nTRYvZnSzgRrtAjj0Ek28Lfho0Ay6MjQn9nuqfpslKwLLLqdFtBl0ZpyLMkvgGmeSKWVI78G02KBEay2c5xKMTEF5 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:cleverness; s=12c45.51c9f6e5.k1306; bh=1yenh+DDapG4wfIzlnqFJB6JCIvbrGmt/A/xQEiYdJY=; b=L73rC+mk/RdQjkgSWrTm2yHLCEZgNTkxySxHqLFh6gjpTvWk17DU5nJNEBcSZHZ1WVTA87wXe1Om0lfnSsL9E0YcjI1HS3a//DNRCbuy8REG8/xlqSnOKYDIaj4fitVJh/jZ1CFpHIsaSmxXEiHoqOTU0OOFqMxQBwhLb9iecwYDKSqQHtYotL/lbJakkBfEtz7Tlzk4mn/sWb+umnqkcdQUGIs4vvRo6HDwcGlxOs8Cu2jvBjfCFx4euteTjX70 Received: (ofmipd 127.0.0.1); 25 Jun 2013 20:00:15 -0000 Date: 25 Jun 2013 16:00:37 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20130625152629.32141.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:00:39 -0000 >> It occurs to me that this is like the bootstrap file in your DNS >> cache. The authoritative copy comes from IANA, but it changes very >> slowly, and the penalty for being slightly out of date is low, so you >> don't need to be able to update it automatically. > I'm a little uncomfortable with the assumption that the numbers list will > never change ever amen, so I'd prefer this sort of approach versus > expecting clients to compile the list in. I figured it'd be in a local config file that is installed with the RDAP client and updated either when you update the client or perhaps by running a separate update program. But again, it doesn't have to be particularly easy or automatic since once a year is likely to be plenty. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From johnl@iecc.com Tue Jun 25 13:26:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A606F21E80DA for ; Tue, 25 Jun 2013 13:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.9 X-Spam-Level: X-Spam-Status: No, score=-109.9 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grxZEWYajMfN for ; Tue, 25 Jun 2013 13:26:36 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C36A221E80C3 for ; Tue, 25 Jun 2013 13:26:35 -0700 (PDT) Received: (qmail 88789 invoked from network); 25 Jun 2013 20:26:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Jun 2013 20:26:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c9fcf9.xn--30v786c.k1306; i=johnl@user.iecc.com; bh=ipcTBuorb2XhMdmdjTAaCsLAvvCudX10dZXTUqUQUfQ=; b=ulU4FoKdXef4njT4fbYZaWq8x4NarTFJ7BfNVDmPvD3VHaNHnqd9rYr7ogq+7zqKKSGF2rsbBaOohDL50inEFU+WsJvQR3eouuADdw0GrrYyCzyZwEmEPJ5Nz9gBDejOYcqxRaSZHOZoPdERpvta6u/LjiOqsbxSXHP5BNURcbJY5eY/509pCzbTiZ6d2hHd9ubaOFA2Pg8HrYmz60Tq6c9mj7utxUezTxiqAmpJJqGBva0RdYoIbUuETzllFV7l DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c9fcf9.xn--30v786c.k1306; olt=johnl@user.iecc.com; bh=ipcTBuorb2XhMdmdjTAaCsLAvvCudX10dZXTUqUQUfQ=; b=Zx2MTimMrCoO9iEo0449+jVCsQGT5ar9tGAFfSvz73P6JfGjO4niqoMqmgJJhOVRQWomM/nW0U7PWv6DXCkKi7YZNOkWmlod8mYy+KgsWEr7XnRTWIBybX8uLminh4tlYVSI1yA5wn/klK5GscsQ46diKUCVHBY2rDvbHyEzjtt/yzE3ZZ1vk0qmT+cgLiazIQbgMWAHegbIfw8cK5okCzkSLS0MbRdwlkzVBEtHl4e+yn2le8WxEIOeAL9IxI/b Date: 25 Jun 2013 20:26:11 -0000 Message-ID: <20130625202611.35638.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <51C9F140.70206@afilias.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:26:43 -0000 >However, there is a strong objection to requiring HTTPS if the server is >only providing public data. In their experience, there is no graceful >way to make certificates work without spending a lot of unnecessary >money (self-signed certs are out, DANE depends on DNSSEC in the resolver >and both are too far off in the future for widespread use). You can get perfectly good certs from Geotrust or Comodo for $9/yr. Or certs that are almost as good (98% rather than 99% coverage or something like that) for free from Startcom. Could you be more specific about what "a lot of unnecessary money" means? The only thing I can think of that might be an issue is getting a cert for .rdap.arpa, which would require some help from IANA to assure the cert signer that it's OK to issue a cert for that name, but that seems like a one time issue that won't take a lot of time or money. R's, John From johnl@iecc.com Tue Jun 25 13:28:06 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550E721E80EE for ; Tue, 25 Jun 2013 13:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrgigum8Gm+z for ; Tue, 25 Jun 2013 13:28:02 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DA19221E80DA for ; Tue, 25 Jun 2013 13:28:00 -0700 (PDT) Received: (qmail 89095 invoked from network); 25 Jun 2013 20:28:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Jun 2013 20:28:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c9fd50.xn--hew.k1306; i=johnl@user.iecc.com; bh=D0UtLwusLfMppEd9grDph14nHeovE/dv1fQ+DGc5YHE=; b=Garxsj2/pSpQnq/1wYdCN4InNEymOP1f4Jpsa9ptMmTTVGKeXkld3A3QHGokKeZlMuKwn1n4ag5T0cCOBZyzwqR7x3VsW/gFJD/XVYvHb8oTyg9V3Hhi8RRZRhUxElti87Mz0mHo13bW0HtyqNSdYQUCTpSDQwEEVQl5+n5Uc/OSvH+yz1rzUlK0E6JHspfJ/surm1WHf4hbdpR2mh4AM4PQ/2oyHJ8m2xuVG5YwWvxbsOf+BjCMxA4XuwoET2IM DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c9fd50.xn--hew.k1306; olt=johnl@user.iecc.com; bh=D0UtLwusLfMppEd9grDph14nHeovE/dv1fQ+DGc5YHE=; b=TRLaflrWna4Ius7RjaaZpTmOelrfXNdzcPO2nijGJBfpE4qSh22TrLq/8h/zqUx7kBCw5hMjxaxHPAvGhU/5PWykvebiuHk4fel5ixVSoXeIIgIVOscykVwtLs4GWPXdOnpFaT9gZ2aPVaT34X/VT6kbOVMcmh8E2nXcQS47YE161fu629OyupZWbKajc0v1F4ktUD1hBlC2uq7C9ZiB8W0NMVyBoDM+NYPkVg+9Jjy7+JX7KVt5k65wHUoGDljQ Date: 25 Jun 2013 20:27:37 -0000 Message-ID: <20130625202737.35660.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:28:07 -0000 >to my knowledge, CNAME and wildcards have been subject to issues in implementations, which brought >RFC4592. Can we agree that the domain bootstrap is just per TLD, with no wildcards? The extra facility provided by wildcards is pretty minor, and the extra hassle appears significant. From edainow@afilias.info Wed Jun 26 11:22:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA91321F9EF5 for ; Wed, 26 Jun 2013 11:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58DRZB95Wzq1 for ; Wed, 26 Jun 2013 11:22:16 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6621F9A38 for ; Wed, 26 Jun 2013 11:22:03 -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 1UruLm-0002Va-6C for weirds@ietf.org; Wed, 26 Jun 2013 18:21:50 +0000 Received: from mail-wg0-f44.google.com ([74.125.82.44]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UruLm-00028U-5l for weirds@ietf.org; Wed, 26 Jun 2013 18:21:50 +0000 Received: by mail-wg0-f44.google.com with SMTP id m15so10521106wgh.11 for ; Wed, 26 Jun 2013 11:21:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=XR+MIE8FdoxoX08nwiaPnkVqbUaWhUa+6/oEEHPTpMY=; b=l8pPlMML+682xuWgGw4Mw7De5XKoqaZKJDyVB03ppolB8Ar0iWMZVYRhDx5t6XuhPq bLpw+QNG697/FaBKtENYlly1QKLKQSFvrDxak0j4DzXREagb8w8tgE5RrL8IVMvGVTii e59gy3xELbXRmT20CMt0tp2RMioViJxyXo2GA0fZ75YZdyP6EV0VaqTwutMEDlfXCPbS r/BPMKDA9n35pgXTkm8dt9rvN3yqSWTlwluVl+hCTy+dsRssXiLwhiQJrdUq2qCEGB7b QnUaHEJC75+o1W9/59my9MknI/1FIQP1D+S1xoERugRjwJN8/sApjjpdc2+PzLFra+YG zB8w== X-Received: by 10.180.198.80 with SMTP id ja16mr13326700wic.53.1372270904793; Wed, 26 Jun 2013 11:21:44 -0700 (PDT) X-Received: by 10.180.198.80 with SMTP id ja16mr13326696wic.53.1372270904712; Wed, 26 Jun 2013 11:21:44 -0700 (PDT) Received: from [192.168.2.21] (bas5-toronto47-1176440534.dsl.bell.ca. [70.31.14.214]) by mx.google.com with ESMTPSA id fb9sm12542808wid.2.2013.06.26.11.21.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 11:21:43 -0700 (PDT) Message-ID: <51CB312A.4090805@afilias.info> Date: Wed, 26 Jun 2013 14:21:30 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Levine , Marc Blanchet References: <20130625202611.35638.qmail@joyce.lan> In-Reply-To: <20130625202611.35638.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmghv8Uv9abhm2zHYZn/Gt+farCn1w+W1BzCeMbYCrKBZaZWCN/j7D0ZksuBP5a+vsBD0XW5PnI5086YEfZPPOCRHGJqh15zTYS2xyzPFY8DWaAPPA2Vy4Kck3GNBN56LZh4M38 Cc: weirds@ietf.org Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 18:22:23 -0000 On 2013-06-25 4:26 PM, John Levine wrote: >> However, there is a strong objection to requiring HTTPS if the server is >> only providing public data. In their experience, there is no graceful >> way to make certificates work without spending a lot of unnecessary >> money (self-signed certs are out, DANE depends on DNSSEC in the resolver >> and both are too far off in the future for widespread use). > You can get perfectly good certs from Geotrust or Comodo for $9/yr. > Or certs that are almost as good (98% rather than 99% coverage or > something like that) for free from Startcom. > > Could you be more specific about what "a lot of unnecessary money" > means? The only thing I can think of that might be an issue is > getting a cert for .rdap.arpa, which would require some help from > IANA to assure the cert signer that it's OK to issue a cert for that > name, but that seems like a one time issue that won't take a lot of > time or money. > > It looks like we could use some of the inexpensive certs for RDAP but it still doesn't seem like the best solution to require https for public data. We would much prefer to see http as the default with server side rewrite/redirect to https if required (as noted by Marc). Based on the data defined in current drafts, most RDAP queries will be for public data. The extra overhead, management and cost (even if not huge) should be born by the traffic that requires security, not by all RDAP servers. -Ernie From johnl@taugh.com Wed Jun 26 11:31:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B111E811D for ; Wed, 26 Jun 2013 11:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJRkavA1qtfp for ; Wed, 26 Jun 2013 11:31:39 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4F74F21F9FE2 for ; Wed, 26 Jun 2013 11:31:39 -0700 (PDT) Received: (qmail 68312 invoked from network); 26 Jun 2013 18:31:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=10ad7.51cb3389.k1306; bh=H1KhTHtBiyy3fTqra5dTOdPPBN/yUFP75I62NIWgROk=; b=KNZh7OPlhXKauEaInAGBc5IMGZvBlE7FavhgI43HicGaKvthlJgiMxncyN8kEdYDNhzmc/CsrmsdDP9rH6SGeTMbjhsmGS93DmRVMZdJNUtorFJdL4z0YfDfYo2Zuo9b8Cbstk5RydfON0Tg02AwpEqXbtZMuuwEAmUfvuTAzoQpQcIK3cm05z2b5VlaXNOIlH3NWF90Rofj+1PnQiuXt0Ievp5CfTNmqowfDxCQ7Str6DBnnlQqdEBmuLGBrOCo 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:cleverness; s=10ad7.51cb3389.k1306; bh=H1KhTHtBiyy3fTqra5dTOdPPBN/yUFP75I62NIWgROk=; b=abDQHL03YhK97bgMsQ1YGu9GlEQaf21yx4YsVyXzkV4JagYqWAtaGD5tgb06OYUkAooQD+pChlF9kGZfHi/glalWluVOUbWountj8/uYu7YceGjw+0FxK2K+t8lsYoL4vuQEPn2fuS5bado1esf8QXImoUZ0F5GE/6jkOIi4RNoA7HaATXvSJLQLMLEQ7DM2ykmOn/ApqFghqCHtra5D13+Q6Kl8nyaXw9pq6p0TllJUHFavivTDP0RfC+Sgio/i Received: (ofmipd 127.0.0.1); 26 Jun 2013 18:31:15 -0000 Date: 26 Jun 2013 14:31:37 -0400 Message-ID: From: "John R Levine" To: "Ernie Dainow" In-Reply-To: <51CB312A.4090805@afilias.info> References: <20130625202611.35638.qmail@joyce.lan> <51CB312A.4090805@afilias.info> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1763218170-1372271497=:44367" Cc: weirds@ietf.org Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 18:31:40 -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. --3825401791-1763218170-1372271497=:44367 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > Based on the data defined in current drafts, most RDAP queries will be for > public data. The extra overhead, management and cost (even if not huge) > should be born by the traffic that requires security, not by all RDAP > servers. Remember that https provides channel security as well as confidentiality. You want to use https when retrieving public data to ensure that you are talking to the server you think you are, and that what you received is what that server sent. Imagine the fun when a bad guy does some DNS poisoning and pretends that his server is http://info.domain.rdap.arpa/. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1763218170-1372271497=:44367 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI2MTgzMTM3WjAjBgkqhkiG 9w0BCQQxFgQU+WMHicXewyK9uH5qMPPPt/WsRP8weQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEANmK0jFMGrmoL AvW6u6bcNkT0K/+ce+jJ+Su64ASHkqAEU97vz5ppaR0CM3/rh9Cg5nWIJYch UQIrulzOMoAazZbO6x56iZn2PipaNeAF0ASTQBopIxkEi1A9Q81o2j0tE6+4 zbtqbYJRGiUJLEAIOP6DtvNP51Y+/SEClftzpdLnwFOSr5UwGOD2dpfjrBtU e+G7Jio+Y5HxhT5kYKU2hSzN+EhefyqomZsNVbqVrPsWoNL3zU/qJ//9Mo1d wL3A3v9E/vAFYvLrPJ0vNk/+OvINKNc/b3u23iLqjaFWawYZCT6QCb5VBXqT WeV+xLJZTygebt86AefY9jySOaaOqA== --3825401791-1763218170-1372271497=:44367-- From marc.blanchet@viagenie.ca Wed Jun 26 11:34:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B80D11E81D9 for ; Wed, 26 Jun 2013 11:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bkWza2CqUAg for ; Wed, 26 Jun 2013 11:34:56 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9411D11E81D4 for ; Wed, 26 Jun 2013 11:34:56 -0700 (PDT) Received: from [IPv6:2620:0:230:2002::1001] (unknown [IPv6:2620:0:230:2002::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CB0AF403E9; Wed, 26 Jun 2013 14:34:55 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Wed, 26 Jun 2013 14:34:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E3040E3-9E78-49AB-828D-9345102E9A28@viagenie.ca> References: <20130625202611.35638.qmail@joyce.lan> <51CB312A.4090805@afilias.info> To: "John R Levine" X-Mailer: Apple Mail (2.1508) Cc: weirds@ietf.org Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 18:34:57 -0000 Le 2013-06-26 =E0 14:31, "John R Levine" a =E9crit : >> Based on the data defined in current drafts, most RDAP queries will = be for public data. The extra overhead, management and cost (even if not = huge) should be born by the traffic that requires security, not by all = RDAP servers. >=20 > Remember that https provides channel security as well as = confidentiality. >=20 > You want to use https when retrieving public data to ensure that you = are talking to the server you think you are, and that what you received = is what that server sent. sure. but playing devil's advocate, we have been running whois without = that security. I prefer better security, but the real question is if it = is mandatory or not. Anyone who requested that as mandatory? Marc. >=20 > Imagine the fun when a bad guy does some DNS poisoning and pretends = that his server is http://info.domain.rdap.arpa/. >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, = crestfallenly._______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@taugh.com Wed Jun 26 11:56:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9158421F9476 for ; Wed, 26 Jun 2013 11:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHuaf4ECIS8v for ; Wed, 26 Jun 2013 11:56:23 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4FC21F944F for ; Wed, 26 Jun 2013 11:56:18 -0700 (PDT) Received: (qmail 72986 invoked from network); 26 Jun 2013 18:56:17 -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:cleverness; s=11d19.51cb3951.k1306; bh=7Vf7X0/jyV5Wfx5nIetmquDFZ4HjEH1kBtqya7zMFWw=; b=d2hryKjkqzNfzqXBM84D0yB3CXNHK9uKdnfJulwlFWlnHRrISnNcw87EbZPGhS4NgpIsO532GgO9KT9PU067tg9KXlsPrwo/E9iPTbDFkyYOAscs5LhlDu6+q/O9JJutm0ckuOgAM18q6nRWY8NLrWQ7EtWOJ3P13DYz8Zyro+G1TsatXuigrIwK/PK47SlksgqbFJT6ft+ut7nD9oQm+7+08St5E8fkI325X9DZpgMtygxB6n6nv6mH7OnyijJY 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:cleverness; s=11d19.51cb3951.k1306; bh=7Vf7X0/jyV5Wfx5nIetmquDFZ4HjEH1kBtqya7zMFWw=; b=WrmRhrs+DkJ2rFkAGJgpJTJtjQAxecOMlj8IsOR4XEkPaS0QGI+tuu7ZrNdERSLQgr/CRZwvjmPP1GGD6i8QLVFzJp8xVJ8BsRCueHlhaDcx/bjgBpYnXK1Bkn9qbffGKtQDdZADkblcfBaML9aIOzcIfDeESugWNpZ6nvayKzhZxUmWAe2w+20WBRMgy9IfCA3nQPyaIpkrszT7n6xm/1+V/+91rHV3SPsmHx6+mzPt/DBNMUnDY3aGwvDgjUpG Received: (ofmipd 127.0.0.1); 26 Jun 2013 18:55:55 -0000 Date: 26 Jun 2013 14:56:17 -0400 Message-ID: From: "John R Levine" To: "Marc Blanchet" In-Reply-To: <5E3040E3-9E78-49AB-828D-9345102E9A28@viagenie.ca> References: <20130625202611.35638.qmail@joyce.lan> <51CB312A.4090805@afilias.info> <5E3040E3-9E78-49AB-828D-9345102E9A28@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1680517522-1372272977=:44367" Cc: weirds@ietf.org Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 18:56:24 -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. --3825401791-1680517522-1372272977=:44367 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > sure. but playing devil's advocate, we have been running whois without that security. I prefer better security, but the real question is if it is mandatory or not. Anyone who requested that as mandatory? Seems to me that if it doesn't start as https, we have the usual downgrade attacks. I realize that there was a time when the computational load of SSL was an issue, but these days when generic blade servers have eight-core 3GHz CPUs, is it any more? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1680517522-1372272977=:44367 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI2MTg1NjE3WjAjBgkqhkiG 9w0BCQQxFgQU3ZZ7qARKGwraN5zwK5G1vrZAUCYweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAuUuy30H+7SWl +0tJtjvxyC2wS7faJHjahk+kNUmgHRUnToCdK2eMOTV/J4Z6HAM3K+/UOeMw A0fpfctIqw1xGDyXiFC+dX505bOnS8jvwn45qqlv3XXo110gs+Rg5oOEAcJq wjyjWHRrsrihntD4qyouPg8MyEFDM2qA14prUgG2MjJBDpgUjOcpMjwnCdFI 81c1Mq8x42rJTYZc2FenCtHLbcGGFuzy7Jk3zjHuZe5jOkXZUOTMw1+1GQFY Lt+FOJkAcLJLe6ShE1Q+jAaNu4JQPrRhLYwXH4O0hUw6nJt9UzpkWBTw130T Ety7YdN9aO9iqZ1wGzp/Ucdrb0trQw== --3825401791-1680517522-1372272977=:44367-- From edainow@afilias.info Wed Jun 26 14:22:51 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6465E21F9AC1 for ; Wed, 26 Jun 2013 14:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaRy4jkT9K7E for ; Wed, 26 Jun 2013 14:22:45 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id AD2C021F9ABD for ; Wed, 26 Jun 2013 14:22:44 -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 1UrxAj-0001SE-4b for weirds@ietf.org; Wed, 26 Jun 2013 21:22:37 +0000 Received: from mail-ob0-f177.google.com ([209.85.214.177]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UrxAj-0002aJ-4H for weirds@ietf.org; Wed, 26 Jun 2013 21:22:37 +0000 Received: by mail-ob0-f177.google.com with SMTP id ta17so13742438obb.22 for ; Wed, 26 Jun 2013 14:22:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=sKXN1iLQzweQl5IOtSRBAdUrCVIsP7I9tQO+NRlKvMg=; b=GIr8sy7olDNekNGtg2l7lwcvOd6M6ebYkOvp96sMwKyy0qkOW1NVE1XooafXC8yD1w IpCeb/d1zOAHdccCyMysm09hYlVCzS7u8KqgICyoqa0ldclD/rzMB75748r8aWFPWYLo wHvldEZukZqerC08Dsr8dfl5mwLLuPQC8cIRzOKiQZ5xVI4PxlZHCmD+zFg9c8764Yqt C9zmX+ZPhhF37GmvRDV2+xVlWtIGzKdyQTFODWZ9b5oZo8Ynp3GyXlTasoKp/0fHrJa8 sbYRDGZdCShS7BwTEfDmJ+a13RfF/J2bsfmBUUW3O8oKmDuipRzHfPGjr2qEN6pVdArW 38hw== X-Received: by 10.182.88.202 with SMTP id bi10mr2649045obb.91.1372281751838; Wed, 26 Jun 2013 14:22:31 -0700 (PDT) X-Received: by 10.182.88.202 with SMTP id bi10mr2649040obb.91.1372281751773; Wed, 26 Jun 2013 14:22:31 -0700 (PDT) Received: from [192.168.2.21] (bas5-toronto47-1176440534.dsl.bell.ca. [70.31.14.214]) by mx.google.com with ESMTPSA id qa4sm9928213oeb.5.2013.06.26.14.22.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 14:22:30 -0700 (PDT) Message-ID: <51CB5B94.7090407@afilias.info> Date: Wed, 26 Jun 2013 17:22:28 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John R Levine References: <20130625202611.35638.qmail@joyce.lan> <51CB312A.4090805@afilias.info> <5E3040E3-9E78-49AB-828D-9345102E9A28@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmPas64PtyUyom8nONxNHIzRAZiFF43pwC8hfzqSrLaPPPNRBQXcpBlkWQnIRcT5nnHobdJeM5EPW1poHE7L4sdd9R7g/QaXee6uP4/ImYYuJorTy+xhbjw+D+C2b/FjGC0l1uV Cc: weirds@ietf.org Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:22:51 -0000 On 2013-06-26 2:56 PM, John R Levine wrote: >> sure. but playing devil's advocate, we have been running whois >> without that security. I prefer better security, but the real >> question is if it is mandatory or not. Anyone who requested that as >> mandatory? > > Seems to me that if it doesn't start as https, we have the usual > downgrade attacks. Securing the channel is a good point. However, I believe http or https is a policy decision to be made by ICANN or the service provider. I understood the WEIRDS scope to be technical, not policy. As such we should not rule out http as a technical choice. > > I realize that there was a time when the computational load of SSL was > an issue, but these days when generic blade servers have eight-core > 3GHz CPUs, is it any more? > This may be partly true for a server. I think it may still be an issue for clients on smaller devices such as mobile phones. The initial SSL handshake is particularly CPU intensive. With a REST architecture, each RDAP request is a new connection. -Ernie From johnl@iecc.com Wed Jun 26 15:06:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9275921F92F5 for ; Wed, 26 Jun 2013 15:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.939 X-Spam-Level: X-Spam-Status: No, score=-110.939 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT-whtwotACN for ; Wed, 26 Jun 2013 15:06:08 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0A821F9AF9 for ; Wed, 26 Jun 2013 15:06:07 -0700 (PDT) Received: (qmail 17761 invoked from network); 26 Jun 2013 22:06:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Jun 2013 22:06:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51cb65ce.xn--yuvv84g.k1306; i=johnl@user.iecc.com; bh=UZHbV7/DYpCt8Zerm7ll5ITBzra2FSDPABINsri5B0Q=; b=bQwUDNe5wKKzCSYeCZBJgU/Ujc6QE6eQtccHRiqYnGXZ+XSpHoYURseUjuRq0zrcjISJkoGgvQC9e6K+kev8ooKK7BBNbWC/C6ffhd6eDJanEpoQF4eAf6k6WJdLk0I1UaVTwaNMo5F478LdoV5MRfAsfr2XaPdX/hEUjFAEfnoV79fFSUuUkXphpfDMDAx//PJ2q3azaj2D7cuoRbjQV2bhzjMidVZiC+y6y10NffmV8q4Na23BaMyy/35Rsd2e DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51cb65ce.xn--yuvv84g.k1306; olt=johnl@user.iecc.com; bh=UZHbV7/DYpCt8Zerm7ll5ITBzra2FSDPABINsri5B0Q=; b=TO2LaX5xuVdSJM8/yuWyaDuIAK8x7EasS+040QaiU5jlpE8c75LL1dZC3c9etc+oN1yBTZi9hl0KKOMPx8K/qotIvgXGnFfPlLEl4UeGeMEavLSQW7J74vvZrkcdqMmEizIThp8oqsykzvSlL+kDGQcfvfMI9PB2fNABE3GvwMOtSOBPT5+QanAWIvV8nzhI3QcXlMls477px/Vj3ta82HWhNMUZPbqj86G9uiGQFS8/Din/c+BNK9A3G92weMjl Date: 26 Jun 2013 22:05:43 -0000 Message-ID: <20130626220543.45259.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <51CB5B94.7090407@afilias.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 22:06:12 -0000 >Securing the channel is a good point. However, I believe http or https >is a policy decision to be made by ICANN or the service provider. I >understood the WEIRDS scope to be technical, not policy. As such we >should not rule out http as a technical choice. As a technical fact, a CNAME or A or AAAA record does not include a port number. If we're going to use a DNS boostrap, we have to specify one or the other. Also, as a matter of good standards design, the fewer gratuitous options in the spec, the more likely it is that implementations will interoperate. >This may be partly true for a server. I think it may still be an issue >for clients on smaller devices such as mobile phones. The initial SSL >handshake is particularly CPU intensive. With a REST architecture, each >RDAP request is a new connection. I look at https sites on my tablet all the time. CPUs are really fast these days. Or if someone is planning to do multiple WEIRDS queries on her phone faster than she can read the results, I can't have a lot of sympathy for complaints that it's too slow. R's, John PS: Please can we not rehash the SRV argument. From chris@ausregistry.com.au Wed Jun 26 17:27:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C5911E8171 for ; Wed, 26 Jun 2013 17:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piwls2LIPEWZ for ; Wed, 26 Jun 2013 17:26:58 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [120.29.255.35]) by ietfa.amsl.com (Postfix) with ESMTP id AF5DF21F99F8 for ; Wed, 26 Jun 2013 17:26:57 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 27 Jun 2013 10:26:57 +1000 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 27 Jun 2013 10:27:04 +1000 From: Chris Wright To: John Levine , "weirds@ietf.org" Date: Thu, 27 Jun 2013 10:26:55 +1000 Thread-Topic: [weirds] bootstrap draft Thread-Index: Ac5yuWrLm6gx6bmlQ4KpF7LGdWhQPAAEvQTw Message-ID: <8CEF048B9EC83748B1517DC64EA130FB771D50FB6F@off-win2003-01.ausregistrygroup.local> References: <51CB5B94.7090407@afilias.info> <20130626220543.45259.qmail@joyce.lan> In-Reply-To: <20130626220543.45259.qmail@joyce.lan> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 00:27:02 -0000 Whilst I still don't agree with the reasons for discounting the SRV record = IF we are to continue with the current proposed solution we could 'hack' it= as follows to support the desired (by some) outcome: -http.whatevernamespace.arpa A 1.2.3.4 -https.whatevernamespace.arap A 1.2.3.4 WERIDS clients should be required to lookup the -https one first, and = use it if found, otherwise they can look-up the http one. Of course SRV is a much cleaner solution, but anyway. Thanks Chris -----Original Message----- From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= John Levine Sent: Thursday, 27 June 2013 8:06 AM To: weirds@ietf.org Subject: Re: [weirds] bootstrap draft >Securing the channel is a good point. However, I believe http or https=20 >is a policy decision to be made by ICANN or the service provider. I=20 >understood the WEIRDS scope to be technical, not policy. As such we=20 >should not rule out http as a technical choice. As a technical fact, a CNAME or A or AAAA record does not include a port nu= mber. If we're going to use a DNS boostrap, we have to specify one or the = other. Also, as a matter of good standards design, the fewer gratuitous op= tions in the spec, the more likely it is that implementations will interope= rate. >This may be partly true for a server. I think it may still be an issue=20 >for clients on smaller devices such as mobile phones. The initial SSL=20 >handshake is particularly CPU intensive. With a REST architecture, each=20 >RDAP request is a new connection. I look at https sites on my tablet all the time. CPUs are really fast thes= e days. Or if someone is planning to do multiple WEIRDS queries on her pho= ne faster than she can read the results, I can't have a lot of sympathy for= complaints that it's too slow. R's, John PS: Please can we not rehash the SRV argument. _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds From johnl@iecc.com Wed Jun 26 18:39:01 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB6A11E8177 for ; Wed, 26 Jun 2013 18:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.982 X-Spam-Level: X-Spam-Status: No, score=-110.982 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moyULUcACk0D for ; Wed, 26 Jun 2013 18:38:57 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2DD11E815C for ; Wed, 26 Jun 2013 18:38:57 -0700 (PDT) Received: (qmail 61887 invoked from network); 27 Jun 2013 01:38:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Jun 2013 01:38:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51cb97b0.xn--yuvv84g.k1306; i=johnl@user.iecc.com; bh=CJ8Msw6H/48SiOTB3vCvAASbtgO+qqaVBjQBTOUXMs0=; b=aGsewgbVWSNFAKWTDns2G198Ijgq6+feo4vrChrMrV0jg4/jdXX0G6SRXfmkk11/1Lt88KGhiafiNW9UTgNu71xclFifCyNnmD47YyC0Tfrzfz6teAMtxzmCNvlr3MmPkGgp9AsdNiop9+f+Qmj2UCdxNIS0TkedFCDT3GxMq3kqyhzP9FSXYKzreAiILJt/99lsieHtQfQBvim32iDhBrPFJLCeZWvJT1Y5gC1hHzH0v4a0NTmjIMV3O1D4qCFA DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51cb97b0.xn--yuvv84g.k1306; olt=johnl@user.iecc.com; bh=CJ8Msw6H/48SiOTB3vCvAASbtgO+qqaVBjQBTOUXMs0=; b=g5tdWUVJ+lWUCXgziZMwR/B/sOEnNgVB+Fe6W16iJ5KObh4TZKbyFi62x+Bjovhzb3YAZRtGVC/V98+Yka9df54DqE3PtdoauDsNy6fEz9k2dTjMxuX3YuSHk50YUZG9OtxYJxSQHDU2cPS1dnu4ubEoJxeoa4fgLiz4rZPOpZFZExSoru6sxAbLFE5xN7MSTy4AHWxtMyxjT/D52PtwfpUcWeJDNWYM8mq9r2zJSIdustaHpMCYTBWbmTw3zZWO Date: 27 Jun 2013 01:38:33 -0000 Message-ID: <20130627013833.45896.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB771D50FB6F@off-win2003-01.ausregistrygroup.local> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 01:39:01 -0000 >-http.whatevernamespace.arpa A 1.2.3.4 >-https.whatevernamespace.arap A 1.2.3.4 Before we start coming up with clever kludges, let's find out if there are registries for whom it would be a real problem to serve RDAP in https. Everyone I know says that in the past the compute load for SSL was an issue and people used special purpose accelerators, but these days regular CPUs are plenty fast. R's, John PS: >Of course SRV is a much cleaner solution, but anyway. Wouldn't help, we'd still have to decide whether to look up _https._tcp.rdap or _http._tcp.rdap. From simon.perreault@viagenie.ca Thu Jun 27 03:05:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C616021F9D2C for ; Thu, 27 Jun 2013 03:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMiONhVxTZFY for ; Thu, 27 Jun 2013 03:05:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 696A921F9D29 for ; Thu, 27 Jun 2013 03:05:03 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B08204040B for ; Thu, 27 Jun 2013 06:05:02 -0400 (EDT) Message-ID: <51CC0E51.3010005@viagenie.ca> Date: Thu, 27 Jun 2013 12:05:05 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: weirds@ietf.org References: <20130626220543.45259.qmail@joyce.lan> In-Reply-To: <20130626220543.45259.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 10:05:03 -0000 Le 2013-06-27 00:05, John Levine a écrit : > As a technical fact, a CNAME or A or AAAA record does not include a > port number. If we're going to use a DNS boostrap, we have to specify > one or the other. Repeating myself: why not specify that the client tries HTTPS first, then falls back to HTTP after e.g. a 5 second timeout? (Maybe it's such a dumb idea that it's not worth replying to...) Simon From andy@arin.net Thu Jun 27 04:49:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8941621F9D08 for ; Thu, 27 Jun 2013 04:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1bDcbmTZUZe for ; Thu, 27 Jun 2013 04:49: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 2E13F21F9D05 for ; Thu, 27 Jun 2013 04:49:36 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id AB28821365E; Thu, 27 Jun 2013 07:49:35 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id F0BD021364F; Thu, 27 Jun 2013 07:49:34 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 27 Jun 2013 07:49:34 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.148]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 07:49:33 -0400 From: Andy Newton To: John R Levine , "weirds@ietf.org" Thread-Topic: bootstrap draft - an root RDAP redirector Thread-Index: AQHOcyxj9cXoLP+vxEuzFnQsCLDV7w== Date: Thu, 27 Jun 2013 11:49:33 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E6A9E6C6@CHAXCH01.corp.arin.net> 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.5.130515 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 Subject: [weirds] bootstrap draft - an root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 11:49:40 -0000 On 6/26/13 2:56 PM, "John R Levine" wrote: > >I realize that there was a time when the computational load of SSL was an >issue, but these days when generic blade servers have eight-core 3GHz >CPUs, is it any more? Server load was the argument given as to why we shouldn't be doing the simpler solution of having somebody (possibly IANA) run a root RDAP redirection service. Somewhere in this thread, it was pointed out that VeriSign gets 3k qps and that would overwhelm most web servers (btw, ARIN has seen load higher than that in the past). So I've taken the time to write a prototype of an RDAP root redirection server. It reads the current IANA XML files and does redirects for /ip, /domain (both forward and reverse), and /autnum. Using one server class machine and two client machines, Jmeter tells me I can push 10k qps (CPU is not the bottleneck, the NICs are and possibly Jmeter itself). I would assume that if IANA were to run this they'd run 4 servers at a minimum (2 per site x 2 sites ). That's more than enough headroom to handle the load. There are multiple benefits to this solution: 1. It handles the HTTP vs HTTPS much more gracefully. 2. Client software is much, much simpler for bootstrapping. 3. Local roots may be setup using the IANA XML files (let's say AfriNIC or CNNIC want to run a local server for their community because roundtripping across satellites and ocean cables is latent). 4. And hey, we have code now! For those interested, the code is in git: git clone http://anon:anon@stash-projects.arin.net/scm/RRR/code.git -andy From andy@arin.net Thu Jun 27 04:57:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAC221F9BF3 for ; Thu, 27 Jun 2013 04:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz9pFW2ZhLOr for ; Thu, 27 Jun 2013 04:57: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 74B9A21F9BEB for ; Thu, 27 Jun 2013 04:57:22 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 26B5D1652DA; Thu, 27 Jun 2013 07:57:22 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 7D32F1652D0; Thu, 27 Jun 2013 07:57:21 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 27 Jun 2013 07:57:09 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.148]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 07:57:08 -0400 From: Andy Newton To: Ernie Dainow , John R Levine Thread-Topic: [weirds] bootstrap draft - HTTPS client issues Thread-Index: AQHOcy1zIyaABs1Ask6RPvmTFdwmjA== Date: Thu, 27 Jun 2013 11:57:08 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E6A9F6DE@CHAXCH01.corp.arin.net> In-Reply-To: <51CB5B94.7090407@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 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 Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - HTTPS client issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 11:57:27 -0000 On 6/26/13 5:22 PM, "Ernie Dainow" wrote: > >This may be partly true for a server. I think it may still be an issue >for clients on smaller devices such as mobile phones. The initial SSL >handshake is particularly CPU intensive. With a REST architecture, each >RDAP request is a new connection. Expanding on Ernie's concern here: there are more reasons than the cost of certs and server CPU as to why HTTPS is not always what a client wants. First, clients have to be configured with the correct root certs. Some will simply ignore unknown roots, but a lot of RESTful software will throw warnings or worse, errors, if not configured with the proper set of roots. This is a hassle when you don't care to be doing HTTPS and can generate unwarranted help desk traffic. I know of this first hand. Second, TLS is more than just a CPU issue. It also adds considerably to the number of packets exchanged when comparing HTTPS to HTTP and thus adds latency. This is not noticeable to a user with a web browser, but to automation and batch queries it slows things down considerably. Registries shouldn't be forced to support HTTPS if they don't see a need to do it. -andy From andy@arin.net Thu Jun 27 04:58:41 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2BC21F9BF1 for ; Thu, 27 Jun 2013 04:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nTfvcMVJyIy for ; Thu, 27 Jun 2013 04:58:35 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEF321F9BD9 for ; Thu, 27 Jun 2013 04:58:35 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 11BB3213662; Thu, 27 Jun 2013 07:58:05 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id AC2FF21364F; Thu, 27 Jun 2013 07:58:04 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 27 Jun 2013 07:58:04 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.148]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 07:58:04 -0400 From: Andy Newton To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] links type Thread-Index: AQHOccjuFDjNAVg5XUWdS6oR+m74QJlJd5OA Date: Thu, 27 Jun 2013 11:58:03 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E6A9F6EE@CHAXCH01.corp.arin.net> In-Reply-To: <51C9D193.6010204@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 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 Subject: Re: [weirds] links type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 11:58:41 -0000 On 6/25/13 1:21 PM, "Ernie Dainow" wrote: >The links type field is currently specified as optional >(json-response-04, p.8). If the link is to an RDAP object and the client >uses it without the correct media type, it may not get a json response. >A client can generally assume a "self" link is to an RDAP object and >include an Accept: header field with application/rdap+json, but wouldn't >it minimize inter-op problems to require the type on links to RDAP >objects, if not on all links. Ernie, I agree and was thinking about proposing the same thing. :) -andy From aservin@lacnic.net Thu Jun 27 05:01:47 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C94E21F9CD3 for ; Thu, 27 Jun 2013 05:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.734 X-Spam-Level: X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4QanOns9Tod for ; Thu, 27 Jun 2013 05:01:43 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2277321F91C4 for ; Thu, 27 Jun 2013 05:01:43 -0700 (PDT) Received: from [192.168.0.5] (unknown [90.214.33.42]) by mail.lacnic.net.uy (Postfix) with ESMTP id 0E3053084CD; Thu, 27 Jun 2013 09:01:21 -0300 (UYT) Message-ID: <51CC299F.6030406@lacnic.net> Date: Thu, 27 Jun 2013 13:01:35 +0100 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E6A9E6C6@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E6A9E6C6@CHAXCH01.corp.arin.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - an root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:01:47 -0000 Andy You mean this registry: http://www.iana.org/domains/root/db This: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml Or both? Regards, as On 6/27/13 12:49 PM, Andy Newton wrote: > It reads the current IANA XML files and does > redirects for /ip, /domain (both forward and reverse), and /autnum. From andy@arin.net Thu Jun 27 05:45:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CC721F9D44 for ; Thu, 27 Jun 2013 05:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=2.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkoXk1b9XDRk for ; Thu, 27 Jun 2013 05:45:10 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF7521F9D3D for ; Thu, 27 Jun 2013 05:45:10 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id C81041652DB; Thu, 27 Jun 2013 08:44:39 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 1555F1652D7; Thu, 27 Jun 2013 08:44:39 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 27 Jun 2013 08:44:14 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.148]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 08:44:14 -0400 From: Andy Newton To: Arturo Servin Thread-Topic: [weirds] bootstrap draft - an root RDAP redirector Thread-Index: AQHOcyxj9cXoLP+vxEuzFnQsCLDV75lJuNmA///I2gA= Date: Thu, 27 Jun 2013 12:44:13 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E6AA077C@CHAXCH01.corp.arin.net> In-Reply-To: <51CC299F.6030406@lacnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - an root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:45:15 -0000 Both, and the IANA Autonomous System XML registry file as well. If you look at the code, you'll see them in there. We'd need to ask IANA to modify these registries to add both HTTP and HTTPS RDAP base URLs for each registry that wishes to supply them, but that's seems very doable. -andy On 6/27/13 8:01 AM, "Arturo Servin" wrote: >Andy > =20 > You mean this registry: > >http://www.iana.org/domains/root/db > > This: > >http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml > >Or both? > >Regards, >as >On 6/27/13 12:49 PM, Andy Newton wrote: >> It reads the current IANA XML files and does >> redirects for /ip, /domain (both forward and reverse), and /autnum. > > From aservin@lacnic.net Thu Jun 27 05:56:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A3021F9948 for ; Thu, 27 Jun 2013 05:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.734 X-Spam-Level: X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InzrUBYknVet for ; Thu, 27 Jun 2013 05:56:26 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id BDD2521F98AC for ; Thu, 27 Jun 2013 05:56:24 -0700 (PDT) Received: from [192.168.0.5] (unknown [90.214.33.42]) by mail.lacnic.net.uy (Postfix) with ESMTP id 4302F30848D; Thu, 27 Jun 2013 09:55:55 -0300 (UYT) Message-ID: <51CC3669.2000408@lacnic.net> Date: Thu, 27 Jun 2013 13:56:09 +0100 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E6AA077C@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E6AA077C@CHAXCH01.corp.arin.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - an root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:56:30 -0000 Thanks Andy. I was a bit lazy to look at the code. :) Regards. as On 6/27/13 1:44 PM, Andy Newton wrote: > Both, and the IANA Autonomous System XML registry file as well. If you > look at the code, you'll see them in there. We'd need to ask IANA to > modify these registries to add both HTTP and HTTPS RDAP base URLs for each > registry that wishes to supply them, but that's seems very doable. > > -andy > > On 6/27/13 8:01 AM, "Arturo Servin" wrote: > >> Andy >> >> You mean this registry: >> >> http://www.iana.org/domains/root/db >> >> This: >> >> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml >> >> Or both? >> >> Regards, >> as >> On 6/27/13 12:49 PM, Andy Newton wrote: >>> It reads the current IANA XML files and does >>> redirects for /ip, /domain (both forward and reverse), and /autnum. >> From marc.blanchet@viagenie.ca Thu Jun 27 07:41:01 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9F021F9E6A for ; Thu, 27 Jun 2013 07:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.95 X-Spam-Level: X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XhtYZZr2WcJ for ; Thu, 27 Jun 2013 07:41: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 2C83D21F9E5E for ; Thu, 27 Jun 2013 07:41:00 -0700 (PDT) Received: from h227.viagenie.ca (h227.viagenie.ca [206.123.31.227]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6374847123; Thu, 27 Jun 2013 10:40:58 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E6A9E6C6@CHAXCH01.corp.arin.net> Date: Thu, 27 Jun 2013 10:40:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <62D9228640AC7F49B2DD9ED0C9CE60E5E6A9E6C6@CHAXCH01.corp.arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1508) Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - an root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:41:01 -0000 Le 2013-06-27 =E0 07:49, Andy Newton a =E9crit : > On 6/26/13 2:56 PM, "John R Levine" wrote: >=20 >>=20 >> I realize that there was a time when the computational load of SSL = was an >> issue, but these days when generic blade servers have eight-core 3GHz >> CPUs, is it any more? >=20 > Server load was the argument given as to why we shouldn't be doing the > simpler solution of having somebody (possibly IANA) run a root RDAP > redirection service. There are other issues related to a central service. The more the = central service do work, the more it is subject to being attacked, to = being legally bound if it does not supply the data in time, etc... =20 So the best is to have a design that does not require a central service, = or the least central service possible, so that those issues do not come = into play.=20 Moreover, I don't know if the IETF can really specify a central service = to be done by someone. What we can do is ask IANA to have protocol = registries or to run a dns zone file under .arpa. We already have that = in place. Something else, well, it may be possible, but it would be a = different story to sell. My take is that we should design a solution which is pretty distributed = by nature using the current set of possibilities and that solution does = not preclude someone to run a central server if the community desires to = run that (for example, the recent ICANN work). For the protocol, the = client and servers delivering the data, the specification should support = that possibility, but not specify/mandate it. I have some wording about = this in the next rev of the draft coming soon. Hope this will get some = concensus... ;-) Marc. >=20 > Somewhere in this thread, it was pointed out that VeriSign gets 3k qps = and > that would overwhelm most web servers (btw, ARIN has seen load higher = than > that in the past). So I've taken the time to write a prototype of an = RDAP > root redirection server. It reads the current IANA XML files and does > redirects for /ip, /domain (both forward and reverse), and /autnum. >=20 > Using one server class machine and two client machines, Jmeter tells = me I > can push 10k qps (CPU is not the bottleneck, the NICs are and possibly > Jmeter itself). I would assume that if IANA were to run this they'd = run 4 > servers at a minimum (2 per site x 2 sites ). That's more than enough > headroom to handle the load. >=20 > There are multiple benefits to this solution: >=20 > 1. It handles the HTTP vs HTTPS much more gracefully. > 2. Client software is much, much simpler for bootstrapping. > 3. Local roots may be setup using the IANA XML files (let's say = AfriNIC or > CNNIC want to run a local server for their community because = roundtripping > across satellites and ocean cables is latent). > 4. And hey, we have code now! >=20 > For those interested, the code is in git: > git clone http://anon:anon@stash-projects.arin.net/scm/RRR/code.git >=20 > -andy From andy@arin.net Thu Jun 27 10:51:23 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7FC21F9EC9 for ; Thu, 27 Jun 2013 10:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhHT2OzHBgoE for ; Thu, 27 Jun 2013 10:51:15 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB2D21F9EC6 for ; Thu, 27 Jun 2013 10:51:12 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 1B6EF213664; Thu, 27 Jun 2013 13:50:42 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 9210B213665; Thu, 27 Jun 2013 13:50:37 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 27 Jun 2013 13:50:37 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.224]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 13:50:36 -0400 From: Andy Newton To: Marc Blanchet Thread-Topic: bootstrap draft - an root RDAP redirector Thread-Index: AQHOcyxj9cXoLP+vxEuzFnQsCLDV75lJ5V8A///x7QA= Date: Thu, 27 Jun 2013 17:50:35 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E6AABBD6@CHAXCH02.corp.arin.net> 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.5.130515 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <47A0CC71E0D3B843A6FBB0C17C9C576B@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - an root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:51:23 -0000 On 6/27/13 10:40 AM, "Marc Blanchet" wrote: > >There are other issues related to a central service. The more the central >service do work, the more it is subject to being attacked, to being >legally bound if it does not supply the data in time, etc... > >So the best is to have a design that does not require a central service, >or the least central service possible, so that those issues do not come >into play. This issue also apply to DNS, so I'm not sure how what I have proposed is any different in this regard. >=20 > >Moreover, I don't know if the IETF can really specify a central service >to be done by someone. What we can do is ask IANA to have protocol >registries or to run a dns zone file under .arpa. We already have that in >place. Something else, well, it may be possible, but it would be a >different story to sell. The IANA will be standing up an RPKI repository in the future. So asking them is certainly possible. But as I've noted, it doesn't have to be IANA. It could be ICANN or it could be any registry operator working in the interest of their community. Overall, these are squishy layer 9 issues which should not outweigh the technical benefits this proposal provides. -andy From johnl@iecc.com Thu Jun 27 11:16:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D86921F9E79 for ; Thu, 27 Jun 2013 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv69mFd5-TxK for ; Thu, 27 Jun 2013 11:16:18 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D731F21F9E77 for ; Thu, 27 Jun 2013 11:16:17 -0700 (PDT) Received: (qmail 47682 invoked from network); 27 Jun 2013 18:16:16 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Jun 2013 18:16:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51cc8170.xn--hew.k1306; i=johnl@user.iecc.com; bh=agsN4qW9HECnEbVxYd08haoVWBiJKKa3h1y0++8r0Qo=; b=ZwzJnfaop0GMtATaji4GXoUJEEEW3jVeJWouoNqK0FLOZx4PbTajGw55T8M7hNqini9BWr2sc3SzMXTaQ4+TGo9H4k8kcvNXBNrqIhD/fN3gMrY8gaWD+FsiZLHTLPXk7zXfrp8ZJDP7FbixS9lob+mf0C6JpR4thn88NpI/bg+jQIlw24qiOf1U50e9/fukmWk8NOKZ0HN/K9kKxwCQ+ElTuI1ZBkhqTRLM29aWtENN7TTpJ3npI6cv6yoD6Mx6 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51cc8170.xn--hew.k1306; olt=johnl@user.iecc.com; bh=agsN4qW9HECnEbVxYd08haoVWBiJKKa3h1y0++8r0Qo=; b=wIyYgpGGYGtScFVwDsNstPZdimMfVtAHsWcwqOw2uQd/0NGnpqaWtbODSEXmzNHh3cbEc91WvhHbo+SgSbHS7HJ/WfKD1ioRQBjjrQv9RUAy6iQuiSzQbf2BuV53avdbzgW3olt/v/7ExEn//5VGJAH0bk2K9IT6cWxzoI8ZstXk2Esc0XUFWvMEg5Ngg+mGaQSiTqVsvNM5x4loJbUpU/YIgg1Z0BIKpatHysxe4k1m67IX0h8C1st+vXQx2nZ1 Date: 27 Jun 2013 18:15:53 -0000 Message-ID: <20130627181553.65193.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <51CC0E51.3010005@viagenie.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] downgrade attacks on the bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 18:16:22 -0000 In article <51CC0E51.3010005@viagenie.ca> you write: >Le 2013-06-27 00:05, John Levine a écrit : >> As a technical fact, a CNAME or A or AAAA record does not include a >> port number. If we're going to use a DNS boostrap, we have to specify >> one or the other. > >Repeating myself: why not specify that the client tries HTTPS first, >then falls back to HTTP after e.g. a 5 second timeout? > >(Maybe it's such a dumb idea that it's not worth replying to...) Please look up "downgrade attack". R's, John From marc.blanchet@viagenie.ca Thu Jun 27 11:19:32 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4507321F9E26 for ; Thu, 27 Jun 2013 11:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdiJWL02ww4Y for ; Thu, 27 Jun 2013 11:19:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCA521F9E8B for ; Thu, 27 Jun 2013 11:19:29 -0700 (PDT) Received: from h115.viagenie.ca (h115.viagenie.ca [206.123.31.115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 788494040A; Thu, 27 Jun 2013 14:19:28 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E6AABBD6@CHAXCH02.corp.arin.net> Date: Thu, 27 Jun 2013 14:19:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F44744F-1E72-4DE0-BE3A-9403BF1939C8@viagenie.ca> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E6AABBD6@CHAXCH02.corp.arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1508) Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - an root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 18:19:32 -0000 Le 2013-06-27 =E0 13:50, Andy Newton a =E9crit : > On 6/27/13 10:40 AM, "Marc Blanchet" = wrote: >=20 >>=20 >> There are other issues related to a central service. The more the = central >> service do work, the more it is subject to being attacked, to being >> legally bound if it does not supply the data in time, etc... >>=20 >> So the best is to have a design that does not require a central = service, >> or the least central service possible, so that those issues do not = come >> into play. >=20 > This issue also apply to DNS, so I'm not sure how what I have proposed = is > any different in this regard. don't agree. DNS is already super distributed, starting with the root = servers. Moreover, the DNS udp paquets are much lightweight then an http = request/response. >=20 >>=20 >>=20 >> Moreover, I don't know if the IETF can really specify a central = service >> to be done by someone. What we can do is ask IANA to have protocol >> registries or to run a dns zone file under .arpa. We already have = that in >> place. Something else, well, it may be possible, but it would be a >> different story to sell. >=20 > The IANA will be standing up an RPKI repository in the future. So = asking > them is certainly possible. But as I've noted, it doesn't have to be = IANA. > It could be ICANN well, currently IANA is a division of ICANN, so... > or it could be any registry operator working in the > interest of their community. >=20 > Overall, these are squishy layer 9 issues which should not outweigh = the > technical benefits this proposal provides. well, I don't think we can completly forget them. The IETF can not = impose someone to run a central service. Marc. >=20 > -andy From simon.perreault@viagenie.ca Thu Jun 27 11:22:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5102121F9E8F for ; Thu, 27 Jun 2013 11:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmCzFSDeh+kP for ; Thu, 27 Jun 2013 11:22: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 7640A21F9E30 for ; Thu, 27 Jun 2013 11:22:14 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 245F24040A; Thu, 27 Jun 2013 14:22:14 -0400 (EDT) Message-ID: <51CC82D5.3090202@viagenie.ca> Date: Thu, 27 Jun 2013 20:22:13 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Levine References: <20130627181553.65193.qmail@joyce.lan> In-Reply-To: <20130627181553.65193.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: weirds@ietf.org Subject: Re: [weirds] downgrade attacks on the bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 18:22:17 -0000 Le 2013-06-27 20:15, John Levine a écrit : >>> As a technical fact, a CNAME or A or AAAA record does not include a >>> port number. If we're going to use a DNS boostrap, we have to specify >>> one or the other. >> >> Repeating myself: why not specify that the client tries HTTPS first, >> then falls back to HTTP after e.g. a 5 second timeout? >> >> (Maybe it's such a dumb idea that it's not worth replying to...) > > Please look up "downgrade attack". ? If the HTTPS attempt works, then you know it's secure. Otherwise, then you can't. Don't trust the data if you don't want to. I can imagine an attacker being somehow able to prevent the HTTPS attempt from working, forcing the victim to fallback to HTTP, but then there's nothing forcing the victim to trust the data obtained over HTTP. Just don't go to HTTP if you're not willing to. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From johnl@taugh.com Thu Jun 27 11:37:51 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A3221F9BB0 for ; Thu, 27 Jun 2013 11:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0C4iu4-86nAa for ; Thu, 27 Jun 2013 11:37:50 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9AE21F9BAB for ; Thu, 27 Jun 2013 11:37:48 -0700 (PDT) Received: (qmail 51252 invoked from network); 27 Jun 2013 18:37:48 -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:cleverness; s=c833.51cc867c.k1306; bh=8wYglXOeaIrzqdYbzk6WZjYHS2qhUuvcYGPUlT57mus=; b=fHuqCIZ3/VfixLYqvAiuHoPg+6I1NoESZfmToKjSg3x7LzMYSyG26wlql9Cw2wGY7/yQFoasvedIfWf4VJRwCBQ+jOFVWi3SZXeWUyih1Bc54jOshjelJcJDspYQXAFPp7fbzSrGeh3VYiUpGBjJwSSMMGjCW9dTuWAuKRtmlB0IrCwiffFNfOCRIdbeIZgiQxnXZQKHzcSPwoOAYl4z6+OYkPflNCHhFlzLMtwsBJmgsVxj62+p6PHOWwhsThpC 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:cleverness; s=c833.51cc867c.k1306; bh=8wYglXOeaIrzqdYbzk6WZjYHS2qhUuvcYGPUlT57mus=; b=agpUFUzrTGPl537SfJ5OVovLjo8No2waZUDtSGX6eo9aVYr0bXT4uPdQ60Ps3o+FjOmOpGraA85jJY1+s7dNDSviIubbpeuG5NmcaaXphADpQIybqRSYU0rsEPsMKJzwCRDcs6UWWkqYXv5frpfuj71lEazszi50NakHHwzOhdpMBBEH8QXYcLMECvmF2EPVKnRTBLqJhIr98LI3PdYD1BYuoWRNt2BwtWxPnbjglC1CNPETIw1o/bjkbaVppkVs Received: (ofmipd 127.0.0.1); 27 Jun 2013 18:37:26 -0000 Date: 27 Jun 2013 14:37:48 -0400 Message-ID: From: "John R Levine" To: "Simon Perreault" In-Reply-To: <51CC82D5.3090202@viagenie.ca> References: <20130627181553.65193.qmail@joyce.lan> <51CC82D5.3090202@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-363932376-1372358268=:65087" Cc: weirds@ietf.org Subject: Re: [weirds] downgrade attacks on the bootstrap draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 18:37:51 -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. --3825401791-363932376-1372358268=:65087 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > If the HTTPS attempt works, then you know it's secure. > > Otherwise, then you can't. Don't trust the data if you don't want to. > > I can imagine an attacker being somehow able to prevent the HTTPS attempt > from working, forcing the victim to fallback to HTTP, but then there's > nothing forcing the victim to trust the data obtained over HTTP. Just don't > go to HTTP if you're not willing to. I don't think you'll find much sympathy for this nihilistic attitude in the security community. The downgrade attack is that the bad guy hijacks the traffic via a routing or DNS or bogus web cache hack or something. But the bad guy doesn't have an SSL certificate so he fails SSL attempts and the victims use his fake non-SSL server. Even though the real server uses SSL to protect all of its content, it doesn't work. If you have a setup where some providers use SSL and some don't, you need a way to tell whether a site isn't offering SSL becuase it really doesn't, or because it's been hijacked. This requires a way for the non-SSL sites to publish an assertion that they don't use SSL, and to do so in a way that is as secure as SSL. Everyone I know who's looked at this problem has ended up using SSL for everything, which is what I think RDAP should do. The incremental cost of SSL is no longer very high, and the set of probiems it avoids is substantial. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-363932376-1372358268=:65087 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI3MTgzNzQ4WjAjBgkqhkiG 9w0BCQQxFgQURDF703C8lveOQ5L8FOBKfTn2orgweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAHA3W34fl8364 iWT1b24IjR0KK6ffRWUv7vtrrrJbCRiSfa5JIT/ASY8VB0IvHzc2Ayg6NwEO hLnBpRB0Vq9iyRWbQfTzyAGuhF0aEbldMCtijkTZjbl/NAGPxWuY8n+AsvoB nLZz26RR9zdtuJ5K6liWqzCvT2Q7jJ4hr8qe8p2Pj9jJkU6T3R7UC0+3nSv4 NPt7L0l4MF9NZDM2onkryZDb2a2Kx2whav/2oxy33iOJ4mDanlkFvQD1LFyG f3B5CoDMZIw5LTsFbQlLYNUBWffrQuFtDz3OqDXy/NDnbum0+DWBe29QOGRF wArxvUP5czcSMq6fANlmm6Ozrxw8FA== --3825401791-363932376-1372358268=:65087-- From johnl@taugh.com Thu Jun 27 11:46:51 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF26A21F9EBE for ; Thu, 27 Jun 2013 11:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tvm1eJVqFRKU for ; Thu, 27 Jun 2013 11:46:51 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A836021F9EA6 for ; Thu, 27 Jun 2013 11:46:50 -0700 (PDT) Received: (qmail 52577 invoked from network); 27 Jun 2013 18:46:49 -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:cleverness; s=cd5f.51cc8899.k1306; bh=mTpkBNdDbf+TzQJexCo6Cy9EI2/uhWvosJ7DfdbxO1I=; b=kvF0tH2RX2IHMJs26HdNb230I3TxFLIQInjlBUjdmY1dGhcamcNwfenL5T/cNVRNheRRTjU5QQpIF1v66Mvi3yw8/a5kh+NykGJ8onF/7d+fmekTqTc0Mg7dMqWdz2ua1bPjMaRPgnRbefyvAP9WfZBB0QukA9yyWsD7hWVvPbiE6EiJvYm+obhbVJ46IyMefBoLMoXbEAmvIvngYo+4zAD0FS0YjNI4BT6IHKRx5gu10q+jxQ690GIlGyvE4rs/ 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:cleverness; s=cd5f.51cc8899.k1306; bh=mTpkBNdDbf+TzQJexCo6Cy9EI2/uhWvosJ7DfdbxO1I=; b=QZLMRR/hkwOmYri81vZ+YsrX1CxqqYEXVn2ZZkI7BkP4O3hq0RUWrGkm9+j2JIHdW7hsRcgo+JbPNGOLIX7hYRXfwB1oj9bKVKNZT6HfMedP8gc6Ccjt9erfLcq1KJGPjYkIozUEV//fgp93lmTnDXGsFAfdxFdCOvwpyVgl3v7t9+k42zZBSpbNM6kW7WwOs0XiwnPU4HioXNCi3OUu4dcaDqZJUFco54ObxcEpDX1QGQ35cjKYixaP+9jbh10Y Received: (ofmipd 127.0.0.1); 27 Jun 2013 18:46:26 -0000 Date: 27 Jun 2013 14:46:48 -0400 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E6AABBD6@CHAXCH02.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E6AABBD6@CHAXCH02.corp.arin.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-691551794-1372358809=:65087" Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - the dangers of a root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 18:46:51 -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. --3825401791-691551794-1372358809=:65087 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII >> So the best is to have a design that does not require a central service, >> or the least central service possible, so that those issues do not come >> into play. > > This issue also apply to DNS, so I'm not sure how what I have proposed is > any different in this regard. I'm with Marc here. If all RDAP queries start with a redirect from the master server, that is a major change to the design. With the DNS bootstrap, the client asks where the TLD server is and makes its own query. If it makes another query of the same TLD, it gets the answer from the local DNS cache so the bootstrap server isn't involved, and all the boostrap server knows is that some DNS cache handled at least one query to that TLD. If you have a bootstrap redirector, there's nothing to cache, so all the queries go through the bootstrap server and that server knows exactly what the queries are and who's making them. At least for names, the contents of that query stream is extremely valuable to domain squatters, SEO, and other bits of the domain industry, a dismaying number of whom have a history of being what we might call ethically challenged. So this central service would be a huge target for all sorts of attacks, some of which could be pretty subtle. For example, a bad guy could use some sort of DNS or route poisoning to steal queries, then return the correct answers while logging the queries. Or he could return mostly correct answers, and lie about some in which he has particular interest. For the numbers crowd, assume that the bad guy is using someone else's IP range and wants to make it look like it belongs to him. I realize that any of these attacks could be aimed at any of the individual TLD or RIR servers, but it seems a lot to ask IANA to have to bear the risk of dealing with all of this. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-691551794-1372358809=:65087 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI3MTg0NjQ4WjAjBgkqhkiG 9w0BCQQxFgQUISvEe0IZenhsT6rbUf9W2pZcRo8weQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAVKQpUwv+MkkW 3U33XvOAmQOauDAwCjchQgLLIcZWs3Mc5B7CqolxRgwk+ZxuzKb38ZV4UllY 2S1NcMbAz+rtNLgtzYKF+Q5/7qztM7fELzmDpk8wJFuPdIN+uw3YKU7UXadz E1F0PbJfJqh/rbOuYczQzVq++olEW0XqSareOjvOS08YNDL7XV0tsPbKVBg2 xoaayHTdcRh/bBHaiYe3dnTYG874nuUhfPx80m7uofPADlZ9DEDmH5KEgDS+ ENwibZniZ65twcc0Xpk8NEbA1C5Fsbpuihu4rqiQEBXZDIDQKO8dFWz906bq N2ZCwN6KnXLxz/pfnn3EA5CFJDQfdA== --3825401791-691551794-1372358809=:65087-- From andy@arin.net Fri Jun 28 06:28:06 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11D621F888F for ; Fri, 28 Jun 2013 06:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUlofxzruWqT for ; Fri, 28 Jun 2013 06:28:01 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id D308921F9A8F for ; Fri, 28 Jun 2013 06:27:57 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 73F2316542A; Fri, 28 Jun 2013 09:27:57 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id C98AF165423; Fri, 28 Jun 2013 09:27:56 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 28 Jun 2013 09:27:56 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.233]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 09:27:56 -0400 From: Andy Newton To: John R Levine Thread-Topic: bootstrap draft - the dangers of a root RDAP redirector Thread-Index: AQHOc2cmMo2QCOtLckyWQ6EOfyCv55lLH8eA Date: Fri, 28 Jun 2013 13:27:55 +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.5.130515 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - the dangers of a root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 13:28:06 -0000 On 6/27/13 2:46 PM, "John R Levine" wrote: >>> > >I'm with Marc here. If all RDAP queries start with a redirect from the >master server, that is a major change to the design. With the DNS >bootstrap, the client asks where the TLD server is and makes its own >query. If it makes another query of the same TLD, it gets the answer >from=20 >the local DNS cache so the bootstrap server isn't involved, and all the >boostrap server knows is that some DNS cache handled at least one query >to=20 >that TLD. This is a mischaracterization of what I proposed. Having IANA run a "master" bootstrap server is only one possibility. In reality, with IANA XML registry files ANYBODY can run a bootstrap server. Given that we currently get domain queries for TLDs, we'll end up doing this regardless of a DNS solution. As I said before, it is just as easy for us to return a 302 as it is a 404 in these cases. >If you have a bootstrap redirector, there's nothing to cache, so all the >queries go through the bootstrap server and that server knows exactly >what=20 >the queries are and who's making them. At least for names, the contents >of that query stream is extremely valuable to domain squatters, SEO, and >other bits of the domain industry, a dismaying number of whom have a >history of being what we might call ethically challenged. So this >central=20 >service would be a huge target for all sorts of attacks, some of which >could be pretty subtle. Caching does exist in HTTP, and my NicInfo RDAP client does caching. It's actually easier to do the smart caching for RDAP with TLD domain queries than with reverse DNS, IP, or autnum queries. -andy From johnl@taugh.com Fri Jun 28 09:38:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43BB21F9A83 for ; Fri, 28 Jun 2013 09:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AbYwNwx0d4y for ; Fri, 28 Jun 2013 09:38:24 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 078C821F9A80 for ; Fri, 28 Jun 2013 09:38:23 -0700 (PDT) Received: (qmail 59113 invoked from network); 28 Jun 2013 16:38:23 -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:cleverness; s=e6e6.51cdbbff.k1306; bh=f39aQc3qxTrsd7EzFMsHMCDA2WKpSjqfmcHod5sbOs0=; b=w4Uc5Kjnsv4U2oXS3tqv0uqkO9mdg9oVYY1gfrhufWIqQ+994M+5zxUFuVz0oYgY4sFSM7VPCZ5z6V3bDVp0d7pKi7SdAhQq7OCkLUaqmfgU9uLzEeNYMKfiV66qA1jsO423K1rQni63fUDNpndF9k7bCni2mMMSpQ6vnE4v2e4TRzXAgLz14vD4gtY3yr9cNyjg4c8uQEMsIlE/ivbvU+1fBNzCHtE+h1w6q5xz3IpxSEwoomGQdAM2UWM5NphN 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:cleverness; s=e6e6.51cdbbff.k1306; bh=f39aQc3qxTrsd7EzFMsHMCDA2WKpSjqfmcHod5sbOs0=; b=hqug9fu49wK8zhA4JsZBBC4/lqXnnArgueMLoPR/cdYQFCzRWv9oJBLnWLU6KB6bGbwFiK70iIepKhnECIEIzN7aGyDCstbSRPvwVzk05ZFzs7ZEHQH6cExO98bbjJTJaTBe75b1lfXd95sVoZFaDvaAly/XcsVDeM+XejzhNdqTEkzIlLCQgT8yUovzkWh87jXDLTh9bAP7Z4QswzRyb1Y2J1yTLbGnKhyINgDxt/8Pd0+Ow/rkjbeNo2FGrLuA Received: (ofmipd 127.0.0.1); 28 Jun 2013 16:38:01 -0000 Date: 28 Jun 2013 12:38:22 -0400 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1588608098-1372437503=:83603" Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - the dangers of a root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:38:24 -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. --3825401791-1588608098-1372437503=:83603 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > This is a mischaracterization of what I proposed. Having IANA run a > "master" bootstrap server is only one possibility. In reality, with IANA > XML registry files ANYBODY can run a bootstrap server. Well, sure, but now we have the new problem of how to tell virtuous bootstrap servers from evil ones that will steal your queries and sometimes redirect you to fake servers that will return lies. There have been plenty of helpful web WHOIS lookup pages that have done ugly stuff like frontrunning domains that people asked about (most notoriously at Network Solutions) so this is not a hypothetical issue. > Given that we currently get domain queries for TLDs, we'll end up doing > this regardless of a DNS solution. As I said before, it is just as easy > for us to return a 302 as it is a 404 in these cases. We're lucky that ARIN is mostly virtuous. >> If you have a bootstrap redirector, there's nothing to cache, ... > Caching does exist in HTTP, and my NicInfo RDAP client does caching. But can it cache anything but exact queries? If I ask for /ip/152.148.255.255 and then /ip/152.149.0.0, does the cache tell you anything useful? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1588608098-1372437503=:83603 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI4MTYzODIyWjAjBgkqhkiG 9w0BCQQxFgQUlSL7TiflPlKM6B0xD1IY/aBEi4AweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAKfKXIM04uXBP vAkaa4HTNnj0bgEDbxxAUnl4Dwr6HmCpI1tS4Bh3u7PrBx5UaVIz9TsaS1pp i7DeAmWjJD7YUdyscrHIX6zgfk/3W1Sr5n+965Jlx1kxoZarti9P7xHahfdw sYYe0jkud2xUYu4c5RWNhpdnz+ps9yFz4Otf9XzA7nR4nQ9MRJ0IUpWGZgWB oM7FDvnQHc+7yNg5taL5keOj59OnPv753pr/nI1lZrxEhNGfcsI2ekhr4iC9 T7Cexv+gFVFiALeo/E0eSDAO3l4GJ5Jhqj6qLK3EJrgK/HTeWKG86cXDppW/ Af21b06LeQBlhutDx+fEtR7s1VGZfQ== --3825401791-1588608098-1372437503=:83603-- From carlosm3011@gmail.com Fri Jun 28 10:27:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4465021F9A78 for ; Fri, 28 Jun 2013 10:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ+4tiQ3u-N2 for ; Fri, 28 Jun 2013 10:27:56 -0700 (PDT) Received: from mail-ye0-x22f.google.com (mail-ye0-x22f.google.com [IPv6:2607:f8b0:4002:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CB34F21F9A70 for ; Fri, 28 Jun 2013 10:27:56 -0700 (PDT) Received: by mail-ye0-f175.google.com with SMTP id q8so455814yen.20 for ; Fri, 28 Jun 2013 10:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=E1xmYBiVGTgZ5IEt18Anq2Rur1d9FpHqGO5bal5FEpc=; b=KnW7ozQrM1SBV5W0FDmz/KjmblSeUAM2demgjaRrRg2qWqIM3H30I+OVHc+ttJakQo 8IQUoB7WHVr1U5XLzgylriKlGnAtgwIdUEy7GuOTQP2pc0WfNdKZ4K+hxm3VsXDtXmiP kCHn5o1ZpvWv9UQNyfZSILjG1Jq0hMfxs/h3Abi/mBFxYYKWPY58R+lv7YSFWKk87tOW 5fTCgytotOzQUnCtpU9kylIgFsUjRFr4CakWjkbE6kg18kQmjn8+MuM5UsdF4Q9s/So6 +nIvilqncGUGZWfo374ePUMjXU1bKyU5fTREv7+q2hHYZjdoz2kjCPdFWToeeAmrcWO9 SBMw== X-Received: by 10.236.135.206 with SMTP id u54mr7691078yhi.163.1372440476337; Fri, 28 Jun 2013 10:27:56 -0700 (PDT) Received: from [172.18.5.10] ([63.68.157.174]) by mx.google.com with ESMTPSA id g66sm69130yhd.11.2013.06.28.10.27.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 10:27:54 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B329) From: Carlos Martinez Date: Fri, 28 Jun 2013 13:27:52 -0400 To: John R Levine Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - the dangers of a root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 17:27:57 -0000 Sent from my iPad On 28/06/2013, at 12:38, "John R Levine" wrote: >> This is a mischaracterization of what I proposed. Having IANA run a >> "master" bootstrap server is only one possibility. In reality, with IANA >> XML registry files ANYBODY can run a bootstrap server. >=20 > Well, sure, but now we have the new problem of how to tell virtuous bootst= rap servers from evil ones that will steal your queries and sometimes redire= ct you to fake servers that will return lies. There have been plenty of hel= pful web WHOIS lookup pages that have done ugly stuff like frontrunning doma= ins that people asked about (most notoriously at Network Solutions) so this i= s not a hypothetical issue. You pool the good ones under trusted domains like *.arpa. If there are other= s outside, you use them at your own risk. >=20 Carlos= From johnl@taugh.com Fri Jun 28 10:41:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0325D21F9C1F for ; Fri, 28 Jun 2013 10:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JKRu3OSK2oi for ; Fri, 28 Jun 2013 10:41:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B56E721F9C1B for ; Fri, 28 Jun 2013 10:41:31 -0700 (PDT) Received: (qmail 68690 invoked from network); 28 Jun 2013 17:41:29 -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:cleverness; s=10c51.51cdcac9.k1306; bh=XYXsNpwTq+g1rksZMM393QYj9tYXmEVTJQ8f10MzF/M=; b=h4m7GswLiRcc7EEa+v87uERqro3X/2WhW1mKZaH5JuHmEuOXDYLv5EJur3P8Wg4LSNc7zjcwbwWc13YqXX5tIxv9fImkudyF+mfV7UBbHDgQ4Lk5kl4RMFSFElysp2heQNqDdkC+pMBEaljca1Cm3EoBKIeX7ah7gqTHhC1pkz6Rvk2C2eCeQ4MfoBmb8xVtXjIKy4twaXpW3giTYbgKMK7HzqGRqEe1OZMa6fpV2KKl1Qek7T4XrAk97Zg0c82+ 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:cleverness; s=10c51.51cdcac9.k1306; bh=XYXsNpwTq+g1rksZMM393QYj9tYXmEVTJQ8f10MzF/M=; b=eviEKtwdDA2GydE4ihZhjrKWpzkR0qh9gPHghC0RRV/po+razDToggvFaG4guucHt29MMVJy8aAGjr6UFbjIsbbJJEr4gQbggkg7fs/YUZH0qThBPYU1pDmpNHSdmdyNi8HPVL6magOav2lfPwpgLfF8ypDrRaMg2QuyOdvaX0IDsCl6c6KWt06Xdm1/FJeDTrPVvLR3Yd8cQCtPpfzPB4/2vW1ClB+Mg5a0QVZAWNqNs7QBp8gh9NVcXnUfTkFs Received: (ofmipd 127.0.0.1); 28 Jun 2013 17:41:07 -0000 Date: 28 Jun 2013 13:41:29 -0400 Message-ID: From: "John R Levine" To: "Carlos Martinez" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-655219708-1372441289=:83603" Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - the dangers of a root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 17:41:33 -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. --3825401791-655219708-1372441289=:83603 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >>> This is a mischaracterization of what I proposed. Having IANA run a >>> "master" bootstrap server is only one possibility. In reality, with IANA >>> XML registry files ANYBODY can run a bootstrap server. >> >> Well, sure, but now we have the new problem of how to tell virtuous bootstrap servers from evil ones that will steal your queries and sometimes redirect you to fake servers that will return lies. There have been plenty of helpful web WHOIS lookup pages that have done ugly stuff like frontrunning domains that people asked about (most notoriously at Network Solutions) so this is not a hypothetical issue. > > You pool the good ones under trusted domains like *.arpa. If there are others outside, you use them at your own risk. Hmmn. You might want to check with IANA and see how they feel about vetting the reliability of random bootstrap servers. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-655219708-1372441289=:83603 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI4MTc0MTI5WjAjBgkqhkiG 9w0BCQQxFgQUBs9QhRTMpDQDdcPLTUziNAVXbQcweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAoi8j3TOf6PBN wkU/oNILsNr1OqFN4fzBhvyyVjipHeosPBymPjYTFafvHipV3Vu4tNHMqE9X gzsR3lL0RX+neEQfubTUy8ZjmxOfctaPtf/H/jHTEHAzXbO5f7ROJ8316aRe 2oQ91rCH4JfmDrVabrly4iMGiNmgNbtxaTZklPaJAQTjNy5ZC+9JY7UEUXmp egBcMIWAZX0g+RCvO8x7iM+M3IX35UBVg+QkAbzvoItJh9Qhu7NcFRXheTqI nFtJLERzxjVFAq1PDFvTFZjxeixoFKk83jm3d2UzPbli8jFxQSOO2sNBx6g5 7/gT5Qe1hZJPjNrlSJWTMbroJ5QVJQ== --3825401791-655219708-1372441289=:83603-- From andy@arin.net Sat Jun 29 04:40:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F29B21F9FDA for ; Sat, 29 Jun 2013 04:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCFI4-wlAnIs for ; Sat, 29 Jun 2013 04:40: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 E382E21F9FD5 for ; Sat, 29 Jun 2013 04:40:09 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 7E30421367F; Sat, 29 Jun 2013 07:40:09 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 21AEF213660; Sat, 29 Jun 2013 07:40:07 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Sat, 29 Jun 2013 07:39:48 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.218]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Sat, 29 Jun 2013 07:39:47 -0400 From: Andy Newton To: John R Levine , Carlos Martinez Thread-Topic: [weirds] bootstrap draft - the dangers of a root RDAP redirector Thread-Index: AQHOdCa99piBskv+FEylTm8T3eybcplMkmaA Date: Sat, 29 Jun 2013 11:39: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.5.130515 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - the dangers of a root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 11:40:14 -0000 On 6/28/13 1:41 PM, "John R Levine" wrote: >>>> This is a mischaracterization of what I proposed. Having IANA run a >>>> "master" bootstrap server is only one possibility. In reality, with >>>>IANA >>>> XML registry files ANYBODY can run a bootstrap server. >>> >>> Well, sure, but now we have the new problem of how to tell virtuous >>>bootstrap servers from evil ones that will steal your queries and >>>sometimes redirect you to fake servers that will return lies. There >>>have been plenty of helpful web WHOIS lookup pages that have done ugly >>>stuff like frontrunning domains that people asked about (most >>>notoriously at Network Solutions) so this is not a hypothetical issue. >> >> You pool the good ones under trusted domains like *.arpa. If there are >>others outside, you use them at your own risk. > >Hmmn. You might want to check with IANA and see how they feel about >vetting the reliability of random bootstrap servers. John, DNS is not magic and has the same layer 9 bootstrap issues all other technologies have. How does IANA know that VeriSign is VeriSign when they sign up their .com CNAME in rdap.arpa? How does a client know that the list of roots in their DNS hints file are the correct ones, or that the list of CA roots in their key store are valid? These are issues that face every bootstrapping system. -andy From andy@arin.net Sat Jun 29 05:08:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CEE11E80EC for ; Sat, 29 Jun 2013 05:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBpmmZmVDLgp for ; Sat, 29 Jun 2013 05:07: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 F40ED11E80E7 for ; Sat, 29 Jun 2013 05:07:54 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 964E816546F; Sat, 29 Jun 2013 08:07:54 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 094211650E4 for ; Sat, 29 Jun 2013 08:07:54 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Sat, 29 Jun 2013 08:07:40 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.218]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Sat, 29 Jun 2013 08:07:39 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: bootstrapping name servers and entities Thread-Index: AQHOdME/ZUJINs8C1k+ayjC0YFInzg== Date: Sat, 29 Jun 2013 12:07:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] bootstrapping name servers and entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 12:08:02 -0000 The current bootstrapping discussions have avoided entities and name servers, most likely because these are identifiers that are not easily mapped to authoritative registries. Though a bootstrapping process for these object types may not be exact, it might be possible to create a system that is best effort. For nameservers, the bootstrapping process could be to look at the TLD of the nameserver name. For example, a bootstrap of ns1.example.com would point a client at the .com registry. That's not perfect, but its better than nothing. With entities, we can borrow a notion that is in use by the RIRs. Contacts in the RIR system are generally suffixed with an identifier for the RIR. Examples: ABC123-ARIN, ABC123-RIPE, ABC123-AP (for APNIC), etc=8A It might be possible to establish a registry for entity suffixes. The bootstrap process would be to redirect to the authoritative server in the registry if a suffix is recognized. For instance, an entity identifier of ABC123-ORG would got to the .org servers. Comments? Suggestions? -andy From johnl@taugh.com Sat Jun 29 07:17:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3849321F9FFF for ; Sat, 29 Jun 2013 07:17:35 -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=-2.599, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU2d1gQdeAuO for ; Sat, 29 Jun 2013 07:17:34 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 347FD21F9FFC for ; Sat, 29 Jun 2013 07:17:34 -0700 (PDT) Received: (qmail 55862 invoked from network); 29 Jun 2013 14:17:32 -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:cleverness; s=da35.51ceec7c.k1306; bh=oi83rCTm4UISm40idUC+uASqJkYewAJjwo4uCpF8Yh8=; b=n5RRkoZF89FEFsiC4s/znlJ00sul57FoT/iWbXruovOgzT0E8UvCzZPSFDRXYtieiw8+zRWalcTR6nA0/n7+rMalOAR6i/NNgGuprZANFrhJMUPGPJxFEpR65r4U1JJN0LXhS5kzLO8X+Zy7rtbDY4A5IrmY2J3DU47/aAyJ27bQ3tBe34Iv+L7a9KcC+ox2s9Qvu2/sI00yc7a+IWLZ7G2+ZyWrPHvVJcL6XODlqPrqXyJMUpepp67UymzzMgBv 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:cleverness; s=da35.51ceec7c.k1306; bh=oi83rCTm4UISm40idUC+uASqJkYewAJjwo4uCpF8Yh8=; b=W/e8r0eInu2gmPtGhw4E5aFF6ZEAFAso7gV1M0v+XnDF6RfpcLIR2oEgQ8VuHD8D3b9eydCcxwV5LG9Unmz+svPORHUlF5Ct4cQ7FxXPczeln6Kr3qEgUHE/TgCXVhZx55a+tww4f9V59/fYC962MVQTPtmxk4E577fo9pXheb+7Hda5ZZc3gU2j9oAlUqmMhe2yk1WOd+CX06K+lL2Ji/3Iokst2BhhnHUlskgWLAMbDA+zwbQET8FpLHbgwAG7 Received: (ofmipd 127.0.0.1); 29 Jun 2013 14:17:10 -0000 Date: 29 Jun 2013 10:17:31 -0400 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-681139479-1372515452=:96256" Cc: "weirds@ietf.org" Subject: Re: [weirds] bootstrap draft - the dangers of a root RDAP redirector X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 14:17:35 -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. --3825401791-681139479-1372515452=:96256 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> Hmmn. You might want to check with IANA and see how they feel about >> vetting the reliability of random bootstrap servers. > > John, DNS is not magic and has the same layer 9 bootstrap issues all other > technologies have. How does IANA know that VeriSign is VeriSign when they > sign up their .com CNAME in rdap.arpa? The same way they know it's Verisign when they update the .com name servers in the root. One of the reasons I want the DNS bootstrap at IANA is that they already know who the TLDs are and have a secure way to accept updates from them. > How does a client know that the list of roots in their DNS hints file > are the correct ones, or that the list of CA roots in their key store > are valid? These are issues that face every bootstrapping system. Of course, but we can at least try not to make them worse. I think there is a meaningful difference between telling people to use bootstrap data that they can trace back to IANA, and telling them to use some random opaque forwarder. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-681139479-1372515452=:96256 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI5MTQxNzMyWjAjBgkqhkiG 9w0BCQQxFgQUzWU0uWy0Cu8kbKev323jpSDqnxcweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAGN4RQbWV66ED XkGheSpwNAcH3cUHy7Aej+IXpESuxqcNlg/8pMi+S+zoqwcVmAxLEoHJNYfP ByGeFDOjlsREsG1w2IgoqUIG8r7YzBid5YEZgLuSOVvZ1/IN0xy3Wg5OQdlB AaT568yoDz+lDeH3u0yu+R4ay1oJ+PmuiOq/XJAwnhW6kLPUEa4WfSAWAXj5 yIpXZn4wrivcBpU19rpp6vTLWReGxZLzPg2g3nNtObFtzXg25l0m2X2+ic+c lDIFLSLCAWHPfgXK3gc9f0zYhXL5lw0Av1cYQNqoAyzIH3aFsAK+cNj2Zq5b VEMLHTW8xiBlNn8vB7Ohp8VJvhSSdw== --3825401791-681139479-1372515452=:96256-- From johnl@iecc.com Sat Jun 29 08:56:51 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B7811E8169 for ; Sat, 29 Jun 2013 08:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.049 X-Spam-Level: X-Spam-Status: No, score=-109.049 tagged_above=-999 required=5 tests=[AWL=2.150, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2304Ngf3WrL for ; Sat, 29 Jun 2013 08:56:47 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 582B711E8174 for ; Sat, 29 Jun 2013 08:56:47 -0700 (PDT) Received: (qmail 69460 invoked from network); 29 Jun 2013 15:56:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Jun 2013 15:56:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51cf03bd.xn--yuvv84g.k1306; i=johnl@user.iecc.com; bh=xoV/wCbud1INM8b4ECfzToTQGByz0OXM1foSo+AA6fA=; b=IMF8K7HUAWp/gc10aO+ag936Crv+5CwdlAReU3HZpolOS/+X6bB4X5riCOHzahoNZlfuz2ZVwqwP4rXjPGWbut1mU1gFDWY2XAmRWJb9LpcYmFBNNbg/oRHSSId3UZSF2SjA7PyadX1HMVBX5Bps5Gp/MqnYbdfWvkAvfOfYRHITpzkCJ0utdVEgSWU5KxQcEqhb/QWe7BGUY77h4wDdygD0Zm5n97DTuxdAq/2VVkPUe7SwOpzhF1TCEPW/S7X6 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51cf03bd.xn--yuvv84g.k1306; olt=johnl@user.iecc.com; bh=xoV/wCbud1INM8b4ECfzToTQGByz0OXM1foSo+AA6fA=; b=h4WtZWO/R0jCsVqwl9AvMnlwSO1r5H+UMr2WpxyO5wwWU6qyUcp8NETROPZm282+CfOv+y3hn6Wvbrg3iuL/cBRhDYxrc02E0SSvPVzMXcQ3VeuXmVmEDhQ9va/oGelMXCgpfYZdyYIF30EFu3v8oUy93UYRSnhlTFriIKtuf1d5kBPFHUn03lscGioZdun6yOp9F7xEzxZVw8ZeYsqAJZIAVuzUImME508q50osM/vu+V5SpvSygWway2t4mM3U Date: 29 Jun 2013 15:56:23 -0000 Message-ID: <20130629155623.96821.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] bootstrapping name servers and entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 15:56:51 -0000 >It might be possible to establish a registry for entity suffixes. The >bootstrap process would be to redirect to the authoritative server in the >registry if a suffix is recognized. For instance, an entity identifier of >ABC123-ORG would got to the .org servers. > >Comments? Suggestions? Is this a problem we have to solve? As far as I know, there's nothing keeping several name registries or registrars from using the same handles and assigning them to different people. I agree that asking the TLD servers about host names is reasonable. Given the way that DNS glue works, that'll be the right place to ask about 99.9% of the time. R's, John From bje@apnic.net Sun Jun 30 17:34:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF0F21F9DAC for ; Sun, 30 Jun 2013 17:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqRTukzeCcop for ; Sun, 30 Jun 2013 17:34:29 -0700 (PDT) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id 2603F21F9D42 for ; Sun, 30 Jun 2013 17:34:22 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Mon, 1 Jul 2013 10:34:16 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a%19]) with mapi id 14.01.0421.002; Mon, 1 Jul 2013 10:34:16 +1000 From: Byron Ellacott To: Andy Newton , "weirds@ietf.org" Thread-Topic: [weirds] bootstrapping name servers and entities Thread-Index: AQHOdME/ZUJINs8C1k+ayjC0YFInzplO++iA Date: Mon, 1 Jul 2013 00:34:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.101.249] Content-Type: text/plain; charset="us-ascii" Content-ID: <86B42D12BEB0784E9109D28DF6D4966A@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] bootstrapping name servers and entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 00:34:35 -0000 Hi Andy, On 29/06/13 10:07 PM, "Andy Newton" wrote: >The current bootstrapping discussions have avoided entities and name >servers, most likely because these are identifiers that are not easily >mapped to authoritative registries. Though a bootstrapping process for >these object types may not be exact, it might be possible to create a >system that is best effort. What's the use case for doing a global lookup on an entity handle? These handles don't have any significance or meaning outside of the context of the registry they're created in, whereas domains, IP networks, AS numbers, and nameservers all do have a life of their own. An entity handle is most likely to only be seen in the context of a result from a previous lookup, in which case it would be wise to include the "self" link for any RDAP response such that the problem of knowing where that entity handle might be found can be translated to handing around entity "self" links instead of handles. (Or make the handle a URI instead of an opaque string). A global search for an entity by name or other attributes has more of a use case in my mind, but how to bootstrap for *search* is an even hairier problem, I think. Byron