From nobody Mon Sep 1 01:14:51 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5326E1A019B for ; Mon, 1 Sep 2014 01:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.34 X-Spam-Level: * X-Spam-Status: No, score=1.34 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBTbmvhrLHEg for ; Mon, 1 Sep 2014 01:14:47 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89481A0196 for ; Mon, 1 Sep 2014 01:14:46 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s818EjZ9025537 for ; Mon, 1 Sep 2014 17:14:45 +0900 X-AuditID: ac120820-b7fc78e000001dd0-b1-54042af5d5f6 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id FB.18.07632.5FA24045; Mon, 1 Sep 2014 17:14:45 +0900 (JST) Date: Mon, 01 Sep 2014 17:13:55 +0900 (JST) Message-Id: <20140901.171355.223467847.kambe@jprs.co.jp> To: weirds@ietf.org From: Naoki Kambe In-Reply-To: <20140901033132.GB13645@main> References: <12.B9.07632.08560045@off-sendsmg01.tyo.jprs.co.jp> <20140829.204443.63040014.kambe@jprs.co.jp> <20140901033132.GB13645@main> Organization: Japan Registry Services Co., Ltd. X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsWyRoiFT/erFkuIQesTCYv5XcdZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XViC3vBQZ6KqfsmsTQwTuToYuTkkBAwkZj4/RsThC0mceHe ejYQW0jgJKPEyUVaIDaLgLbEoiPrWUFsXgELiff/n4PViwgISyx++Y4FxBYWMJbofLCZEcRm E1CRWHZvM1gNp4CWxKSfd4FmcgHN7GWUeDH3L1ADBwe/gL7E1KYUiL12Ek1/34GFeQUEJf7u EAYJMwO19sx4zA5hy0tsfzuHeQIj/yyEqllIqmYhqVrAyLyKUSY/LU23ODUvpTg33cBQr6Qy Xy+roKhYLxlEb2IEhxyHwg7GGacMDjEKcDAq8fC+WMgcIsSaWFZcmXuIUZKDSUmUt0CCJUSI Lyk/pTIjsTgjvqg0J7X4EKMEB7OSCO9uTaAcb0piZVVqUT5MSpqDRUmcl9m4N1hIID2xJDU7 NbUgtQgmK8PBoSTBuwukUbAoNT21Ii0zpwQhzcTBCTKcB2j4EbDhxQWJucWZ6RD5U4yGHBu+ vuxl4jjxG0Q2nP7QyyTEkpeflyolztsG0iAA0pBRmgc38xWjONBrwrxzQbI8wHQDN+0V0CIm oEUVVYwgi0oSEVJSDYwlxw92PL1/RFfoyIyQl1Wti3h+OAhWPmnQczK5Evb0xNMprUxyB0WE 1tuGsnUZ93SyJdw+d9mbi9evt/BAjnzdcq75HbnN5zRiT91N31s4M0f8YPPz+vjvQTf/rGB5 z/OJ84V6j5LZ9U9nlzf6Pdt53KBA8K5jQ91xTsnPQc/bb2b2mRmtClNiKc5INNRiLipOBAAR Ouh89AIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/OKh6zzcA-bjoGVqlbtpGYQrUFgs Subject: [weirds] Comments on draft-ietf-weirds-bootstrap-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 08:14:48 -0000 From: Tom Harrison Date: Mon, 1 Sep 2014 13:31:32 +1000 > On Fri, Aug 29, 2014 at 08:35:28PM +0900, Naoki Kambe wrote: > > Additionally I've tried to write a small script in Javascript for my > > understating the I-D. Please see the attachment. Note that this is > > only for a domain bootstrap and requires punycode.js: > > . > > > > Could anyone review it and give any comments? > > Works for me, including the IDN-related behaviour (A-labels and > U-labels are matched correctly and the request URL is encoded > correctly). Thanks for looking at the IDN-related behaviour in addition. Regarding IDN, I have a further suggestion on the revision -05. In addition to the current example in Section 4, putting an IDN case for the clarification might be helpful like following: { "rdap_bootstrap": { "version": "1.0", "publication": "YYYY-MM-DDTHH:MM:SSZ", "services": [ [ ["net", "com"], [ "https://registry.example.com/myrdap/" ] ], [ ["org", "mytld"], [ "http://example.org/" ] ], [ ["mytld2"], [ "https://example.net/rdapmytld2/", "http://example.net/rdapmytld2/" ] ], [ ["xn--fo-5ja"], [ "https://example-registry.net/rdapidntld/" ] ] ] } } Regards, Naoki Kambe From nobody Wed Sep 3 00:00:41 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80701A86EA for ; Wed, 3 Sep 2014 00:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULaHJhCfyhMo for ; Wed, 3 Sep 2014 00:00:36 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349E31A86DE for ; Wed, 3 Sep 2014 00:00:33 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mc6so9250566lab.1 for ; Wed, 03 Sep 2014 00:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Al8iTtX+lDh1E4MjMrw2AYu1u0jWghW3JOiBYjxse10=; b=JSYkrRE1pl23VYdq+kyauFftKfbmoqcPdMpIobF4pyFAzBuq/6ZUJgp2/wShtAk8XZ JwGHJ+boU9JP70WGjBrlh+BbA8ZD7uKU7l6fCOBI6m7mw67/RuW0ejoQelkrXJB32pfq 2eVTB6bO3VH5CBthxwjIYoaf6tLK6nfAxVTYpH97/C0/PwM3nmlkN82FaIOAKI2aajFp jVeqroWMw7Vkh5i6OXAUmSqfMX+u3N/XQoYzmvpl9Kt+pOnJ1sNypfhlr4cKzGKOlZd3 848dTlYKKPVBgYtiYUXUQ7KKPcoTOu35wF7J9rivHSrNxdYLOVCn/GwFoUyFMOznJTEQ /ihw== MIME-Version: 1.0 X-Received: by 10.152.1.6 with SMTP id 6mr28961693lai.22.1409727631295; Wed, 03 Sep 2014 00:00:31 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Wed, 3 Sep 2014 00:00:31 -0700 (PDT) Date: Wed, 3 Sep 2014 00:00:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e013c6706b18c1d050223ca70 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/gxoheEwB-vQgSL3QJL0qVJ3Rn04 Subject: [weirds] Timeline reminder X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 07:00:37 -0000 --089e013c6706b18c1d050223ca70 Content-Type: text/plain; charset=UTF-8 Colleagues, Just a reminder that we're planning to enter WGLC for all documents this Friday. Our milestones for winding up this work as discussed in Toronto and recorded in the minutes are as follows: We need to send all the 7 drafts to IESG. This means we have this schedule for all documents: x IESG telechat: October 16. x IETF Last Calls: Completed October 10 x Working Group Last Calls: Completed September 19 x Documents Ready For WGLC: September 5 If we miss these deadlines, the WG will close in October without producing anything. Authors: If you have any final edits to make or updates to post, now's the time! -MSK, WEIRDS co-chair --089e013c6706b18c1d050223ca70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

Just a reminder th= at we're planning to enter WGLC for all documents this Friday.=C2=A0 Ou= r milestones for winding up this work as discussed in Toronto and recorded = in the minutes are as follows:

We need to send all the 7 drafts to IESG. This means we have this=
=20
schedule for all documents:

x IESG telechat: October 16.=20
x IETF Last Calls: Completed October 10=20
x Working Group Last Calls: Completed September 19=20
x Documents Ready For WGLC: September 5=20

If we miss these deadlines, the WG will close in October without=20
producing anything.

Authors: If you have any final edits to = make or updates to post, now's the time!

-MSK, WEIRDS co-c= hair
--089e013c6706b18c1d050223ca70-- From nobody Thu Sep 4 08:09:47 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DF81A88C5; Thu, 4 Sep 2014 08:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvYjnpox4kWW; Thu, 4 Sep 2014 08:09:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F9B1A0330; Thu, 4 Sep 2014 08:09:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140904150943.2578.37782.idtracker@ietfa.amsl.com> Date: Thu, 04 Sep 2014 08:09:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ldKtP4awQ9zoNy4LD78lQFhsu4s Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-bootstrap-06.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:09:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Finding the Authoritative Registration Data (RDAP) Service Authors : Marc Blanchet Guillaume Leclanche Filename : draft-ietf-weirds-bootstrap-06.txt Pages : 14 Date : 2014-09-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-ietf-weirds-bootstrap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-bootstrap-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 4 08:11:46 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506CE1A890A for ; Thu, 4 Sep 2014 08:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En9q_pe4cjJB for ; Thu, 4 Sep 2014 08:11: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 E780E1A88F5 for ; Thu, 4 Sep 2014 08:11:23 -0700 (PDT) Received: from h118.viagenie.ca (h118.viagenie.ca [206.123.31.118]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A46FC403C1 for ; Thu, 4 Sep 2014 11:11:22 -0400 (EDT) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_C62924BC-0BF6-4A50-8537-0AFE7F600966" Date: Thu, 4 Sep 2014 11:11:21 -0400 References: <20140904150943.2578.37782.idtracker@ietfa.amsl.com> To: "" Message-Id: <605990B8-3519-4151-8166-A48AF57B36D3@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ueZqP1BC4EPG6I-hhVZwMceCoR4 Subject: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-06.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:11:38 -0000 --Apple-Mail=_C62924BC-0BF6-4A50-8537-0AFE7F600966 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, this is a new version that intends to implement all comments received = so far, including the IANA considerations part. =46rom our side, it = should be ready for WGLC.=20 Please review.=20 Regards, Marc. D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : > De: internet-drafts@ietf.org > Objet: I-D Action: draft-ietf-weirds-bootstrap-06.txt > Date: 4 septembre 2014 11:09:43 UTC=E2=88=924 > =C3=80: i-d-announce@ietf.org > Cc: weirds@ietf.org > R=C3=A9pondre =C3=A0: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Extensible Internet Registration = Data Service Working Group of the IETF. >=20 > Title : Finding the Authoritative Registration Data = (RDAP) Service > Authors : Marc Blanchet > Guillaume Leclanche > Filename : draft-ietf-weirds-bootstrap-06.txt > Pages : 14 > Date : 2014-09-04 >=20 > Abstract: > This document specifies a method to find which Registration Data > Access Protocol (RDAP) server is authoritative to answer queries for > a requested scope, such as domain names, IP addresses or Autonomous > System numbers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-bootstrap-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_C62924BC-0BF6-4A50-8537-0AFE7F600966 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,
 this is a new version that intends = to implement all comments received so far, including the IANA = considerations part. =46rom our side, it should be ready for = WGLC. 
Please = review. 

Regards, = Marc.

D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 = :

Objet: = I-D Action: = draft-ietf-weirds-bootstrap-06.txt
Date: 4 septembre 2014 11:09:43 = UTC=E2=88=924
R=C3=A9pondre =C3=A0: internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work item of = the Web Extensible Internet Registration Data Service Working Group of = the IETF.

       Title =           : Finding = the Authoritative Registration Data (RDAP) Service
=        Authors =         : Marc Blanchet
=             &n= bsp;           &nbs= p;Guillaume Leclanche
Filename =        : = draft-ietf-weirds-bootstrap-06.txt
Pages =           : = 14
= Date =            : = 2014-09-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:
htt= ps://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/

Ther= e's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-06

A = diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-bootstrap-06

Please note that it may take a couple of minutes from the time = of submission
until the htmlized version and diff are available at = tools.ietf.org.

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

________________________= _______________________
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=_C62924BC-0BF6-4A50-8537-0AFE7F600966-- From nobody Thu Sep 4 09:43:23 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0075D1A6F64 for ; Thu, 4 Sep 2014 09:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzNjRujthKOv for ; Thu, 4 Sep 2014 09:43:21 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7431C1A06E2 for ; Thu, 4 Sep 2014 09:43:20 -0700 (PDT) Received: (qmail 33184 invoked from network); 4 Sep 2014 16:43:19 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Sep 2014 16:43:19 -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=10b15.540896a7.k1409; i=johnl@user.iecc.com; bh=wDQgJP61JDaeNrvjKTsHg4QuzVVlsSnzbO3dEP7Xu/8=; b=EW8QXAUJjJf4KeEqkC2LjViZdGu0RpxXa33QxGvphzNJDxiXI13I/99bESersEx2DwWTdy4KHapkr1+ugxcPyMwoda+Ji5eoN0Gpu3RfndwatBjZhfh/F18NfmnGs2UnoS+j87ilZAeJnk+5FQMQXLPmApCzHueDhWCV7fiqc/hpNRiDfvj3N/3ApO/WY5rZIQz6zDqIeT+o/bawmbHLjIkcedl0VhOpb2qWoVfK5nA3/RhoBJzO3D20c89rPk97 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=10b15.540896a7.k1409; olt=johnl@user.iecc.com; bh=wDQgJP61JDaeNrvjKTsHg4QuzVVlsSnzbO3dEP7Xu/8=; b=37SuSI1oVmCItCraahLI7GFvyJGpdiKBkVmXciSnHpoBFigry8rHHHNIac7kdoIz/HVM1KQGz0v0VmyxPQtB8mI0fMubaxWz4bfbX+mePh6be+kjZAYvFy+ijHezp/smiIA1N1q8R+QQ+UbAOYhH3eSGLG+8Bokt6GfF8WOg9c7bGwdHR0YcvVbLv5UT6vW0V+mTgZXvEgxbSpX+x5DBN2CHLcsjdBC/Dl7kQsf0XdmR3G1kZNIZXZ0BVJcFqn99 Date: 4 Sep 2014 16:42:56 -0000 Message-ID: <20140904164256.68369.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <605990B8-3519-4151-8166-A48AF57B36D3@viagenie.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Jj9hZJxPo0Wa63XuNQhg0eAX5Mg Subject: Re: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-06.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 16:43:22 -0000 In article <605990B8-3519-4151-8166-A48AF57B36D3@viagenie.ca> you write: >Hello, > this is a new version that intends to implement all comments received so far, including the IANA >considerations part. From our side, it should be ready for WGLC. >Please review. Other than some minor editing issues that the editorial process can easily fix, it looks fine to me. R's, John From nobody Thu Sep 4 10:13:49 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5641A0054; Thu, 4 Sep 2014 10:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LjMRSPdUWwk; Thu, 4 Sep 2014 10:13:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B10F21A0056; Thu, 4 Sep 2014 10:13:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140904171343.28490.78681.idtracker@ietfa.amsl.com> Date: Thu, 04 Sep 2014 10:13:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/mXHd2HaiKSFDvvIK6YgPzKePPPg Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-11.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 17:13:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : HTTP usage in the Registration Data Access Protocol (RDAP) Authors : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-11.txt Pages : 16 Date : 2014-09-04 Abstract: This document is one of a collection that together describe the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-using-http-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 4 10:16:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416BD1A00F6 for ; Thu, 4 Sep 2014 10:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OEoSfay8zvp for ; Thu, 4 Sep 2014 10:16: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 73AD71A006B for ; Thu, 4 Sep 2014 10:16:08 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 2066D21392C; Thu, 4 Sep 2014 13:16:08 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 8419C2138EF for ; Thu, 4 Sep 2014 13:16:07 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 4 Sep 2014 13:17:20 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Thu, 4 Sep 2014 13:16:06 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-11.txt Thread-Index: AQHPyGOa7XP6JbqUdUGRFVW5/ELz+pvxehkA Date: Thu, 4 Sep 2014 17:16:06 +0000 Message-ID: <941D0A34-992C-48B4-AF50-54A1FD2A1B5C@arin.net> References: <20140904171343.28490.78681.idtracker@ietfa.amsl.com> In-Reply-To: <20140904171343.28490.78681.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <4053B14741048B498ACEC3335A6FC165@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/WfJI3rwibhtFEU-ausnGfEijbLo Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-11.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 17:16:14 -0000 Just a minor revision to get the JSON reference up to date and to close out= the issue that clients MUST support HTTPS. -andy On Sep 4, 2014, at 1:13 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Extensible Internet Registration Dat= a Service Working Group of the IETF. >=20 > Title : HTTP usage in the Registration Data Access Proto= col (RDAP) > Authors : Andrew Lee Newton > Byron J. Ellacott > Ning Kong > Filename : draft-ietf-weirds-using-http-11.txt > Pages : 16 > Date : 2014-09-04 >=20 > Abstract: > This document is one of a collection that together describe the > Registration Data Access Protocol (RDAP). It describes how RDAP is > transported using the Hypertext Transfer Protocol (HTTP). RDAP is a > successor protocol to the very old WHOIS protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-weirds-using-http-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-using-http-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Thu Sep 4 21:28:13 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D6D1A03FE for ; Thu, 4 Sep 2014 21:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGSs33RrFd3K for ; Thu, 4 Sep 2014 21:28:09 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1DE1A03F7 for ; Thu, 4 Sep 2014 21:28:08 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id c11so12699900lbj.4 for ; Thu, 04 Sep 2014 21:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=t1YBPscqkR8jsqVdkj4QK/wDoACxOXf9kWw2UYD9NTY=; b=OmLMFuq0cvFHSZTJQ+wMXGm84mJt9AJpR/umZlnqdYkHoh+JoKlrFAEY3KIMaANO+r 96HfOMwopRsiu+2qVMT57nFlNA9ofA4u2nfrgX1yPYH/diX13eVZ3IeUrIySS3n604KT GtkfChCfcRALSWrkKZaMmcgDCjiduQrdYshcSiqikrnY9du5Akg/FK2X9KyNfIdJuR6g pq6lTu5Ivcz8yg3ZjM47cS4TIk5yqQruEsIxvzsAN/GovWuiGwg8QYH3A4dw5XdMVACG 8OcZKoWN2bVjayAbKZmpJY5HiTIzbpZ/vzwZXQ5rhT7CISSBdxvwiTI9LYdqG5Ck2A/y OUGg== MIME-Version: 1.0 X-Received: by 10.112.157.132 with SMTP id wm4mr8276885lbb.89.1409891287188; Thu, 04 Sep 2014 21:28:07 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Thu, 4 Sep 2014 21:28:07 -0700 (PDT) Date: Thu, 4 Sep 2014 21:28:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c24356584a94050249e5e1 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/gNFDmE4nsQFmq0wa5urpaplHBqo Subject: [weirds] Working Group Last Call ending 9/19 for all documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 04:28:12 -0000 --001a11c24356584a94050249e5e1 Content-Type: text/plain; charset=UTF-8 Colleagues, Congratulations, we've met our first milestone as laid out at IETF 91! This message begins a two-week Working Group Last Call for all documents currently active in the WEIRDS WG. They are: draft-ietf-weirds-bootstrap draft-ietf-weirds-json-response draft-ietf-weirds-object-inventory draft-ietf-weirds-rdap-query draft-ietf-weirds-rdap-sec draft-ietf-weirds-redirects draft-ietf-weirds-using-http Please provide review comments either on this list or privately to the author(s) on or before Friday, September 19, 2014. Please don't assume everyone else in the group is doing reviews, so you don't need to; if we all assume that, then the WGLCs are useless and consensus will be hard to demonstrate. Also, if any participant has knowledge of IPR that needs to be declared on any of this work, please do so, as required by BCPs 78 and 79. I will fulfill the duties of document shepherd for all of them unless I hear from others that there's interest in volunteering for a particular document (I have one outstanding request so far). -MSK, WEIRDS co-chair --001a11c24356584a94050249e5e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

Congratulations, we've me= t our first milestone as laid out at IETF 91!

This message begins a = two-week Working Group Last Call for all documents currently active in the = WEIRDS WG.=C2=A0 They are:

draft-ietf-weirds-bootstrap
draf= t-ietf-weirds-json-response
draft-ietf-weirds-object-inventory
draft-= ietf-weirds-rdap-query
draft-ietf-weirds-rdap-sec
draft-ietf-weirds-r= edirects
draft-ietf-weirds-using-http

Please provide review= comments either on this list or privately to the author(s) on or before Fr= iday, September 19, 2014.=C2=A0 Please don't assume everyone else in th= e group is doing reviews, so you don't need to; if we all assume that, = then the WGLCs are useless and consensus will be hard to demonstrate.

Also, if any participant has knowledge of IPR that needs to be declared= on any of this work, please do so, as= required by BCPs 78 and 79.

I will fulfill the duties of document s= hepherd for all of them unless I hear from others that there's interest= in volunteering for a particular document (I have one outstanding request = so far).

-MSK, WEIRDS co-chair
--001a11c24356584a94050249e5e1-- From nobody Sun Sep 7 17:21:12 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78D1A0ACA for ; Sun, 7 Sep 2014 17:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v36I9Bxeq6SH for ; Sun, 7 Sep 2014 17:21: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 C09011A0A94 for ; Sun, 7 Sep 2014 17:21:07 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 28FC4164F26; Sun, 7 Sep 2014 20:21:04 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id B6D08164F22 for ; Sun, 7 Sep 2014 20:21:03 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 7 Sep 2014 20:21:53 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Sun, 7 Sep 2014 20:21:03 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: bootstrap files Thread-Index: AQHPyvrFazZEdX73GECSFhFYqDkI9w== Date: Mon, 8 Sep 2014 00:21:02 +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.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <4DB0E4A42C408844B1314F3B35E4226E@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/fvstaph2wF3TZWh16O5CWz6xhdg Subject: [weirds] bootstrap files X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 00:21:10 -0000 All, I created some Ruby scripts to convert the current IANA XML allocation files into RDAP bootstrap JSON files. You can find the files and the code here: http://stash-projects.arin.net/projects/MRBF/repos/code/browse -andy From nobody Mon Sep 8 00:52:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D641A6F44 for ; Mon, 8 Sep 2014 00:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.743 X-Spam-Level: X-Spam-Status: No, score=-0.743 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xm2YJ8OK1gw for ; Mon, 8 Sep 2014 00:52:27 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB48B1A6F52 for ; Mon, 8 Sep 2014 00:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:date:from:to:subject:message-id:mail-followup-to: mime-version:content-type:content-disposition:user-agent:return-path; bh=cMmPKeEtElaog7ewAWgFPKKzoe/0C+pGKPiAJ7Xvr0o=; b=BMEy0TFdipi1ULkmSZvnCt1m3QTbvSJXXUGD2TSGPdbDog38IA5Zy+LEYkq/abNlbyF7D56PjjkD8 nw4OqFPGmwb1ZqJ0X7vXAFuGO3ZFvZw2FbJZow3Wf9mPSaGiTv1nnFHFy5AGAkezbrDpZkzBKKgDfT jki0Ay5zke+qvuxY= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Mon, 8 Sep 2014 17:52:20 +1000 (EST) Received: from main (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 8 Sep 2014 17:52:22 +1000 Received: from tomh by main with local (Exim 4.84) (envelope-from ) id 1XQtkL-00020w-Vo for weirds@ietf.org; Mon, 08 Sep 2014 17:52:21 +1000 Date: Mon, 8 Sep 2014 17:52:21 +1000 From: Tom Harrison To: Message-ID: <20140908075221.GA3687@main> Mail-Followup-To: weirds@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/EMrTkc-FzlQkQpAjY8EU9ojTr0c Subject: [weirds] WGLC review for draft-ietf-weirds-json-response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 07:52:29 -0000 I have read and reviewed the document, and think it's in good shape. The following are only minor issues. * General Section 3.2 requires that clients not treat unrecognised JSON attributes as errors. This is problem when dealing with jCard objects, which will typically be passed off to a third-party library for validation: that library may or may not support a relaxed validation option, which skips unknown/unrecognised attributes. I think the following after "Insertion of..." would work: The allowances made above for unrecognized attributes do not apply to jCard objects. The term "JSON vCard" is used throughout the document. It looks like "jCard" should be used instead. The references to ietf-jcardcal-jcard should be updated to point to RFC 7095, too. Section 5.4 permits the "lang" attribute to "appear anywhere in an object class or data structure". The same considerations as for unrecognised attributes and jCards are relevant to "lang", too. After "structure", I would add ", except for in jCard objects". "nameserver" is cased inconsistently: the object class name is "nameserver", and search uses "nameserverSearchResults", but the domain has an array of "nameServers". I think the last one should be changed back to "nameservers". * Example objects In section 5.2, the link example object has an array as the value of "title". RFC 5988 (5.4) states that links may only have one value for the "title" parameter, though. Throughout the document, there is an example event with an eventDate of "1991-12-31T23:59:60Z". This is not a valid datetime, as far as I can tell (a leap second was added at the end of 1990, though). In section 6.2, the object has a unicodeName of "foo.example". This should be "ns1.foo.example", so as to match the ldhName. In sections 6.3, 6.4 and 6.5, a status of "allocated" appears in the example objects. These objects should use the "active" status instead. In sections 6.3 and 6.4, there are IP network objects with endAddresses of "2001:db8::0:FFFF:FFFF:FFFF:FFFF:FFFF". The double colon should become a single colon. Various example jCards contain trailing commas. These all appear after instances of "work"-type email addresses. See e.g. section 6.1. In section 6.3, one of the variants has a relation of "restricted registration". It should be "registration restricted". In section 6.4, one of the links has "example.ent", which should be "example.net" instead. -Tom From nobody Mon Sep 8 07:12:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7321A8828 for ; Mon, 8 Sep 2014 07:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHDkz3w9HBlx for ; Mon, 8 Sep 2014 07:12: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 C39801A87EC for ; Mon, 8 Sep 2014 07:12:25 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 815B5164F78; Mon, 8 Sep 2014 10:12:25 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id ACDD8164F62; Mon, 8 Sep 2014 10:12:24 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 8 Sep 2014 10:13:31 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Mon, 8 Sep 2014 10:12:24 -0400 From: Andy Newton To: Tom Harrison , "weirds@ietf.org" Thread-Topic: [weirds] WGLC review for draft-ietf-weirds-json-response Thread-Index: AQHPyzncRppjtlpGNkKpG7OyGb0gMZv3R1uA Date: Mon, 8 Sep 2014 14:12:23 +0000 Message-ID: In-Reply-To: <20140908075221.GA3687@main> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <7CEAA091E2A38A4189F2A5E0AAB01C14@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/YvIC_BzhG_Z4H1xjE3C0B40_dqM Subject: Re: [weirds] WGLC review for draft-ietf-weirds-json-response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 14:12:28 -0000 Tom, Thanks for the review. I agree with all of your suggestions and have created a ticket for it in the issue tracker. -andy On 9/8/14, 3:52 AM, "Tom Harrison" wrote: >I have read and reviewed the document, and think it's in good shape. >The following are only minor issues. > > >* General > >Section 3.2 requires that clients not treat unrecognised JSON >attributes as errors. This is problem when dealing with jCard >objects, which will typically be passed off to a third-party library >for validation: that library may or may not support a relaxed >validation option, which skips unknown/unrecognised attributes. I >think the following after "Insertion of..." would work: > > The allowances made above for unrecognized attributes do not apply > to jCard objects. > >The term "JSON vCard" is used throughout the document. It looks like >"jCard" should be used instead. The references to ietf-jcardcal-jcard >should be updated to point to RFC 7095, too. > >Section 5.4 permits the "lang" attribute to "appear anywhere in an >object class or data structure". The same considerations as for >unrecognised attributes and jCards are relevant to "lang", too. After >"structure", I would add ", except for in jCard objects". > >"nameserver" is cased inconsistently: the object class name is >"nameserver", and search uses "nameserverSearchResults", but the >domain has an array of "nameServers". I think the last one should be >changed back to "nameservers". > > >* Example objects > >In section 5.2, the link example object has an array as the value of >"title". RFC 5988 (5.4) states that links may only have one value for >the "title" parameter, though. > >Throughout the document, there is an example event with an eventDate >of "1991-12-31T23:59:60Z". This is not a valid datetime, as far as I >can tell (a leap second was added at the end of 1990, though). > >In section 6.2, the object has a unicodeName of "foo.example". This >should be "ns1.foo.example", so as to match the ldhName. > >In sections 6.3, 6.4 and 6.5, a status of "allocated" appears in the >example objects. These objects should use the "active" status >instead. > >In sections 6.3 and 6.4, there are IP network objects with >endAddresses of "2001:db8::0:FFFF:FFFF:FFFF:FFFF:FFFF". The double >colon should become a single colon. > >Various example jCards contain trailing commas. These all appear >after instances of "work"-type email addresses. See e.g. section 6.1. > >In section 6.3, one of the variants has a relation of "restricted >registration". It should be "registration restricted". > >In section 6.4, one of the links has "example.ent", which should be >"example.net" instead. > >-Tom > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds > From nobody Mon Sep 8 16:12:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681AF1A0384 for ; Mon, 8 Sep 2014 16:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTnP7ieNOVaN for ; Mon, 8 Sep 2014 16:12:20 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9015D1A0370 for ; Mon, 8 Sep 2014 16:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:date:from:to:subject:message-id:mail-followup-to: mime-version:content-type:content-disposition:user-agent:return-path; bh=bnG0HYWX73TBoCCx5VhcXzur9jgoR+Qls+ddklTILtc=; b=8t7hPaRW26zPpJvyBiWXbA8ncg3BY8PXCTIGlsysLeNUBrVh5E0Gva1mHoGEg/BizcTDYYUMNUBWV twC8c5Ko0EDE8CrdZPZhY+mBCkkR3ZaRlXlJZYxym10wRy8+9pwtVfD63cwtXOOELbBXM6C90CwQ1l luasFHHA5mRoaqDM= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Tue, 9 Sep 2014 09:12:11 +1000 (EST) Received: from main (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 9 Sep 2014 09:12:14 +1000 Received: from tomh by main with local (Exim 4.84) (envelope-from ) id 1XR86X-00038J-St for weirds@ietf.org; Tue, 09 Sep 2014 09:12:13 +1000 Date: Tue, 9 Sep 2014 09:12:13 +1000 From: Tom Harrison To: Message-ID: <20140908231213.GA9220@main> Mail-Followup-To: weirds@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/yDMrHxwo0j5c6qO2jfmenLoScKs Subject: [weirds] WGLC review for draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 23:12:22 -0000 The document looks good. One thing to consider is the following text in section 3: First, each query is meant to return either zero or one result. With the maximum upper bound being set to one, the issuance of redirects is simplified to the traditional query/response model used by HTTP [RFC7230]. Should an entity contain more than one result, some of which are better served by other servers, the redirection model becomes much more complicated. Now that searches are described in rdap-query and json-response, this text is a bit confusing. I think the following would work: First, each lookup query is meant to return either zero or one result. With the maximum upper bound being set to one, the issuance of redirects is simplified to the traditional query/response model used by HTTP [RFC7230]. Search queries may return multiple results; for these, the server will generally answer as best it can from the data immediately available to it. -Tom From nobody Mon Sep 8 17:31:03 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC49F1A0338 for ; Mon, 8 Sep 2014 17:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_A6wAZ6kH20 for ; Mon, 8 Sep 2014 17:31:00 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093C61A033A for ; Mon, 8 Sep 2014 17:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:date:from:to:subject:message-id:mail-followup-to: mime-version:content-type:content-disposition:user-agent:return-path; bh=4RTHdMYsljS0MTUS8DzEMuCqA4g5+IBkUI1OxUv/Rcw=; b=yBFr6ZiBaO0DyctLPWm9qBlZ5CUrIEshaSerp/Xlm17HrZa11m+MGq1NHhgBzoz/GYci3bq3Ygq+r DkSUJzOWOKzuIEwss6BkVvx5nN/IqsZQ8zLkpcGU9pZZ4nCf5Bv8fRPYt9gaYk3vvaQseVZeO0inp9 QIuZbywshAtGu8MU= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Tue, 9 Sep 2014 10:30:54 +1000 (EST) Received: from main (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 9 Sep 2014 10:30:56 +1000 Received: from tomh by main with local (Exim 4.84) (envelope-from ) id 1XR9Kh-0003aW-QC for weirds@ietf.org; Tue, 09 Sep 2014 10:30:55 +1000 Date: Tue, 9 Sep 2014 10:30:55 +1000 From: Tom Harrison To: Message-ID: <20140909003055.GC9220@main> Mail-Followup-To: weirds@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/fPAr_uQbULgJnAlPqkUuBH2Zl2w Subject: [weirds] WGLC review for draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 00:31:02 -0000 The document looks good, just a couple of minor issues. It was previously suggested (http://www.ietf.org/mail-archive/web/weirds/current/msg03908.html) that the "rdap_bootstrap" keys be removed from the bootstrap files. I agree with this suggestion, but if there is a reason for the key to be retained, its name should be changed to "rdapBootstrap", to avoid any confusion with regard to the use of underscores for extensions as per section 3.2 of json-response. For domain bootstrap (section 4), I think it needs to be clearer that the matching is on a per-label basis. Changing "doing the longest match" to "doing the label-wise longest match" and striking "This is a string search ... in the arrays" could work. -Tom From nobody Mon Sep 8 17:47:13 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7518C1A0347 for ; Mon, 8 Sep 2014 17:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysGS0JhVkZRU for ; Mon, 8 Sep 2014 17:47:10 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6921A0344 for ; Mon, 8 Sep 2014 17:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:date:from:to:subject:message-id:mail-followup-to: mime-version:content-type:content-disposition:user-agent:return-path; bh=AlVksOVTbfbElq3tRfwaUXylbS2WRZ7d/FBpofAORdg=; b=FqRHzlfe3a1ZKf3azyj9jklq6JIyP4yX4MraodGYcj2M8v88yUw4nttlDPSnpnDS4hTr4u+N9S/Cr 0aiTFemFvq2qNSgKshFh5MjDX2SKHOfZ8FvzEp5tbuSpyNbnheFZfcTwQhoas1i7/27cW46o7nFf1I 3gLHbQjCxC15VcoY= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Tue, 9 Sep 2014 10:47:02 +1000 (EST) Received: from main (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 9 Sep 2014 10:47:06 +1000 Received: from tomh by main with local (Exim 4.84) (envelope-from ) id 1XR9aM-0003fu-EG for weirds@ietf.org; Tue, 09 Sep 2014 10:47:06 +1000 Date: Tue, 9 Sep 2014 10:47:06 +1000 From: Tom Harrison To: Message-ID: <20140909004706.GD9220@main> Mail-Followup-To: weirds@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/6EAMsOMjnwITn4693oipKpaePZQ Subject: [weirds] WGLC review for draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 00:47:12 -0000 The document looks good, just one issue. Section 3.2, "Search Path Segment Specification", has: A simple search to determine if an object exists (or not) without returning RDAP-encoded results can be performed using the HTTP HEAD method as described in Section 4.1 of [I-D.ietf-weirds-using-http]. Detailed results can be retrieved using the path segments specified here. I think the last sentence should become "Detailed results can be retrieved using the HTTP GET method", since the same path segments will be used regardless of the request method. -Tom From nobody Tue Sep 9 00:32:51 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087C71A0B7C for ; Tue, 9 Sep 2014 00:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-R4bWRGFmsr for ; Tue, 9 Sep 2014 00:32:48 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831E51A0B72 for ; Tue, 9 Sep 2014 00:32:48 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s897Wk0h008110 for ; Tue, 9 Sep 2014 16:32:46 +0900 X-AuditID: ac120820-b7fc78e000001dd0-f4-540ead1ec68f Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 3E.84.07632.E1DAE045; Tue, 9 Sep 2014 16:32:46 +0900 (JST) Date: Tue, 09 Sep 2014 16:31:01 +0900 (JST) Message-Id: <20140909.163101.157473808.kambe@jprs.co.jp> To: weirds@ietf.org From: Naoki Kambe In-Reply-To: <20140909003055.GC9220@main> References: <20140909003055.GC9220@main> Organization: Japan Registry Services Co., Ltd. X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFIsWRmVeSWpSXmKPExsWyRoiFT1duLV+IwdcXhhbzu46zODB6LFny kymAMYrLJiU1J7MstUjfLoEr43vHBtaCK0IVfWcOMDUw/uftYuTkkBAwkVjTf4YdwhaTuHBv PVsXIxeHkMBJRol/DZ9ZQRIsAtoSJ9fcBLN5BSwkFlzpBWsQERCWWPzyHQuILSzgKLH68jRm EJtNQEVi2b3NTCA2p4CmRMe+n0A1HEBDNSSuz48DMfkF9CWmNqVArLWTaPr7DqyCV0BQ4u8O YZAws4CWRM+Mx+wQtrzE9rdzmCcw8s9CqJqFpGoWkqoFjMyrGGXy09J0i1PzUopz0w0M9Uoq 8/WyCoqK9ZJB9CZGcMBxKOxgnHHK4BCjAAejEg+vRARfiBBrYllxZe4hRkkOJiVR3kMrgUJ8 SfkplRmJxRnxRaU5qcWHGCU4mJVEeAVXAOV4UxIrq1KL8mFS0hwsSuK8zMa9wUIC6Yklqdmp qQWpRTBZGQ4OJQlehjVAjYJFqempFWmZOSUIaSYOTpDhPEDDvUFqeIsLEnOLM9Mh8qcYtTk2 fH3Zy8SxrvNbP5MQS15+XqqUOO+p1UClAiClGaV5cNNeMYoDPSXMqwkyiAeYYODmvAJawQS0 YlIwL8iKkkSElFQD45rl/Q1RfDI557oNQ3eWxL7uF25W+vkl3V+qa/YSiyi/hOjfPw/23Fl0 uuGYYMOmbBY3uX/6Md8/cunb9QRZNB47VzZhWrvdhxZWrkPG2u7WJ/07Xry3X3Dk6AOhdQf3 mb66/pv/49WL6bfYXiwXibr7une6dSqPzFqZ8PadpvYX+EKDXnG8VWIpzkg01GIuKk4EAKoy QYbtAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/tcSPZvhXbkzBypq3dawl8P3VD78 Subject: Re: [weirds] WGLC review for draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 07:32:50 -0000 Hello, I have some minor comments on draft-ietf-weirds-bootstrap for WGLC. --- In the Bootstrap examles: { "rdap_bootstrap": { "version": "1.0", "publication": "YYYY-MM-DDTHH:MM:SSZ", "description": "RDAP Bootstrap file for example registries.", "services": [ + The "publication" value should be an actual date like "2014-09-09T10:23:57Z". + A blank line between either "publication" or "description" and "services" should be removed because it has no special meaning. --- In Section 3, The syntax of "publication" value conforms to the Internet date/time format [RFC3339]. In addition to that, the "publication" value must be updated every time the corresponding registration data are updated by IANA. --- Also in Section 3, All Domain Names labels used as keys or base RDAP URLs in the registries defined in this document MUST be only represented in lowercase. In addition to that, All Domain Names must be unique (must not be duplicate) in one Bootstrap. --- In Section 4, The domain names authoritative registration data service is found by doing the longest match of the target domain name with the domain values in the arrays in the IANA Domain Name RDAP Bootstrap Registry. As Tom-san previously pointed out, "the longest match" is a bit unclear for me too. For example, if the registry has the following Bootstrap: ... [ [ "example.com" ], [ "https://example.com/foo/" ], ], [ [ "b.example.com" ], [ "https://example.com/bar/" ] ] ... in case of an RDAP query for "ab.example.com", which must be the longest match, "example.com" or "b.example.com" ? So for avoiding such confusion, I'd like to propose that it should explicitly have a "." prefix in each name as the following: ... [ [ ".example.com" ], [ "https://example.com/foo/" ], ], [ [ ".b.example.com" ], [ "https://example.com/bar/" ] ] ... --- In Section 11, The HTTP Content-Type returned to clients accessing the JSON output of the registries MUST be "application/json" as defined in [RFC7159]. In addition to that, the registry must produce HTTP headers including "Access-Control-Allow-Origin: *" for being widely accessed. --- Regards, Naoki Kambe From nobody Tue Sep 9 05:50:20 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7A31A00DC for ; Tue, 9 Sep 2014 05:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfuXpQwrYJMF for ; Tue, 9 Sep 2014 05:50:16 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F631A00E7 for ; Tue, 9 Sep 2014 05:50:13 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKVA73hawzPKeHbLTlYLZKqbaUS0TI54xI@postini.com; Tue, 09 Sep 2014 05:50:15 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 s89CoBuh016424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 08:50:12 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 9 Sep 2014 08:50:11 -0400 From: "Hollenbeck, Scott" To: Tom Harrison , "weirds@ietf.org" Thread-Topic: [weirds] WGLC review for draft-ietf-weirds-rdap-query Thread-Index: AQHPy8ea/3UW7o1FBUCGR0Y+9iIMXJv4wTdw Date: Tue, 9 Sep 2014 12:50:11 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494ADC9B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140909004706.GD9220@main> In-Reply-To: <20140909004706.GD9220@main> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/1__0XvggJA2JHsYo6Kot9ORDB2w Subject: Re: [weirds] WGLC review for draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 12:50:17 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Tom Harrison > Sent: Monday, September 08, 2014 8:47 PM > To: weirds@ietf.org > Subject: [weirds] WGLC review for draft-ietf-weirds-rdap-query >=20 > The document looks good, just one issue. Section 3.2, "Search Path > Segment Specification", has: >=20 > A simple search to determine if an object exists (or not) without > returning RDAP-encoded results can be performed using the HTTP > HEAD method as described in Section 4.1 of > [I-D.ietf-weirds-using-http]. Detailed results can be retrieved > using the path segments specified here. >=20 > I think the last sentence should become "Detailed results can be > retrieved using the HTTP GET method", since the same path segments > will be used regardless of the request method. I see your point, but there's more to it than just the GET method. You also= need the path segments. How about this? "Detailed results can be retrieved using the HTTP GET method and the path s= egments specified here." Scott From nobody Tue Sep 9 06:25:59 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2910D1A02EA for ; Tue, 9 Sep 2014 06:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwO0bnH__BqZ for ; Tue, 9 Sep 2014 06:25: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 E95A11A02ED for ; Tue, 9 Sep 2014 06:25:57 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id A442C2137B2; Tue, 9 Sep 2014 09:25:57 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 3E7A1213762 for ; Tue, 9 Sep 2014 09:25:57 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 9 Sep 2014 09:27:44 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Tue, 9 Sep 2014 09:25:56 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: [weirds] WGLC review for draft-ietf-weirds-bootstrap Thread-Index: AQHPy8VXkB47ml0o50C1j6ENZXR6dpv4q4WAgABjKYA= Date: Tue, 9 Sep 2014 13:25:55 +0000 Message-ID: References: <20140909003055.GC9220@main> <20140909.163101.157473808.kambe@jprs.co.jp> In-Reply-To: <20140909.163101.157473808.kambe@jprs.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/EhGAkrNlYO1ax-se65VBoeR9z5E Subject: Re: [weirds] WGLC review for draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 13:25:59 -0000 I started coding up use of the bootstrap JSON as described in this draft, a= nd ran across something that makes generalization of parsing code more diff= icult than it should be. For domains, IPv4, and IPv6 bootstraps the entry array is simply an array o= f strings. But for AS numbers, the array can contain a number, an array of = two numbers, or a combination thereof (and the given example doesn=92t show= that last one). It would be simpler if it was simply an array of strings l= ike the other bootstraps, where a single AS number is given as a number in = a string and a range of AS numbers is given as a string in the form of =93s= tart-end=94 (e.g. =9364512-65534=94). This would make writing one routine f= or parsing all the bootstraps much easier. The ABNF for the string would be *DIGIT 0*1(=93-=93 *DIGIT) -andy= From nobody Tue Sep 9 06:51:08 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312921A034D for ; Tue, 9 Sep 2014 06:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4q8OIyH_PTL for ; Tue, 9 Sep 2014 06:51:02 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A5E771A05F5 for ; Tue, 9 Sep 2014 06:51:02 -0700 (PDT) Received: from h118.viagenie.ca (h118.viagenie.ca [206.123.31.118]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 561C8403B0; Tue, 9 Sep 2014 09:51:01 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: Date: Tue, 9 Sep 2014 09:51:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140909003055.GC9220@main> <20140909.163101.157473808.kambe@jprs.co.jp> To: Andy Newton X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/zOAiCn8ZGR-hlnYBcwg6SYGw6lc Cc: "weirds@ietf.org" Subject: Re: [weirds] WGLC review for draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 13:51:05 -0000 Le 2014-09-09 =E0 09:25, Andy Newton a =E9crit : > I started coding up use of the bootstrap JSON as described in this = draft, good! > and ran across something that makes generalization of parsing code = more difficult than it should be. >=20 > For domains, IPv4, and IPv6 bootstraps the entry array is simply an = array of strings. But for AS numbers, the array can contain a number, an = array of two numbers, or a combination thereof (and the given example = doesn=92t show that last one). It would be simpler if it was simply an = array of strings like the other bootstraps, where a single AS number is = given as a number in a string and a range of AS numbers is given as a = string in the form of =93start-end=94 (e.g. =9364512-65534=94). This = would make writing one routine for parsing all the bootstraps much = easier. >=20 > The ABNF for the string would be *DIGIT 0*1(=93-=93 *DIGIT) I agree with that. In fact, it was strings a few revisions ago and = someone (John if I remember well) was arguing about to have AS numbers = as numbers. Others? Marc. >=20 > -andy > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Tue Sep 9 07:08:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63581A6FB3 for ; Tue, 9 Sep 2014 07:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqMgYKtEV1JN for ; Tue, 9 Sep 2014 07:06:27 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id C89FB1A06F7 for ; Tue, 9 Sep 2014 07:05:57 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 7CC16164FC5; Tue, 9 Sep 2014 10:05:57 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 1323F164FBC; Tue, 9 Sep 2014 10:05:57 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 9 Sep 2014 10:07:38 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Tue, 9 Sep 2014 10:05:49 -0400 From: Andy Newton To: Marc Blanchet Thread-Topic: [weirds] WGLC review for draft-ietf-weirds-bootstrap Thread-Index: AQHPy8VXkB47ml0o50C1j6ENZXR6dpv4q4WAgABjKYCAAAcCAIAABCSA Date: Tue, 9 Sep 2014 14:05:49 +0000 Message-ID: References: <20140909003055.GC9220@main> <20140909.163101.157473808.kambe@jprs.co.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: <272D6E3968EF0C43A131B2F46EC1F5F2@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/fli05T7Adz9QBvL90Jz7lmSywxQ Cc: "weirds@ietf.org" Subject: Re: [weirds] WGLC review for draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 14:07:56 -0000 On Sep 9, 2014, at 9:51 AM, Marc Blanchet wrote= : >=20 > I agree with that. In fact, it was strings a few revisions ago and someon= e (John if I remember well) was arguing about to have AS numbers as numbers= . Others? Yeah, I remember that. And I may have even agreed with him at the time. But= coding these things up tends to find the rough spots. -andy= From nobody Tue Sep 9 12:10:55 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E2E1A88A2 for ; Tue, 9 Sep 2014 11:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVPXGKYVacYl for ; Tue, 9 Sep 2014 11:30:14 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB6B1A8925 for ; Tue, 9 Sep 2014 11:27:21 -0700 (PDT) Received: (qmail 80243 invoked from network); 9 Sep 2014 18:27:18 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Sep 2014 18:27:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f16.540f4686.k1409; i=johnl@user.iecc.com; bh=BVc5tUiPzL+zdjlKqbzMZkzwgTg61X6fnwL5Lw4EJ7k=; b=rEtUvPss6Acm+NakvMw1PDYGRxhl0Mcj52QrreeMlZ0z6nonzY6w0FWaor3t/mebSZ1+VNH+AGRNSk52q0IXkhwgKYQy0Du3jKLc3SnBCEHq2ait4fuex7x8nPw3loAwR27sK/y9kUgZcP/ri7QxHaeRNoY/KuzF9/YhH3UVhi8t4eVSiFIMkx7Vk6huXpHi8uYJn+MBApPejaA8CuHLKz8tnJ2m4GhVu5j1L6Dhxz8glg7ug8fICmlcQvyMXgIc 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=f16.540f4686.k1409; olt=johnl@user.iecc.com; bh=BVc5tUiPzL+zdjlKqbzMZkzwgTg61X6fnwL5Lw4EJ7k=; b=kE6AG2vR9t1Sofm+0UyEfbKPFmtj944JMug2xsVJ3jCZO5qqqKnwLeboZ+D0Qr4txpVXBhRJotU+ULhvPrFRJv0jMx0ZA/KGggjQA4H1f7GQDk78dYsj0KVgARkpUrsYqLm/6iM0Nd16JuoTeOOWIYABjme+6SbNtXaeObLQr8jNmTJipBsk+u7qNlFv2NPppk2ZGLO703y07yGL5QD0DN59KCzS2PWmuVu8pmL/oTJYYVyZRYCs0q+BjMxl8wAP Date: 9 Sep 2014 18:26:56 -0000 Message-ID: <20140909182656.3861.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 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/SGObd0Yje8-Eb4RG-eBwQtPD6dk Subject: Re: [weirds] WGLC review for draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 18:30:15 -0000 In article you write: >I started coding up use of the bootstrap JSON as described in this draft, and ran across something that makes >generalization of parsing code more difficult than it should be. > >For domains, IPv4, and IPv6 bootstraps the entry array is simply an array of strings. But for AS numbers, the array can >contain a number, an array of two numbers, or a combination thereof (and the given example doesn’t show that last one). >It would be simpler if it was simply an array of strings like the other bootstraps, where a single AS number is given >as a number in a string and a range of AS numbers is given as a string in the form of “start-end” (e.g. “64512-65534”). >This would make writing one routine for parsing all the bootstraps much easier. How about always a pair of numbers? If it's a single ASN, the numbers are the same. R's, John From nobody Tue Sep 9 12:19:59 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BDB1A0191 for ; Tue, 9 Sep 2014 12:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqzCwQf70hYk for ; Tue, 9 Sep 2014 12:19:56 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id D414D1A0184 for ; Tue, 9 Sep 2014 12:19:56 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 91BC5164FAD; Tue, 9 Sep 2014 15:19:56 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 22640164FAA; Tue, 9 Sep 2014 15:19:56 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 9 Sep 2014 15:21:00 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Tue, 9 Sep 2014 15:19:55 -0400 From: Andy Newton To: John Levine Thread-Topic: [weirds] WGLC review for draft-ietf-weirds-bootstrap Thread-Index: AQHPy8VXkB47ml0o50C1j6ENZXR6dpv4q4WAgABjKYCAAFQaAIAADsyA Date: Tue, 9 Sep 2014 19:19:54 +0000 Message-ID: References: <20140909182656.3861.qmail@joyce.lan> In-Reply-To: <20140909182656.3861.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: multipart/alternative; boundary="_000_A84387344DC649C5831F4900FD2F6F22arinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ISScJY4FyzG4KH5gSC03zaS-Mno Cc: "weirds@ietf.org" Subject: Re: [weirds] WGLC review for draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 19:19:58 -0000 --_000_A84387344DC649C5831F4900FD2F6F22arinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sep 9, 2014, at 2:26 PM, John Levine > wrote: How about always a pair of numbers? If it's a single ASN, the numbers are = the same. Even simpler. -andy --_000_A84387344DC649C5831F4900FD2F6F22arinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 9, 2014, at 2:26 PM, John Levine <johnl@taugh.com> wrote:

How about always a pair of numbers?  If it's a single ASN, the numbers ar= e the same.

Even simpler.

-andy
--_000_A84387344DC649C5831F4900FD2F6F22arinnet_-- From nobody Tue Sep 9 12:28:43 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF701A014A for ; Tue, 9 Sep 2014 12:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrWuhoV4d2LM for ; Tue, 9 Sep 2014 12:28:41 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 53F401A011B for ; Tue, 9 Sep 2014 12:28:41 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 0EC4F2137FA; Tue, 9 Sep 2014 15:28:41 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 7368F2137D9; Tue, 9 Sep 2014 15:28:40 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 9 Sep 2014 15:30:27 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Tue, 9 Sep 2014 15:28:39 -0400 From: Andy Newton To: Tom Harrison Thread-Topic: [weirds] WGLC review for draft-ietf-weirds-using-http Thread-Index: AQHPy7pgzwzR5atJCEWnpghb9dkX9Jv5dBsA Date: Tue, 9 Sep 2014 19:28:38 +0000 Message-ID: <780957EF-235A-478E-9F95-8E14845F5916@arin.net> References: <20140908231213.GA9220@main> In-Reply-To: <20140908231213.GA9220@main> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Z0k2JK6p_3gM040hgmv0ltpJcEI Cc: "weirds@ietf.org" Subject: Re: [weirds] WGLC review for draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 19:28:42 -0000 On Sep 8, 2014, at 7:12 PM, Tom Harrison wrote: > The document looks good. One thing to consider is the following text > in section 3: >=20 > First, each query is meant to return either zero or one result. > With the maximum upper bound being set to one, the issuance of > redirects is simplified to the traditional query/response model > used by HTTP [RFC7230]. Should an entity contain more than one > result, some of which are better served by other servers, the > redirection model becomes much more complicated. >=20 > Now that searches are described in rdap-query and json-response, this > text is a bit confusing. I think the following would work: >=20 > First, each lookup query is meant to return either zero or one > result. With the maximum upper bound being set to one, the > issuance of redirects is simplified to the traditional > query/response model used by HTTP [RFC7230]. Search queries may > return multiple results; for these, the server will generally > answer as best it can from the data immediately available to it. >=20 > -Tom Maybe something a little more direct: First, each query is meant to return only one path of execution to obtain= an answer. A response may contain an answer, no answer, or a redirect, and clients are not expected to fork multiple paths of execution to satisfy a= query. -andy= From nobody Tue Sep 9 15:01:04 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6531A8942 for ; Tue, 9 Sep 2014 15:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PszrWsET_fgg for ; Tue, 9 Sep 2014 15:00:24 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485991A034A for ; Tue, 9 Sep 2014 15:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:date:from:to:subject:message-id:mail-followup-to: references:mime-version:content-type:content-disposition:in-reply-to: user-agent:return-path; bh=Xq16ENlfD5EnYE0nQbRRNM7AJYOhATLTHtNljI1tY6s=; b=2YI9/DVSBlWADV2fbKv0RPJYdiVdIRIyB8Rx4tsffjuYwN2znFwO8rVyOLYxcua+WJY8BJ86kD/5H q5xPI5ZUL02E/cNsCA/MZv3ZzgvC3ZrD4XY5CK0SEiIAqmR1Bjxdnn1RX1C9zKdtg9VBhHX8qGghrJ EEI0xh6TTtBU0AsE= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Wed, 10 Sep 2014 08:00:14 +1000 (EST) Received: from main (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 10 Sep 2014 08:00:20 +1000 Received: from tomh by main with local (Exim 4.84) (envelope-from ) id 1XRTSW-000721-2J for weirds@ietf.org; Wed, 10 Sep 2014 08:00:20 +1000 Date: Wed, 10 Sep 2014 08:00:20 +1000 From: Tom Harrison To: "weirds@ietf.org" Message-ID: <20140909220020.GE22115@main> Mail-Followup-To: "weirds@ietf.org" References: <20140908231213.GA9220@main> <780957EF-235A-478E-9F95-8E14845F5916@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <780957EF-235A-478E-9F95-8E14845F5916@arin.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Sf8Z-cGEHXSihW6Ibt7fO0axxDM Subject: Re: [weirds] WGLC review for draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 22:00:38 -0000 On Tue, Sep 09, 2014 at 07:28:38PM +0000, Andy Newton wrote: > On Sep 8, 2014, at 7:12 PM, Tom Harrison wrote: >> The document looks good. One thing to consider is the following >> text in section 3: >> >> First, each query is meant to return either zero or one result. >> With the maximum upper bound being set to one, the issuance of >> redirects is simplified to the traditional query/response model >> used by HTTP [RFC7230]. Should an entity contain more than one >> result, some of which are better served by other servers, the >> redirection model becomes much more complicated. >> >> Now that searches are described in rdap-query and json-response, >> this text is a bit confusing. I think the following would work: >> >> First, each lookup query is meant to return either zero or one >> result. With the maximum upper bound being set to one, the >> issuance of redirects is simplified to the traditional >> query/response model used by HTTP [RFC7230]. Search queries may >> return multiple results; for these, the server will generally >> answer as best it can from the data immediately available to it. >> >> -Tom > > Maybe something a little more direct: > > First, each query is meant to return only one path of execution to > obtain an answer. A response may contain an answer, no answer, or > a redirect, and clients are not expected to fork multiple paths of > execution to satisfy a query. Thanks, this is better. -Tom From nobody Tue Sep 9 15:26:02 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B981E1A03EE for ; Tue, 9 Sep 2014 15:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeXFXuKhEVVF for ; Tue, 9 Sep 2014 15:26:00 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56BE1A03BE for ; Tue, 9 Sep 2014 15:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:date:from:to:subject:message-id:mail-followup-to: references:mime-version:content-type:content-disposition:in-reply-to: user-agent:return-path; bh=9yIm1S//cg9MPP89M1fx7vvhmskdrdMWlSc1eC5j8JA=; b=BtJR7ez6cXjb4rJ6hUgIrDTLGLEZ6Op4Advw99pgdu4i2lrkSpObDT+JfnILQkdQRuWSHUIqyvJVS Nb5t54ywYW7ZTH3P8YZks5ptAtjxbg1Cw4e4fxb0cZjAMJsK55GnDkuedjyx1wTqHj/F5dYORDE7ox 3bO8ZTGlPF7QdhNI= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Wed, 10 Sep 2014 08:25:53 +1000 (EST) Received: from main (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 10 Sep 2014 08:25:55 +1000 Received: from tomh by main with local (Exim 4.84) (envelope-from ) id 1XRTrH-0007gD-IM for weirds@ietf.org; Wed, 10 Sep 2014 08:25:55 +1000 Date: Wed, 10 Sep 2014 08:25:55 +1000 From: Tom Harrison To: "weirds@ietf.org" Message-ID: <20140909222555.GF22115@main> Mail-Followup-To: "weirds@ietf.org" References: <20140909004706.GD9220@main> <831693C2CDA2E849A7D7A712B24E257F494ADC9B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494ADC9B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/tHBPbqcy34wEWbYPlKlltF9zHPE Subject: Re: [weirds] WGLC review for draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 22:26:01 -0000 On Tue, Sep 09, 2014 at 12:50:11PM +0000, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Tom Harrison >> Sent: Monday, September 08, 2014 8:47 PM >> To: weirds@ietf.org >> Subject: [weirds] WGLC review for draft-ietf-weirds-rdap-query >> >> The document looks good, just one issue. Section 3.2, "Search Path >> Segment Specification", has: >> >> A simple search to determine if an object exists (or not) >> without returning RDAP-encoded results can be performed using >> the HTTP HEAD method as described in Section 4.1 of >> [I-D.ietf-weirds-using-http]. Detailed results can be >> retrieved using the path segments specified here. >> >> I think the last sentence should become "Detailed results can be >> retrieved using the HTTP GET method", since the same path segments >> will be used regardless of the request method. > > I see your point, but there's more to it than just the GET method. > You also need the path segments. How about this? > > "Detailed results can be retrieved using the HTTP GET method and the > path segments specified here." The reference to path segments in the second sentence still reads to me like those segments are somehow specific to the GET request. What about moving the paragraph to the end of 3.2? That would avoid any problems with context, I think. -Tom From nobody Wed Sep 10 03:54:07 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1751A6F32 for ; Wed, 10 Sep 2014 03:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRRZMYwtbQfb for ; Wed, 10 Sep 2014 03:54:05 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15AE1A212D for ; Wed, 10 Sep 2014 03:54:02 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKVBAtymgddB+4obLvYIrnHwCM7XkeJJDk@postini.com; Wed, 10 Sep 2014 03:54:04 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 s8AAs175026755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 06:54:01 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 06:54:00 -0400 From: "Hollenbeck, Scott" To: Tom Harrison , "weirds@ietf.org" Thread-Topic: [weirds] WGLC review for draft-ietf-weirds-rdap-query Thread-Index: AQHPy8ea/3UW7o1FBUCGR0Y+9iIMXJv4wTdwgADkUoCAAI0PUA== Date: Wed, 10 Sep 2014 10:54:00 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494AEEA2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140909004706.GD9220@main> <831693C2CDA2E849A7D7A712B24E257F494ADC9B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140909222555.GF22115@main> In-Reply-To: <20140909222555.GF22115@main> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/lvMekvi62FmyM3yOvLaqcfYP4IQ Subject: Re: [weirds] WGLC review for draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 10:54:06 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Tom Harrison > Sent: Tuesday, September 09, 2014 6:26 PM > To: weirds@ietf.org > Subject: Re: [weirds] WGLC review for draft-ietf-weirds-rdap-query >=20 > On Tue, Sep 09, 2014 at 12:50:11PM +0000, Hollenbeck, Scott wrote: > >> -----Original Message----- > >> From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Tom > Harrison > >> Sent: Monday, September 08, 2014 8:47 PM > >> To: weirds@ietf.org > >> Subject: [weirds] WGLC review for draft-ietf-weirds-rdap-query > >> > >> The document looks good, just one issue. Section 3.2, "Search Path > >> Segment Specification", has: > >> > >> A simple search to determine if an object exists (or not) > >> without returning RDAP-encoded results can be performed using > >> the HTTP HEAD method as described in Section 4.1 of > >> [I-D.ietf-weirds-using-http]. Detailed results can be > >> retrieved using the path segments specified here. > >> > >> I think the last sentence should become "Detailed results can be > >> retrieved using the HTTP GET method", since the same path segments > >> will be used regardless of the request method. > > > > I see your point, but there's more to it than just the GET method. > > You also need the path segments. How about this? > > > > "Detailed results can be retrieved using the HTTP GET method and the > > path segments specified here." >=20 > The reference to path segments in the second sentence still reads to > me like those segments are somehow specific to the GET request. What > about moving the paragraph to the end of 3.2? That would avoid any > problems with context, I think. Sure, that's doable. Scott From nobody Sun Sep 14 00:29:45 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B434F1A029C for ; Sun, 14 Sep 2014 00:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_STOP=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojw5VeyCpkRA for ; Sun, 14 Sep 2014 00:29:40 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF061A0294 for ; Sun, 14 Sep 2014 00:29:39 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id ty20so3116049lab.35 for ; Sun, 14 Sep 2014 00:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WPmYWkgGsdH4zzrALyJyCjNqYyXEOdtwSyry/S13a7A=; b=b81JPomo1WGrzqrq/jEfj/izdKA5I4+2rpJr4PkD2ENWWMfvHOXmat1cvmnjm/p6/w FQ2xdAbpsc5NjbiRe+RUSmym44eyhITWLXPZgdUmSbGLQ/DtBHZFEtljTJ4OE0aqS4WX q948VNMiwN+NiZenFtKTQnyJmF4DdOjrNRhY05Fm6H8tYcjo0GcxKXdXgkktRBJar6H0 g+ESTQQ12GVE9owrDO8eOmo0S/GNR/U3PMzCJ2qGsOs8M1jeqePD3WchPGgL80XOlnMM F4unEGOc3/NI8mSuyoVHVE1RDOYmujjRwdERgGLAn73obIF2leN3exaHioRhPSN+K3fH +jww== MIME-Version: 1.0 X-Received: by 10.112.35.44 with SMTP id e12mr18835627lbj.13.1410679777951; Sun, 14 Sep 2014 00:29:37 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Sun, 14 Sep 2014 00:29:37 -0700 (PDT) Date: Sun, 14 Sep 2014 00:29:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=14dae93d970a0e85040503017bcd Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/lBZLwPtxayDzY_-Nb8hsq6bm-Jc Subject: [weirds] Comments on draft-ietf-weirds-object-inventory X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 07:29:43 -0000 --14dae93d970a0e85040503017bcd Content-Type: text/plain; charset=UTF-8 Hi, I've reviewed this draft and I think the substance of it is in pretty good shape but it requires quite a bit of editorial work before we can send it to the IESG. I hope you can get to it all before WGLC ends! 1) In Section 1, I suggest expanding RPSL on first use, even though there's a defining document referenced there. 2) Still in Section 1, the second reference to RFC3912 (in the second paragraph) isn't needed; just saying WHOIS is fine here since it's defined earlier in the document. 3) ccTLD and gTLD need to be defined when first used. 4) Delete the paragraph referencing RFC2119. 5) Still in Section 1, the following editorial changes: - s/shortcomings that limits/shortcomings that limit/ - s/Internationalized/internationalized/ (2x) - s/Domain Name/Domain Names/ - the "For example, ..." sentence might better be expressed as a bullet list or enumerated list; at a minimum, it toggles between being comma-separated and semicolon-separated, and that should be fixed up - s/This document is aimed to build an object inventory.../This document records an inventory of registry data objects./ - s/Based on this statistics result.../The Registration Data Access Protocol (RDAP) was developed using this inventory as input./ - s/5/five/ - s/All RIRs .../Although all RIRs .../ - s/we are intended/there is no intent/ - s/will be discussed, other objects such as RPSL data structure/are discussed, but other objects such as RPSL data structures/ - s/will be added later/can be documented later/ 6) In Section 2, the definition of "Label" needs to be reworked. I believe you simply mean "The name given to a particular data element, which may vary between registries." 7) In Section 3, I'm completely confused by bullet (4). Specifically: a) "Specification 4 of the New gTLD Applicant Guidebook" should get a proper reference if at all possible. I would expect it to be an ICANN URL or some such. b) The four documents referenced are EPP definition documents, so we should be saying so before referring to them and probably explaining why there's a reference to them. At a minimum, why are we talking about the New gTLD Applicant Guidebook but actually referring to EPP RFCs? c) "above two documents" doesn't make sense when there are four RFC references and a reference to an external document in the paragraph. 8) Still in Section 3, the following editorial changes: - s/is collected/was collected/ (2x) - s/is relatively easy/was relatively easy/ - s/Find ... firstly./First, find .../ - s/5/five/ (3x) - s/is applied/was applied/ - s/query string which/query string, which/ - s/So the sample/Thus, the sample/ - s/are collected/were collected/ (2x) - s/may not seem to be correct. So/did not seem to be correct, so/ - s/are grouped together/were grouped together/ (2x) - s/is calculated/are shown/ 9) In Section 4.1, the wrapping of names makes this hard to read. In some cases, there are words broken across multiple lines, even without hyphens. The rows also run together as a result of this. This needs to be fixed. 10) In Section 4.2, change "5" to "five", and then the wrapping problem appears again. 11) Section 4.3, same thing. 12) Also in Section 4.3, I don't understand the title "WHOIS Data of IP". Does this mean a lookup of an IP address in a WHOIS server? If so, then perhaps "Replies to WHOIS Queries about IP Addresses"? 13) Section 4.4, same formatting problem. 14) Section 4.4 also has an awkward title. 15) In Section 4.5, the following editorial changes: - s/referred different/labeled differently/ - s/each object a selection/each object, a selection/ - s/starting point of the previous document of/starting point for/ 16) Section 5.1, the following editorial changes: - s/is collected/was collected/ - s/support domain query/support domain queries/ - s/support contact query/support queries for specific contact persons or roles/ - s/support name server query/support queries by nameserver/ - s/support registrar query/support registrar queries/ - s/data contains/data contain/ - s/there are total 392/there is a total of 392/ - s/Domain/domain/ - s/accessed with the following link: .../accessed at .../ 17) Section 5.2 has the same issue I mentioned in (7) above. 18) Section 5.2.1, the following editorial changes: - s/WHOIS data of domain includes/WHOIS replies about domains include/ - s/registries support XXX data element/registries support a XXX data element/ 19) Also in Section 5.2.1, the "Analyzing ..." paragraph might better be expressed as a bullet list. 20) The title of Section 5.2.2 should be more like "WHOIS Data for Contacts". 21) In each of Sections 5.2.2.1 through 5.2.2.4, the following editorial changes: - s/information of registrant/information for a registrant/ - s/3/three/ 22) The title of Section 5.2.3 should be more like "WHOIS Data for Nameservers". 23) In Section 5.2.3, the following editorial changes: - s/WHOIS response/WHOIS responses/ - s/But/However,/ - s/Top 3/The top three/ - s/So there/Thus, there/ 24) Also in Section 5.2.3, in the paragraph at the top, the labels should be quoted as you have done in previous sections. 25) The title of Section 5.2.4 should be more like "WHOIS Data for Registrars". 26) Also in 5.2.4, s/sponsoring registrar/"Sponsoring Registrar"/ for consistency. 27) In Section 5.3, the following editorial changes: - s/So called other objects/So-called "other objects"/ 28) Also in Section 5.3, I think the prose after the table is a bit confusing. I think what you mean to say is: Some registries returned things that looked like labels, but were not. For example, in this reply: Registrant: Name: Email: "Name" and "Email" appeared to be data elements, but "Registrant" was not. The inventory work proceeded on that assumption, i.e., there were two data elements to be recorded in this example. 29) In Section 5.4.1, the following editorial changes: - s/statistics conclusion/conclusions/ - s/that is/which is/ - s/And only 7/Only seven/ - s/in remarks part/in a "remarks" section/ 30) In Section 5.4.2, the following editorial changes: - s/Top 10/The top 10/ - s/We did a cumulative distribution analysis .../A cumulative distribution analysis ... was done./ - s/of data elements/of the data elements discovered by the inventory work/ - s/we can conclude/it is clear/ 31) In section 5.4.3, the following editorial changes: - s/name server label/the "Name Server" label/ - s/So label numbers of name server are much more/Thus, the count of labels for name servers is much higher/ - s/Other elements .../Data elements representing dates and street addresses were also common./ - s/2 Labels/two labels/ - s/So it is very/It is therefore/ - s/of WHOIS response/in a WHOIS response/ 32) In section 5.4.4, the following editorial changes: - s/According to statistics result,/The results indicate that/ - s/or privately owned/or are privately defined/ - s/Top 50 other/The top 50 other/ - s/You can find that/It is clear that/ - s/So in order/In order/ - s/Restful Whois/RDAP/ - s/establishing/establishment of/ - s/a necessary requirement/advised/ 33) Section 5.5's title needs to be more clear about what it's presenting. I see it as enumerating assumptions or possible flaws in the survey work. Maybe call it "Limitations", and then start with a sentence or two about what you're listing, such as: This section enumerates limitations of the survey and some assumptions that were made in the execution of this work. 34) Also in Section 5.5: Does "local script" refer to the written form in the region where the registry is based? Since we're talking about web-based replies, "script" might be interpreted differently by some people. 35) Also in Section 5.5: OLD: We only use "Whois contactID/nameserver/registrar" as the query commands to check." NEW: Only WHOIS queries for contact ID, nameserver, and registrar were used. 36) Section 6, editorial changes: - s/existed/existing/ - delete "the document of" - s/ogjects/objects/ 37) Section 6.2, editorial changes: - s/Top 50/top 50/ - s/over 5/more than five/ - s/it is usually/typically/ - s/whethe/whether/ - s/domain is hold/domain is "on hold"/ 38) In Section 7, add: [RFC Editor: Please delete this section prior to publication.] 39) Section 9, change "Weirds" to "WEIRDS". -MSK --14dae93d970a0e85040503017bcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I've reviewed this draf= t and I think the substance of it is in pretty good shape but it requires q= uite a bit of editorial work before we can send it to the IESG.=C2=A0 I hop= e you can get to it all before WGLC ends!

1) In Section 1, I s= uggest expanding RPSL on first use, even though there's a defining docu= ment referenced there.

2) Still in Section 1, the second refer= ence to RFC3912 (in the second paragraph) isn't needed; just saying WHO= IS is fine here since it's defined earlier in the document.

3) ccTLD and gTLD need to be defined when first used.

<= div>4) Delete the paragraph referencing RFC2119.

5) Still in S= ection 1, the following editorial changes:

- s/shortcomings that lim= its/shortcomings that limit/
- s/Internationalized/internatio= nalized/ (2x)
- s/Domain Name/Domain Names/
- t= he "For example, ..." sentence might better be expressed as a bul= let list or enumerated list; at a minimum, it toggles between being comma-s= eparated and semicolon-separated, and that should be fixed up
- s/This document is aimed to build an object inventory.../This document r= ecords an inventory of registry data objects./
- s/Based on t= his statistics result.../The Registration Data Access Protocol (RDAP) was d= eveloped using this inventory as input./
- s/5/five/
- s/All RIRs .../Although all RIRs .../
- s/we are inte= nded/there is no intent/
- s/will be discussed, other objects= such as RPSL data structure/are discussed, but other objects such as RPSL = data structures/
- s/will be added later/can be documented la= ter/

6) In Section 2, the definition of "Label" needs= to be reworked.=C2=A0 I believe you simply mean "The name given to a = particular data element, which may vary between registries."

7) In Section 3, I'm completely confused by bullet (4).=C2=A0 = Specifically:

a) "Specification 4 of the New gTLD Ap= plicant Guidebook" should get a proper reference if at all possible.= =C2=A0 I would expect it to be an ICANN URL or some such.

b) The fou= r documents referenced are EPP definition documents, so we should be saying= so before referring to them and probably explaining why there's a refe= rence to them.=C2=A0 At a minimum, why are we talking about the New gTLD Ap= plicant Guidebook but actually referring to EPP RFCs?

c) = "above two documents" doesn't make sense when there are four = RFC references and a reference to an external document in the paragraph.
8) Still in Section 3, the following editorial changes:

<= /div>
- s/is collected/was collected/ (2x)
- s/is relativ= ely easy/was relatively easy/
- s/Find ... firstly./First, fi= nd .../
- s/5/five/ (3x)
- s/is applied/was app= lied/
- s/query string which/query string, which/
- s/So the sample/Thus, the sample/
- s/are collected/were= collected/ (2x)
- s/may not seem to be correct.=C2=A0 So/did= not seem to be correct, so/
- s/are grouped together/were gr= ouped together/ (2x)
- s/is calculated/are shown/

9) In Section 4.1, the wrapping of names makes this hard to read.=C2= =A0 In some cases, there are words broken across multiple lines, even witho= ut hyphens.=C2=A0 The rows also run together as a result of this.=C2=A0 Thi= s needs to be fixed.

10) In Section 4.2, change "5&q= uot; to "five", and then the wrapping problem appears again.
<= br>
11) Section 4.3, same thing.

12) Also in Se= ction 4.3, I don't understand the title "WHOIS Data of IP".= =C2=A0 Does this mean a lookup of an IP address in a WHOIS server?=C2=A0 If= so, then perhaps "Replies to WHOIS Queries about IP Addresses"?<= br>
13) Section 4.4, same formatting problem.

14) Section 4.4 also has an awkward title.

15) In Sect= ion 4.5, the following editorial changes:

- s/referred di= fferent/labeled differently/
- s/each object a selection/each= object, a selection/
- s/starting point of the previous docu= ment of/starting point for/

16) Section 5.1, the followin= g editorial changes:

- s/is collected/was collected/
<= /div>
- s/support domain query/support domain queries/
- = s/support contact query/support queries for specific contact persons or rol= es/
- s/support name server query/support queries by nameserv= er/
- s/support registrar query/support registrar queries/
- s/data contains/data contain/
- s/there are tot= al 392/there is a total of 392/
- s/Domain/domain/
<= div>- s/accessed with the following link: .../accessed at .../

17) Section 5.2 has the same issue I mentioned in (7) above.

<= /div>
18) Section 5.2.1, the following editorial changes:

=
- s/WHOIS data of domain includes/WHOIS replies about domains include/=
- s/registries support XXX data element/registries support a= XXX data element/

19) Also in Section 5.2.1, = the "Analyzing ..." paragraph might better be expressed as a bull= et list.

20) The title of Section 5.2.2 should be more li= ke "WHOIS Data for Contacts".

21) In each of Se= ctions 5.2.2.1 through 5.2.2.4, the following editorial changes:

- s= /information of registrant/information for a registrant/
- s/= 3/three/

22) The title of Section 5.2.3 should be more li= ke "WHOIS Data for Nameservers".

23) In Section= 5.2.3, the following editorial changes:

- s/WHOIS respon= se/WHOIS responses/
- s/But/However,/
- s/Top 3= /The top three/
- s/So there/Thus, there/

2= 4) Also in Section 5.2.3, in the paragraph at the top, the labels should be= quoted as you have done in previous sections.

25) The ti= tle of Section 5.2.4 should be more like "WHOIS Data for Registrars&qu= ot;.

26) Also in 5.2.4, s/sponsoring registrar/"Spon= soring Registrar"/ for consistency.

27) In Section 5= .3, the following editorial changes:

- s/So called other = objects/So-called "other objects"/

28) Also in = Section 5.3, I think the prose after the table is a bit confusing.=C2=A0 I = think what you mean to say is:

Some registries returned t= hings that looked like labels, but were not.=C2=A0 For example, in this rep= ly:

Registrant:
=C2=A0 Name:
=C2=A0 Emai= l:

"Name" and "Email" appeared to be = data elements, but "Registrant" was not.=C2=A0 The inventory work= proceeded on that assumption, i.e., there were two data elements to be rec= orded in this example.

29) In Section 5.4.1, the followin= g editorial changes:

- s/statistics conclusion/conclusion= s/
- s/that is/which is/
- s/And only 7/Only se= ven/
- s/in remarks part/in a "remarks" section/
30) In Section 5.4.2, the following editorial changes:
<= br>- s/Top 10/The top 10/
- s/We did a cumulative distributio= n analysis .../A cumulative distribution analysis ... was done./
<= div>- s/of data elements/of the data elements discovered by the inventory w= ork/
- s/we can conclude/it is clear/

31) I= n section 5.4.3, the following editorial changes:

- s/nam= e server label/the "Name Server" label/
- s/So labe= l numbers of name server are much more/Thus, the count of labels for name s= ervers is much higher/
- s/Other elements .../Data elements r= epresenting dates and street addresses were also common./
- s/2 Lab= els/two labels/
- s/So it is very/It is therefore/
<= div>- s/of WHOIS response/in a WHOIS response/

32) In section = 5.4.4, the following editorial changes:

- s/According to = statistics result,/The results indicate that/
- s/or privatel= y owned/or are privately defined/
- s/Top 50 other/The top 50= other/
- s/You can find that/It is clear that/
- s/So in order/In order/
- s/Restful Whois/RDAP/
<= div>- s/establishing/establishment of/
- s/a necessary requir= ement/advised/

33) Section 5.5's title needs to be mo= re clear about what it's presenting.=C2=A0 I see it as enumerating assu= mptions or possible flaws in the survey work.=C2=A0 Maybe call it "Lim= itations", and then start with a sentence or two about what you're= listing, such as:

This section enumerates limitations of= the survey and some assumptions that were made in the execution of this wo= rk.

34) Also in Section 5.5: Does "local script"= ; refer to the written form in the region where the registry is based?=C2= =A0 Since we're talking about web-based replies, "script" mig= ht be interpreted differently by some people.

35) Also in= Section 5.5:

OLD:

We only use "Whois contact= ID/nameserver/registrar" as the query commands to check."

=
NEW:

Only WHOIS queries for contact ID, namese= rver, and registrar were used.

36) Section 6, editorial c= hanges:

- s/existed/existing/
- delete &quo= t;the document of"
- s/ogjects/objects/

37) Section 6.2, editorial changes:

- s/Top 50/top 50/<= br>
- s/over 5/more than five/
- s/it is usually/ty= pically/
- s/whethe/whether/
- s/domain is hold= /domain is "on hold"/

38) In Section 7, add:
[RFC Editor: Please delete this section prior to publication.]

=
39) Section 9, change "Weirds" to "WEIRDS".<= br>
-MSK
--14dae93d970a0e85040503017bcd-- From nobody Sun Sep 14 19:25:14 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6B61A02F9 for ; Sun, 14 Sep 2014 19:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.897 X-Spam-Level: *** X-Spam-Status: No, score=3.897 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MANGLED_STOP=2.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgDkWPVR7XIA for ; Sun, 14 Sep 2014 19:25:08 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 93ED91A04AC for ; Sun, 14 Sep 2014 19:25:06 -0700 (PDT) Received: from [218.241.103.68] (unknown [218.241.103.68]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0Dpj4T9TRZUTOUDAA--.8469S2; Mon, 15 Sep 2014 10:25:01 +0800 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FDA4CE95-3394-406E-9746-9F571587FA55" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: Date: Mon, 15 Sep 2014 10:25:00 +0800 Message-Id: References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0Dpj4T9TRZUTOUDAA--.8469S2 X-Coremail-Antispam: 1UD129KBjvJXoW3Jr1rKr13Wr4DKF4DZFyrZwb_yoWfXrW5pF WFk3srKrs8Ar1UZ348uF4UuFyFyrWDtrZxJ3y5Gryqv3y5WFn2gFs3tF45Za47Cr1S9Fy0 qr12gFZ8Xa98ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUk0b7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAv7VC0I7IY x2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4 x0Y48IcxkI7VAKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_Gr1l42xK82IY c2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVW3JVWrJr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUqzuAUUUUU X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/XQ3uMqDXJzTllaCkX-P9Xdmfu6c Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-object-inventory X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 02:25:11 -0000 --Apple-Mail=_FDA4CE95-3394-406E-9746-9F571587FA55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Murray, Thanks for your detailed suggestions. We=A1=AFll update the draft based = on your comments before WGLC ends. Cheers, Ning =D4=DA 2014=C4=EA9=D4=C214=C8=D5=A3=AC=CF=C2=CE=E73:29=A3=ACMurray S. = Kucherawy =D0=B4=B5=C0=A3=BA > Hi, >=20 > I've reviewed this draft and I think the substance of it is in pretty = good shape but it requires quite a bit of editorial work before we can = send it to the IESG. I hope you can get to it all before WGLC ends! >=20 > 1) In Section 1, I suggest expanding RPSL on first use, even though = there's a defining document referenced there. >=20 > 2) Still in Section 1, the second reference to RFC3912 (in the second = paragraph) isn't needed; just saying WHOIS is fine here since it's = defined earlier in the document. >=20 > 3) ccTLD and gTLD need to be defined when first used. >=20 > 4) Delete the paragraph referencing RFC2119. >=20 > 5) Still in Section 1, the following editorial changes: >=20 > - s/shortcomings that limits/shortcomings that limit/ > - s/Internationalized/internationalized/ (2x) > - s/Domain Name/Domain Names/ > - the "For example, ..." sentence might better be expressed as a = bullet list or enumerated list; at a minimum, it toggles between being = comma-separated and semicolon-separated, and that should be fixed up > - s/This document is aimed to build an object inventory.../This = document records an inventory of registry data objects./ > - s/Based on this statistics result.../The Registration Data Access = Protocol (RDAP) was developed using this inventory as input./ > - s/5/five/ > - s/All RIRs .../Although all RIRs .../ > - s/we are intended/there is no intent/ > - s/will be discussed, other objects such as RPSL data structure/are = discussed, but other objects such as RPSL data structures/ > - s/will be added later/can be documented later/ >=20 > 6) In Section 2, the definition of "Label" needs to be reworked. I = believe you simply mean "The name given to a particular data element, = which may vary between registries." >=20 > 7) In Section 3, I'm completely confused by bullet (4). Specifically: >=20 > a) "Specification 4 of the New gTLD Applicant Guidebook" should get a = proper reference if at all possible. I would expect it to be an ICANN = URL or some such. >=20 > b) The four documents referenced are EPP definition documents, so we = should be saying so before referring to them and probably explaining why = there's a reference to them. At a minimum, why are we talking about the = New gTLD Applicant Guidebook but actually referring to EPP RFCs? >=20 > c) "above two documents" doesn't make sense when there are four RFC = references and a reference to an external document in the paragraph. >=20 > 8) Still in Section 3, the following editorial changes: >=20 > - s/is collected/was collected/ (2x) > - s/is relatively easy/was relatively easy/ > - s/Find ... firstly./First, find .../ > - s/5/five/ (3x) > - s/is applied/was applied/ > - s/query string which/query string, which/ > - s/So the sample/Thus, the sample/ > - s/are collected/were collected/ (2x) > - s/may not seem to be correct. So/did not seem to be correct, so/ > - s/are grouped together/were grouped together/ (2x) > - s/is calculated/are shown/ >=20 > 9) In Section 4.1, the wrapping of names makes this hard to read. In = some cases, there are words broken across multiple lines, even without = hyphens. The rows also run together as a result of this. This needs to = be fixed. >=20 > 10) In Section 4.2, change "5" to "five", and then the wrapping = problem appears again. >=20 > 11) Section 4.3, same thing. >=20 > 12) Also in Section 4.3, I don't understand the title "WHOIS Data of = IP". Does this mean a lookup of an IP address in a WHOIS server? If = so, then perhaps "Replies to WHOIS Queries about IP Addresses"? >=20 > 13) Section 4.4, same formatting problem. >=20 > 14) Section 4.4 also has an awkward title. >=20 > 15) In Section 4.5, the following editorial changes: >=20 > - s/referred different/labeled differently/ > - s/each object a selection/each object, a selection/ > - s/starting point of the previous document of/starting point for/ >=20 > 16) Section 5.1, the following editorial changes: >=20 > - s/is collected/was collected/ > - s/support domain query/support domain queries/ > - s/support contact query/support queries for specific contact persons = or roles/ > - s/support name server query/support queries by nameserver/ > - s/support registrar query/support registrar queries/ > - s/data contains/data contain/ > - s/there are total 392/there is a total of 392/ > - s/Domain/domain/ > - s/accessed with the following link: .../accessed at .../ >=20 > 17) Section 5.2 has the same issue I mentioned in (7) above. >=20 > 18) Section 5.2.1, the following editorial changes: >=20 > - s/WHOIS data of domain includes/WHOIS replies about domains include/ > - s/registries support XXX data element/registries support a XXX data = element/ >=20 > 19) Also in Section 5.2.1, the "Analyzing ..." paragraph might better = be expressed as a bullet list. >=20 > 20) The title of Section 5.2.2 should be more like "WHOIS Data for = Contacts". >=20 > 21) In each of Sections 5.2.2.1 through 5.2.2.4, the following = editorial changes: >=20 > - s/information of registrant/information for a registrant/ > - s/3/three/ >=20 > 22) The title of Section 5.2.3 should be more like "WHOIS Data for = Nameservers". >=20 > 23) In Section 5.2.3, the following editorial changes: >=20 > - s/WHOIS response/WHOIS responses/ > - s/But/However,/ > - s/Top 3/The top three/ > - s/So there/Thus, there/ >=20 > 24) Also in Section 5.2.3, in the paragraph at the top, the labels = should be quoted as you have done in previous sections. >=20 > 25) The title of Section 5.2.4 should be more like "WHOIS Data for = Registrars". >=20 > 26) Also in 5.2.4, s/sponsoring registrar/"Sponsoring Registrar"/ for = consistency. >=20 > 27) In Section 5.3, the following editorial changes: >=20 > - s/So called other objects/So-called "other objects"/ >=20 > 28) Also in Section 5.3, I think the prose after the table is a bit = confusing. I think what you mean to say is: >=20 > Some registries returned things that looked like labels, but were not. = For example, in this reply: >=20 > Registrant: > Name: > Email: >=20 > "Name" and "Email" appeared to be data elements, but "Registrant" was = not. The inventory work proceeded on that assumption, i.e., there were = two data elements to be recorded in this example. >=20 > 29) In Section 5.4.1, the following editorial changes: >=20 > - s/statistics conclusion/conclusions/ > - s/that is/which is/ > - s/And only 7/Only seven/ > - s/in remarks part/in a "remarks" section/ >=20 > 30) In Section 5.4.2, the following editorial changes: >=20 > - s/Top 10/The top 10/ > - s/We did a cumulative distribution analysis .../A cumulative = distribution analysis ... was done./ > - s/of data elements/of the data elements discovered by the inventory = work/ > - s/we can conclude/it is clear/ >=20 > 31) In section 5.4.3, the following editorial changes: >=20 > - s/name server label/the "Name Server" label/ > - s/So label numbers of name server are much more/Thus, the count of = labels for name servers is much higher/ > - s/Other elements .../Data elements representing dates and street = addresses were also common./ > - s/2 Labels/two labels/ > - s/So it is very/It is therefore/ > - s/of WHOIS response/in a WHOIS response/ >=20 > 32) In section 5.4.4, the following editorial changes: >=20 > - s/According to statistics result,/The results indicate that/ > - s/or privately owned/or are privately defined/ > - s/Top 50 other/The top 50 other/ > - s/You can find that/It is clear that/ > - s/So in order/In order/ > - s/Restful Whois/RDAP/ > - s/establishing/establishment of/ > - s/a necessary requirement/advised/ >=20 > 33) Section 5.5's title needs to be more clear about what it's = presenting. I see it as enumerating assumptions or possible flaws in = the survey work. Maybe call it "Limitations", and then start with a = sentence or two about what you're listing, such as: >=20 > This section enumerates limitations of the survey and some assumptions = that were made in the execution of this work. >=20 > 34) Also in Section 5.5: Does "local script" refer to the written form = in the region where the registry is based? Since we're talking about = web-based replies, "script" might be interpreted differently by some = people. >=20 > 35) Also in Section 5.5: >=20 > OLD: >=20 > We only use "Whois contactID/nameserver/registrar" as the query = commands to check." >=20 > NEW: >=20 > Only WHOIS queries for contact ID, nameserver, and registrar were = used. >=20 > 36) Section 6, editorial changes: >=20 > - s/existed/existing/ > - delete "the document of" > - s/ogjects/objects/ >=20 > 37) Section 6.2, editorial changes: >=20 > - s/Top 50/top 50/ > - s/over 5/more than five/ > - s/it is usually/typically/ > - s/whethe/whether/ > - s/domain is hold/domain is "on hold"/ >=20 > 38) In Section 7, add: >=20 > [RFC Editor: Please delete this section prior to publication.] >=20 > 39) Section 9, change "Weirds" to "WEIRDS". >=20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_FDA4CE95-3394-406E-9746-9F571587FA55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312
Hi Murray,

Thanks = for your detailed suggestions. We=A1=AFll update the draft based on your = comments before WGLC ends.

Cheers,
Ning


=D4=DA 2014=C4=EA9=D4=C214=C8=D5=A3=AC=CF=C2=CE=E73:29=A3=AC= Murray S. Kucherawy <superuser@gmail.com> = =D0=B4=B5=C0=A3=BA

Hi,

I've reviewed this draft and = I think the substance of it is in pretty good shape but it requires = quite a bit of editorial work before we can send it to the IESG.  I = hope you can get to it all before WGLC ends!

1) In Section = 1, I suggest expanding RPSL on first use, even though there's a defining = document referenced there.

2) Still in Section 1, the = second reference to RFC3912 (in the second paragraph) isn't needed; just = saying WHOIS is fine here since it's defined earlier in the = document.

3) ccTLD and gTLD need to be defined when = first used.

4) Delete the paragraph referencing = RFC2119.

5) Still in Section 1, the following editorial = changes:

- s/shortcomings that limits/shortcomings that = limit/
- s/Internationalized/internationalized/ = (2x)
- s/Domain Name/Domain Names/
- the = "For example, ..." sentence might better be expressed as a bullet list = or enumerated list; at a minimum, it toggles between being = comma-separated and semicolon-separated, and that should be fixed = up
- s/This document is aimed to build an object = inventory.../This document records an inventory of registry data = objects./
- s/Based on this statistics result.../The = Registration Data Access Protocol (RDAP) was developed using this = inventory as input./
- s/5/five/
- s/All = RIRs .../Although all RIRs .../
- s/we are intended/there = is no intent/
- s/will be discussed, other objects such as = RPSL data structure/are discussed, but other objects such as RPSL data = structures/
- s/will be added later/can be documented = later/

6) In Section 2, the definition of "Label" needs to = be reworked.  I believe you simply mean "The name given to a = particular data element, which may vary between = registries."

7) In Section 3, I'm completely confused = by bullet (4).  Specifically:

a) "Specification 4 = of the New gTLD Applicant Guidebook" should get a proper reference if at = all possible.  I would expect it to be an ICANN URL or some = such.

b) The four documents referenced are EPP definition = documents, so we should be saying so before referring to them and = probably explaining why there's a reference to them.  At a minimum, = why are we talking about the New gTLD Applicant Guidebook but actually = referring to EPP RFCs?

c) "above two documents" = doesn't make sense when there are four RFC references and a reference to = an external document in the paragraph.

8) Still in Section = 3, the following editorial changes:

- s/is = collected/was collected/ (2x)
- s/is relatively easy/was = relatively easy/
- s/Find ... firstly./First, find = .../
- s/5/five/ (3x)
- s/is applied/was = applied/
- s/query string which/query string, = which/
- s/So the sample/Thus, the sample/
- = s/are collected/were collected/ (2x)
- s/may not seem to = be correct.  So/did not seem to be correct, so/
- = s/are grouped together/were grouped together/ (2x)
- s/is = calculated/are shown/

9) In Section 4.1, the wrapping = of names makes this hard to read.  In some cases, there are words = broken across multiple lines, even without hyphens.  The rows also = run together as a result of this.  This needs to be = fixed.

10) In Section 4.2, change "5" to "five", and = then the wrapping problem appears again.

11) Section = 4.3, same thing.

12) Also in Section 4.3, I don't = understand the title "WHOIS Data of IP".  Does this mean a lookup = of an IP address in a WHOIS server?  If so, then perhaps "Replies = to WHOIS Queries about IP Addresses"?

13) Section 4.4, = same formatting problem.

14) Section 4.4 also has an = awkward title.

15) In Section 4.5, the following = editorial changes:

- s/referred different/labeled = differently/
- s/each object a selection/each object, a = selection/
- s/starting point of the previous document = of/starting point for/

16) Section 5.1, the following = editorial changes:

- s/is collected/was = collected/
- s/support domain query/support domain = queries/
- s/support contact query/support queries for = specific contact persons or roles/
- s/support name server = query/support queries by nameserver/
- s/support registrar = query/support registrar queries/
- s/data contains/data = contain/
- s/there are total 392/there is a total of = 392/
- s/Domain/domain/
- s/accessed with = the following link: .../accessed at .../

17) Section = 5.2 has the same issue I mentioned in (7) above.

18) = Section 5.2.1, the following editorial changes:

- = s/WHOIS data of domain includes/WHOIS replies about domains = include/
- s/registries support XXX data = element/registries support a XXX data = element/

19) Also in Section 5.2.1, the = "Analyzing ..." paragraph might better be expressed as a bullet = list.

20) The title of Section 5.2.2 should be more = like "WHOIS Data for Contacts".

21) In each of = Sections 5.2.2.1 through 5.2.2.4, the following editorial = changes:

- s/information of registrant/information for a = registrant/
- s/3/three/

22) The title = of Section 5.2.3 should be more like "WHOIS Data for = Nameservers".

23) In Section 5.2.3, the following = editorial changes:

- s/WHOIS response/WHOIS = responses/
- s/But/However,/
- s/Top 3/The = top three/
- s/So there/Thus, there/

24) = Also in Section 5.2.3, in the paragraph at the top, the labels should be = quoted as you have done in previous sections.

25) The = title of Section 5.2.4 should be more like "WHOIS Data for = Registrars".

26) Also in 5.2.4, s/sponsoring = registrar/"Sponsoring Registrar"/ for consistency.

27) = In Section 5.3, the following editorial changes:

- = s/So called other objects/So-called "other = objects"/

28) Also in Section 5.3, I think the prose = after the table is a bit confusing.  I think what you mean to say = is:

Some registries returned things that looked like = labels, but were not.  For example, in this = reply:

Registrant:
  = Name:
  Email:

"Name" and "Email" = appeared to be data elements, but "Registrant" was not.  The = inventory work proceeded on that assumption, i.e., there were two data = elements to be recorded in this example.

29) In = Section 5.4.1, the following editorial changes:

- = s/statistics conclusion/conclusions/
- s/that is/which = is/
- s/And only 7/Only seven/
- s/in = remarks part/in a "remarks" section/

30) In Section = 5.4.2, the following editorial changes:

- s/Top 10/The top = 10/
- s/We did a cumulative distribution analysis .../A = cumulative distribution analysis ... was done./
- s/of = data elements/of the data elements discovered by the inventory = work/
- s/we can conclude/it is = clear/

31) In section 5.4.3, the following editorial = changes:

- s/name server label/the "Name Server" = label/
- s/So label numbers of name server are much = more/Thus, the count of labels for name servers is much = higher/
- s/Other elements .../Data elements representing = dates and street addresses were also common./
- s/2 Labels/two = labels/
- s/So it is very/It is therefore/
- = s/of WHOIS response/in a WHOIS response/

32) In section = 5.4.4, the following editorial changes:

- s/According = to statistics result,/The results indicate that/
- s/or = privately owned/or are privately defined/
- s/Top 50 = other/The top 50 other/
- s/You can find that/It is clear = that/
- s/So in order/In order/
- s/Restful = Whois/RDAP/
- s/establishing/establishment = of/
- s/a necessary = requirement/advised/

33) Section 5.5's title needs to = be more clear about what it's presenting.  I see it as enumerating = assumptions or possible flaws in the survey work.  Maybe call it = "Limitations", and then start with a sentence or two about what you're = listing, such as:

This section enumerates limitations = of the survey and some assumptions that were made in the execution of = this work.

34) Also in Section 5.5: Does "local = script" refer to the written form in the region where the registry is = based?  Since we're talking about web-based replies, "script" might = be interpreted differently by some people.

35) Also in = Section 5.5:

OLD:

We only use "Whois = contactID/nameserver/registrar" as the query commands to = check."

NEW:

Only WHOIS queries for = contact ID, nameserver, and registrar were used.

36) = Section 6, editorial changes:

- = s/existed/existing/
- delete "the document = of"
- s/ogjects/objects/

37) Section = 6.2, editorial changes:

- s/Top 50/top = 50/
- s/over 5/more than five/
- s/it is = usually/typically/
- s/whethe/whether/
- = s/domain is hold/domain is "on hold"/

38) In Section = 7, add:

[RFC Editor: Please delete this section prior to = publication.]

39) Section 9, change "Weirds" to = "WEIRDS".

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

= --Apple-Mail=_FDA4CE95-3394-406E-9746-9F571587FA55-- From nobody Sun Sep 14 23:27:25 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F911A068E for ; Sun, 14 Sep 2014 23:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG3-V4yMlloU for ; Sun, 14 Sep 2014 23:27:22 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027AA1A0672 for ; Sun, 14 Sep 2014 23:27:21 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id p9so3839557lbv.10 for ; Sun, 14 Sep 2014 23:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0tb2AndS+pUb+ycdKuT0n8ATurMrQfPr1iUc4c8rMAA=; b=tWISIRc2DOEq9JoxJRysL2ZIiQTj0kDV+S2eCj8R39tNxbHru/9FIM90f7C0XJWW2+ jYULlmrSg985WdE8NgwRSbfb64nv/pttAd8T1uBf7CbPtDS/pbLUTa/Is3yqEwijCuq8 y0ZVDncMT4I2FFijILZk0bVRXE9kbMOfXt43WjTuCX/H6hM6NppKpMEqDyAPz+TCLyBB S6awNUIfZboi3rvLBf7W38fNJ6UlPztxX3lYFRDiJkJqdxQrnhLjktccnniMLVzB00s+ jUqmarkwIig76wl0V9tO4ul02ciI3qvnVsqVeXXjtLi/UKIXxeiqlERolVKAUi/WTJeW 1y4Q== MIME-Version: 1.0 X-Received: by 10.152.43.50 with SMTP id t18mr26002516lal.25.1410762439951; Sun, 14 Sep 2014 23:27:19 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Sun, 14 Sep 2014 23:27:19 -0700 (PDT) Date: Sun, 14 Sep 2014 23:27:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c239d0188bbe050314ba68 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Y4yX1h3iFa3eGMWWBbPDxRDhx2Y Subject: [weirds] Comments on draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 06:27:24 -0000 --001a11c239d0188bbe050314ba68 Content-Type: text/plain; charset=UTF-8 Hi, I've reviewed this draft and it's in pretty good shape. I have the following suggestions for the authors to consider as we march toward IESG evaluation. I think the most critical stuff is some revisiting of the RFC2119 language and a couple of definitions. 1) Some editorial suggestions for Section 1: - add a space between "HTTP" and "[RFC7230]" - "Registration Data Directory Services" (the capitalization) made me go look for a definition for that term, which of course isn't there. Should this be RDAP? Should a definition be added? Should it just be de-capitalized? - same thing happens in the same paragraph with "Registration Data" and "Directory Services" separately, though it looks like "Registration Data" is actually defined in the second paragraph so maybe that text can just be moved to Definitions - is there a definition of RESTful that could be included or referenced here? - Suggest changing "This data is typically provided" to either "These data area typically provided" or "This information is typically provided" ("data" is actually plural) - add a space between "GET" and "[RFC7231]" - in the "basic usage pattern" list, the first bullet shows an example query URL, but it ends with a period that's not part of the query. Might this be better separated out, like with
? - in the second bullet, delete "standardized by the IETF" - should the third bullet reference the redirects draft? - delete "It is important to note that" 2) In Section 2, "consideration" should be "considerations". 3) In Section 4.1, there are instances of both "SHOULD" and "should". The second one might better be "is usually". 4) Again about Section 4.1, the definition of SHOULD allows for deviation from that advice when there's a good reason to do so. Would it be worth talking about other choices, and the impacts of using those options, and why one might choose them? 5) Section 5's "SHOULD" has a similar issue. Why would one choose not to understand the response codes? 6) The example in Section 5.2 might be better done with
so an actual example can be viewed. 7) Section 5.3 talks about an "empty set", but this sounds a bit wrong to me because an object can be undefined or it can be defined but empty. It sounds like we want to make it clear that we're saying "I don't have that data" versus "I have a record for that, but it's empty." 8) Section 5.4 appears to suggest a client rejected for policy reasons can retry. Would it ever get a different result, unless the policy (or permissions) changed? 9) In Section 5.6, remove the comma from the second paragraph. 10) Section 7 says the document requires use of HTTPS, but other than in examples, this is the first reference to it. Should a sentence or small subsection be added about this somewhere earlier? 11) In Section 8.1, what are valid values for "Intended Usage"? 12) In Section 9.3, add a comma after "specified". 13) A general point: Should a small section be added someplace that refers to the bootstrap protocol, at least to give some hint as to where the query URL might come from? --001a11c239d0188bbe050314ba68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I'= ve reviewed this draft and it's in pretty good shape.=C2=A0 I have the = following suggestions for the authors to consider as we march toward IESG e= valuation.=C2=A0 I think the most critical stuff is some revisiting of the = RFC2119 language and a couple of definitions.

1) Some editoria= l suggestions for Section 1:

- add a space between "HTTP&= quot; and "[RFC7230]"

- "Registration Data Dire= ctory Services" (the capitalization) made me go look for a definition = for that term, which of course isn't there.=C2=A0 Should this be RDAP?= =C2=A0 Should a definition be added?=C2=A0 Should it just be de-capitalized= ?

- same thing happens in the same paragraph with "R= egistration Data" and "Directory Services" separately, thoug= h it looks like "Registration Data" is actually defined in the se= cond paragraph so maybe that text can just be moved to Definitions

- is there a definition of RESTful that could be included o= r referenced here?

- Suggest changing "This data is typic= ally provided" to either "These data area typically provided"= ; or "This information is typically provided" ("data" i= s actually plural)

- add a space between "GET" and &= quot;[RFC7231]"

- in the "basic usage pattern" = list, the first bullet shows an example query URL, but it ends with a perio= d that's not part of the query.=C2=A0 Might this be better separated ou= t, like with <figure><artwork>?

- in the second bu= llet, delete "standardized by the IETF"

- should the= third bullet reference the redirects draft?

- delete "It= is important to note that"

2) In Section 2, "consid= eration" should be "considerations".

3) In Sect= ion 4.1, there are instances of both "SHOULD" and "should&qu= ot;.=C2=A0 The second one might better be "is usually".

4) Again about Section 4.1, the definition of SHOULD allows for deviati= on from that advice when there's a good reason to do so.=C2=A0 Would it= be worth talking about other choices, and the impacts of using those optio= ns, and why one might choose them?

5) Section 5's "SH= OULD" has a similar issue.=C2=A0 Why would one choose not to understan= d the response codes?

6) The example in Section 5.2 might be b= etter done with <figure><artwork> so an actual example can be v= iewed.

7) Section 5.3 talks about an "empty set"= ;, but this sounds a bit wrong to me because an object can be undefined or = it can be defined but empty.=C2=A0 It sounds like we want to make it clear = that we're saying "I don't have that data" versus "I= have a record for that, but it's empty."

8) Section = 5.4 appears to suggest a client rejected for policy reasons can retry.=C2= =A0 Would it ever get a different result, unless the policy (or permissions= ) changed?

9) In Section 5.6, remove the comma from the second= paragraph.

10) Section 7 says the document requires use of HT= TPS, but other than in examples, this is the first reference to it.=C2=A0 S= hould a sentence or small subsection be added about this somewhere earlier?=

11) In Section 8.1, what are valid values for "Intended = Usage"?

12) In Section 9.3, add a comma after "speci= fied".

13) A general point: Should a small section be add= ed someplace that refers to the bootstrap protocol, at least to give some h= int as to where the query URL might come from?
--001a11c239d0188bbe050314ba68-- From nobody Sun Sep 14 23:51:57 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58461A06A7 for ; Sun, 14 Sep 2014 23:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDw8OTSSGAs4 for ; Sun, 14 Sep 2014 23:51:55 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE2D1A06A0 for ; Sun, 14 Sep 2014 23:51:54 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id pv20so3988321lab.36 for ; Sun, 14 Sep 2014 23:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2LiXEA7uiME5xsJ/TZ9ld2jqur16hr0sgJKdRLwWo2M=; b=C13kdynB4g23iQjyhz5CPCYM5Vs2eKpmTJngdeZOD93+Okao6/0BCFK/RqLfPaaTX2 YusQuyXuHNKFa7SO5Z+uK4Ms5NLFRnS8J7KGp11FFBLjUacVdyFiO3gzaRf712qQQRP/ Ci5vC3Soe4jPUXu2eGYKmvSL82sAvYB3GGYe2XyvsL5vJvc/B32Sh1msl6+22mCwgebh G4wBQvDwyqPFHxxJAPOoBKmC4RJd21PQ5RKCQeV0Eu2fVM/kjQNbcfxH7ScHI+vJRhua M99UaZJrwELlnZKjaEbL8V+7LxZc+GNKIqjdOxhZ/CIKWbOqq++CqsONoBC7eXYXvBPS La6g== MIME-Version: 1.0 X-Received: by 10.152.25.170 with SMTP id d10mr25354722lag.37.1410763913270; Sun, 14 Sep 2014 23:51:53 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Sun, 14 Sep 2014 23:51:53 -0700 (PDT) Date: Sun, 14 Sep 2014 23:51:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e0158b738e99cbc05031511f2 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/a4lZu4tZ3wADJv7w7rsqFm7Ox6s Subject: [weirds] Comments on draft-ietf-weirds-redirects X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 06:51:57 -0000 --089e0158b738e99cbc05031511f2 Content-Type: text/plain; charset=UTF-8 Hi again, I've reviewed this document. It appears to be incomplete, which pretty much means we need to finish it this week or abandon it. In addition to that concern, I have the following change suggestions for the WG to consider: 1) In the Abstract, I suggest removing the first three paragraphs. Summaries of why we're doing this work appear in some of the other documents already. 2) Also in the abstract, the last sentence needs spaces before the parentheses, and needs to end with a period. 3) In the Introduction, HTTP needs an RFC reference and should be expanded on first use. 4) Also in the Introduction, change "I-D" to "document", since it won't be an I-D for much longer. :-) 5) Section 1.3 has a "should" in it. Do we intend it as a SHOULD? If so, when would one choose to do something else? 6) Also in Section 1.3, we say "could provide". Could it do something else? Aren't we defining the intended way to do redirects here? 7) Section 1.4 appears to have two titles. Please delete one of them. 8) The first paragraph of Section 2.1 appears to be malformed or incomplete. What's "TBC"? 9) Also in Section 2.1, "AS" needs to be defined before it's used. 10) Also in Section 2.1, change "provide" to "provides". 11) Also in Section 2.1, might the example be best redone using RFC6890 address space? 12) Section 2.2 appears to be incomplete. Do you have planned text to add here? -MSK --089e0158b738e99cbc05031511f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi again,

I've reviewed this document.=C2=A0 I= t appears to be incomplete, which pretty much means we need to finish it th= is week or abandon it.=C2=A0 In addition to that concern, I have the follow= ing change suggestions for the WG to consider:

1) In the Abstr= act, I suggest removing the first three paragraphs.=C2=A0 Summaries of why = we're doing this work appear in some of the other documents already.
2) Also in the abstract, the last sentence needs spaces before t= he parentheses, and needs to end with a period.

3) In the Intr= oduction, HTTP needs an RFC reference and should be expanded on first use.<= br>
4) Also in the Introduction, change "I-D" to "d= ocument", since it won't be an I-D for much longer.=C2=A0 :-)
<= br>
5) Section 1.3 has a "should" in it.=C2=A0 Do we intend = it as a SHOULD?=C2=A0 If so, when would one choose to do something else?
6) Also in Section 1.3, we say "could provide".=C2=A0 = Could it do something else?=C2=A0 Aren't we defining the intended way t= o do redirects here?

7) Section 1.4 appears to have two titles= .=C2=A0 Please delete one of them.

8) The first paragraph of S= ection 2.1 appears to be malformed or incomplete.=C2=A0 What's "TB= C"?

9) Also in Section 2.1, "AS" needs to be de= fined before it's used.

10) Also in Section 2.1, change &q= uot;provide" to "provides".

11) Also in Section= 2.1, might the example be best redone using RFC6890 address space?

=
12) Section 2.2 appears to be incomplete.=C2=A0 Do you have planned t= ext to add here?

-MSK
--089e0158b738e99cbc05031511f2-- From nobody Mon Sep 15 00:03:34 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070DC1A06CA for ; Mon, 15 Sep 2014 00:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGtCwpN2vtvv for ; Mon, 15 Sep 2014 00:03:30 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66F41A06C1 for ; Mon, 15 Sep 2014 00:03:29 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id w7so3897909lbi.3 for ; Mon, 15 Sep 2014 00:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RsN3MW8OTTW/A7NOfuKBDMtmX55C1rWd4/3mld37J9g=; b=H5kOh/fZfiBuyv+J6iLrv6koIvYt20dRz42AVRpEDScrzJFvny0MdyVRJ0epybxDi0 inxEfrJ60Ht0NQrx+yBGmxfDcRe21cJ0Dz0esU88dr8QEGKHBSjj49gfMormiYCZZZzA KfGxtskJaHO5+pm+hqvHHmepkgeVYHV3p1MWLcMM56JyYep5ao1K2gCuwrjhuWeWLCd/ s1mvG7S8QWI3dOra2T9PgRlZ3+YB6qozBXbOwiaWH4j8MWrBH+AStxSKCjVnjcOl6BWQ Ns0Odc/sKkQZ9rMGqWjy6ECE54lxsQLv/Mfipd3y/q4B83LkGH4EgQIfr95mOIzak4PP 8KCw== MIME-Version: 1.0 X-Received: by 10.152.20.1 with SMTP id j1mr25736433lae.57.1410764607874; Mon, 15 Sep 2014 00:03:27 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 00:03:27 -0700 (PDT) Date: Mon, 15 Sep 2014 00:03:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e013d1d4c506c490503153bfe Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/c3rO129k-JQnJaQh4qfY7E5YnEc Subject: [weirds] Comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 07:03:32 -0000 --089e013d1d4c506c490503153bfe Content-Type: text/plain; charset=UTF-8 Hi, I've reviewed this draft. It looks pretty much ready to go. My only question is about Section 3.1.1 which talks about federated authentications. All of the 3.x sections except this one are of the form "RDAP needs to do X, so here's how you do X". This one describes federated authentication and says that an RDAP server might do it if it wants to, and lists a few ways to do so (OAuth, OpenID). I'm not totally familiar with these, so this might be a naive question: Is there any need for us to include a mechanism by which an RDAP server can be discovered to be part of such a federation? For example, should an RDAP client be able to contact, say, rdap.arin.net and discover that it's federated with LACNIC's server via an arrangement using OAuth? Or is that sort of thing arranged and discovered completely out of band? -MSK --089e013d1d4c506c490503153bfe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I've reviewed this dra= ft.=C2=A0 It looks pretty much ready to go.

My only question i= s about Section 3.1.1 which talks about federated authentications.=C2=A0 Al= l of the 3.x sections except this one are of the form "RDAP needs to d= o X, so here's how you do X".=C2=A0 This one describes federated a= uthentication and says that an RDAP server might do it if it wants to, and = lists a few ways to do so (OAuth, OpenID).=C2=A0 I'm not totally famili= ar with these, so this might be a naive question: Is there any need for us = to include a mechanism by which an RDAP server can be discovered to be part= of such a federation?=C2=A0 For example, should an RDAP client be able to = contact, say, rdap.arin.net and discov= er that it's federated with LACNIC's server via an arrangement usin= g OAuth?=C2=A0 Or is that sort of thing arranged and discovered completely = out of band?

-MSK
--089e013d1d4c506c490503153bfe-- From nobody Mon Sep 15 00:47:03 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C310A1A00FA for ; Mon, 15 Sep 2014 00:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LFKu1JvQq4t for ; Mon, 15 Sep 2014 00:47:00 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC441A00C6 for ; Mon, 15 Sep 2014 00:47:00 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id gq15so1486653lab.11 for ; Mon, 15 Sep 2014 00:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=maw8+jYH6lKtmlN/0Y8KiNk4eXd2OVBYdN9Te8FMl84=; b=yxvGBpw1Y0dm9urX7Rr7s+qwI1ZwtjJVy5/Ulfb6iUfsCLHL8DZAw7+Jk6i/k+DI2P L2+VUfl4r/s4U8+Q7YmtMWbBgJKYHH/DIj6SJr0A/hrAxRH3at9CeZKIdAihm7hG9bcS NbF9kQbzbkz4Hogopxz2tPgnYXnYEj2kZvDiNVqS9dfb5uzEq3eELUsCXEPHiljOOg/D oRjpq1NsYSDcFeAMhL62VibUkHSIyo6gQ30Y3fyBucVRjc2gkHW9jxQr0QTyx7hygnk2 txhARB0UTgD4MHxpBeFrE1vo8KmIoYJh4d7B1BtHYr+y2/ShZ+MmR82DIU1CI+0Yly6U lkRQ== MIME-Version: 1.0 X-Received: by 10.152.36.73 with SMTP id o9mr1110735laj.88.1410767215466; Mon, 15 Sep 2014 00:46:55 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 00:46:55 -0700 (PDT) Date: Mon, 15 Sep 2014 00:46:55 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e0160adf8bd1f60050315d6bf Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/AJjAKHH91Su4EbcBnLrCOKlvTx4 Subject: [weirds] Comments on draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 07:47:01 -0000 --089e0160adf8bd1f60050315d6bf Content-Type: text/plain; charset=UTF-8 Hi there, I've reviewed this draft. It looks pretty much ready to go. I have these editorial suggestions: 1) Are the bullet lists in Section 1.1 and 2 done with the usual xml2rfc mechanisms? The spacing seems to be unusual. 2) Section 2 includes a reference to NICNAME. Do we need to include a definition or reference for it? 3) The end of section 2 starts to tread into security stuff. Should there be a reference to draft-ietf-weirds-rdap-sec? 4) Section 3.1.3 has SHOULDs and SHOULD NOTs, but I'm wondering why they aren't MUSTs and MUST NOTs. Otherwise, under what conditions would one deviate from the advice, and in what way (i.e., what alternatives are there)? 5) Section 3.1.4, same thing. 6) In Section 3.1.5, indicate that the syntax of is specific to the registration provider. 7) Same question about the SHOULDs in Section 4. -MSK --089e0160adf8bd1f60050315d6bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi there,

I've reviewed this dr= aft.=C2=A0 It looks pretty much ready to go.=C2=A0 I have these editorial s= uggestions:

1) Are the bullet lists in Section 1.1 and 2 = done with the usual xml2rfc mechanisms?=C2=A0 The spacing seems to be unusu= al.

2) Section 2 includes a reference to NICNAME.=C2=A0 D= o we need to include a definition or reference for it?

3)= The end of section 2 starts to tread into security stuff.=C2=A0 Should the= re be a reference to draft-ietf-weirds-rdap-sec?

4) Secti= on 3.1.3 has SHOULDs and SHOULD NOTs, but I'm wondering why they aren&#= 39;t MUSTs and MUST NOTs.=C2=A0 Otherwise, under what conditions would one = deviate from the advice, and in what way (i.e., what alternatives are there= )?

5) Section 3.1.4, same thing.

6) In = Section 3.1.5, indicate that the syntax of <handle> is specific to th= e registration provider.

7) Same question about the SHOUL= Ds in Section 4.

-MSK
--089e0160adf8bd1f60050315d6bf-- From nobody Mon Sep 15 05:54:57 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164261A0324 for ; Mon, 15 Sep 2014 05:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5h5CLqWxNzY for ; Mon, 15 Sep 2014 05:54:53 -0700 (PDT) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEFA1A0328 for ; Mon, 15 Sep 2014 05:54:51 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKVBbhl/cJZ+0cCgqrc1oQh/TAKYydaHna@postini.com; Mon, 15 Sep 2014 05:54:52 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s8FCsjax001641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Sep 2014 08:54:45 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 15 Sep 2014 08:54:44 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-rdap-sec Thread-Index: AQHP0LMs9mffhQfSuEKo2FUQtmUMW5wCJZJg Date: Mon, 15 Sep 2014 12:54:43 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494B36B4@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_831693C2CDA2E849A7D7A712B24E257F494B36B4BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/JH3F8J5bp4LHyFzgWHdBmEVlUZs Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 12:54:55 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F494B36B4BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogd2VpcmRzIFttYWlsdG86d2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAxNSwgMjAxNCAz OjAzIEFNDQpUbzogd2VpcmRzQGlldGYub3JnDQpTdWJqZWN0OiBbd2VpcmRzXSBDb21tZW50cyBv biBkcmFmdC1pZXRmLXdlaXJkcy1yZGFwLXNlYw0KDQpIaSwNCkkndmUgcmV2aWV3ZWQgdGhpcyBk cmFmdC4gIEl0IGxvb2tzIHByZXR0eSBtdWNoIHJlYWR5IHRvIGdvLg0KTXkgb25seSBxdWVzdGlv biBpcyBhYm91dCBTZWN0aW9uIDMuMS4xIHdoaWNoIHRhbGtzIGFib3V0IGZlZGVyYXRlZCBhdXRo ZW50aWNhdGlvbnMuICBBbGwgb2YgdGhlIDMueCBzZWN0aW9ucyBleGNlcHQgdGhpcyBvbmUgYXJl IG9mIHRoZSBmb3JtICJSREFQIG5lZWRzIHRvIGRvIFgsIHNvIGhlcmUncyBob3cgeW91IGRvIFgi LiAgVGhpcyBvbmUgZGVzY3JpYmVzIGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiBhbmQgc2F5cyB0 aGF0IGFuIFJEQVAgc2VydmVyIG1pZ2h0IGRvIGl0IGlmIGl0IHdhbnRzIHRvLCBhbmQgbGlzdHMg YSBmZXcgd2F5cyB0byBkbyBzbyAoT0F1dGgsIE9wZW5JRCkuICBJJ20gbm90IHRvdGFsbHkgZmFt aWxpYXIgd2l0aCB0aGVzZSwgc28gdGhpcyBtaWdodCBiZSBhIG5haXZlIHF1ZXN0aW9uOiBJcyB0 aGVyZSBhbnkgbmVlZCBmb3IgdXMgdG8gaW5jbHVkZSBhIG1lY2hhbmlzbSBieSB3aGljaCBhbiBS REFQIHNlcnZlciBjYW4gYmUgZGlzY292ZXJlZCB0byBiZSBwYXJ0IG9mIHN1Y2ggYSBmZWRlcmF0 aW9uPyAgRm9yIGV4YW1wbGUsIHNob3VsZCBhbiBSREFQIGNsaWVudCBiZSBhYmxlIHRvIGNvbnRh Y3QsIHNheSwgcmRhcC5hcmluLm5ldDxodHRwOi8vcmRhcC5hcmluLm5ldD4gYW5kIGRpc2NvdmVy IHRoYXQgaXQncyBmZWRlcmF0ZWQgd2l0aCBMQUNOSUMncyBzZXJ2ZXIgdmlhIGFuIGFycmFuZ2Vt ZW50IHVzaW5nIE9BdXRoPyAgT3IgaXMgdGhhdCBzb3J0IG9mIHRoaW5nIGFycmFuZ2VkIGFuZCBk aXNjb3ZlcmVkIGNvbXBsZXRlbHkgb3V0IG9mIGJhbmQ/DQpbU0FIXSAgSeKAmW0gbm90IGZhbWls aWFyIGVub3VnaCB3aXRoIGF1dG9tYXRlZCBzZXJ2aWNlIGRpc2NvdmVyeSB0byBzYXkgZm9yIHN1 cmUsIGJ1dCB0aGUgc2VhcmNoaW5nIEkgZGlkIHJpZ2h0IG5vdyBzZWVtcyB0byBpbXBseSB0aGF0 IG1hbnVhbCBzdGVwcyBhcmUgcmVxdWlyZWQuIFRoZSBPQXV0aCAyLjAgYXV0aG9yaXphdGlvbiBm cmFtZXdvcmsgc3BlY2lmaWVkIGluIFJGQyA2NzQ5IHNheXMgdGhhdCDigJx0aGlzIHNwZWNpZmlj YXRpb24gbGVhdmVzIGEgZmV3IHJlcXVpcmVkIGNvbXBvbmVudHMgcGFydGlhbGx5IG9yIGZ1bGx5 IHVuZGVmaW5lZCAoZS5nLiwgY2xpZW50IHJlZ2lzdHJhdGlvbiwgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgY2FwYWJpbGl0aWVzLCBlbmRwb2ludCBkaXNjb3Zlcnkp4oCdLiBOaW5nLCB5b3Ugd2VyZSB0 aGUgcHJvcG9uZW50IGZvciBhZGRpbmcgdGhpcyBzZWN0aW9uLiBDYW4geW91IGFuc3dlciBNdXJy YXnigJlzIHF1ZXN0aW9uIGRlZmluaXRpdmVseT8NCg0KU2NvdHQNCg== --_000_831693C2CDA2E849A7D7A712B24E257F494B36B4BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gd2VpcmRzIFttYWlsdG86d2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPk11cnJheSBTLiBLdWNoZXJhd3k8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBT ZXB0ZW1iZXIgMTUsIDIwMTQgMzowMyBBTTxicj4NCjxiPlRvOjwvYj4gd2VpcmRzQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFt3ZWlyZHNdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtd2Vp cmRzLXJkYXAtc2VjPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+SGksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2ZSByZXZpZXdlZCB0aGlzIGRyYWZ0LiZuYnNwOyBJ dCBsb29rcyBwcmV0dHkgbXVjaCByZWFkeSB0byBnby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NeSBvbmx5 IHF1ZXN0aW9uIGlzIGFib3V0IFNlY3Rpb24gMy4xLjEgd2hpY2ggdGFsa3MgYWJvdXQgZmVkZXJh dGVkIGF1dGhlbnRpY2F0aW9ucy4mbmJzcDsgQWxsIG9mIHRoZSAzLnggc2VjdGlvbnMgZXhjZXB0 IHRoaXMgb25lIGFyZSBvZiB0aGUgZm9ybSAmcXVvdDtSREFQIG5lZWRzIHRvIGRvIFgsIHNvIGhl cmUncyBob3cgeW91IGRvIFgmcXVvdDsuJm5ic3A7IFRoaXMgb25lIGRlc2NyaWJlcw0KIGZlZGVy YXRlZCBhdXRoZW50aWNhdGlvbiBhbmQgc2F5cyB0aGF0IGFuIFJEQVAgc2VydmVyIG1pZ2h0IGRv IGl0IGlmIGl0IHdhbnRzIHRvLCBhbmQgbGlzdHMgYSBmZXcgd2F5cyB0byBkbyBzbyAoT0F1dGgs IE9wZW5JRCkuJm5ic3A7IEknbSBub3QgdG90YWxseSBmYW1pbGlhciB3aXRoIHRoZXNlLCBzbyB0 aGlzIG1pZ2h0IGJlIGEgbmFpdmUgcXVlc3Rpb246IElzIHRoZXJlIGFueSBuZWVkIGZvciB1cyB0 byBpbmNsdWRlIGEgbWVjaGFuaXNtIGJ5IHdoaWNoDQogYW4gUkRBUCBzZXJ2ZXIgY2FuIGJlIGRp c2NvdmVyZWQgdG8gYmUgcGFydCBvZiBzdWNoIGEgZmVkZXJhdGlvbj8mbmJzcDsgRm9yIGV4YW1w bGUsIHNob3VsZCBhbiBSREFQIGNsaWVudCBiZSBhYmxlIHRvIGNvbnRhY3QsIHNheSwNCjxhIGhy ZWY9Imh0dHA6Ly9yZGFwLmFyaW4ubmV0Ij5yZGFwLmFyaW4ubmV0PC9hPiBhbmQgZGlzY292ZXIg dGhhdCBpdCdzIGZlZGVyYXRlZCB3aXRoIExBQ05JQydzIHNlcnZlciB2aWEgYW4gYXJyYW5nZW1l bnQgdXNpbmcgT0F1dGg/Jm5ic3A7IE9yIGlzIHRoYXQgc29ydCBvZiB0aGluZyBhcnJhbmdlZCBh bmQgZGlzY292ZXJlZCBjb21wbGV0ZWx5IG91dCBvZiBiYW5kPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltTQUhd ICZuYnNwO0nigJltIG5vdCBmYW1pbGlhciBlbm91Z2ggd2l0aCBhdXRvbWF0ZWQgc2VydmljZSBk aXNjb3ZlcnkgdG8gc2F5IGZvciBzdXJlLCBidXQgdGhlIHNlYXJjaGluZyBJIGRpZCByaWdodCBu b3cgc2VlbXMgdG8gaW1wbHkgdGhhdCBtYW51YWwgc3RlcHMgYXJlIHJlcXVpcmVkLiBUaGUgT0F1 dGggMi4wDQogYXV0aG9yaXphdGlvbiBmcmFtZXdvcmsgc3BlY2lmaWVkIGluIFJGQyA2NzQ5IHNh eXMgdGhhdCDigJx0aGlzIHNwZWNpZmljYXRpb24gbGVhdmVzIGEgZmV3IHJlcXVpcmVkIGNvbXBv bmVudHMgcGFydGlhbGx5IG9yIGZ1bGx5IHVuZGVmaW5lZCAoZS5nLiwgY2xpZW50IHJlZ2lzdHJh dGlvbiwgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY2FwYWJpbGl0aWVzLCBlbmRwb2ludCBkaXNjb3Zl cnkp4oCdLiBOaW5nLCB5b3Ugd2VyZSB0aGUgcHJvcG9uZW50IGZvcg0KIGFkZGluZyB0aGlzIHNl Y3Rpb24uIENhbiB5b3UgYW5zd2VyIE11cnJheeKAmXMgcXVlc3Rpb24gZGVmaW5pdGl2ZWx5Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TY290dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_831693C2CDA2E849A7D7A712B24E257F494B36B4BRN1WNEXMBX01vc_-- From nobody Mon Sep 15 06:19:50 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5311A034D for ; Mon, 15 Sep 2014 06:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCSSXfsYGhv3 for ; Mon, 15 Sep 2014 06:19:41 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40D71A0340 for ; Mon, 15 Sep 2014 06:19:39 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKVBbna04SnIQfXl/I+CC5BU/eKXHdh+PI@postini.com; Mon, 15 Sep 2014 06:19:40 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 s8FDJcAT030895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Sep 2014 09:19:38 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 15 Sep 2014 09:19:38 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-rdap-query Thread-Index: AQHP0Lk+Zd29w+nKZkOWiwF8Nb9RpJwCK7cQ Date: Mon, 15 Sep 2014 13:19:38 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494B3727@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_831693C2CDA2E849A7D7A712B24E257F494B3727BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/gq_0vzD-bPQJ7rXfcTRb8_E_aBY Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 13:19:47 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F494B3727BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogd2VpcmRzIFttYWlsdG86d2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAxNSwgMjAxNCAz OjQ3IEFNDQpUbzogd2VpcmRzQGlldGYub3JnDQpTdWJqZWN0OiBbd2VpcmRzXSBDb21tZW50cyBv biBkcmFmdC1pZXRmLXdlaXJkcy1yZGFwLXF1ZXJ5DQoNCkhpIHRoZXJlLA0KSSd2ZSByZXZpZXdl ZCB0aGlzIGRyYWZ0LiAgSXQgbG9va3MgcHJldHR5IG11Y2ggcmVhZHkgdG8gZ28uICBJIGhhdmUg dGhlc2UgZWRpdG9yaWFsIHN1Z2dlc3Rpb25zOg0KMSkgQXJlIHRoZSBidWxsZXQgbGlzdHMgaW4g U2VjdGlvbiAxLjEgYW5kIDIgZG9uZSB3aXRoIHRoZSB1c3VhbCB4bWwycmZjIG1lY2hhbmlzbXM/ ICBUaGUgc3BhY2luZyBzZWVtcyB0byBiZSB1bnVzdWFsLg0KW1NBSF0gWWVzLCBsaXN0IHN0eWxl PSJoYW5naW5nIi4NCjIpIFNlY3Rpb24gMiBpbmNsdWRlcyBhIHJlZmVyZW5jZSB0byBOSUNOQU1F LiAgRG8gd2UgbmVlZCB0byBpbmNsdWRlIGEgZGVmaW5pdGlvbiBvciByZWZlcmVuY2UgZm9yIGl0 Pw0KW1NBSF0gTklDTkFNRSBhbmQgV0hPSVMgYXJlIHJlYWxseSB0aGUgc2FtZSB0aGluZyBwZXIg UkZDIDk1NC4gV2Ugc2hvdWxkIGVpdGhlciBhZGQgTklDTkFNRSB0byB0aGUgZmlyc3QgdXNlIG9m IFdIT0lTIG9yIGRyb3AgaXQgZnJvbSBTZWN0aW9uIDIgc2luY2Ugd2UgY2l0ZSBSRkMgMzkxMiBh cyBhIHJlZmVyZW5jZSwgYW5kIDM5MTIgZG9lc27igJl0IHVzZSBOSUNOQU1FLiBJ4oCZZCBwcmVm ZXIgdG8gZHJvcCB1c2Ugb2YgTklDTkFNRS4NCjMpIFRoZSBlbmQgb2Ygc2VjdGlvbiAyIHN0YXJ0 cyB0byB0cmVhZCBpbnRvIHNlY3VyaXR5IHN0dWZmLiAgU2hvdWxkIHRoZXJlIGJlIGEgcmVmZXJl bmNlIHRvIGRyYWZ0LWlldGYtd2VpcmRzLXJkYXAtc2VjPw0KW1NBSF0gWWVzLCB0aGF0IHdvdWxk IGJlIGFwcHJvcHJpYXRlLg0KNCkgU2VjdGlvbiAzLjEuMyBoYXMgU0hPVUxEcyBhbmQgU0hPVUxE IE5PVHMsIGJ1dCBJJ20gd29uZGVyaW5nIHdoeSB0aGV5IGFyZW4ndCBNVVNUcyBhbmQgTVVTVCBO T1RzLiAgT3RoZXJ3aXNlLCB1bmRlciB3aGF0IGNvbmRpdGlvbnMgd291bGQgb25lIGRldmlhdGUg ZnJvbSB0aGUgYWR2aWNlLCBhbmQgaW4gd2hhdCB3YXkgKGkuZS4sIHdoYXQgYWx0ZXJuYXRpdmVz IGFyZSB0aGVyZSk/DQo1KSBTZWN0aW9uIDMuMS40LCBzYW1lIHRoaW5nLg0KW1NBSF0gVGhleeKA mXJlIFNIT1VMRHMgYW5kIFNIT1VMRCBOT1RzIGJlY2F1c2UgdGhlIHBlb3BsZSB0aGF0IHN1Z2dl c3RlZCB0aGF0IHRleHQgd3JvdGUgaXQgdGhhdCB3YXkg4pi6LiBQZXJoYXBzIEFuZHJldyBTdWxs aXZhbiBjYW4gZXhwbGFpbiB0aGUgZGV2aWF0aW9uIGNvbmRpdGlvbnMgaWYgdGhleSBleGlzdC4N CjYpIEluIFNlY3Rpb24gMy4xLjUsIGluZGljYXRlIHRoYXQgdGhlIHN5bnRheCBvZiA8aGFuZGxl PiBpcyBzcGVjaWZpYyB0byB0aGUgcmVnaXN0cmF0aW9uIHByb3ZpZGVyLg0KW1NBSF0gT0suDQo3 KSBTYW1lIHF1ZXN0aW9uIGFib3V0IHRoZSBTSE9VTERzIGluIFNlY3Rpb24gNC4NCg0KLU1TSw0K --_000_831693C2CDA2E849A7D7A712B24E257F494B3727BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsNCglm b250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHdlaXJkcyBbbWFpbHRvOndlaXJkcy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NdXJyYXkgUy4gS3VjaGVyYXd5 PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgU2VwdGVtYmVyIDE1LCAyMDE0IDM6NDcgQU08YnI+ DQo8Yj5Ubzo8L2I+IHdlaXJkc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbd2VpcmRz XSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXdlaXJkcy1yZGFwLXF1ZXJ5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSB0aGVyZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JJ3Zl IHJldmlld2VkIHRoaXMgZHJhZnQuJm5ic3A7IEl0IGxvb2tzIHByZXR0eSBtdWNoIHJlYWR5IHRv IGdvLiZuYnNwOyBJIGhhdmUgdGhlc2UgZWRpdG9yaWFsIHN1Z2dlc3Rpb25zOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij4xKSBBcmUgdGhlIGJ1bGxldCBsaXN0cyBpbiBTZWN0aW9uIDEuMSBhbmQg MiBkb25lIHdpdGggdGhlIHVzdWFsIHhtbDJyZmMgbWVjaGFuaXNtcz8mbmJzcDsgVGhlIHNwYWNp bmcgc2VlbXMgdG8gYmUgdW51c3VhbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPltTQUhdIFllcywgbGlzdCBzdHlsZT0mcXVvdDtoYW5naW5nJnF1b3Q7LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+MikgU2VjdGlvbiAyIGluY2x1ZGVzIGEgcmVmZXJlbmNlIHRv IE5JQ05BTUUuJm5ic3A7IERvIHdlIG5lZWQgdG8gaW5jbHVkZSBhIGRlZmluaXRpb24gb3IgcmVm ZXJlbmNlIGZvciBpdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bU0FIXSBO SUNOQU1FIGFuZCBXSE9JUyBhcmUgcmVhbGx5IHRoZSBzYW1lIHRoaW5nIHBlciBSRkMgOTU0LiBX ZSBzaG91bGQgZWl0aGVyIGFkZCBOSUNOQU1FIHRvIHRoZSBmaXJzdCB1c2Ugb2YgV0hPSVMgb3Ig ZHJvcCBpdCBmcm9tIFNlY3Rpb24gMg0KIHNpbmNlIHdlIGNpdGUgUkZDIDM5MTIgYXMgYSByZWZl cmVuY2UsIGFuZCAzOTEyIGRvZXNu4oCZdCB1c2UgTklDTkFNRS4gSeKAmWQgcHJlZmVyIHRvIGRy b3AgdXNlIG9mIE5JQ05BTUUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4zKSBUaGUg ZW5kIG9mIHNlY3Rpb24gMiBzdGFydHMgdG8gdHJlYWQgaW50byBzZWN1cml0eSBzdHVmZi4mbmJz cDsgU2hvdWxkIHRoZXJlIGJlIGEgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtd2VpcmRzLXJkYXAt c2VjPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltTQUhdIFllcywgdGhhdCB3 b3VsZCBiZSBhcHByb3ByaWF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjQpIFNl Y3Rpb24gMy4xLjMgaGFzIFNIT1VMRHMgYW5kIFNIT1VMRCBOT1RzLCBidXQgSSdtIHdvbmRlcmlu ZyB3aHkgdGhleSBhcmVuJ3QgTVVTVHMgYW5kIE1VU1QgTk9Ucy4mbmJzcDsgT3RoZXJ3aXNlLCB1 bmRlciB3aGF0IGNvbmRpdGlvbnMgd291bGQgb25lIGRldmlhdGUgZnJvbSB0aGUgYWR2aWNlLCBh bmQgaW4gd2hhdCB3YXkgKGkuZS4sIHdoYXQgYWx0ZXJuYXRpdmVzDQogYXJlIHRoZXJlKT88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+NSkgU2VjdGlvbiAzLjEuNCwgc2FtZSB0aGluZy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bU0FIXSBUaGV54oCZcmUgU0hPVUxEcyBhbmQg U0hPVUxEIE5PVHMgYmVjYXVzZSB0aGUgcGVvcGxlIHRoYXQgc3VnZ2VzdGVkIHRoYXQgdGV4dCB3 cm90ZSBpdCB0aGF0IHdheQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGlu Z3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi4gUGVy aGFwcyBBbmRyZXcgU3VsbGl2YW4gY2FuIGV4cGxhaW4gdGhlIGRldmlhdGlvbiBjb25kaXRpb25z IGlmIHRoZXkgZXhpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij42KSBJbiBTZWN0 aW9uIDMuMS41LCBpbmRpY2F0ZSB0aGF0IHRoZSBzeW50YXggb2YgJmx0O2hhbmRsZSZndDsgaXMg c3BlY2lmaWMgdG8gdGhlIHJlZ2lzdHJhdGlvbiBwcm92aWRlci48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bU0FIXSBPSy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj43KSBTYW1lIHF1ZXN0aW9uIGFib3V0IHRoZSBT SE9VTERzIGluIFNlY3Rpb24gNC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tTVNLPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_831693C2CDA2E849A7D7A712B24E257F494B3727BRN1WNEXMBX01vc_-- From nobody Mon Sep 15 10:52:57 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F91A1A8546 for ; Mon, 15 Sep 2014 10:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwUSs2DENyHf for ; Mon, 15 Sep 2014 10:52:53 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4FC1A888F for ; Mon, 15 Sep 2014 10:08:50 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id pv20so5037701lab.8 for ; Mon, 15 Sep 2014 10:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DpuM/T+ajgkZdSRCOiY8uh6V8s6zRSFLu8un66pjnR0=; b=L6OaMVnzbf12JBiTVwA03Qn55Jja/zcfip+9VWLUtwF1vu9KvelxLRPr9sWhEFd+Sg eDT5GFtpME+smyaz+Kd26c/weBQpxQcOvQScWvdh5PGTYpFWJbAEK+UcWQ5EDqBl37+p RExbuX8TaB+GqBPARF1Y0Ipw6JPB4s/+2F3j8xbRgRnGtB7Nzr94SarAxZ82A8F9Swo0 0Hp8qvjb7UWqlIGr6M8iCp2MzaE0D24pryrm5zhtaHMaMADL6XdDN0gDwIoCrABlLbSu 5vnQyCJq+xvvvqAMoz3JnNDjjADHf/sDVDaoH7XV/2YD79ZI9AyxCiB0TyDf4ulD2Prm 6ydw== MIME-Version: 1.0 X-Received: by 10.152.43.50 with SMTP id t18mr29826325lal.25.1410800926962; Mon, 15 Sep 2014 10:08:46 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 10:08:46 -0700 (PDT) Date: Mon, 15 Sep 2014 10:08:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c239d019ba0605031db0a3 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/vsHULXgRGEw9x5gxHtCx1AOOXPQ Subject: [weirds] WGLC reviews X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 17:52:56 -0000 --001a11c239d019ba0605031db0a3 Content-Type: text/plain; charset=UTF-8 Colleagues, The open WGLCs on all documents end this coming Friday evening. I'm concerned that we've only seen reviews from myself and Tom Harrison. Is anyone else planning to do some? If not, I'm concerned about being able to represent to the IESG that these documents actually have consensus within the WG, which is of course required for us to proceed on our timeline. -MSK --001a11c239d019ba0605031db0a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The open WGLCs on all documents en= d this coming Friday evening.=C2=A0 I'm concerned that we've only s= een reviews from myself and Tom Harrison.

Is anyone else planning to= do some?

If not, I'm concerned about being able to represent to= the IESG that these documents actually have consensus within the WG, which= is of course required for us to proceed on our timeline.

-MSK=
--001a11c239d019ba0605031db0a3-- From nobody Mon Sep 15 11:31:15 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FD61A0383 for ; Mon, 15 Sep 2014 11:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MP5cX10GiXx for ; Mon, 15 Sep 2014 11:31:10 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67861A2130 for ; Mon, 15 Sep 2014 10:57:55 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id b12so4976466lbj.11 for ; Mon, 15 Sep 2014 10:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qHGPLlp6h8zEeLMr+VqjfS3VSpq/TsY6pFEHdn1GxdY=; b=pPKnqBvl95Jjj91BGpPzobw8uZncY8JWcxfEmLjXn60KiStCUZW6C6Q3iSL6z2yfw8 eucwHxpjH0A8h5UuwNcMQB5GExYuFvE7ildavNBBLYc0HxNacOEPzfXVeiEwQog/dm27 KYIWO9o56Ez/N7gx1m8ar8B1kYfQFSw4ogU5VUzDbhsYfaW02Xa2UQBJs57RA4YmDfk/ 8jMKbJsaI7x0gjiJNtUpEpJn4q1jLoqRB8gXzylnzX4G77qCVwmeIDkV/g8BTNjGpUcZ JEDFF2agK29x1TWGWBUc82VJuEPoEhkuuVD3Srj7ofQAksAesbTqRvitg8KNfN/nMpOT WhMw== MIME-Version: 1.0 X-Received: by 10.152.7.212 with SMTP id l20mr30528192laa.7.1410803869865; Mon, 15 Sep 2014 10:57:49 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 10:57:49 -0700 (PDT) Date: Mon, 15 Sep 2014 10:57:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c34a0a82de7d05031e5f6c Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/YVIHq1sF1BjpQ9cmg2ZXOTgygGg Subject: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 18:31:14 -0000 --001a11c34a0a82de7d05031e5f6c Content-Type: text/plain; charset=UTF-8 Hi, I've reviewed this draft. It's definitely on the right track and close to being ready, but there are a few things that need to be reviewed (especially Section 11) plus several editorial suggestions below. 1) In Section 1: - add a space before "(RDAP)" - s/request IANA/requests of IANA/ - s/extract/extracts/ - s/do a match/does a match/ 2) In Section 3: - s/version id identified/version identifier represented/ - s/defaults values/default values/ - s/Then the "services" element is/There exists a "services" element, which is/ 3) Also in Section 3, I would not be surprised if we were asked for ABNF describing this. I had to do this for RFC7071 as well, so you might find Section 6.2 helpful. 4) Also in Section 3, rather than requiring that all base URLs end in "/", couldn't the client just add one if it's missing in the bootstrap object? I'm wondering why that MUST is needed. 5) Also in Section 3, the SHOULD about ordering suggests to me that we ought to at least explain why the ordering is important. Does that mean clients are to try them in the order given, and we say SHOULD because HTTPS is preferred? Under what conditions might one legitimately deviate from the SHOULD? Would it not be better to simply have clients prefer secure protocols over insecure ones, in which case ordering doesn't matter? What about the idea of using URLs randomly to spread load in the same way the DNS returns randomized answers? 6) Also in Section 3, why do we MUST things into lowercase in the registry? Isn't it easier to require resolvers to treat them that way (which DNS resolvers already do)? 7) In Section 4, isn't the matching not only longest and right-justified, and ending at a label boundary? That is, for a successful match, the character right before the matching substring needs to be a dot as well, or maybe even start-of-string. 8) Also in Section 4, I would say something about how b.example.com, if present, would supersede the values found in example.com, when looking up a.b.example.com. 9) Also in Section 4, suggest dropping "This example is not normative." Same Sections 5.1, 5.2, and 5.3. (Are examples ever normative?) 10) In Section 5, I'm a little puzzled by the use of "longest match". I think it's right, but we might want to add parenthetically that we're actually looking to match the largest number of network bits. Otherwise, I'm a little fuzzy on what "longest" might mean because IP addresses are all the same size (within the same family). 11) In Section 8, suggest the following changes: - s/such as HTTP Expires/such as the HTTP Expires/ - delete "to be RDAP queried" - s/no more current/no longer current/ - s/a RDAP aggregator/an RDAP aggregator/ - delete "This specification does not assume while not prohibiting how"; what's left is fine - s/garantee/guarantee/ - s/rdap/RDAP/ - s/garanteed/guaranteed/ 12) In Section 9, suggest deleting "for" from the beginning of each bullet. 13) In Section 10: - s/helps making sure/helps to ensure/ - s/from authoritative source/from an authoritative source/ - s/The method itself/The method/ 14) Section 11 still needs some work, as we discussed offline. One of the main things I believe it needs is to have each of the registries described in its own subsection; in particular, each needs to have a name and description given to the rows that would be needed to produce the JSON that RDAP needs. For example: 11.1. IPv4 Address Space RDAP Registry IANA is requested to create the IPv4 Address Space RDAP Registry. Entries in this registry contain at least the following fields: o A CIDR [reference to definition of CIDR] specification for the network block being registered o One or more URLs that provide RDAP service regarding this registration. HTTPS URIs are to appear first in the list. (Or if order doesn't really matter to IANA, don't say that.) [then copy the text about registry population that you already have] [then copy the text about exporting it in JSON] 15) Also in Section 11, delete "such as XML" (two instances). 16) In Section 12, capitalize "WEIRDS". -MSK --001a11c34a0a82de7d05031e5f6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I've reviewed this draft.= =C2=A0 It's definitely on the right track and close to being ready, but= there are a few things that need to be reviewed (especially Section 11) pl= us several editorial suggestions below.

1) In Section 1:<= br>
- add a space before "(RDAP)"
- s= /request IANA/requests of IANA/
- s/extract/extracts/
- s/do a match/does a match/

2) In Section 3:
<= br>
- s/version id identified/version identifier represented/
=
- s/defaults values/default values/
- s/Then the &= quot;services" element is/There exists a "services" element,= which is/

3) Also in Section 3, I would not be surprised= if we were asked for ABNF describing this.=C2=A0 I had to do this for RFC7= 071 as well, so you might find Section 6.2 helpful.

4) Al= so in Section 3, rather than requiring that all base URLs end in "/&qu= ot;, couldn't the client just add one if it's missing in the bootst= rap object?=C2=A0 I'm wondering why that MUST is needed.

<= div>5) Also in Section 3, the SHOULD about ordering suggests to me that we = ought to at least explain why the ordering is important.=C2=A0 Does that me= an clients are to try them in the order given, and we say SHOULD because HT= TPS is preferred?=C2=A0 Under what conditions might one legitimately deviat= e from the SHOULD?=C2=A0 Would it not be better to simply have clients pref= er secure protocols over insecure ones, in which case ordering doesn't = matter?=C2=A0 What about the idea of using URLs randomly to spread load in = the same way the DNS returns randomized answers?

6) Also in Section 3, why do we MUST things into lowercase in the regist= ry?=C2=A0 Isn't it easier to require resolvers to treat them that way (= which DNS resolvers already do)?

7) In Section= 4, isn't the matching not only longest and right-justified, and ending= at a label boundary?=C2=A0 That is, for a successful match, the character = right before the matching substring needs to be a dot as well, or maybe eve= n start-of-string.

8) Also in Section 4, I would say some= thing about how b.example.com, if pres= ent, would supersede the values found in exa= mple.com, when looking up a.b.exampl= e.com.

9) Also in Section 4, suggest dropping "T= his example is not normative."=C2=A0 Same Sections 5.1, 5.2, and 5.3.= =C2=A0 (Are examples ever normative?)

10) In Section 5, I= 'm a little puzzled by the use of "longest match".=C2=A0 I th= ink it's right, but we might want to add parenthetically that we're= actually looking to match the largest number of network bits.=C2=A0 Otherw= ise, I'm a little fuzzy on what "longest" might mean because = IP addresses are all the same size (within the same family).

<= div>11) In Section 8, suggest the following changes:

- s/such as HTT= P Expires/such as the HTTP Expires/
- delete "to be RDAP= queried"
- s/no more current/no longer current/
- s/a RDAP aggregator/an RDAP aggregator/
- delete &qu= ot;This specification does not assume while not prohibiting how"; what= 's left is fine
- s/garantee/guarantee/
- s= /rdap/RDAP/
- s/garanteed/guaranteed/

12) In Section 9, suggest deleting "for" from the beginning= of each bullet.

13) In Section 10:

- s/helps maki= ng sure/helps to ensure/
- s/from authoritative source/from a= n authoritative source/
- s/The method itself/The method/
=
14) Section 11 still needs some work, as we discussed offlin= e.=C2=A0 One of the main things I believe it needs is to have each of the r= egistries described in its own subsection; in particular, each needs to hav= e a name and description given to the rows that would be needed to produce = the JSON that RDAP needs.=C2=A0 For example:

11.1.=C2=A0 = IPv4 Address Space RDAP Registry

IANA is requested to cre= ate the IPv4 Address Space RDAP Registry.

Entries in this= registry contain at least the following fields:

o A CIDR= [reference to definition of CIDR] specification for the network block bein= g registered
o One or more URLs that provide RDAP service reg= arding this registration.=C2=A0 HTTPS URIs are to appear first in the list.= =C2=A0 (Or if order doesn't really matter to IANA, don't say that.)=

[then copy the text about registry population that you a= lready have]

[then copy the text about exporting it in JS= ON]

15) Also in Section 11, delete "such = as XML" (two instances).

16) In Section 12, capitali= ze "WEIRDS".

-MSK

--001a11c34a0a82de7d05031e5f6c-- From nobody Mon Sep 15 13:03:25 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF30A1A6F2E for ; Mon, 15 Sep 2014 13:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntinbWuwkRsO for ; Mon, 15 Sep 2014 13:03:22 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D151A6EDB for ; Mon, 15 Sep 2014 13:03:21 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id ft15so6897251pdb.32 for ; Mon, 15 Sep 2014 13:03:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wXqvkhxJKHDHflGx0wW2HLbmYaqMlSo8Y0Kbd5UP1hU=; b=A4uKpY5/WoQRqwRkMAHzgBsljlIk2GeVFCdYCTEz2cgRBVnRNenKeT44zJZ3mltFKa DElHhE7WvECsaGOmYJ7xRslTubZuVjld7e6sXBCBGMLyJv1+7j9s+HZcRgISdjEdPrDg 10SZhZWWp6Oej3NL1LhhF5sHVbrvpIoo0PJdnA1ukR1JuD9bhv54eg9x9ApA+Yv0McN+ IjMzvAKMtkjNo/eZQLW9jrXigJ6qgHtuiZJDnJ0TRTkXjM0Kg73JqBIjEW99vNuMAsIa 4a2naDxiN0M1GevwFNk67lBYD1Law1Y1cZh4xJvd1Cu9MXrhaYb9kkCcEYAmd8kQ9qWp D7Rg== X-Gm-Message-State: ALoCoQmGszBemBqX6IKat6IkLH+Df/g7Pw1k28FHRCmlTzoDhZ6iznRrD8a9cmp2QJ2dATBmsqWg MIME-Version: 1.0 X-Received: by 10.66.233.226 with SMTP id tz2mr42217004pac.94.1410811401570; Mon, 15 Sep 2014 13:03:21 -0700 (PDT) Received: by 10.66.159.3 with HTTP; Mon, 15 Sep 2014 13:03:21 -0700 (PDT) X-Originating-IP: [2001:500:4:15:f24d:a2ff:fe31:a268] In-Reply-To: References: Date: Mon, 15 Sep 2014 16:03:21 -0400 Message-ID: From: Andrew Newton To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/GmxRyepyeAkmUhr4ip_hb9-WzSo Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:03:24 -0000 On Mon, Sep 15, 2014 at 2:27 AM, Murray S. Kucherawy wrote: > Hi, > > - is there a definition of RESTful that could be included or referenced > here? My understanding is NO. > 10) Section 7 says the document requires use of HTTPS, but other than in > examples, this is the first reference to it. Should a sentence or small > subsection be added about this somewhere earlier? It requires implementation, not use. > 13) A general point: Should a small section be added someplace that refers > to the bootstrap protocol, at least to give some hint as to where the query > URL might come from? That's a good idea. -andy From nobody Mon Sep 15 13:20:17 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80311A802A for ; Mon, 15 Sep 2014 13:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkEe-kGo4YBY for ; Mon, 15 Sep 2014 13:20:14 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B7A1A86E1 for ; Mon, 15 Sep 2014 13:20:10 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id mc6so5454763lab.17 for ; Mon, 15 Sep 2014 13:20:09 -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=FIk4SuVnqpwle4ijSYoK1QNegFOcHWHG9Hy//mRVJRs=; b=AX3BeahEGn/fhOgwYqyrRlQipQKViA+IDyHTBfIqmLpqUGXa8F5N9lmqopaVbFGN1W QQdzKWmX384C3Jic3HReRZGVjS8N7Hx/D3RS2T//cmeBsHOwZkaFc6rcfj1Z9G5OvuE4 u3kZDQIPIKVZ+gDMplQIPvyulFMpLU955Eziic+8NsukuqdjMJTty2qKUdHhetRtRGj5 6Y4JmlkHjkJXLz2uWfdadTR8u3oG5cdzcGp748DjvLaz2VEY2PD9bfYUkc/tnqQforJc IU9xifsbhypX90clc2d3DPVUWbeXVGlAxPuD2RBp9MHfeL2j+F+bFdBw6l5353U5AWJ4 +6CQ== MIME-Version: 1.0 X-Received: by 10.112.171.202 with SMTP id aw10mr12720037lbc.52.1410812409338; Mon, 15 Sep 2014 13:20:09 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 13:20:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Sep 2014 13:20:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Newton Content-Type: multipart/alternative; boundary=001a11c36b2280e3260503205c0d Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/1KuxW_xpogzEE6HPltvZWfZyxrA Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:20:16 -0000 --001a11c36b2280e3260503205c0d Content-Type: text/plain; charset=UTF-8 Hi Andy, On Mon, Sep 15, 2014 at 1:03 PM, Andrew Newton wrote: > > - is there a definition of RESTful that could be included or referenced > > here? > > My understanding is NO. > That's surprising. I did find a wikipedia page that describes it but I don't know if we consider that a sufficiently stable reference for RFCs. I've asked on apps-discuss, but we can let it go as-is if there's no good answer. The IESG might ask us to define it, in which case we can do so in a subsection or appendix, and later documents can refer to this one for such a definition. > > 10) Section 7 says the document requires use of HTTPS, but other than in > > examples, this is the first reference to it. Should a sentence or small > > subsection be added about this somewhere earlier? > > It requires implementation, not use. > My point is that a single sentence in Security Considerations seems kind of thin on the topic and fairly late in the document. Also the wording "This document requires..." made me think this was covered earlier, but it was not. -MSK --001a11c36b2280e3260503205c0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andy,

On Mon, Sep 15, 2014 at 1:03 PM, Andrew Ne= wton <andy@hxr.us> wrote:
> - is = there a definition of RESTful that could be included or referenced
> here?

My understanding is NO.

That'= ;s surprising.=C2=A0 I did find a wikipedia page that describes it but I do= n't know if we consider that a sufficiently stable reference for RFCs.= =C2=A0 I've asked on apps-discuss, but we can let it go as-is if there&= #39;s no good answer.

The IESG might ask us to define it, in which c= ase we can do so in a subsection or appendix, and later documents can refer= to this one for such a definition.
=C2=A0
> 10) Section 7 says the document requires use of HTTPS= , but other than in
> examples, this is the first reference to it.=C2=A0 Should a sentence o= r small
> subsection be added about this somewhere earlier?

It requires implementation, not use.

=
My point is that a single sentence in Security Considerations seems ki= nd of thin on the topic and fairly late in the document.=C2=A0 Also the wor= ding "This document requires..." made me think this was covered e= arlier, but it was not.

-MSK
--001a11c36b2280e3260503205c0d-- From nobody Mon Sep 15 13:59:03 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6977E1A875F for ; Mon, 15 Sep 2014 13:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToZc4wPE1LVi for ; Mon, 15 Sep 2014 13:59:01 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2812A1A871B for ; Mon, 15 Sep 2014 13:59:01 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id p10so7058910pdj.30 for ; Mon, 15 Sep 2014 13:59:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HwieSYgtFI0550XV7VICECoA3DfLa3339Si949CKLJA=; b=HL3y7a7LW4uP8CUaDq9qhP9xIdDyP7Lz1YxNGXvvbQ//lUdbnUrp0mCjNB4B0C3N2x 9f5dMWsldEAWv9E2GHyw6tbQ+GOYOmJ5HjJ6vMwcPxcKrjLUEO3jfcM7qizc+mYVIYoN MPtjBIiJh8jJOgA8vtyL5TBQOwjYR19Tu7bys9jW72qg3jzSsa6v0t7nQ1ma3Nm1fh6k wFIZs7KUWcgx8vzWpikx82RXasMa1tID5UKjwjbHPsVubfJcv9+qL4c3CG7Ih2C1wP62 szlxV/Rdt9sZRJS9bfReTEfWlkMhaHncKRYN0t/IPhfQLPyW2crf2nQKrmYUlaIpwN2c kNCg== X-Gm-Message-State: ALoCoQm9bf9olyOTwg/qSSSa/ItBa/27bAYYV7hLyLAUk/n8DJgT3fyswozRCIJE5eeGGiJ57Y6P MIME-Version: 1.0 X-Received: by 10.68.179.228 with SMTP id dj4mr16850986pbc.130.1410814740821; Mon, 15 Sep 2014 13:59:00 -0700 (PDT) Received: by 10.66.159.3 with HTTP; Mon, 15 Sep 2014 13:59:00 -0700 (PDT) X-Originating-IP: [2001:500:4:15:f24d:a2ff:fe31:a268] In-Reply-To: References: Date: Mon, 15 Sep 2014 16:59:00 -0400 Message-ID: From: Andrew Newton To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/FUEUbd7lMIIyJTBSDa-AHAMo7uo Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:59:02 -0000 On Mon, Sep 15, 2014 at 4:20 PM, Murray S. Kucherawy wrote: >> > - is there a definition of RESTful that could be included or referenced >> > here? >> >> My understanding is NO. > > > That's surprising. I did find a wikipedia page that describes it but I > don't know if we consider that a sufficiently stable reference for RFCs. > I've asked on apps-discuss, but we can let it go as-is if there's no good > answer. Oh boy! > > The IESG might ask us to define it, in which case we can do so in a > subsection or appendix, and later documents can refer to this one for such a > definition. Well, they didn't the first time around. -andy From nobody Mon Sep 15 14:10:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2101A0299 for ; Mon, 15 Sep 2014 14:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89XleP5YZfe8 for ; Mon, 15 Sep 2014 14:10:20 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B301A8730 for ; Mon, 15 Sep 2014 14:10:15 -0700 (PDT) Received: (qmail 84272 invoked from network); 15 Sep 2014 21:10:14 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 15 Sep 2014 21:10: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=a98.541755b5.k1409; i=johnl@user.iecc.com; bh=LZ2rebSpU/MpD4NdmBHIPamRzhs21ddpqqbcXl9E0wE=; b=PVTYoV9E4vwRbboZ+YHzJTZESPRgy2W70f0jDa5WkxY2B14jPBb+u4nwMvlvDiyBzHCfsPRAH9kN1KO6UHwgXttslr47E0DOXWF4IlJqHmOJ7BQggard2xKNW7a5At3GUquMkVOVITb07dwHGUWiIySfD687oafekWyeqbd6IBpLbVaE0Aqe4gS1LLMYr2DXoy9sFhjSyywECwf3wxu+J6X4MIpFtFsF28QGO3Cf7mIYjTWJnQF/KxE/cuUwqs7p 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=a98.541755b5.k1409; olt=johnl@user.iecc.com; bh=LZ2rebSpU/MpD4NdmBHIPamRzhs21ddpqqbcXl9E0wE=; b=YOYq4QFf6OZozeZ+YBX8Ri5ltU7ykx97ic0czDgx8/tNq3LuFos4x8q9I18IbzAFkrYsZDof9W0eEZLORSdhifC50rn9orhsbYkyJv2dO9c+b6yHcSY8EoFTPQvMEls+bQcu0tMLmt7miPzuQzUXEX5MqEZWd7o6qooWQ3Sx7iMeU/qQbNsMrEsZLYZUiiHHpgpMCiaP/XI8oaEi4r5MATTG6fhy+Gelwn4doPFj7ZSXH4KnkZwo5G1oT1UGzAHA Date: 15 Sep 2014 21:09:51 -0000 Message-ID: <20140915210951.2711.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 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/HhytwN7Snjo7VCyVf7AVf9hCQ5I Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:10:22 -0000 >My only question is about Section 3.1.1 which talks about federated >authentications. All of the 3.x sections except this one are of the form >"RDAP needs to do X, so here's how you do X". This one describes federated >authentication and says that an RDAP server might do it if it wants to, and >lists a few ways to do so (OAuth, OpenID). I'm not totally familiar with >these, so this might be a naive question: Is there any need for us to >include a mechanism by which an RDAP server can be discovered to be part of >such a federation? Short answer: yes; Longer answer: whatever the answer is for RDAP would be the same answer for every other service that uses federated authentication. The whole federated thing is in major flux. It was my idea in the first place to mention it, but I don't think it would be a good idea for us to get ahead of the people who are working on the underlying technologies. Hence the unsatisfying language that says it would be nice, but not how to do it. R's from Bucharest, John From nobody Mon Sep 15 14:59:27 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCC81A87AA for ; Mon, 15 Sep 2014 14:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOdNeuYfkDwK for ; Mon, 15 Sep 2014 14:59:23 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B3F1A87CD for ; Mon, 15 Sep 2014 14:59:22 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id mc6so5687330lab.3 for ; Mon, 15 Sep 2014 14:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mYe1mwOtKqJI6Iq7m+3fklCtdhITFaRugbECpnFW30Q=; b=E+qOkNHFYAqdAsV6oQKEjz2agdXRhNK+nytU2Ra6XJCDnm2Cj7MqqRNeBdv5pcBZJw PD1y5bytg9JU+WdyXXiIeuUhbRu/qbXm/jTf1PC4Jyit62r0j8bo56oS84SIvwEr3/Lm pwloiPxMC6ppxffRsRzwmbrdHI9Pq9GIIEkPZONyuleZCypZ0L71K08zycAoB8Ix4GYE AiGgG3Mj6YjL6c+igG2IQPf2onEid3/jVbUlbU1862eS2pMS5jerFSpF2fNYn6io5AG+ wBf2oBavQBhPmxufe9xV3hSnxq6pJlS+Usu309NhEsHJJ43U4SVyrOY6fzI25+6StuTU beiw== MIME-Version: 1.0 X-Received: by 10.152.43.50 with SMTP id t18mr31607104lal.25.1410818361390; Mon, 15 Sep 2014 14:59:21 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 14:59:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Sep 2014 14:59:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Newton Content-Type: multipart/alternative; boundary=001a11c239d045fd38050321bffd Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/m2J28ezOfrQ6kQal0Kbh0KCmfuk Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:59:25 -0000 --001a11c239d045fd38050321bffd Content-Type: text/plain; charset=UTF-8 On Mon, Sep 15, 2014 at 1:59 PM, Andrew Newton wrote: > > That's surprising. I did find a wikipedia page that describes it but I > > don't know if we consider that a sufficiently stable reference for RFCs. > > I've asked on apps-discuss, but we can let it go as-is if there's no good > > answer. > > Oh boy! > Looks like it worked. RFC7252 (CoAP) contains a citation they used for REST, so we can just use that. -MSK --001a11c239d045fd38050321bffd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--001a11c239d045fd38050321bffd-- From nobody Mon Sep 15 15:01:13 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2631A87F0 for ; Mon, 15 Sep 2014 15:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJUicpg7pcWz for ; Mon, 15 Sep 2014 15:01:10 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542701A87C4 for ; Mon, 15 Sep 2014 15:01:10 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ge10so5464478lab.41 for ; Mon, 15 Sep 2014 15:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9rumvDdzYOqztCoVpLG44mBqJCgcltp4mMlQQSgwlZg=; b=Co0VoyorHkpacb3DcI6V0P+rap7zlkh1G+naIGPYyoXEpI62MSjqcW4GP8q5iY6dTH 8ffAfOcn/Tp1GBwsJEskiepDihyf4CUvTKhILMC21RTWwPJi2GYeVrk4EK+lZP1WBVcV fM5xw7z0Ah29FWNTFP8BmaGDzExtgH4c1B6pS8hpDupMlrEjVTQ2CijO1/RZ4X4vJXdn ozXXJDi5rVb+100tWV8MHmFYch3St9ci1icmgkpq6cYKi56wl/Dw32ayJedliSUG+NnC WKJmmKgC0OVAUACnjFplesykptMJesKt7alqDiN/C3Wu/tQdXpjKQxE0y7ZjkmhwyhZL 8SQg== MIME-Version: 1.0 X-Received: by 10.112.161.135 with SMTP id xs7mr8517294lbb.13.1410818468664; Mon, 15 Sep 2014 15:01:08 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 15:01:08 -0700 (PDT) In-Reply-To: <20140915210951.2711.qmail@joyce.lan> References: <20140915210951.2711.qmail@joyce.lan> Date: Mon, 15 Sep 2014 15:01:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a11c31858aada50050321c57c Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/GL6ehz2bOZBD9No2jQ8Jwlj2aZo Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:01:12 -0000 --001a11c31858aada50050321c57c Content-Type: text/plain; charset=UTF-8 On Mon, Sep 15, 2014 at 2:09 PM, John Levine wrote: > Longer answer: whatever the answer is for RDAP would be the same > answer for every other service that uses federated authentication. > > The whole federated thing is in major flux. It was my idea in the > first place to mention it, but I don't think it would be a good idea > for us to get ahead of the people who are working on the underlying > technologies. Hence the unsatisfying language that says it would be > nice, but not how to do it. > So we have to hand-wave on this because it's not currently possible to give a more definite answer? That's fine if it's the case; I just want to have the back story in case we get asked. -MSK --001a11c31858aada50050321c57c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 15, 2014 at 2:09 PM, John Levine <johnl@taugh.c= om> wrote:
Longer answer: whatever the answer is= for RDAP would be the same
answer for every other service that uses federated authentication.

The whole federated thing is in major flux.=C2=A0 It was my idea in the
first place to mention it, but I don't think it would be a good idea for us to get ahead of the people who are working on the underlying
technologies.=C2=A0 Hence the unsatisfying language that says it would be nice, but not how to do it.

So we have = to hand-wave on this because it's not currently possible to give a more= definite answer?

That's fine if it's the case; I= just want to have the back story in case we get asked.

-= MSK
--001a11c31858aada50050321c57c-- From nobody Mon Sep 15 16:48:06 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAD41A002C for ; Mon, 15 Sep 2014 16:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5ePQURaXDEu for ; Mon, 15 Sep 2014 16:48:03 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D650E1A0023 for ; Mon, 15 Sep 2014 16:48:02 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id hz20so5832709lab.29 for ; Mon, 15 Sep 2014 16:48: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 :cc:content-type; bh=XgbQ80B44w+x07HYkXqh6ECWQqrMPXndjsc3oR2Xiz0=; b=UiJPjWXgZ0PPYqzbRyflcrjAw5BilB/RssWarqgpbQlT9fkGs0XmGW/bbltUhwgJwQ GjPrnQTXDfGntWhfoPMATLPDjEyR73EZNimS8cj2HtRBT5/fzOdcadMPxw9N8TnVfKnx dY6DtSDiJTLs1KQECl+iAc5SSlJagqbpmac4K7jGf6ZKVlh2fjfRUskuvwSgd3HnT1bv kW3aSzC/BxuNE5ny+fyveZrwsBgmXOqy+aJiTcHKO9khyb9xRhAT6+eRdGnWnTHGSreu ATmlG/Jl1GU0pJNw4Q2Mf72p4uFOPGwv6JuSgqPwnjQEqDR+Gp1Um9QQ5PSeS/8nU65r SiCA== MIME-Version: 1.0 X-Received: by 10.152.26.133 with SMTP id l5mr32937598lag.4.1410824881011; Mon, 15 Sep 2014 16:48:01 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 16:48:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Sep 2014 16:48:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Newton Content-Type: multipart/alternative; boundary=089e0160a6fadf80e105032343c2 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/wxCXCu7WQKfY1UgsPVJmd-4p9Ck Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 23:48:05 -0000 --089e0160a6fadf80e105032343c2 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 15, 2014 at 2:59 PM, Murray S. Kucherawy wrote: > Looks like it worked. RFC7252 (CoAP) contains a citation they used for > REST, so we can just use that. > How hard would it be to summarize the constraints defined on the Wikipedia page into a small definition in this document? It seems like writing down something terse might be useful to this and future RFCs. http://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraints -MSK --089e0160a6fadf80e105032343c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 15, 2014 at 2:59 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
Looks like i= t worked.=C2=A0 RFC7252 (CoAP) contains a citation they used for REST, so w= e can just use that.

How hard would it be to summariz= e the constraints defined on the Wikipedia page into a small definition in = this document?=C2=A0 It seems like writing down something terse might be us= eful to this and future RFCs.

http://en.wiki= pedia.org/wiki/Representational_state_transfer#Architectural_constraints

--089e0160a6fadf80e105032343c2-- From nobody Mon Sep 15 23:21:36 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE551A02E6 for ; Mon, 15 Sep 2014 23:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqbBbah9cJPN for ; Mon, 15 Sep 2014 23:21:31 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D84C1A02F6 for ; Mon, 15 Sep 2014 23:21:30 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id hz20so6242732lab.29 for ; Mon, 15 Sep 2014 23:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wO5aW3x8g5jD5+Eowa+tg8jBj5UQesI2w4kckUcr7Xw=; b=PpiD0sBxX08ZTLkqysEd6IH9I/sHum8Hjm13Jpu4Z+32mhyOKcv+3+pW3dYTrLcVT3 PPj3G2sIrOgPzINMStRRYezLabN9EgXNwm2ifwmAeuQ9ZPzyOtP3IifOBHzwtMCEelf+ FkVYgrjoDdgen7tSD1IgLlSxjAMTFRyVZo6LvG+0wjPFhlsoPzyBFainvo3bj6P5tvPj Q39xKsBXCxq+W3EY30ELHbsK21rMKIixXyiW42im+QkfFb4+3Wryx/SofCAIvPjASnDH OAFUVhNLrPlyBd77LHYGMtPu2yX84c0A81S9DC+SHEnlIL3C3U6cc3+Cji4ewX8uIB22 roUQ== MIME-Version: 1.0 X-Received: by 10.152.206.35 with SMTP id ll3mr2747850lac.88.1410848488902; Mon, 15 Sep 2014 23:21:28 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 23:21:28 -0700 (PDT) Date: Mon, 15 Sep 2014 23:21:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11348914035488050328c37f Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/BABMLl1y1d_PUgXZlVHgMbtV4sY Subject: [weirds] Comments on draft-ietf-weirds-json-response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 06:21:34 -0000 --001a11348914035488050328c37f Content-Type: text/plain; charset=UTF-8 Hi, I've reviewed this draft. Sorry it's last, but it's also the biggest. :-) I have the following concerns and editorial suggestions: 1) In Section 1, RESTful is not defined before use. This is being discussed on the thread for another document already, so the result of that debate can be applied here as well. 2) Also in Section 1, "forward DNS names" might be more simply expressed as "domain names". 3) Also in Section 1, some editorial suggestions: - s/an JSON object/a JSON object/ - s/object which contains/object that contains/ 4) In Section 2, drop the period at the end of each definition and remove quotes (they aren't needed). 5) Also in Section 2, s/with in/within/ 6) In Section 3.1, change one of the "specified"s to "described" or similar. 7) In Section 3.2, the SHOULD NOTs and SHOULDs are stirring up the usual question: When would it be appropriate to deviate from that advice, and what might one do instead? 8) Starting about here and throughout the document, there are lots of "should", "may", "optional", etc. that are all lowercase. We might get some whining about the fact that they're RFC2119 words. You could go through and tweak the text if you're so inclined to avoid this. 9) In Section 4, some editorial suggestions: - s/The semantics ... is .../The semantics ... are .../ - s/'handle'/handle/ - s/2 character/two-character/ 10) In Section 5, "common data structures used commonly" is redundant. 11) In Section 5.1, this "should" is probably supposed to be a "SHOULD". 12) Also in Section 5.1, there's a reference to a prefix identifier registry defined in the "using-http" draft, but that draft does not define a registry by that name. 13) In Section 5.3: - s/it is contained within/that contains it/ - s/Both are an array/Both are arrays/ 14) Also in Section 5.3, the SHOULD NOT can probably just be replaced by something like: Each string in the "description" array contains a single complete sentence indicating to clients where there are semantic breaks in the text. 15) In Section 5.4, I suggest: This data structure consists solely of a name/value pair, where the name is "lang" and the value is a string containing a language identifier as described in [RFC5646]. 16) In Section 5.7, should we also allow an IP address? 17) In Section 5.8, do the valid types need to be enumerated? 18) In Section 5.9, why not just require it? 19) In Section 6, another instance of "specified ... specified" in the same sentence. 20) Also in Section 6, the usual SHOULD/SHOULD NOT questions come up: Under what conditions might one deviate from this advice? 21) Has anyone tried putting all of the JSON examples through a JSON parser just to see if they at least conform to basic JSON syntax? 22) In Section 6.2, change "should be the string" to "always the string" or just "the string". Same in 6.3, 6.4, and 6.5. 23) In Section 6.3, change instances of "boolean true" to just "true". 24) There are references in Section 6.3 that look like "RFC 4034 RFC 4034 [RFC4034]" that should be tidied up. 25) There are more instances of "specified ... as specified" in the same sentence in 6.3. 26) Also in 6.3, the "keyData" bullet list has a few entries that end in periods, unlike the bullets in the rest of the section. 27) Section 6.4 and 6.5: change "2 character" to "two-character". 28) Section 7, "followed by ... followed by" in the same sentence; perhaps just change the second one to "and"?' 29) Section 8, "as defined ... as defined" in the same sentence; perhaps just change the second one to "from"? 30) In Section 11.2, why force everything to lowercase rather than just making comparisons case-insensitive? 31) Also about Section 11.2, it helps the IESG when creating a registry like this to recommend some people to act as the designated experts. I propose we have two DNR and two RIR representatives. Does anyone want to volunteer? 32) In Section 11.2.1, "yield" is misspelled as "yeild" in multiple places. (Might want to pass the whole thing through a spell checker just in case.) 33) In Section 11.2.1, registration #3 and #6, the last sentence is kind of meaningless because retrying might yield a longer result too if whatever transient condition clears up. The client doesn't really know either way. Or am I missing something? 34) In Section 11.2.2, registration #1, I remember this being a topic of some discussion. I think it had something to do with the notion of "validated" being unspecified. Do we need to say more about that here? 35) In Section 11.2.2, registration #18, "in no longer" should be "is no longer". 36) In Section 11.2.2, registration #11, is the first document's reference to EPP. We need to define that there or someplace earlier (definitions section, maybe?) and include a defining reference. 37) In Section 12, I suggest we make reference to the Security Considerations of the using-http document, or to the rdap-sec document, or both. 38) Section 13.1 mentions XML as if it's an acceptable format. I don't think it is, so that should be removed. 39) Appendix F needs a notation like "[RFC Editor: Please delete this section prior to publication.]" -MSK --001a11348914035488050328c37f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I've reviewed this draft.=C2=A0 Sorry = it's last, but it's also the biggest.=C2=A0 :-)

I have the f= ollowing concerns and editorial suggestions:

1) In Sectio= n 1, RESTful is not defined before use.=C2=A0 This is being discussed on th= e thread for another document already, so the result of that debate can be = applied here as well.

2) Also in Section 1, "forward= DNS names" might be more simply expressed as "domain names"= .

3) Also in Section 1, some editorial suggestions:
- s/an JSON object/a JSON object/
- s/object which contains= /object that contains/

4) In Section 2, drop the period a= t the end of each definition and remove quotes (they aren't needed).
5) Also in Section 2, s/with in/within/

6= ) In Section 3.1, change one of the "specified"s to "describ= ed" or similar.

7) In Section 3.2, the SHOULD NOTs a= nd SHOULDs are stirring up the usual question: When would it be appropriate= to deviate from that advice, and what might one do instead?
=
8) Starting about here and throughout the document, there ar= e lots of "should", "may", "optional", etc. t= hat are all lowercase.=C2=A0 We might get some whining about the fact that = they're RFC2119 words.=C2=A0 You could go through and tweak the text if= you're so inclined to avoid this.

9) In Section 4, s= ome editorial suggestions:

- s/The semantics ... is .../T= he semantics ... are .../
- s/'handle'/handle/
- s/2 character/two-character/

10) In Section 5, = "common data structures used commonly" is redundant.

11) In Section 5.1, this "should" is probably supposed to b= e a "SHOULD".

12) Also in Section 5.1, there= 9;s a reference to a prefix identifier registry defined in the "using-= http" draft, but that draft does not define a registry by that name.
13) In Section 5.3:

- s/it is contained within/that= contains it/
- s/Both are an array/Both are arrays/

<= /div>
14) Also in Section 5.3, the SHOULD NOT can probably just be repl= aced by something like:

Each string in the "descript= ion" array contains a single complete sentence indicating to clients w= here there are semantic breaks in the text.

15) In Sectio= n 5.4, I suggest:

This data structure consists solely of = a name/value pair, where the name is "lang" and the value is a st= ring containing a language identifier as described in [RFC5646].

16) In Section 5.7, should we also allow an IP address?

17) In Section 5.8, do the valid types need to be enumerated?
18) In Section 5.9, why not just require it?

= 19) In Section 6, another instance of "specified ... specified" i= n the same sentence.

20) Also in Section 6, the usual SHO= ULD/SHOULD NOT questions come up: Under what conditions might one deviate f= rom this advice?

21) Has anyone tried putting all of the = JSON examples through a JSON parser just to see if they at least conform to= basic JSON syntax?

22) In Section 6.2, change "shou= ld be the string" to "always the string" or just "the s= tring".=C2=A0 Same in 6.3, 6.4, and 6.5.

23) In Sect= ion 6.3, change instances of "boolean true" to just "true&qu= ot;.

24) There are references in Section 6.3 that look li= ke "RFC 4034 RFC 4034 [RFC4034]" that should be tidied up.
25) There are more instances of "specified ... as specifie= d" in the same sentence in 6.3.

26) Also in 6.3, the= "keyData" bullet list has a few entries that end in periods, unl= ike the bullets in the rest of the section.

27) Section 6= .4 and 6.5: change "2 character" to "two-character".
28) Section 7, "followed by ... followed by" in t= he same sentence; perhaps just change the second one to "and"?= 9;

29) Section 8, "as defined ... as defined" i= n the same sentence; perhaps just change the second one to "from"= ?

30) In Section 11.2, why force everything to lowercase = rather than just making comparisons case-insensitive?

31)= Also about Section 11.2, it helps the IESG when creating a registry like t= his to recommend some people to act as the designated experts.=C2=A0 I prop= ose we have two DNR and two RIR representatives.=C2=A0 Does anyone want to = volunteer?

32) In Section 11.2.1, "yield" is mi= sspelled as "yeild" in multiple places.=C2=A0 (Might want to pass= the whole thing through a spell checker just in case.)

3= 3) In Section 11.2.1, registration #3 and #6, the last sentence is kind of = meaningless because retrying might yield a longer result too if whatever tr= ansient condition clears up.=C2=A0 The client doesn't really know eithe= r way.=C2=A0 Or am I missing something?

34) In Section 11= .2.2, registration #1, I remember this being a topic of some discussion.=C2= =A0 I think it had something to do with the notion of "validated"= being unspecified.=C2=A0 Do we need to say more about that here?

35) In Section 11.2.2, registration #18, "in no longer" = should be "is no longer".

36) In Section 11.2.2= , registration #11, is the first document's reference to EPP.=C2=A0 We = need to define that there or someplace earlier (definitions section, maybe?= ) and include a defining reference.

37) In Section 12, I = suggest we make reference to the Security Considerations of the using-http = document, or to the rdap-sec document, or both.

38) Secti= on 13.1 mentions XML as if it's an acceptable format.=C2=A0 I don't= think it is, so that should be removed.

39) Appendix F n= eeds a notation like "[RFC Editor: Please delete this section prior to= publication.]"

-MSK
--001a11348914035488050328c37f-- From nobody Tue Sep 16 05:02:34 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E211A068F for ; Tue, 16 Sep 2014 05:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.383 X-Spam-Level: X-Spam-Status: No, score=-7.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW5KgX791sTt for ; Tue, 16 Sep 2014 05:02:31 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFA21A0696 for ; Tue, 16 Sep 2014 05:02:26 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Tue, 16 Sep 2014 14:02:24 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0195.001; Tue, 16 Sep 2014 14:02:21 +0200 From: Alexander Mayrhofer To: "weirds@ietf.org" Thread-Topic: Review of draft-ietf-weirds-boostrap-06 Thread-Index: Ac/RoZ39sK6MmZg8TGC6NAh7Nd80AA== Date: Tue, 16 Sep 2014 12:02:20 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0752688754D@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/vAnJZfE2HbkgJrjdEibljy9JIak Subject: [weirds] Review of draft-ietf-weirds-boostrap-06 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 12:02:33 -0000 I've reviewed the bootstrap document. Generally, i think it does what it is= supposed to do, but could use some editorial work and some definitions / c= larifications:=20 There we go: ** 1. Introduction:=20 "extracts" instead of "extract", "does" instead of "do" ** 3. Structure:=20 - "version id identified as a timestamp" etc.. sounds confusing. change to= proper definition of metadata - Further, i think the whole document would benefit from defining a name fo= r the several sub-arrays, because "the second third-level array" makes me l= ook it up each time. I suggest using this section to define the "Entries" a= rray, and the "Base URL" arrays, and use that terminology in subsequent sec= tions. Sometimes those "Entries" seem to be called "keys" subsequently in t= he document? Clarify on terminology. - There's no text about recommended sorting in the "Entries" array ** 4. Domain RDAP registry - I find it weird (sic!) that the *definition* starts with an example. The = definition should go first, and after that an example should be illustrativ= e. It even gets more confusing reading the last sentence of that section "T= his example is not normative". To which of the two examples does this refer= ? Suggest to change the section so that formal definition comes first, and = example follows. - Again, we have the "first array" and "second array" issue here. I think e= verybody knows what is supposed to happen, but i don't think that's formal = enough for a Proposed Standard. ** 5. Internet Numbers - Again, this could benefit from being clear which "array" is being searche= d, in order to remove ambigiuity...=20 - The description here is better than in section 4, because the definition = comes first, followed by examples. - Text explaining what is in the "second array" is repetitive ("... which i= s an array of RDAP URLS..."). Again, defining a name for the Arrays in the = document would make it clearer - (Same for the V6 section, where the text is repeated 1:1) ** 5.3. AS numbers - funny enough, the text defines a name for the "first arrays" here ("AS Nu= mbers array"). Besides that, my comment from above apply again. ** 6. Entity - I'm unsure if the "could be queried" text tries to RECOMMEND some kind of= client behaviour? It seems vague.=20 - On the other hand, where is the client behaviour actually specified (Disc= laimer: I have yet to read the other drafts). I can't find in the document = that the client MUST or SHOULD use those URLs once it has discovered them (= besides the text in the Introduction) -> Add this text? ** 7.=20 - The "error behaviour" of the client is much more precisely specified than= the "success" bahaviour anywhere else in the document... I take that as an= indication that we tend to be pessimists? ;-) We should also specify the "= success" behaviour of the client (see above) ** 8. Deployment Cons. - "fetch registry every time" -> "fetch registry on every RDAP request" - I would actually be even stronger on the caching, and make that a MUST. T= his can be dangerous if clients get too creative.. - Typo "garanteed" ** 9. Limitations - Change text slightly so that types don'T need to be prefixed with "for" e= verytime? - I'm confused by the "queries using search patterns", and have no idea wha= t that means (but, again, i have yet to read the other documents thoroughly= ) ** 10. Security considerations - "Clients" rather than "End users"? I don't see how the registry makes sur= e that an entity that is not even defined for the document scope gets whate= very kind of information... If "end user" is defined in another RDAP docume= nt, refer there for terminology. ** 11. IANA - Without having an insight into the hallway discussions with IANA, i under= stand that the definition of Registries would require more information (see= RFC5226, Section 4). Specifically, a registration policy etc. is required.= Also, change control in case a revision of the Bootstrap document was to b= e done. However, i guess this is all up to discussion between document shep= herds and IANA... I do=20 tia, Alex From nobody Tue Sep 16 07:36:07 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDD91A0656 for ; Tue, 16 Sep 2014 07:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt7HekQRq2m2 for ; Tue, 16 Sep 2014 07:36:00 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id CFF981A0356 for ; Tue, 16 Sep 2014 07:35:56 -0700 (PDT) Received: from [192.168.1.105] (unknown [123.112.102.25]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMJDGShhUsWQEAA--.9278S2; Tue, 16 Sep 2014 22:35:50 +0800 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4720F671-D119-4CE1-A524-1D0AA89060B4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: Date: Tue, 16 Sep 2014 22:35:40 +0800 Message-Id: <37551984-88C8-4E86-9CCD-60BB91B636F2@cnnic.cn> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0ApMJDGShhUsWQEAA--.9278S2 X-Coremail-Antispam: 1UD129KBjvdXoWruFWUAF1fJrW3WF4kArWkWFg_yoWDZwc_uw s2qrs3Aa1Uta12v390qF1kJwn5K3y8Ga4UJw48tr17K3s8Aws8XFZrCrnagrn7JFs8W3Z8 Wa909w1xtwsrWjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb58YjsxI4VW3JwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z2 80aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487McIj6xIIjxv20xvE 14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2 IYc2Ij64vIr41l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAq x4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r 17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF 7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14 v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x 07j0ApnUUUUU= X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/aS0KSkCfeQLeUF-SIgcztWL71jE Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 14:36:05 -0000 --Apple-Mail=_4720F671-D119-4CE1-A524-1D0AA89060B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > My only question is about Section 3.1.1 which talks about federated = authentications. All of the 3.x sections except this one are of the = form "RDAP needs to do X, so here's how you do X". This one describes = federated authentication and says that an RDAP server might do it if it = wants to, and lists a few ways to do so (OAuth, OpenID). I'm not = totally familiar with these, so this might be a naive question: Is there = any need for us to include a mechanism by which an RDAP server can be = discovered to be part of such a federation? For example, should an RDAP = client be able to contact, say, rdap.arin.net and discover that it's = federated with LACNIC's server via an arrangement using OAuth? Or is = that sort of thing arranged and discovered completely out of band? Hi Murray, I think this kind of mechanism you supposed is useful but it = is now out of scope for the current federated authentication protocols = (OAuth, OpenID). As far as I know, this kind of mechanism is usually = implemented by current web applications through some out of band ways. Cheers, Ning= --Apple-Mail=_4720F671-D119-4CE1-A524-1D0AA89060B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

= --Apple-Mail=_4720F671-D119-4CE1-A524-1D0AA89060B4-- From nobody Tue Sep 16 07:51:52 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD891A0367 for ; Tue, 16 Sep 2014 07:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7ZDpnfCs7su for ; Tue, 16 Sep 2014 07:51:45 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C241A0357 for ; Tue, 16 Sep 2014 07:51:45 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id hz1so9040313pad.21 for ; Tue, 16 Sep 2014 07:51:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HqqFjGTES3MeJofIkoGEg17XclTqe/paAvtrGRpgENE=; b=iDD6b2CQ0wIS7XjvuI27gqL+4Fqbkhu2mR6TGuqyof+/L6lFxwz52v8eOh4WR/88FG 0FGkR4JqPgRhAx/3dNbTacgmvO+kP9Iha0zzs7C/3G9EbrJKdIriLeRvxpEdqKK9xaB1 QHFF104p6CWZ8Y/lykixrW/houGy9xbErzseuDFOVnGUdCGhDs3+8OK4zQX4XnNnlJf+ O6I3HSsNhIOYh2SWi6ZnJ+5xOOwU9Ia8NbHtYbL4MiNYacYVHglyw5TzWXrqmmuksvdA rVl/EYbMkrx8sLQZTQ1BGwa3u60a9KxS53j+mBBYCWZIsupqSdIoM7wmhvLyL/+UXKzx lvbw== X-Gm-Message-State: ALoCoQlnsMgJKEvs1Oh6FUOauKsKzKr5t7XQ9Ta7gJ++XSLmE4W5vYI49xKoSXWZMfP+nDHC90i6 MIME-Version: 1.0 X-Received: by 10.66.161.232 with SMTP id xv8mr49255999pab.81.1410879104963; Tue, 16 Sep 2014 07:51:44 -0700 (PDT) Received: by 10.66.159.3 with HTTP; Tue, 16 Sep 2014 07:51:44 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: References: Date: Tue, 16 Sep 2014 10:51:44 -0400 Message-ID: From: Andrew Newton To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ojHzcD7rlYxa4--ftx1MYpNNq38 Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 14:51:50 -0000 On Mon, Sep 15, 2014 at 7:48 PM, Murray S. Kucherawy wrote: > On Mon, Sep 15, 2014 at 2:59 PM, Murray S. Kucherawy > wrote: >> >> Looks like it worked. RFC7252 (CoAP) contains a citation they used for >> REST, so we can just use that. > > > How hard would it be to summarize the constraints defined on the Wikipedia > page into a small definition in this document? It seems like writing down > something terse might be useful to this and future RFCs. > > http://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraints > > -MSK Just how much definition of "RESTful" (not REST) do you want? One sentence? Or a section at the back of the draft? -andy From nobody Tue Sep 16 08:46:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994841A0B78 for ; Tue, 16 Sep 2014 08:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSSV2zyqRr9v for ; Tue, 16 Sep 2014 08:45:58 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485001A0AD1 for ; Tue, 16 Sep 2014 08:45:58 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id ft15so39402pdb.18 for ; Tue, 16 Sep 2014 08:45:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Cn9UggpOHzY+2KisnFBIfHk497pYk6IousxasjTWjfA=; b=AECGgn3l1ynr+LBW3VABzw0JLId/x/hYj76Rv0QIK8udYGPbZGUtQ/I3oaZEkvXfzm H1e1ueXu8fanRAEl5ZhVaOZK9V3dJ8z2A4hU30n0cKSPkkeipjw0YHvVyzwVZxD8AwdU b4Jt0AcFdyWdMMqixhG++9sHOGzc18luoItB9t28MjNKJc2JY0SzQyW2xmfn5ESkSbJe 4TCBDMcMOnljcOZiFtJ8CG5Gq4CMQC+5bNK8R92FlIQa3kZC4GxOK+BH1ZmToSG6xurF pWX+CI6PWMD/U/TzSeEAigAYYHWGXHLFVP8GCBN6RIjVQB21F5wEbEin/cMKpKajNh/9 0jtQ== X-Gm-Message-State: ALoCoQlPSkbvoTIBY6w6rKpGKbZr6yt9cXfALp5kkEJnHHMGCG+kKK+sIy3n4UinxxYwp92fmbUy MIME-Version: 1.0 X-Received: by 10.66.120.99 with SMTP id lb3mr16469971pab.152.1410882357878; Tue, 16 Sep 2014 08:45:57 -0700 (PDT) Received: by 10.66.159.3 with HTTP; Tue, 16 Sep 2014 08:45:57 -0700 (PDT) X-Originating-IP: [2001:500:4:12:81cb:40a:21c2:c954] In-Reply-To: References: Date: Tue, 16 Sep 2014 11:45:57 -0400 Message-ID: From: Andrew Newton To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/UxvoxmJKSuDSS4__kAqDOGHURlY Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 15:45:59 -0000 On Tue, Sep 16, 2014 at 2:21 AM, Murray S. Kucherawy wrote: > 2) Also in Section 1, "forward DNS names" might be more simply expressed as > "domain names". Well, that is less accurate as the reverse DNS is also composed of domain names. > 8) Starting about here and throughout the document, there are lots of > "should", "may", "optional", etc. that are all lowercase. We might get some > whining about the fact that they're RFC2119 words. You could go through and > tweak the text if you're so inclined to avoid this. So what is the excepted practice now with 2119? Even uncapitalized 2119 words have 2119 meaning now? Or can we explicitly say up front that when we want to attach 2119 meaning, those words are in caps? > 11) In Section 5.1, this "should" is probably supposed to be a "SHOULD". I don't know about that. Not using the prefix will also likely not cause problems. Using it is more a matter of style and a way for programmers to reference back to the IANA registry. > 16) In Section 5.7, should we also allow an IP address? Specifying an IP address is bad practice. I would hope most registries have their whois infrastructure behind load balancers or multiple DNS entries, etc... > 17) In Section 5.8, do the valid types need to be enumerated? As we don't validate them, no. > 18) In Section 5.9, why not just require it? Ok. > 21) Has anyone tried putting all of the JSON examples through a JSON parser > just to see if they at least conform to basic JSON syntax? I have, though not lately. The elided examples require editing though. > 30) In Section 11.2, why force everything to lowercase rather than just > making comparisons case-insensitive? Since they are identifiers, a straight string comparison is all that is required. It's also about style of the raw JSON. > > 31) Also about Section 11.2, it helps the IESG when creating a registry like > this to recommend some people to act as the designated experts. I propose > we have two DNR and two RIR representatives. Does anyone want to volunteer? I can do it. > 34) In Section 11.2.2, registration #1, I remember this being a topic of > some discussion. I think it had something to do with the notion of > "validated" being unspecified. Do we need to say more about that here? That would up to individual policy of the registry. I don't think we should specify it. -andy From nobody Tue Sep 16 09:17:07 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859041A7034 for ; Tue, 16 Sep 2014 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ2CO31Zxexb for ; Tue, 16 Sep 2014 09:17:03 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C0E1A212D for ; Tue, 16 Sep 2014 09:17:02 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so118082lam.0 for ; Tue, 16 Sep 2014 09:17: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 :cc:content-type; bh=O/THd3Rww1XxFotqdKmvutc0q5klS4LoVzdusqzEXe8=; b=LqKpEFjLJbJTzqNK3OGqkI4pv5wAGSa6P9oWAS67Z8MsSROH3lxW5UK3CZaReNVf+G TTYpZNV8ygAPF+NjBo1uEJQb4dAjRTcY+MHdIdM2wIPVTIzFBKKOQHCkt8HLpbDB/axz C/+hYMJuSKZ1xW27UXUOnAry2VuAt2LpGUxoj+TPODtRTQfPAp4dmgi5oJioHpe6tUX7 HdvpZnTMsnZAOpVu7A6iRLCMnJIwTBwTzy+lCYfn1NZkYYtxH0auCstZKTwldKjvnxVK n9ypxu5UaHpEeULL02FiSok6mObLMv47MZUaeC0LfDDXQePyMP+Upqwt/ZI/jx7TXYiw etaA== MIME-Version: 1.0 X-Received: by 10.112.78.38 with SMTP id y6mr12012228lbw.94.1410884221072; Tue, 16 Sep 2014 09:17:01 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Tue, 16 Sep 2014 09:17:01 -0700 (PDT) In-Reply-To: <37551984-88C8-4E86-9CCD-60BB91B636F2@cnnic.cn> References: <37551984-88C8-4E86-9CCD-60BB91B636F2@cnnic.cn> Date: Tue, 16 Sep 2014 09:17:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ning Kong Content-Type: multipart/alternative; boundary=001a11c3db42d0fa570503311436 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/9ZlDOHI6DySByWR_nfS47xyCTKo Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 16:17:05 -0000 --001a11c3db42d0fa570503311436 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 16, 2014 at 7:35 AM, Ning Kong wrote: > My only question is about Section 3.1.1 which talks about federated > authentications. All of the 3.x sections except this one are of the form > "RDAP needs to do X, so here's how you do X". This one describes federated > authentication and says that an RDAP server might do it if it wants to, and > lists a few ways to do so (OAuth, OpenID). I'm not totally familiar with > these, so this might be a naive question: Is there any need for us to > include a mechanism by which an RDAP server can be discovered to be part of > such a federation? For example, should an RDAP client be able to contact, > say, rdap.arin.net and discover that it's federated with LACNIC's server > via an arrangement using OAuth? Or is that sort of thing arranged and > discovered completely out of band? > > Hi Murray, I think this kind of mechanism you supposed is useful but it is > now out of scope for the current federated authentication protocols (OAuth, > OpenID). As far as I know, this kind of mechanism is usually implemented by > current web applications through some out of band ways. > > Is it worth adding a sentence or two indicating this in the document? Something like "At the time of this document's publication, negotiation or advertisement of federated authentication services is a developing mechanism and is therefore not discussed here." It's not critical that this be added, just a suggestion. I just feel like we point to this cool idea and then say absolutely nothing further about how to use it with RDAP. If that's the best we can do right now, it might be useful to say so. Thanks, -MSK --001a11c3db42d0fa570503311436 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 16, 2014 at 7:35 AM, Ning Kong <nkong@cnnic.cn> wrote:
My on= ly question is about Section 3.1.1 which talks about federated authenticati= ons.=C2=A0 All of the 3.x sections except this one are of the form "RD= AP needs to do X, so here's how you do X".=C2=A0 This one describe= s federated authentication and says that an RDAP server might do it if it w= ants to, and lists a few ways to do so (OAuth, OpenID).=C2=A0 I'm not t= otally familiar with these, so this might be a naive question: Is there any= need for us to include a mechanism by which an RDAP server can be discover= ed to be part of such a federation?=C2=A0 For example, should an RDAP clien= t be able to contact, say, rdap.arin.net and discover that it's federated with LACNIC'= s server via an arrangement using OAuth?=C2=A0 Or is that sort of thing arr= anged and discovered completely out of band?
=



--001a11c3db42d0fa570503311436-- From nobody Tue Sep 16 09:35:04 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A11F1A6F85 for ; Tue, 16 Sep 2014 09:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e-VUo0GbiFh for ; Tue, 16 Sep 2014 09:35:00 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5C21A0B83 for ; Tue, 16 Sep 2014 09:34:59 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id l4so138768lbv.36 for ; Tue, 16 Sep 2014 09:34:58 -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=KAv8zSBBPGIsv0fO+PZ7FP1NG5snyPtJjixIPOqyZZE=; b=RlvctU7hsF3905Y+7+Gz5LxOHc6tdK5rfGAUSsjHMm4Kwr6hLB6WkUD3a0vlLif2jd +CllNkMyMW2NBjLbPCIdNLnelyi9JDV0moAoCAlcu5hlv0iaoL7+PnVr6lzmragauGA6 TKqHGmXogBvtl0E74Y79qUbHihQXnbIoKQVxCUR4J78L3fGS8vWL0983IyouuiE752oT 1L/b7b10CbeX5Rat1eZAmlDGaquHU2Jsk4MlkdR8T3dWF8iel3f0pMl06C4/Mue7L4Wo 682dw5Fx2QAdIU4iIlDU1YR+Yo7xlit8m8iMx2+qRHb5C/xHNFz/UdhLu06/y3B7oQ+x 3ZZg== MIME-Version: 1.0 X-Received: by 10.152.19.66 with SMTP id c2mr38771946lae.64.1410885298047; Tue, 16 Sep 2014 09:34:58 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Tue, 16 Sep 2014 09:34:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Sep 2014 09:34:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Newton Content-Type: multipart/alternative; boundary=089e01493e4602506005033155af Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/LuCZsKyQSRxxfzCi5LLn5a3-sns Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 16:35:02 -0000 --089e01493e4602506005033155af Content-Type: text/plain; charset=UTF-8 On Tue, Sep 16, 2014 at 8:45 AM, Andrew Newton wrote: > On Tue, Sep 16, 2014 at 2:21 AM, Murray S. Kucherawy > wrote: > > 2) Also in Section 1, "forward DNS names" might be more simply expressed > as > > "domain names". > > Well, that is less accurate as the reverse DNS is also composed of domain > names. > Hmm, right. I just think "forward DNS" is practically a term of art; end users won't necessarily know what that means if it appears in the output they see. > 8) Starting about here and throughout the document, there are lots of > > "should", "may", "optional", etc. that are all lowercase. We might get > some > > whining about the fact that they're RFC2119 words. You could go through > and > > tweak the text if you're so inclined to avoid this. > > So what is the excepted practice now with 2119? Even uncapitalized > 2119 words have 2119 meaning now? Or can we explicitly say up front > that when we want to attach 2119 meaning, those words are in caps? > I don't really like this issue either, and I only bring it up because it's been brought up for other documents in the past. How it gets resolved unfortunately depends on who's reviewing it. The problem is that RFC2119 doesn't say that "SHOULD" only means "SHOULD" when it's in all-caps, which was probably an oversight when that RFC was written. Some people suggest including modified RFC2119 boilerplate that specifically says only the all-caps versions carry the RFC2119 meaning, others argue that's not necessary, etc. I think I brought it up because if we can sidestep it by simply using a different word, then we avoid the problem altogether. But it's a pain to have to do that now. I guess we can leave this as-is, but it might come back to us later. > > 11) In Section 5.1, this "should" is probably supposed to be a "SHOULD". > > I don't know about that. Not using the prefix will also likely not > cause problems. Using it is more a matter of style and a way for > programmers to reference back to the IANA registry. > On re-reading, I actually don't understand the sentence containing that SHOULD. Is it trying to encourage operators to use registered prefixes when using their own custom tokens in responses? > 16) In Section 5.7, should we also allow an IP address? > > Specifying an IP address is bad practice. I would hope most registries > have their whois infrastructure behind load balancers or multiple DNS > entries, etc... > That's interesting... Why is it bad practice? It's certainly inconvenient to humans that want to hit the WHOIS server from the command line, but is it harmful? > 17) In Section 5.8, do the valid types need to be enumerated? > > As we don't validate them, no. > OK; I ask because there are other places where "type" refers to something enumerated, but here it doesn't. > 21) Has anyone tried putting all of the JSON examples through a JSON > parser > > just to see if they at least conform to basic JSON syntax? > > I have, though not lately. The elided examples require editing though. > OK. That might be a good idea before this goes up (though I know it's a bit time consuming). > > 30) In Section 11.2, why force everything to lowercase rather than just > > making comparisons case-insensitive? > > Since they are identifiers, a straight string comparison is all that > is required. It's also about style of the raw JSON. > Does requiring lowercase mean anything to non-English character sets? > > 31) Also about Section 11.2, it helps the IESG when creating a registry > like > > this to recommend some people to act as the designated experts. I > propose > > we have two DNR and two RIR representatives. Does anyone want to > volunteer? > > I can do it. > Great! Anyone else, especially at least one DNR representative? > > 34) In Section 11.2.2, registration #1, I remember this being a topic of > > some discussion. I think it had something to do with the notion of > > "validated" being unspecified. Do we need to say more about that here? > > That would up to individual policy of the registry. I don't think we > should specify it. > OK; I suggest then that we make it explicit that we're punting on this one. Thanks! -MSK --089e01493e4602506005033155af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 16, 2014 at 8:45 AM, Andrew Newton <andy@hxr.us> wrote:
On Tue, Sep 16, 2014 at = 2:21 AM, Murray S. Kucherawy
<superuser@gmail.com> wrot= e:
> 2) Also in Section 1, "forward DNS names" might be more simp= ly expressed as
> "domain names".

Well, that is less accurate as the reverse DNS is also composed of d= omain names.

Hmm, right.=C2=A0 I just t= hink "forward DNS" is practically a term of art; end users won= 9;t necessarily know what that means if it appears in the output they see.<= br>
> 8) Starting about here and throughout the document, t= here are lots of
> "should", "may", "optional", etc. that a= re all lowercase.=C2=A0 We might get some
> whining about the fact that they're RFC2119 words.=C2=A0 You could= go through and
> tweak the text if you're so inclined to avoid this.

So what is the excepted practice now with 2119? Even uncapitalized 2119 words have 2119 meaning now? Or can we explicitly say up front
that when we want to attach 2119 meaning, those words are in caps?

I don't really like this issue either, and = I only bring it up because it's been brought up for other documents in = the past.=C2=A0 How it gets resolved unfortunately depends on who's rev= iewing it.=C2=A0 The problem is that RFC2119 doesn't say that "SHO= ULD" only means "SHOULD" when it's in all-caps, which wa= s probably an oversight when that RFC was written.=C2=A0 Some people sugges= t including modified RFC2119 boilerplate that specifically says only the al= l-caps versions carry the RFC2119 meaning, others argue that's not nece= ssary, etc.

I think I brought it up because if we can sid= estep it by simply using a different word, then we avoid the problem altoge= ther.=C2=A0 But it's a pain to have to do that now.

I= guess we can leave this as-is, but it might come back to us later.
=C2= =A0
> 11) In Section 5.1, this "should" is probab= ly supposed to be a "SHOULD".

I don't know about that. Not using the prefix will also likely n= ot
cause problems. Using it is more a matter of style and a way for
programmers to reference back to the IANA registry.
On re-reading, I actually don't understand the sentence co= ntaining that SHOULD.=C2=A0 Is it trying to encourage operators to use regi= stered prefixes when using their own custom tokens in responses?

> 16) In Section 5.7, should we also allow an IP addres= s?

Specifying an IP address is bad practice. I would hope most registri= es
have their whois infrastructure behind load balancers or multiple DNS
entries, etc...

That's interesting.= .. Why is it bad practice?=C2=A0 It's certainly inconvenient to humans = that want to hit the WHOIS server from the command line, but is it harmful?=

> 17) In Section 5.8, do the valid types need to be enu= merated?

As we don't validate them, no.

OK; I ask because there are other places where "type" refers t= o something enumerated, but here it doesn't.

> 21) Has anyone tried putting all of the JSON examples= through a JSON parser
> just to see if they at least conform to basic JSON syntax?

I have, though not lately. The elided examples require editing thoug= h.

OK.=C2=A0 That might be a good idea = before this goes up (though I know it's a bit time consuming).
=C2= =A0
> 30) In Section 11.2, why force everything to lowercas= e rather than just
> making comparisons case-insensitive?

Since they are identifiers, a straight string comparison is all that=
is required. It's also about style of the raw JSON.

Does requiring lowercase mean anything to non-English char= acter sets?
=C2=A0
> 31) Also about Section 11.2, it helps the IESG when c= reating a registry like
> this to recommend some people to act as the designated experts.=C2=A0 = I propose
> we have two DNR and two RIR representatives.=C2=A0 Does anyone want to= volunteer?

I can do it.

Great!=C2=A0 Anyone= else, especially at least one DNR representative?
=C2=A0
> 34) In Section 11.2.2, registration #1, I remember th= is being a topic of
> some discussion.=C2=A0 I think it had something to do with the notion = of
> "validated" being unspecified.=C2=A0 Do we need to say more = about that here?

That would up to individual policy of the registry. I don't thin= k we
should specify it.

OK; I suggest then t= hat we make it explicit that we're punting on this one.

Thanks!
-MSK
--089e01493e4602506005033155af-- From nobody Tue Sep 16 10:05:24 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEA71A885B for ; Tue, 16 Sep 2014 10:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqhPHoExa8KD for ; Tue, 16 Sep 2014 10:05:19 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77031A87E1 for ; Tue, 16 Sep 2014 10:05:19 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id v10so179560pde.19 for ; Tue, 16 Sep 2014 10:05:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dvKv7ZC+FcS9dCTFkYpK0YvEv59szvKR9l4cuHNErfk=; b=nLDaT7HtHPjXkjHhdgsozdLuoNg+sQ2ox98yBIW649y4SPV98OCJN0RoU7mq9fTYer UpY+vT2sMmD9ihsuyWRHtVOrctJjLTRB/MJFbM76eQ7RY+72EI3JwtLm9XI1/LZYMoHa rkP+HvR5uFFkLLLfgu1l4APpfnKQwQB5kAiIEiarGw0nf5U0zieRuctcNJhy0XzDkAPW Bop+B/UjHmtqGZzdG+eGG29pz/Of6KWmGXz6mUYHSrJBLyvhC4RTMzdH4mM/SxPsRwMo L7iH8HEkycmP2rFDeqajmHyUvxs97twqKUPshysTPfx+sU5dcwCFLAqD2Dm8+2rqPWS8 Kj7w== X-Gm-Message-State: ALoCoQmfJBrczGxiIEqRLk9vVQg7V1b8MnWYEpNi7tA8UIsLrCPvyjNw6gh67BZz8IOgv0tp1Enx MIME-Version: 1.0 X-Received: by 10.70.89.108 with SMTP id bn12mr2560119pdb.146.1410887119307; Tue, 16 Sep 2014 10:05:19 -0700 (PDT) Received: by 10.66.159.3 with HTTP; Tue, 16 Sep 2014 10:05:19 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: References: Date: Tue, 16 Sep 2014 13:05:19 -0400 Message-ID: From: Andrew Newton To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/kDTTELEVUMSoRtTRoCqHgT-mwbI Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 17:05:21 -0000 On Tue, Sep 16, 2014 at 12:34 PM, Murray S. Kucherawy wrote: > On Tue, Sep 16, 2014 at 8:45 AM, Andrew Newton wrote: >> >> On Tue, Sep 16, 2014 at 2:21 AM, Murray S. Kucherawy >> wrote: >> > 2) Also in Section 1, "forward DNS names" might be more simply expressed >> > as >> > "domain names". >> >> Well, that is less accurate as the reverse DNS is also composed of domain >> names. > > > Hmm, right. I just think "forward DNS" is practically a term of art; end > users won't necessarily know what that means if it appears in the output > they see. Why would they see it in output? This is just a description of the types of registries using RDAP. > >> > 8) Starting about here and throughout the document, there are lots of >> > "should", "may", "optional", etc. that are all lowercase. We might get >> > some >> > whining about the fact that they're RFC2119 words. You could go through >> > and >> > tweak the text if you're so inclined to avoid this. >> >> So what is the excepted practice now with 2119? Even uncapitalized >> 2119 words have 2119 meaning now? Or can we explicitly say up front >> that when we want to attach 2119 meaning, those words are in caps? > > > I don't really like this issue either, and I only bring it up because it's > been brought up for other documents in the past. How it gets resolved > unfortunately depends on who's reviewing it. The problem is that RFC2119 > doesn't say that "SHOULD" only means "SHOULD" when it's in all-caps, which > was probably an oversight when that RFC was written. Some people suggest > including modified RFC2119 boilerplate that specifically says only the > all-caps versions carry the RFC2119 meaning, others argue that's not > necessary, etc. > I'm partial to this solution. > I think I brought it up because if we can sidestep it by simply using a > different word, then we avoid the problem altogether. But it's a pain to > have to do that now. > > I guess we can leave this as-is, but it might come back to us later. > >> >> > 11) In Section 5.1, this "should" is probably supposed to be a "SHOULD". >> >> I don't know about that. Not using the prefix will also likely not >> cause problems. Using it is more a matter of style and a way for >> programmers to reference back to the IANA registry. > > > On re-reading, I actually don't understand the sentence containing that > SHOULD. Is it trying to encourage operators to use registered prefixes when > using their own custom tokens in responses? Yes, and the prefix registry stops collisions. > >> > 16) In Section 5.7, should we also allow an IP address? >> >> Specifying an IP address is bad practice. I would hope most registries >> have their whois infrastructure behind load balancers or multiple DNS >> entries, etc... > > > That's interesting... Why is it bad practice? It's certainly inconvenient > to humans that want to hit the WHOIS server from the command line, but is it > harmful? For the same reason a website shouldn't use it. If you want to move that web site to a different host but everybody has the IP address, that is a problem. >> >> > 30) In Section 11.2, why force everything to lowercase rather than just >> > making comparisons case-insensitive? >> >> Since they are identifiers, a straight string comparison is all that >> is required. It's also about style of the raw JSON. > > > Does requiring lowercase mean anything to non-English character sets? I don't know. But since these are protocol tokens and the IETF specifies things in English, we should probably add "should be English" to the list. -andy From nobody Tue Sep 16 10:10:39 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6080D1A87BF for ; Tue, 16 Sep 2014 10:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwnGAcTW8Fr2 for ; Tue, 16 Sep 2014 10:10:34 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C700C1A6F66 for ; Tue, 16 Sep 2014 10:10:30 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKVBhvBq0e61lh78Zu9s1hzt91R5PTGTgP@postini.com; Tue, 16 Sep 2014 10:10:34 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 s8GHASnJ022210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Sep 2014 13:10:28 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 16 Sep 2014 13:10:27 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , Ning Kong Thread-Topic: [weirds] Comments on draft-ietf-weirds-rdap-sec Thread-Index: AQHP0LMs9mffhQfSuEKo2FUQtmUMW5wEGKEAgAAcUYD//8upYA== Date: Tue, 16 Sep 2014 17:10:26 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494B50B4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <37551984-88C8-4E86-9CCD-60BB91B636F2@cnnic.cn> 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_831693C2CDA2E849A7D7A712B24E257F494B50B4BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/7WgY-58Ktzw7e_ky5PBvQrVIqFw Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 17:10:36 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F494B50B4BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogd2VpcmRzIFttYWlsdG86d2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTYsIDIwMTQg MTI6MTcgUE0NClRvOiBOaW5nIEtvbmcNCkNjOiB3ZWlyZHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbd2VpcmRzXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXdlaXJkcy1yZGFwLXNlYw0KDQpPbiBU dWUsIFNlcCAxNiwgMjAxNCBhdCA3OjM1IEFNLCBOaW5nIEtvbmcgPG5rb25nQGNubmljLmNuPG1h aWx0bzpua29uZ0Bjbm5pYy5jbj4+IHdyb3RlOg0KTXkgb25seSBxdWVzdGlvbiBpcyBhYm91dCBT ZWN0aW9uIDMuMS4xIHdoaWNoIHRhbGtzIGFib3V0IGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbnMu ICBBbGwgb2YgdGhlIDMueCBzZWN0aW9ucyBleGNlcHQgdGhpcyBvbmUgYXJlIG9mIHRoZSBmb3Jt ICJSREFQIG5lZWRzIHRvIGRvIFgsIHNvIGhlcmUncyBob3cgeW91IGRvIFgiLiAgVGhpcyBvbmUg ZGVzY3JpYmVzIGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiBhbmQgc2F5cyB0aGF0IGFuIFJEQVAg c2VydmVyIG1pZ2h0IGRvIGl0IGlmIGl0IHdhbnRzIHRvLCBhbmQgbGlzdHMgYSBmZXcgd2F5cyB0 byBkbyBzbyAoT0F1dGgsIE9wZW5JRCkuICBJJ20gbm90IHRvdGFsbHkgZmFtaWxpYXIgd2l0aCB0 aGVzZSwgc28gdGhpcyBtaWdodCBiZSBhIG5haXZlIHF1ZXN0aW9uOiBJcyB0aGVyZSBhbnkgbmVl ZCBmb3IgdXMgdG8gaW5jbHVkZSBhIG1lY2hhbmlzbSBieSB3aGljaCBhbiBSREFQIHNlcnZlciBj YW4gYmUgZGlzY292ZXJlZCB0byBiZSBwYXJ0IG9mIHN1Y2ggYSBmZWRlcmF0aW9uPyAgRm9yIGV4 YW1wbGUsIHNob3VsZCBhbiBSREFQIGNsaWVudCBiZSBhYmxlIHRvIGNvbnRhY3QsIHNheSwgcmRh cC5hcmluLm5ldDxodHRwOi8vcmRhcC5hcmluLm5ldC8+IGFuZCBkaXNjb3ZlciB0aGF0IGl0J3Mg ZmVkZXJhdGVkIHdpdGggTEFDTklDJ3Mgc2VydmVyIHZpYSBhbiBhcnJhbmdlbWVudCB1c2luZyBP QXV0aD8gIE9yIGlzIHRoYXQgc29ydCBvZiB0aGluZyBhcnJhbmdlZCBhbmQgZGlzY292ZXJlZCBj b21wbGV0ZWx5IG91dCBvZiBiYW5kPw0KSGkgTXVycmF5LCBJIHRoaW5rIHRoaXMga2luZCBvZiBt ZWNoYW5pc20geW91IHN1cHBvc2VkIGlzIHVzZWZ1bCBidXQgaXQgaXMgbm93IG91dCBvZiBzY29w ZSBmb3IgdGhlIGN1cnJlbnQgZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9uIHByb3RvY29scyAoT0F1 dGgsIE9wZW5JRCkuIEFzIGZhciBhcyBJIGtub3csIHRoaXMga2luZCBvZiBtZWNoYW5pc20gaXMg dXN1YWxseSBpbXBsZW1lbnRlZCBieSBjdXJyZW50IHdlYiBhcHBsaWNhdGlvbnMgdGhyb3VnaCBz b21lIG91dCBvZiBiYW5kIHdheXMuDQoNCg0KSXMgaXQgd29ydGggYWRkaW5nIGEgc2VudGVuY2Ug b3IgdHdvIGluZGljYXRpbmcgdGhpcyBpbiB0aGUgZG9jdW1lbnQ/ICBTb21ldGhpbmcgbGlrZSAi QXQgdGhlIHRpbWUgb2YgdGhpcyBkb2N1bWVudCdzIHB1YmxpY2F0aW9uLCBuZWdvdGlhdGlvbiBv ciBhZHZlcnRpc2VtZW50IG9mIGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlcyBpcyBh IGRldmVsb3BpbmcgbWVjaGFuaXNtIGFuZCBpcyB0aGVyZWZvcmUgbm90IGRpc2N1c3NlZCBoZXJl LiINCkl0J3Mgbm90IGNyaXRpY2FsIHRoYXQgdGhpcyBiZSBhZGRlZCwganVzdCBhIHN1Z2dlc3Rp b24uICBJIGp1c3QgZmVlbCBsaWtlIHdlIHBvaW50IHRvIHRoaXMgY29vbCBpZGVhIGFuZCB0aGVu IHNheSBhYnNvbHV0ZWx5IG5vdGhpbmcgZnVydGhlciBhYm91dCBob3cgdG8gdXNlIGl0IHdpdGgg UkRBUC4gIElmIHRoYXQncyB0aGUgYmVzdCB3ZSBjYW4gZG8gcmlnaHQgbm93LCBpdCBtaWdodCBi ZSB1c2VmdWwgdG8gc2F5IHNvLg0KDQpbU0FIXSBUaGF0IHNlZW1zIHJlYXNvbmFibGUuDQoNClNj b3R0DQoNCg== --_000_831693C2CDA2E849A7D7A712B24E257F494B50B4BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gd2VpcmRzIFttYWlsdG86d2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPk11cnJheSBTLiBLdWNoZXJhd3k8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg U2VwdGVtYmVyIDE2LCAyMDE0IDEyOjE3IFBNPGJyPg0KPGI+VG86PC9iPiBOaW5nIEtvbmc8YnI+ DQo8Yj5DYzo8L2I+IHdlaXJkc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3dl aXJkc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi13ZWlyZHMtcmRhcC1zZWM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBTZXAgMTYs IDIwMTQgYXQgNzozNSBBTSwgTmluZyBLb25nICZsdDs8YSBocmVmPSJtYWlsdG86bmtvbmdAY25u aWMuY24iIHRhcmdldD0iX2JsYW5rIj5ua29uZ0Bjbm5pYy5jbjwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IG9ubHkgcXVlc3Rpb24g aXMgYWJvdXQgU2VjdGlvbiAzLjEuMSB3aGljaCB0YWxrcyBhYm91dCBmZWRlcmF0ZWQgYXV0aGVu dGljYXRpb25zLiZuYnNwOyBBbGwgb2YgdGhlIDMueCBzZWN0aW9ucyBleGNlcHQgdGhpcyBvbmUg YXJlIG9mIHRoZSBmb3JtICZxdW90O1JEQVAgbmVlZHMgdG8gZG8gWCwgc28gaGVyZSdzIGhvdyB5 b3UgZG8gWCZxdW90Oy4mbmJzcDsgVGhpcyBvbmUgZGVzY3JpYmVzIGZlZGVyYXRlZCBhdXRoZW50 aWNhdGlvbiBhbmQNCiBzYXlzIHRoYXQgYW4gUkRBUCBzZXJ2ZXIgbWlnaHQgZG8gaXQgaWYgaXQg d2FudHMgdG8sIGFuZCBsaXN0cyBhIGZldyB3YXlzIHRvIGRvIHNvIChPQXV0aCwgT3BlbklEKS4m bmJzcDsgSSdtIG5vdCB0b3RhbGx5IGZhbWlsaWFyIHdpdGggdGhlc2UsIHNvIHRoaXMgbWlnaHQg YmUgYSBuYWl2ZSBxdWVzdGlvbjogSXMgdGhlcmUgYW55IG5lZWQgZm9yIHVzIHRvIGluY2x1ZGUg YSBtZWNoYW5pc20gYnkgd2hpY2ggYW4gUkRBUCBzZXJ2ZXIgY2FuIGJlIGRpc2NvdmVyZWQNCiB0 byBiZSBwYXJ0IG9mIHN1Y2ggYSBmZWRlcmF0aW9uPyZuYnNwOyBGb3IgZXhhbXBsZSwgc2hvdWxk IGFuIFJEQVAgY2xpZW50IGJlIGFibGUgdG8gY29udGFjdCwgc2F5LA0KPGEgaHJlZj0iaHR0cDov L3JkYXAuYXJpbi5uZXQvIiB0YXJnZXQ9Il9ibGFuayI+cmRhcC5hcmluLm5ldDwvYT4gYW5kIGRp c2NvdmVyIHRoYXQgaXQncyBmZWRlcmF0ZWQgd2l0aCBMQUNOSUMncyBzZXJ2ZXIgdmlhIGFuIGFy cmFuZ2VtZW50IHVzaW5nIE9BdXRoPyZuYnNwOyBPciBpcyB0aGF0IHNvcnQgb2YgdGhpbmcgYXJy YW5nZWQgYW5kIGRpc2NvdmVyZWQgY29tcGxldGVseSBvdXQgb2YgYmFuZD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE11cnJheSwgSSB0aGluayB0aGlzIGtpbmQgb2YgbWVj aGFuaXNtIHlvdSBzdXBwb3NlZCBpcyB1c2VmdWwgYnV0IGl0IGlzIG5vdyBvdXQgb2Ygc2NvcGUg Zm9yIHRoZSBjdXJyZW50IGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiBwcm90b2NvbHMgKE9BdXRo LCBPcGVuSUQpLiBBcyBmYXIgYXMgSSBrbm93LCB0aGlzIGtpbmQgb2YgbWVjaGFuaXNtIGlzIHVz dWFsbHkgaW1wbGVtZW50ZWQgYnkgY3VycmVudCB3ZWINCiBhcHBsaWNhdGlvbnMgdGhyb3VnaCBz b21lIG91dCBvZiBiYW5kIHdheXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPklzIGl0IHdvcnRoIGFkZGluZyBhIHNlbnRlbmNlIG9yIHR3byBpbmRp Y2F0aW5nIHRoaXMgaW4gdGhlIGRvY3VtZW50PyZuYnNwOyBTb21ldGhpbmcgbGlrZSAmcXVvdDtB dCB0aGUgdGltZSBvZiB0aGlzIGRvY3VtZW50J3MgcHVibGljYXRpb24sIG5lZ290aWF0aW9uIG9y IGFkdmVydGlzZW1lbnQgb2YgZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9uIHNlcnZpY2VzIGlzIGEg ZGV2ZWxvcGluZw0KIG1lY2hhbmlzbSBhbmQgaXMgdGhlcmVmb3JlIG5vdCBkaXNjdXNzZWQgaGVy ZS4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkl0J3Mgbm90IGNyaXRpY2FsIHRoYXQgdGhpcyBiZSBhZGRlZCwganVzdCBhIHN1Z2dlc3Rp b24uJm5ic3A7IEkganVzdCBmZWVsIGxpa2Ugd2UgcG9pbnQgdG8gdGhpcyBjb29sIGlkZWEgYW5k IHRoZW4gc2F5IGFic29sdXRlbHkgbm90aGluZyBmdXJ0aGVyIGFib3V0IGhvdyB0byB1c2UgaXQg d2l0aCBSREFQLiZuYnNwOyBJZiB0aGF0J3MgdGhlIGJlc3Qgd2UgY2FuIGRvIHJpZ2h0IG5vdywg aXQgbWlnaHQgYmUgdXNlZnVsIHRvDQogc2F5IHNvLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bU0FIXSBU aGF0IHNlZW1zIHJlYXNvbmFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNj b3R0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_831693C2CDA2E849A7D7A712B24E257F494B50B4BRN1WNEXMBX01vc_-- From nobody Tue Sep 16 11:01:27 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489DE1A6F8D for ; Tue, 16 Sep 2014 11:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2imSoGHnLMLW for ; Tue, 16 Sep 2014 11:01:20 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29731A03CF for ; Tue, 16 Sep 2014 11:01:19 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so316794lam.0 for ; Tue, 16 Sep 2014 11:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y/QPeQMuYac1+AvRnKLpMWGmniue8KMyrNa96XTMLgk=; b=YnMQyOscQrbi6vFewPcXEc8F0FN2MXT/XjzLyH0O5085KK83qu8ib3SIQGxXok09Y0 BBskvI4r/2QEni/EiB5igbj36bpbTc/3k/FFaUqv8W1n7ejsAM6PjgVK5HPTkw+fqzwI fK9QBH1gzjgYAIvbR57MNLMfC6v/pP/OZJ65oeGDHnRg5CRrrhot/tNo7ikkXe1BUWdd 190lOaphqfTB4TKdCp3uVxl6378wePzAOUJg7FDbydmBopZzkjz/AD5XqdrMHzIa82uH Tfo+ueASP8zQQ+LRfVgWsF7bnM8waFuTYPuPGZZz4uqBXxhK9EaH+SXrzYwRIJt1zytp 1QtQ== MIME-Version: 1.0 X-Received: by 10.152.25.170 with SMTP id d10mr37880572lag.37.1410890478054; Tue, 16 Sep 2014 11:01:18 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Tue, 16 Sep 2014 11:01:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Sep 2014 11:01:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Newton Content-Type: multipart/alternative; boundary=089e0158b738c2f0b20503328901 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/iU7wAj0JtrAT-7s4o8dm5Q0PSTM Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 18:01:24 -0000 --089e0158b738c2f0b20503328901 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 16, 2014 at 10:05 AM, Andrew Newton wrote: > > Hmm, right. I just think "forward DNS" is practically a term of art; end > > users won't necessarily know what that means if it appears in the output > > they see. > > Why would they see it in output? This is just a description of the > types of registries using RDAP. > Not all implementers are as thoughtful as you are. :-) > > I don't really like this issue either, and I only bring it up because > it's > > been brought up for other documents in the past. How it gets resolved > > unfortunately depends on who's reviewing it. The problem is that RFC2119 > > doesn't say that "SHOULD" only means "SHOULD" when it's in all-caps, > which > > was probably an oversight when that RFC was written. Some people suggest > > including modified RFC2119 boilerplate that specifically says only the > > all-caps versions carry the RFC2119 meaning, others argue that's not > > necessary, etc. > > I'm partial to this solution. > > > I think I brought it up because if we can sidestep it by simply using a > > different word, then we avoid the problem altogether. But it's a pain to > > have to do that now. > > > > I guess we can leave this as-is, but it might come back to us later. > Let's just leave it. I admit that I may just be projecting my own prior battle damage here, and really nobody will notice or care. > On re-reading, I actually don't understand the sentence containing that > > SHOULD. Is it trying to encourage operators to use registered prefixes > when > > using their own custom tokens in responses? > > Yes, and the prefix registry stops collisions. > OK, can we rework that sentence so it's more clear? > > That's interesting... Why is it bad practice? It's certainly > inconvenient > > to humans that want to hit the WHOIS server from the command line, but > is it > > harmful? > > For the same reason a website shouldn't use it. If you want to move > that web site to a different host but everybody has the IP address, > that is a problem. > But if the IP address changes, wouldn't the response start using the new IP address? I'll drop it here because I've made my point. I just wanted to understand the restriction here when in just about everywhere else I can think of in application space, either form is allowed. -MSK --089e0158b738c2f0b20503328901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 16, 2014 at 10:05 AM, Andrew Newton <andy@hxr.us> wrote:
> Hmm, right.=C2=A0 I= just think "forward DNS" is practically a term of art; end
> users won't necessarily know what that means if it appears in the = output
> they see.

Why would they see it in output? This is just a description of the types of registries using RDAP.

Not all= implementers are as thoughtful as you are.=C2=A0 :-)
=C2=A0
> I don't really like this issue either, and I only= bring it up because it's
> been brought up for other documents in the past.=C2=A0 How it gets res= olved
> unfortunately depends on who's reviewing it.=C2=A0 The problem is = that RFC2119
> doesn't say that "SHOULD" only means "SHOULD" = when it's in all-caps, which
> was probably an oversight when that RFC was written.=C2=A0 Some people= suggest
> including modified RFC2119 boilerplate that specifically says only the=
> all-caps versions carry the RFC2119 meaning, others argue that's n= ot
> necessary, etc.

I'm partial to this solution.

> I think I brought it up because if we can sidestep it by simply using = a
> different word, then we avoid the problem altogether.=C2=A0 But it'= ;s a pain to
> have to do that now.
>
> I guess we can leave this as-is, but it might come back to us later.

Let's just leave it.=C2=A0 I = admit that I may just be projecting my own prior battle damage here, and re= ally nobody will notice or care.

> On re-reading, I actually don't understand the sentence containing= that
> SHOULD.=C2=A0 Is it trying to encourage operators to use registered pr= efixes when
> using their own custom tokens in responses?

Yes, and the prefix registry stops collisions.
=
OK, can we rework that sentence so it's more clear?
= =C2=A0
> That's interesting... Why is it bad practice?=C2= =A0 It's certainly inconvenient
> to humans that want to hit the WHOIS server from the command line, but= is it
> harmful?

For the same reason a website shouldn't use it. If you want to m= ove
that web site to a different host but everybody has the IP address,
that is a problem.

But if the IP addres= s changes, wouldn't the response start using the new IP address?
I'll drop it here because I've made my point.=C2=A0 I just wanted = to understand the restriction here when in just about everywhere else I can= think of in application space, either form is allowed.
=C2=A0
= -MSK
--089e0158b738c2f0b20503328901-- From nobody Tue Sep 16 15:51:53 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886861A6F32 for ; Tue, 16 Sep 2014 15:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ7jUXkcM2oW for ; Tue, 16 Sep 2014 15:51:47 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8861A6F30 for ; Tue, 16 Sep 2014 15:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:date:from:to:subject:message-id:mail-followup-to: references:mime-version:content-type:content-disposition:in-reply-to: user-agent:return-path; bh=DWvm4cYvvtRmgjjchYvWU0KvecEKJ+x+Q/mUt5ALXDU=; b=Ic5rhuRopUTikZ2w4fuvdByTob6rVmZ+qT9WdIcqW3MWXBRFpckOHXR4GPpYbbBnsvbRwKORahadz nXHXiKx9lXmDONXbZdHJyr863C5kgLznM1R1F3m8YWJuJRuwZgCCP222trFJw90nXegjOEVvemb4JW x3yFQDCS9/0Fubp4= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Wed, 17 Sep 2014 08:51:34 +1000 (EST) Received: from main (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 17 Sep 2014 08:51:42 +1000 Received: from tomh by main with local (Exim 4.84) (envelope-from ) id 1XU1b4-0005oV-HJ for weirds@ietf.org; Wed, 17 Sep 2014 08:51:42 +1000 Date: Wed, 17 Sep 2014 08:51:42 +1000 From: Tom Harrison To: Message-ID: <20140916225142.GA21306@main> Mail-Followup-To: weirds@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/renKJwhCVBXICK5fTA5gmzNrpWU Subject: Re: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 22:51:49 -0000 On Mon, Sep 15, 2014 at 10:57:49AM -0700, Murray S. Kucherawy wrote: > 4) Also in Section 3, rather than requiring that all base URLs end in "/", > couldn't the client just add one if it's missing in the bootstrap object? > I'm wondering why that MUST is needed. Speaking for myself, the previous text here was: Base RDAP URLs are likely to have a trailing "/" character because they are aggregated to the various segments defined in [I-D.ietf-weirds-rdap-query]. Without any other instruction, the obvious thing for a client to do in the absence of the trailing "/" is append that "/", given the way in which the segments are defined in rdap-query. However, there is nothing prohibiting a server operator from having a bootstrap base URL like "https://registry.example.com/myrdap-", and resource paths like "https://registry.example.com/myrdap-domain/example.com". I was interested to avoid any confusion on this point, hence the suggestion for MUST. If this were replaced with text that required the appending of the "/" for bootstrap URLs that do not have it, that would work as well. > 10) In Section 5, I'm a little puzzled by the use of "longest match". I > think it's right, but we might want to add parenthetically that we're > actually looking to match the largest number of network bits. Otherwise, > I'm a little fuzzy on what "longest" might mean because IP addresses are > all the same size (within the same family). Additionally, I think it would be worth clarifying what to do when looking up a network range that is larger than any single range in the registry, or that is split equally between multiple ranges in the registry. Treating these cases in the same way as "non-existent entries" as per section 7 is probably the simplest approach. -Tom From nobody Tue Sep 16 18:23:28 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9771A212A for ; Tue, 16 Sep 2014 18:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6vXAs6Yangj for ; Tue, 16 Sep 2014 18:23:04 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B17E1A005A for ; Tue, 16 Sep 2014 18:23:04 -0700 (PDT) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D41D48A031 for ; Wed, 17 Sep 2014 01:23:02 +0000 (UTC) Date: Tue, 16 Sep 2014 21:22:56 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20140917012256.GA89444@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/9lPpFcq0gc4DUhvfiSJeEgjph_E Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 01:23:06 -0000 Hi, It would appear that I've fallen down on the job (again) because the internationalization advice in the document as it now stands is inconsistent among sections. Section 3.1.3 says to convert everything to A-labels for the purposes of matching. Section 4 recommends storing things as U-labels. I recognize my hand in some of this text, and yet it's clearly mad advice. (This may be telling me something about my state of mind.) I want to describe three things that I think we're trying to do, and then suggest an answer to Murray at the end. There are three basic problems we're facing. The first is that we want handling to be reliable, and handling of IDNs seems to be more reliable if we use only specialized name-handling code to deal with IDNA. I expect RDAP servers to cope with the whole domain name query. They're unlikely to have specialized DNS stuff in them that knows how to break the presentation-format version of a name into constituent labels in every case. (In practice, people often try to do this using the presentation-format label separator, ".". The problem is that "." is itself a legal character in some labels, and so if an RDAP client is assembling stuff from poorly-controlled data sources, it's entirely possible to get something that has an embedded dot. This is a corner case, of course, but I think it's a corner we need to cope with.) I think, not having to break the name into labels in order to convert the different labels into one form or the other and then reassemble the resulting labels into a name and then to look the name up increases the chances of success, and I think servers should be free to refuse to do that work on behalf of clients if they want. The second problem we have is that people want partial-string matching for U-labels to work pretty much the way it works for LDH-labels. So, in section 3.2.1 we say to use U-labels even though just above we just finished telling people "always match on the A-label". We _have_ to do this, because there's no way to do a partial-string match on the A-label. But worse, there isn't really a good way to do partial-string matching on a U-label either that is always reliable. For instance, suppose we have the name passé.com. Now, the string passé when NFC-normalized uses U+00E9. But the decomposition form would use e (U+0065) and the combining acute accent (U+0301). The document now says that you're not allowed to do partial-matching "where a Unicode character may be legally combined with another Unicode character or characters," but the simple fact is that, due to combining characters, _any_ characters can in fact be combined. And in the case of "passe*", it looks like an LDH query, but it might not be. (Fine: our answer to that is "passé" doesn't match and "passed" does; but now respecting "Clients should avoid submitting a partial match search of Unicode characters where a Unicode character may be legally combined with another Unicode character or characters," looks like a taller order.) The third problem we have is that we didn't want to wait on precis profiles to cope with most of this, deciding instead to try to do it in the document. I _think_ we got the rules right in section 4 (I think I contributed some text, but I can't remember for sure), but I don't know quite how carefully it's been reviewed. On Mon, Sep 15, 2014 at 12:46:55AM -0700, Murray S. Kucherawy wrote: > 4) Section 3.1.3 has SHOULDs and SHOULD NOTs, but I'm wondering why they > aren't MUSTs and MUST NOTs. Otherwise, under what conditions would one > deviate from the advice, and in what way (i.e., what alternatives are > there)? Some of us thought that MUST [NOT] was the right specification, but people pointed out that you might be sending things from a system that wasn't IDNA-clever and so didn't know how to do the conversion. Hence the SHOULDs. We had a discussion about how to handle the case where the server can't cope with the mixed form, and I don't think we came to a conclusion about what error to return. Here's another possible addition of text, in case it helps: […] IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, all internationalized labels in an IDN SHOULD be either A-labels or U-labels. It is possible for an RDAP client to assemble a query string from multiple independent data sources. Such a client might not be able to perform conversions between A-labels and U-labels. An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup. In such cases, the response to be returned to the query source may not match the input from the query source. Alternatively, the server MAY refuse to process the query. [I _think_ the right response in that case is 400, but I defer to others on it.] On another note, I still think that If the client sends the server an IDN in U-label format, servers that support IDNs MUST convert the IDN into A-label format and perform IDNA processing as specified in RFC 5891 [RFC5891]. The server should perform an exact match lookup using the A-label. is overspecifying in the last sentence. It could say instead "The server MAY perform the match using either the A-label or U-label form; using one consistent form for matching every label is likely to be more reliable." The point of the "peform IDNA processing" is to ensure that the putative U-label in hand really is a valid IDN that could (in A-label form) be in the DNS. I don't think we care how actual matches in people's databases are performed. I think we arrived at "should match A-label form" because, if you've already done all this work, the match is more likely to be correct. > 5) Section 3.1.4, same thing. This should work the same. Maybe a reference back to the previous section. > 7) Same question about the SHOULDs in Section 4. I'm much more nervous about the discussion in section 4, and I think it wouldn't be a bad idea to try to get some review from people in precis or on the idnabis list or something. (Did we already do that and I've just been running to hard to see it? If so, apologies.) The SHOULD NOT in Servers SHOULD NOT partially match combinations of Unicode characters where a Unicode character may be legally combined with another Unicode character or characters. is basically a way of weaseling out of the combining-character problem I was talking about above, without getting into a deep discussion of all the ways that this precept can be violated. Would it help to say, "It should be noted that, because of the way combining characters can be combined with many other charactes, it may not always be possible to detect possible cases where a character could have been combined with another character, but was not"? I read the document through, and the rest of the sections look sane to me. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Sep 16 19:24:11 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2781A00CF for ; Tue, 16 Sep 2014 19:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPTj9ZWcMPri for ; Tue, 16 Sep 2014 19:23:30 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id E51401A00CD for ; Tue, 16 Sep 2014 19:23:29 -0700 (PDT) Received: from [218.241.103.156] (unknown [218.241.103.156]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CZoJCe8BhUWX0EAA--.9725S2; Wed, 17 Sep 2014 10:23:27 +0800 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_CEE02A2B-12C8-40CF-8A11-26559FBE1056" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494B50B4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 17 Sep 2014 10:23:26 +0800 Message-Id: <2F537A80-1576-4770-A6EE-25DE13955001@cnnic.cn> References: <37551984-88C8-4E86-9CCD-60BB91B636F2@cnnic.cn> <831693C2CDA2E849A7D7A712B24E257F494B50B4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0CZoJCe8BhUWX0EAA--.9725S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Aw4Uuw17Aw1fuw43XF18Krg_yoW8GF47pa yYkrs2vas8tw48A3Z5Zw10gry29Fs3CFW7CFyDA342y3sxt3WvqF9rKw4Yka4UuFW0vFyj vrs2kF98ur9YyaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9vb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k0 8I80eVWUJVW8JwAqx4xG64kEw2xG04xIwI0_Gr0_Xr1lYx0E2Ix0cI8IcVAFwI0_JrI_Jr ylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxG rwCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK67AK6r4UMxAIw28IcxkI7VAKI48JMxC20s 026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_ JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14 v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xva j40_Zr0_Wr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr 0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8w2-UUUUUU== X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/SF44ebdZolrxjEYQOkRRbgjbsKk Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 02:23:32 -0000 --Apple-Mail=_CEE02A2B-12C8-40CF-8A11-26559FBE1056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 >=20 > Is it worth adding a sentence or two indicating this in the document? = Something like "At the time of this document's publication, negotiation = or advertisement of federated authentication services is a developing = mechanism and is therefore not discussed here." >=20 > It's not critical that this be added, just a suggestion. I just feel = like we point to this cool idea and then say absolutely nothing further = about how to use it with RDAP. If that's the best we can do right now, = it might be useful to say so. >=20 > [SAH] That seems reasonable. +1 IMO, although the OAUTH WG is still developing several working group = documents (e.g. draft-ietf-oauth-dyn-reg-20, = draft-ietf-oauth-dyn-reg-management-05), these working group documents = don=A1=AFt actually cover the mechanism we=A1=AFre discussing. It seems = to me that such mechanism is out of scope of the current charter of the = OAUTH WG. So I=A1=AFm afraid the word =A1=B0developing=A1=B1 is = appropriate. So, if we=A1=AFd like to add some text on this issue, I prefer the = following modified text based on Murray=A1=AFs. At the time of this document's publication, negotiation or advertisement = of federated authentication services is still an undefined mechanism by = the above federated authentication protocols. Developing this mechanism = is beyond the scope of this document.=20 Any comments or suggestions to update the above text are welcome. Cheers, Ning= --Apple-Mail=_CEE02A2B-12C8-40CF-8A11-26559FBE1056 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312

Is it = worth adding a sentence or two indicating this in the document?  = Something like "At the time of this document's publication, negotiation = or advertisement of federated authentication services is a developing = mechanism and is therefore not discussed = here."

It's not = critical that this be added, just a suggestion.  I just feel like = we point to this cool idea and then say absolutely nothing further about = how to use it with RDAP.  If that's the best we can do right now, = it might be useful to say so.

[SAH] That seems = reasonable.
+1
=
IMO, although the OAUTH WG is still developing several = working group documents (e.g. draft-ietf-oauth-dyn-reg-20, = draft-ietf-oauth-dyn-reg-management-05), these working group documents = don=A1=AFt actually cover the mechanism we=A1=AFre discussing. It seems = to me that such mechanism is out of scope of the current charter of the = OAUTH WG. So I=A1=AFm afraid the word =A1=B0developing=A1=B1 is = appropriate.

So, if we=A1=AFd like to add some = text on this issue, I prefer the following modified text based on = Murray=A1=AFs.

At the time of this document's = publication, negotiation or advertisement of federated authentication = services is still an undefined mechanism by the above federated = authentication protocols. Developing this mechanism is beyond the scope = of this document. 

Any comments or = suggestions to update the above text are = welcome.

Cheers,
Ning
= --Apple-Mail=_CEE02A2B-12C8-40CF-8A11-26559FBE1056-- From nobody Tue Sep 16 19:33:43 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F78E1A6F80 for ; Tue, 16 Sep 2014 19:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRp94KmYF17M for ; Tue, 16 Sep 2014 19:32:42 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1152A1A00D8 for ; Tue, 16 Sep 2014 19:32:41 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id p9so955974lbv.14 for ; Tue, 16 Sep 2014 19:32: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=GFTRMuHEpKEFG3td0ax1PXanfG8tzB9Y2LZGeQYGxdM=; b=h+QkwBWVVuBH0RVSC+LRmKpd5Zdmk2X5oPYuIppkrRQJI7VRW46aeDn/VIf6ha8mLa zQzcfy6yv53sVU1sFAuRLApIFw9TdcpxUNobz4gD+9jPyACRYP1islMQO86QFLa6pZdG I9fHpPPYd5iW5OStEiMro/O0BzHtB79h73bUrHpA+y/rB41Ge1JyQ10FsgnD28hMf990 BBcUwwBNlFsNfJORZ/wcBVju6/zXmIkMwGQhkOWkpMKTQESDfdxnzQ8Shzbw5w0Ze7Je J8TWjmmp6TDVhe87hFI9P/xS5W2TG0bow91HgupaSaTbauO0XLnlSzo6/VZGx569h852 M58g== MIME-Version: 1.0 X-Received: by 10.152.18.199 with SMTP id y7mr41280122lad.0.1410921159790; Tue, 16 Sep 2014 19:32:39 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Tue, 16 Sep 2014 19:32:39 -0700 (PDT) In-Reply-To: <2F537A80-1576-4770-A6EE-25DE13955001@cnnic.cn> References: <37551984-88C8-4E86-9CCD-60BB91B636F2@cnnic.cn> <831693C2CDA2E849A7D7A712B24E257F494B50B4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2F537A80-1576-4770-A6EE-25DE13955001@cnnic.cn> Date: Tue, 16 Sep 2014 19:32:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ning Kong Content-Type: multipart/alternative; boundary=089e0149420889173b050339ae46 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/6qnYQmzMj3Fdw06zo8EHbr-4iIc Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 02:32:43 -0000 --089e0149420889173b050339ae46 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 16, 2014 at 7:23 PM, Ning Kong wrote: > > At the time of this document's publication, negotiation or advertisement > of federated authentication services is still an undefined mechanism by the > above federated authentication protocols. Developing this mechanism is > beyond the scope of this document. > > > Works for me, thanks! -MSK --089e0149420889173b050339ae46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--089e0149420889173b050339ae46-- From nobody Tue Sep 16 19:40:25 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8111A011F for ; Tue, 16 Sep 2014 19:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov5q9rL9l9dE for ; Tue, 16 Sep 2014 19:38:54 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC6B1A0137 for ; Tue, 16 Sep 2014 19:38:54 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ge10so993248lab.13 for ; Tue, 16 Sep 2014 19:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EB8tYetpSm5k1Z9qs0KwpzuQZvQQNjgOemdk4/GggiI=; b=fvVhO/KVzgkazWZZ+mcOrISGzO2cMscctexSFUWW5vY1NO7lMUV6ZIdz8fydYPrPm2 zMUeoUw5lRJzDCeZpHiFGAw86uFQw53lJRriwhHGGMDyYIkRYgCIORwzLbZQR3ZdXHd5 JIp/xLHhDQ96rskvfeDijeVCMzeB82QtehAHRgz+CUQ4zrfTcpuCc2V0Jo8DeLYJAN1Z 4ZhL7rtP8aaBT0T+RmdgLMmH3FHfiiKlPhv3grcd7Nr4GfvN7UqdwfAJRnyQhyMXX3SP UbcVczzp8PcGb5nRS9IxHJuYygKLSrW1OTtjkNY+bXWV3qjQyTEAcIJeHiOi4FxcCwhs uVXg== MIME-Version: 1.0 X-Received: by 10.112.55.102 with SMTP id r6mr38051263lbp.23.1410921532685; Tue, 16 Sep 2014 19:38:52 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Tue, 16 Sep 2014 19:38:52 -0700 (PDT) Date: Tue, 16 Sep 2014 19:38:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a1133d0b2c3016a050339c4db Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/CtIhjOFRqbqzGdOyzQQWVfEiT7w Subject: [weirds] Trackers and WGLC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 02:38:56 -0000 --001a1133d0b2c3016a050339c4db Content-Type: text/plain; charset=UTF-8 Document authors, If you have need of using the issue tracker for updating your documents in light of the WGLC feedback you're getting, please feel free to do so. If you need access arranged, please let me know ASAP. -MSK --001a1133d0b2c3016a050339c4db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Document authors,

If you have need of using th= e issue tracker for updating your documents in light of the WGLC feedback y= ou're getting, please feel free to do so.=C2=A0 If you need access arra= nged, please let me know ASAP.

-MSK
--001a1133d0b2c3016a050339c4db-- From nobody Wed Sep 17 00:20:58 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CABE1A0310 for ; Wed, 17 Sep 2014 00:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.383 X-Spam-Level: X-Spam-Status: No, score=-7.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6cTqUqCV6QD for ; Wed, 17 Sep 2014 00:20:56 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3EA1A02F0 for ; Wed, 17 Sep 2014 00:20:55 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Wed, 17 Sep 2014 09:20:37 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 09:20:35 +0200 From: Alexander Mayrhofer To: "weirds@ietf.org" Thread-Topic: Review of draft-ietf-weirds-using-http-11 Thread-Index: Ac/RqKJvom3EreERRdyeuHs3XhiEgw== Date: Wed, 17 Sep 2014 07:20:34 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075268879AC@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/0Q0BnTvLa066GONUWMEQSD9QRBQ Subject: [weirds] Review of draft-ietf-weirds-using-http-11 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 07:20:57 -0000 I've reviewed the "using HTTP" document, and i find it's in very good shape= . I have only a few minor comments: - Some acronyms are not expanded on first use (eg. JSON, but also HTTP and= RDAP). minor nit. - URLs could benefit from enclosing them in < >, for example at the end of = Section 5.2, where one could get the impression the final full stop is part= of the URL. ** 2. Terminology: - "HTTP User Agent" uses caps, while "HTTP server" does not. Should the lat= ter have caps too? ** 5.3. Negative Answer: - (That might have been discussed before): Are servers which are *not* auth= oritative for a certain set of objects also allowed to send back 404? From = an HTTP perspective, that is of course correct, but a client could assume t= hat eg. RDAP information for a domain (or, worse, the object itself) does n= ot exist at all, although it had just hit the "wrong" server? I don't see m= any other options in terms of response codes anyway, though... So, i think = 404 is appropriate -> Maybe add a note to the draft that if a client receives a 404, it cannot= assume the object itself does not exist (It's tricky, admitted).. ** 5.5. Rate Limiting - More of a general note - i understand that the section defines client beh= aviour in case of a 429 response code. I think we really need to be careful= that the bahaviour recommended doesn't conflict with the HTTP specs - I'm = sure that by no means we want an "Updates:" Header in this document.. (Disc= laimer: Didn't read the 429 text in the HTTP specs). I think, though, we ca= n recommend *additional* client behaviour that is not covered in the HTTP s= pecs. tia, Alex =20 From nobody Wed Sep 17 07:10:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093C61A0438 for ; Wed, 17 Sep 2014 07:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhWkcaXu-U0h for ; Wed, 17 Sep 2014 07:10:25 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 844A41A0457 for ; Wed, 17 Sep 2014 07:10:22 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 413E2164FF9; Wed, 17 Sep 2014 10:10:22 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id BD425164FEB; Wed, 17 Sep 2014 10:10:21 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 17 Sep 2014 10:11:55 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Wed, 17 Sep 2014 10:10:21 -0400 From: Andy Newton To: "Murray S. Kucherawy" Thread-Topic: [weirds] Trackers and WGLC Thread-Index: AQHP0iDWajwqDiqQi02hgVmoD8h3iZwFoQYA Date: Wed, 17 Sep 2014 14:10:20 +0000 Message-ID: <4AB38AAA-72F2-4EAA-A322-833D98E1B554@arin.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/i6cy7sjKTcUkIAJB0yx2PZfkwIA Cc: "weirds@ietf.org" Subject: Re: [weirds] Trackers and WGLC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 14:10:29 -0000 Can we go further than that? While authors can strive to enter all substant= ial issues into the tracker, ultimately the reviewers should make sure the = issues are created in the tracker. Again, I=92m talking about substantial a= nd non-editorial issues=85 ones that require discussion to resolve. -andy On Sep 16, 2014, at 10:38 PM, Murray S. Kucherawy wro= te: > Document authors, >=20 > If you have need of using the issue tracker for updating your documents i= n light of the WGLC feedback you're getting, please feel free to do so. If= you need access arranged, please let me know ASAP. >=20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Wed Sep 17 07:19:40 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4014F1A0438 for ; Wed, 17 Sep 2014 07:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obU3thPJ34PP for ; Wed, 17 Sep 2014 07:19:37 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 78D311A0110 for ; Wed, 17 Sep 2014 07:19:37 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 3512F16500B; Wed, 17 Sep 2014 10:19:37 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 69824164FBA; Wed, 17 Sep 2014 10:19:36 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 17 Sep 2014 10:21:28 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Wed, 17 Sep 2014 10:19:36 -0400 From: Andy Newton To: Alexander Mayrhofer Thread-Topic: [weirds] Review of draft-ietf-weirds-using-http-11 Thread-Index: Ac/RqKJvom3EreERRdyeuHs3XhiEgwA+0wQA Date: Wed, 17 Sep 2014 14:19:34 +0000 Message-ID: <6FFF37E5-33C7-470D-8AD4-5A64ECBA7514@arin.net> References: <19F54F2956911544A32543B8A9BDE075268879AC@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075268879AC@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7838625738B39143AC069EBB0B1278BD@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/I1B4Cf0jyHN-f3c5yaLaPtnJpw8 Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-using-http-11 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 14:19:39 -0000 On Sep 17, 2014, at 3:20 AM, Alexander Mayrhofer wrote: > - (That might have been discussed before): Are servers which are *not* au= thoritative for a certain set of objects also allowed to send back 404? Fro= m an HTTP perspective, that is of course correct, but a client could assume= that eg. RDAP information for a domain (or, worse, the object itself) does= not exist at all, although it had just hit the "wrong" server? I don't see= many other options in terms of response codes anyway, though... So, i thin= k 404 is appropriate >=20 > -> Maybe add a note to the draft that if a client receives a 404, it cann= ot assume the object itself does not exist (It's tricky, admitted).. >=20 Yes, it has been discussed over and over again. I would think that if a ser= ver is not authoritative for an object or set of objects and does not wish = to issue redirects, 404 is a good response. I don=92t think we should say that a client should assume a 404 means the o= bject does not exist universally. It just means it does not exist against t= he server being queried. If a client started with the bootstrap (either dir= ectly or through a redirect server) and ultimately ends up with a 404, then= that=92s that. If a client starts by targeting an arbitrary server and get= s a 404, they get what they deserve. > ** 5.5. Rate Limiting >=20 > - More of a general note - i understand that the section defines client b= ehaviour in case of a 429 response code. I think we really need to be caref= ul that the bahaviour recommended doesn't conflict with the HTTP specs - I'= m sure that by no means we want an "Updates:" Header in this document.. (Di= sclaimer: Didn't read the 429 text in the HTTP specs). I think, though, we = can recommend *additional* client behaviour that is not covered in the HTTP= specs. Send text, and be prepared for another round of discussions on this. -andy= From nobody Wed Sep 17 07:40:39 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09B41A048D for ; Wed, 17 Sep 2014 07:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.383 X-Spam-Level: X-Spam-Status: No, score=-7.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_9e0cmcr15o for ; Wed, 17 Sep 2014 07:40:36 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A531A0489 for ; Wed, 17 Sep 2014 07:40:35 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Wed, 17 Sep 2014 16:40:33 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 16:40:32 +0200 From: Alexander Mayrhofer To: Andy Newton Thread-Topic: [weirds] Review of draft-ietf-weirds-using-http-11 Thread-Index: Ac/RqKJvom3EreERRdyeuHs3XhiEgwA+0wQAAAgpOBA= Date: Wed, 17 Sep 2014 14:40:31 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07526887DE4@NICS-EXCH2.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE075268879AC@NICS-EXCH2.sbg.nic.at> <6FFF37E5-33C7-470D-8AD4-5A64ECBA7514@arin.net> In-Reply-To: <6FFF37E5-33C7-470D-8AD4-5A64ECBA7514@arin.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/KnMOoUH3QeOiw6Q_kutjQYdi19o Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-using-http-11 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 14:40:38 -0000 > I don't think we should say that a client should assume a 404 means the > object does not exist universally. It just means it does not exist agains= t the > server being queried. If a client started with the bootstrap (either dire= ctly or > through a redirect server) and ultimately ends up with a 404, then that's= that. > If a client starts by targeting an arbitrary server and gets a 404, they = get what > they deserve. [Alexander Mayrhofer]=20 Exactly. Actually, what i meant originally is that we should maybe add text= that a client should *not* assume an object doesn't exist universally, jus= t because it got a 404 from whatever RDAP server. However, it *might*, if t= he server is authoritative... sigh.. which, in turn, begs the question how = the client identifies whether a certain server is authoritative for a certa= in set of objects..=20 Maybe just a "warning" like Note that a 404 response code only indicates that the server queried does n= ot have any information about the object, but does not give an universal in= dication whether the object itself exists or not. (This might also cover the situation where eg. a domain name itself exists,= but RDAP information for it doesn't?) > > - More of a general note - i understand that the section defines client > behaviour in case of a 429 response code. I think we really need to be ca= reful > that the bahaviour recommended doesn't conflict with the HTTP specs - I'm > sure that by no means we want an "Updates:" Header in this document.. > (Disclaimer: Didn't read the 429 text in the HTTP specs). I think, though= , we > can recommend *additional* client behaviour that is not covered in the HT= TP > specs. >=20 > Send text, and be prepared for another round of discussions on this. [Alexander Mayrhofer]=20 Reading through RFC6585, the original specification of the 429 response cod= e doesn't seem to include *any* specification of client behaviour at all (e= xcept it must not be cached). Therefore, i think we're fine with what we do= here, and can happily avoid a round of discussion :) Alex From nobody Wed Sep 17 09:24:03 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229FB1A0662 for ; Wed, 17 Sep 2014 09:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeTNpGy8V2Pd for ; Wed, 17 Sep 2014 09:24:00 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 980FC1A0639 for ; Wed, 17 Sep 2014 09:24:00 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 56FCB165001; Wed, 17 Sep 2014 12:24:00 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id A9DEC164FD2; Wed, 17 Sep 2014 12:23:59 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 17 Sep 2014 12:25:33 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Wed, 17 Sep 2014 12:23:59 -0400 From: Andy Newton To: Alexander Mayrhofer Thread-Topic: [weirds] Review of draft-ietf-weirds-using-http-11 Thread-Index: Ac/RqKJvom3EreERRdyeuHs3XhiEgwA+0wQAAAgpOBD//+F6AA== Date: Wed, 17 Sep 2014 16:23:58 +0000 Message-ID: References: <19F54F2956911544A32543B8A9BDE075268879AC@NICS-EXCH2.sbg.nic.at> <6FFF37E5-33C7-470D-8AD4-5A64ECBA7514@arin.net> <19F54F2956911544A32543B8A9BDE07526887DE4@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE07526887DE4@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <79137579FBA2ED469F761EB9F8671BC7@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/BDXD0hHNnEctiJX9YPyZfB__MlE Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-using-http-11 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 16:24:02 -0000 On Sep 17, 2014, at 10:40 AM, Alexander Mayrhofer wrote: >> I don't think we should say that a client should assume a 404 means the >> object does not exist universally. It just means it does not exist again= st the >> server being queried. If a client started with the bootstrap (either dir= ectly or >> through a redirect server) and ultimately ends up with a 404, then that'= s that. >> If a client starts by targeting an arbitrary server and gets a 404, they= get what >> they deserve. >=20 > [Alexander Mayrhofer]=20 > Exactly. Actually, what i meant originally is that we should maybe add te= xt that a client should *not* assume an object doesn't exist universally, j= ust because it got a 404 from whatever RDAP server. However, it *might*, if= the server is authoritative... sigh.. which, in turn, begs the question ho= w the client identifies whether a certain server is authoritative for a cer= tain set of objects..=20 >=20 > Maybe just a "warning" like >=20 > Note that a 404 response code only indicates that the server queried does= not have any information about the object, but does not give an universal = indication whether the object itself exists or not. >=20 > (This might also cover the situation where eg. a domain name itself exist= s, but RDAP information for it doesn't?) While I think you and I have an understanding of this, I feel this is one o= f those things better left unsaid because we have more potential to cause c= onfusion than to bring clarity. Further, it will all shake out over time as= people implement and use RDAP. -andy= From nobody Wed Sep 17 12:42:05 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C38F1A0AD3 for ; Wed, 17 Sep 2014 12:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnCokDfLhpis for ; Wed, 17 Sep 2014 12:41:58 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D118C1A0ACD for ; Wed, 17 Sep 2014 12:41:58 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 17 Sep 2014 12:41:55 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Wed, 17 Sep 2014 12:41:55 -0700 From: Edward Lewis To: "weirds@ietf.org" Thread-Topic: Combined response to - Re: [weirds] WGLC reviews Thread-Index: AQHP0q9vq9Lv2KL1JUi3PO0x7olt2A== Date: Wed, 17 Sep 2014 19:41:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3493813306_3228277" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Iv-z7gLRikrztBnnTIEWItRyYFA Subject: [weirds] Combined response to - Re: WGLC reviews X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 19:42:02 -0000 --B_3493813306_3228277 Content-type: multipart/alternative; boundary="B_3493813306_3231907" --B_3493813306_3231907 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I read the documents and have a few comments (mostly nits). Hopefully posting in one message is sufficient. Overall the documents are ready for advancement in my opinion. Just a few nits, and wondering about the idea of =E2=80=9Cmatching=E2=80=9D non-ASCII strings beyo= nd U-labels. (Which might appear in, say, internationalized email or names of entities.) draft-ietf-weirds-using-http-11.txt No comments on that one, looks done to me. draft-ietf-weirds-redirects-04.txt section 2.1: change "provide authoritative answers***TBC=E2=80=9D section 2.2: change =E2=80=9CTBD" I haven=E2=80=99t thought of text for those. draft-ietf-weirds-rdap-sec-08.txt Idle question - would DANE offer help for rogue CA's? (Not an ask to add to doc.) This thought occurred to me reading the security considerations abou= t the reliability of the certificate authorities. Treat this as just an idle thought, it was a knee-jerk reaction I had when reading the section. draft-ietf-weirds-rdap-query-13.txt section 3.1.1: Are odd-ball ranges (192.0.2.1-192.0.2.255) considered (as relics of the past)? (Asking for my education.) page12: Is there a reference supporting the statement: "Partial matching is not feasible across combinations of Unicode" section 6: What about non-IDN Unicode items? E.g., email addresses. Perhaps they are out of scope or section 3.2.3. I=E2=80=99ve not learned much about matching or searching outside of the ASCII character set, these comments are more based on ignorance than thinking tha= t something is missing. Specifically, asking for a reference isn=E2=80=99t because= I disagree, I just want to know if there is something =E2=80=9Cestablishing=E2=80=9D that= as fact. draft-ietf-weirds-object-inventory-03.txt The document is correct, although the facts (numbers of TLDs) are dated. I.e., there are over 21 gTLDs - =E2=80=9Cway=E2=80=9D over now. But the statement is correct and I wouldn=E2=80=99t change anything - except - one of the editor=E2=80=99s address has changed (ICANN moved offices sometime back). draft-ietf-weirds-json-response-08.txt Looks fine to me, send it on. draft-ietf-weirds-bootstrap-06.txt Some nits: section 3: s/some defaults values/some default values/ section 3: s/no assumption of sorting at/no assumption of sorting within/ section 11: s/IANA own format/IANA's preferred format/ {perhaps?} I=E2=80=99m not certain =E2=80=9Cpreferred=E2=80=9D is the right word, just a suggestion. I believe that covers the open WGLC documents. From: "Murray S. Kucherawy" Date: Monday, September 15, 2014 at 13:08 To: "weirds@ietf.org" Subject: [weirds] WGLC reviews > Colleagues, >=20 > The open WGLCs on all documents end this coming Friday evening. I'm conc= erned > that we've only seen reviews from myself and Tom Harrison. >=20 > Is anyone else planning to do some? >=20 > If not, I'm concerned about being able to represent to the IESG that thes= e > documents actually have consensus within the WG, which is of course requi= red > for us to proceed on our timeline. >=20 > -MSK --B_3493813306_3231907 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
I read the documents and have a= few comments (mostly nits).  Hopefully posting in one message is suffi= cient.

= Overall the documents are ready for advancement in my opinion.  Just a = few nits, and wondering about the idea of “matching” non-ASCII s= trings beyond U-labels.  (Which might appear in, say, internationalized= email or names of entities.)

=

draft-ietf-weirds-using-http-11.txt


No comments on that one, looks done to= me.


draft-i= etf-weirds-redirects-04.txt


section 2.1: change "provide authoritative answers***TBC”

=

section 2.2: ch= ange “TBD"

I haven’t thought of text for those.


draft-ietf-weirds-rdap-sec-08.txt


Idle question - would DANE offer= help for rogue CA's? (Not an ask to add to doc.)  This thought occurre= d to me reading the security considerations about the reliability of the cer= tificate authorities.  Treat this as just an idle thought, it was a kne= e-jerk reaction I had when reading the section.


draft-ietf-weirds-rdap-query-13.txt


section 3.1.1: Are odd-ball ra= nges (192.0.2.1-192.0.2.255) considered (as relics of the past)?  (Aski= ng for my education.)

page12: Is there a reference supporting the statement:

      &n= bsp;"Partial matching is not feasible across combinations of Unicode"

section 6:= What about non-IDN Unicode items?  E.g., email addresses.  Perhap= s they are out of scope or section 3.2.3.


I’ve not learned much about matching or searchi= ng outside of the ASCII character set, these comments are more based on igno= rance than thinking that something is missing.  Specifically, asking fo= r a reference isn’t because I disagree, I just want to know if there i= s something “establishing” that as fact.


draft-ietf-weirds-object-inventory-03.txt<= /p>


The document is cor= rect, although the facts (numbers of TLDs) are dated.  I.e., there are = over 21 gTLDs - “way” over now.  But the statement is corre= ct and I wouldn’t change anything - except - one of the editor’s= address has changed (ICANN moved offices sometime back).


draft-ietf-weirds-json-response-08.tx= t


Looks fine to me,= send it on.


draft-= ietf-weirds-bootstrap-06.txt


Some nits:

section 3: s/some defaults values/some default values/

section 3: s/no assumpti= on of sorting at/no assumption of sorting within/

section 11= : s/IANA own format/IANA's preferred format/ {perhaps?}


I’m not certain “preferred&= #8221; is the right word, just a suggestion.


I believe that covers the open WG= LC documents.


From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Monday, September 15, 2014 at 13:08
To:= "weirds@ietf.org" <weirds@ietf.org>
Subject: [weirds] WGLC reviews

Colleagues,
The open WGLCs on all documents end this coming Friday evening.  I'm c= oncerned that we've only seen reviews from myself and Tom Harrison.

Is anyone else planning to do some?

If not, I'm concerned about being able to represent to the IESG that these = documents actually have consensus within the WG, which is of course required= for us to proceed on our timeline.

-MSK
--B_3493813306_3231907-- --B_3493813306_3228277 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQZ75KOdtljcsdXvJYQ EhTqZf21YjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5 MTcxOTQxNDZaMA0GCSqGSIb3DQEBAQUABIIBAJe6xImREGf8cArN5cM+0BASrg9MSQWKRFcN gHShr0/7sW+xkT0fgWZZObhpEh/HJMK9XLg4PaYFkYTT/RqdbzR+nd3h9dnHj03OFLb+/413 DQ6l6gqvT1K12AARNVOiuzSAh7yDRCbGaXdIiCBqtCaHTldk8Wn/TnimKxvOLUOZOgj1NDYn 2jPooZ1uGzKX06vnTFvvsm37bIwM07kohas24ANygAl6uiNUb4aJbISVqrnurxRN2n+E1Iaz amFH2Wbxe6R97QRFXzE5L4lHjiNvUYrOXfW6tlo6BFhipGbPWwaQn1FiOg4C7VbB5EBFa684 494L0aC5x4/nm48fihc= --B_3493813306_3228277-- From nobody Wed Sep 17 13:07:11 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADDD1A0387 for ; Wed, 17 Sep 2014 13:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.758 X-Spam-Level: * X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVBcIt-PT7KU for ; Wed, 17 Sep 2014 13:07:08 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63AF1A03C6 for ; Wed, 17 Sep 2014 13:07:08 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 813608A031 for ; Wed, 17 Sep 2014 20:07:07 +0000 (UTC) Date: Wed, 17 Sep 2014 16:07:05 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20140917200705.GO89960@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/pJU_eH5UKjOgahjghJS8n9Bwp14 Subject: Re: [weirds] Combined response to - Re: WGLC reviews X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 20:07:10 -0000 On Wed, Sep 17, 2014 at 07:41:55PM +0000, Edward Lewis wrote: > page12: Is there a reference supporting the statement: > > "Partial matching is not feasible across combinations of Unicode" > > section 6: What about non-IDN Unicode items? E.g., email addresses. > Perhaps they are out of scope or section 3.2.3. I suppose you could just read the Unicode standard and particularly how normalization works. The problem is that some conceptual characters are made up _only_ by combining code points, and there's no way to know in advance whether the series of actual code points plus the wildcard that you get is a conceptual-character-complete series of code points or not. But I am not aware of a place that makes this point quite as simply as the statement in the draft (which is strictly speaking an oversimplification). A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Sep 17 14:03:38 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3E71A6F3A for ; Wed, 17 Sep 2014 14:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKa5dQJ5PJuL for ; Wed, 17 Sep 2014 14:03: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 87A331A6F2C for ; Wed, 17 Sep 2014 14:03:36 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 3FD9B164FC3; Wed, 17 Sep 2014 17:03:36 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id C907B164F54; Wed, 17 Sep 2014 17:03:35 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 17 Sep 2014 17:05:09 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Wed, 17 Sep 2014 17:03:35 -0400 From: Andy Newton To: Edward Lewis Thread-Topic: [weirds] Combined response to - Re: WGLC reviews Thread-Index: AQHP0q9vq9Lv2KL1JUi3PO0x7olt2JwGE14A Date: Wed, 17 Sep 2014 21:03:34 +0000 Message-ID: <2684F1BC-9E7E-4F61-B641-0B212BD3992A@arin.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <78A7AC76D50F5749BF4CDF7A06F3C89F@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/hLVJTCWGSxBQhT7_1kPNdeTdFhk Cc: "weirds@ietf.org" Subject: Re: [weirds] Combined response to - Re: WGLC reviews X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 21:03:38 -0000 On Sep 17, 2014, at 3:41 PM, Edward Lewis wrote: > draft-ietf-weirds-rdap-query-13.txt >=20 > section 3.1.1: Are odd-ball ranges (192.0.2.1-192.0.2.255) considered (as= relics of the past)? (Asking for my education.) Nope. Only ARIN supports off-bit registrations and so it is not worth dorki= ng up the query syntax to support that. -andy From nobody Wed Sep 17 19:34:20 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F2E1A6F41 for ; Wed, 17 Sep 2014 19:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdUhQvPdAORl for ; Wed, 17 Sep 2014 19:34:16 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3E41B1A0079 for ; Wed, 17 Sep 2014 19:34:16 -0700 (PDT) Received: from [218.241.103.35] (unknown [218.241.103.35]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMJCMRBpUx64EAA--.10095S2; Thu, 18 Sep 2014 10:33:50 +0800 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3E40792-89D7-482F-B0CE-71F373068E75" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: Date: Thu, 18 Sep 2014 10:33:48 +0800 Message-Id: <1B2C16FC-AA49-4F12-B355-C3EEBD679D68@cnnic.cn> References: To: Edward Lewis X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0ApMJCMRBpUx64EAA--.10095S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUYj7k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j 6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26F 4UJVW0owA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvE ncxIr21lYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4 IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK 67AK6r4UMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrV AFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCI c40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267 AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Zr0_Wr1UMIIF0xvEx4A2jsIE14v26r1j 6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU81SoJ UUUUU== X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/6u7R67vudVwdw-5bE50e5jIF_Tc Cc: "weirds@ietf.org" Subject: Re: [weirds] Combined response to - Re: WGLC reviews X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 02:34:18 -0000 --Apple-Mail=_E3E40792-89D7-482F-B0CE-71F373068E75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 > draft-ietf-weirds-object-inventory-03.txt >=20 > The document is correct, although the facts (numbers of TLDs) are = dated. I.e., there are over 21 gTLDs - =A1=B0way=A1=B1 over now. But = the statement is correct and I wouldn=A1=AFt change anything - except - = one of the editor=A1=AFs address has changed (ICANN moved offices = sometime back). Thanks Ed. We=A1=AFll update the above information you mentioned. Cheers, Ning --Apple-Mail=_E3E40792-89D7-482F-B0CE-71F373068E75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312

draft-ietf-weirds-object-inventory-03.txt

The document is correct, although the facts = (numbers of TLDs) are dated.  I.e., there are over 21 gTLDs - = =A1=B0way=A1=B1 over now.  But the statement is correct and I = wouldn=A1=AFt change anything - except - one of the editor=A1=AFs = address has changed (ICANN moved offices sometime = back).
Thanks Ed. We=A1=AFll update the = above information you = mentioned.

Cheers,
Ning

= --Apple-Mail=_E3E40792-89D7-482F-B0CE-71F373068E75-- From nobody Fri Sep 19 06:38:31 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6303C1A0166 for ; Fri, 19 Sep 2014 06:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbu1UxFlKFL2 for ; Fri, 19 Sep 2014 06:38:28 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2771A0173 for ; Fri, 19 Sep 2014 06:38:27 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id l4so3160332lbv.19 for ; Fri, 19 Sep 2014 06:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nknztszLiHhV95pSf4d9rltysOW7qKea2ZIQcsZ/HIs=; b=VwYa2440lddKH2C9yiUbW+7oSt0wQrCuETP5/xq4LQfCOyiMH/nLWOUkXPE+qApje8 UiEELoelIftYnQQQ3K1E0DgxpjqsG72W+JYjNULu930sKvXkY0LLXRPdSFsl/R4CaZrh hmucQY04uq41uGcklMF2bxoUSnfXAkQE7c88gJqnbsTXL3Wd4nJbPORv1H5xtU+AkJs9 f15pfGgZ3/J+73crEZtJ9KXhnYmTFC/HFL27jGR7BiGW8nWLhP+dYnly+FrZyEJqwyva sHmrRcpN6jkHgNG1EEMFTVstiA0opiEc40zWLcHNLk4znE/gHV/7tewQpL7mFGvAF992 NaLA== MIME-Version: 1.0 X-Received: by 10.152.19.66 with SMTP id c2mr7110796lae.64.1411133906451; Fri, 19 Sep 2014 06:38:26 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Fri, 19 Sep 2014 06:38:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Sep 2014 06:38:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e01493e4639822205036b3726 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/EkTqYHlZVORrpVbvuwt0Yibe9QM Subject: Re: [weirds] Working Group Last Call ending 9/19 for all documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 13:38:30 -0000 --089e01493e4639822205036b3726 Content-Type: text/plain; charset=UTF-8 Hi all, This massive WGLC ends today. Thank you to all of the participants that did take the time to submit reviews. I'm a bit disappointed that there were not more, but we'll take what we can get and hope it works. Authors, I suggest you wait about another 12 hours and then start posting your revisions. When you see a state change email from the data tracker putting documents in "Waiting for WG Chair Go-Ahead", it means WGLC has officially ended and we're waiting on you to do so. To make our next milestone, we have a week from today to send them to Pete and complete the AD Evaluation phase with him so he can initiate the IETF-wide Last Calls. AD Evaluation can result in some back-and-forth between him and the working group if he identifies issues, so please get your revisions posted without delay, or reply to this indicating your document is ready to go as-is. Let's keep moving! -MSK On Thu, Sep 4, 2014 at 9:28 PM, Murray S. Kucherawy wrote: > Colleagues, > > Congratulations, we've met our first milestone as laid out at IETF 91! > > This message begins a two-week Working Group Last Call for all documents > currently active in the WEIRDS WG. They are: > > draft-ietf-weirds-bootstrap > draft-ietf-weirds-json-response > draft-ietf-weirds-object-inventory > draft-ietf-weirds-rdap-query > draft-ietf-weirds-rdap-sec > draft-ietf-weirds-redirects > draft-ietf-weirds-using-http > > Please provide review comments either on this list or privately to the > author(s) on or before Friday, September 19, 2014. Please don't assume > everyone else in the group is doing reviews, so you don't need to; if we > all assume that, then the WGLCs are useless and consensus will be hard to > demonstrate. > > Also, if any participant has knowledge of IPR that needs to be declared on > any of this work, please do so, as required by BCPs 78 and 79. > > I will fulfill the duties of document shepherd for all of them unless I > hear from others that there's interest in volunteering for a particular > document (I have one outstanding request so far). > > -MSK, WEIRDS co-chair > --089e01493e4639822205036b3726 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

This massive WGLC ends= today.=C2=A0 Thank you to all of the participants that did take the time t= o submit reviews.=C2=A0 I'm a bit disappointed that there were not more= , but we'll take what we can get and hope it works.

Authors, I s= uggest you wait about another 12 hours and then start posting your revision= s.=C2=A0 When you see a state change email from the data tracker putting do= cuments in "Waiting for WG Chair Go-Ahead", it means WGLC has off= icially ended and we're waiting on you to do so.

To make o= ur next milestone, we have a week from today to send them to Pete and compl= ete the AD Evaluation phase with him so he can initiate the IETF-wide Last = Calls.=C2=A0 AD Evaluation can result in some back-and-forth between him an= d the working group if he identifies issues, so please get your revisions p= osted without delay, or reply to this indicating your document is ready to = go as-is.

Let's keep moving!

-MSK


On Thu, Sep 4, 2014 a= t 9:28 PM, Murray S. Kucherawy <superuser@gmail.com> wrote= :
Colleagues,<= br>
Congratulations, we've met our first milestone as laid out at IE= TF 91!

This message begins a two-week Working Group Last Call for al= l documents currently active in the WEIRDS WG.=C2=A0 They are:

draft-ietf-weirds-bootstrap
draft-ietf-weirds-json-response
draft-ie= tf-weirds-object-inventory
draft-ietf-weirds-rdap-query
draft-ietf-we= irds-rdap-sec
draft-ietf-weirds-redirects
draft-ietf-weirds-using-htt= p

Please provide review comments either on this list or privat= ely to the author(s) on or before Friday, September 19, 2014.=C2=A0 Please = don't assume everyone else in the group is doing reviews, so you don= 9;t need to; if we all assume that, then the WGLCs are useless and consensu= s will be hard to demonstrate.

Also, if any participant has knowledge of IPR that needs to be declared= on any of this work, please do so, as required b= y BCPs 78 and 79.

I will fulfill the duties of document shepherd for= all of them unless I hear from others that there's interest in volunte= ering for a particular document (I have one outstanding request so far).
-MSK, WEIRDS co-chair

--089e01493e4639822205036b3726-- From nobody Fri Sep 19 06:40:06 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC4F1A0181 for ; Fri, 19 Sep 2014 06:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcVgpDmDUlbO for ; Fri, 19 Sep 2014 06:40:04 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3AF1A0166 for ; Fri, 19 Sep 2014 06:40:04 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id q1so3159531lam.31 for ; Fri, 19 Sep 2014 06:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TmBqd96tPXefLzNEZgRgQ0FBP53VcLQ0JA/BqMzcGPk=; b=WT/PWvrCyLudVVDGtd+IO32JPKEjv5+Nd9QdZtLiQe6wZMZUZa8iuglvkL8+NuCQ5J mYdDIMHIQ32rssSrYeZ13aSaMJAgSSbH1/+bAhmllcRnLvCPaKKvv9P81E+s/AX8wJ3W USJ18nwU7erclGBxbPbtluWlS0fVh8L7jD4FzGsi+1iqKWnw6mY/DhFyRTGeABjJqv2i ZRTl1CmjujPXPaaSaUsZ3FATSBhvdoBz98tlNrdqC+MrEU2G5yzYNitH6qVIXEEgX3Ps RTNXdydLoLHw5KfqVNuMjpENOUXKUODRS3hFo8g3nRnj4Bq71kCuksDCaMg3NMglqG4L OIpg== MIME-Version: 1.0 X-Received: by 10.152.116.44 with SMTP id jt12mr5264521lab.7.1411134002689; Fri, 19 Sep 2014 06:40:02 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Fri, 19 Sep 2014 06:40:02 -0700 (PDT) Date: Fri, 19 Sep 2014 06:40:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c35370f5faf305036b3cfd Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ihn5Qh4N-Hc4Tkt7AsloREE6SdE Subject: [weirds] Interop and (no) meeting at IETF 91 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 13:40:05 -0000 --001a11c35370f5faf305036b3cfd Content-Type: text/plain; charset=UTF-8 Colleagues, I have notified the IESG that WEIRDS will not be meeting as a working group in Honolulu. If, on the other hand, we want to hold another interop event, please let me know so that I can make a request to the Secretariat for some unofficial meeting space. Does anyone have a preference to when? What equipment is needed in the room? How many people should we be able to accommodate? -MSK --001a11c35370f5faf305036b3cfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

I have notified the IESG that= WEIRDS will not be meeting as a working group in Honolulu.

If= , on the other hand, we want to hold another interop event, please let me k= now so that I can make a request to the Secretariat for some unofficial mee= ting space.=C2=A0 Does anyone have a preference to when?=C2=A0 What equipme= nt is needed in the room?=C2=A0 How many people should we be able to accomm= odate?

-MSK
--001a11c35370f5faf305036b3cfd-- From nobody Fri Sep 19 07:46:29 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930731A01C3 for ; Fri, 19 Sep 2014 07:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.383 X-Spam-Level: X-Spam-Status: No, score=-7.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7S-5xquVocD for ; Fri, 19 Sep 2014 07:46:26 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0C21A0164 for ; Fri, 19 Sep 2014 07:46:25 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Fri, 19 Sep 2014 16:46:20 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 16:46:16 +0200 From: Alexander Mayrhofer To: "weirds@ietf.org" Thread-Topic: Review of draft-ietf-weirds-rdap-query-13 Thread-Index: Ac/UDU+p9abcPxH9RBmYZDWJLrJ56g== Date: Fri, 19 Sep 2014 14:46:15 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/rYAnVA2B0SEb67cFxLJB2E1d7fo Subject: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:46:28 -0000 I've reviewed the Query document, and i think it's in very good shape, with= open "real" issue (see below "OPEN ISSUE"). All the other comments are min= or / editorial: ** 1. Introduction:=20 - I'm missing a clear description right at the beginning what this document= does. Something like "This document specifies query patterns for the Regis= tration Data Access Protocol..." (BTW, I'm still not sure which of the docu= ment specifies the *actual* RDAP, understanding that all documents specify = a certain aspect of it... But there's no document saying "This document spe= cifies RDAP" - is it this one?...) - OPEN ISSUE: I feel that it is *really important* to say that it's local s= erver policy whether or not a server supports a certain query pattern, and = which subset of it - especially for the "search" pattern. Do we have that s= omewhere in the documents? ** 3.1 Path Segments - Hosts/Domains: Since we talk about "U-Labels" there, i do assume that UTF= -8 strings that are not valid U-Labels would trigger an error in the requir= ed IDNA processing. For that error, i do assume server behaviour would then= be covered by the HTTP draft, Section 5.4,so it would send back a 400 resp= onse code, correct? =20 =20 ** 3.2 Search Path Segment - The text description doesn't seem to match the examples. while the text r= equires a slash concatenated to the plural form of the subject before the q= uery string, the examples do not contain this slash. Are both Segments fine= ? Then we need to say an "OPTIONAL forward slash character"... - I was writing a paragraph/rant here about the "pattern" being underspecif= ied, until i got to Section 4. Section 4 made me happy, but maybe a forward= reference to the search pattern descrition in section 4 would be good on f= irst use of the "blah*" pattern.. ** 4. Query Processing - This section could really use sub-sections, such as "4.1 Search Processin= g", "4.2 Character Folding", "4.3 Matching Rules" - it would make it easier= to read (and would also require some thought on re-arranging paragraphs, a= dmitted) tia, Alex From nobody Fri Sep 19 09:49:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAEF1A0330 for ; Fri, 19 Sep 2014 09:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLJ0zpZ9ZYnl for ; Fri, 19 Sep 2014 09:48:58 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B5E1A032E for ; Fri, 19 Sep 2014 09:48:53 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVBxeddk/0pODnL2DrjwEGPps3kY9q7Vt@postini.com; Fri, 19 Sep 2014 09:48:58 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 s8JGmpTn009656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 12:48:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 19 Sep 2014 12:48:51 -0400 From: "Hollenbeck, Scott" To: Alexander Mayrhofer , "weirds@ietf.org" Thread-Topic: Review of draft-ietf-weirds-rdap-query-13 Thread-Index: Ac/UDU+p9abcPxH9RBmYZDWJLrJ56gAGXnXQ Date: Fri, 19 Sep 2014 16:48:50 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/g8cKJQJtYd4nQ_z8UJrM2z5_tHs Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 16:49:00 -0000 Thanks for the feedback, Alex. Scott > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Alexander > Mayrhofer > Sent: Friday, September 19, 2014 10:46 AM > To: weirds@ietf.org > Subject: [weirds] Review of draft-ietf-weirds-rdap-query-13 >=20 > I've reviewed the Query document, and i think it's in very good shape, > with open "real" issue (see below "OPEN ISSUE"). All the other comments > are minor / editorial: >=20 > ** 1. Introduction: >=20 > - I'm missing a clear description right at the beginning what this > document does. Something like "This document specifies query patterns > for the Registration Data Access Protocol..." (BTW, I'm still not sure > which of the document specifies the *actual* RDAP, understanding that > all documents specify a certain aspect of it... But there's no document > saying "This document specifies RDAP" - is it this one?...) I can add some text to both the Abstract and the introduction. Add to end o= f abstract and end of first paragraph in the intro: "These uniform patterns define the query syntax for the Registration Data A= ccess Protocol (RDAP)." > - OPEN ISSUE: I feel that it is *really important* to say that it's > local server policy whether or not a server supports a certain query > pattern, and which subset of it - especially for the "search" pattern. > Do we have that somewhere in the documents? I can make a change in Section 2 to address this. OLD: "It is envisioned that each registry will continue to maintain NICNAME/WHOI= S and/or RESTful web services specific to their needs and those of their co= nstituencies" NEW "Server implementations will likely implement a subset of these features de= pending on local requirements. It is also envisioned that each registry wil= l continue to maintain NICNAME/WHOIS and/or RESTful web services specific t= o their needs and those of their constituencies" > ** 3.1 Path Segments >=20 > - Hosts/Domains: Since we talk about "U-Labels" there, i do assume that > UTF-8 strings that are not valid U-Labels would trigger an error in the > required IDNA processing. For that error, i do assume server behaviour > would then be covered by the HTTP draft, Section 5.4,so it would send > back a 400 response code, correct? I would expect any syntactically invalid query to be addressed as described= in Section 5 of using-http. > ** 3.2 Search Path Segment >=20 > - The text description doesn't seem to match the examples. while the > text requires a slash concatenated to the plural form of the subject > before the query string, the examples do not contain this slash. Are > both Segments fine? Then we need to say an "OPTIONAL forward slash > character"... I think the "forward slash" text is incorrect and should be removed. There = should be no forward slash to make the text consistent with the examples. > - I was writing a paragraph/rant here about the "pattern" being > underspecified, until i got to Section 4. Section 4 made me happy, but > maybe a forward reference to the search pattern descrition in section 4 > would be good on first use of the "blah*" pattern.. OK, that's reasonable, but the details of each search pattern are spelled o= ut in more detail in 3.2.1 ("XXXX is a search pattern representing"...), 3.= 2.2, and 3.2.3. Section 4 describes query processing. Is this helpful? OLD "the equal sign character ('=3D', ASCII value 0x003D), and the search patte= rn." NEW "the equal sign character ('=3D', ASCII value 0x003D), and the search patte= rn. Search pattern query processing is described more fully in Section 4." > ** 4. Query Processing >=20 > - This section could really use sub-sections, such as "4.1 Search > Processing", "4.2 Character Folding", "4.3 Matching Rules" - it would > make it easier to read (and would also require some thought on re- > arranging paragraphs, admitted) Yes, I think it would help. I'll see what I can do. Scott From nobody Fri Sep 19 11:14:03 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6841A064D for ; Fri, 19 Sep 2014 11:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eU9TXz15eyM for ; Fri, 19 Sep 2014 11:14:00 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id DFAAC1A0645 for ; Fri, 19 Sep 2014 11:13:59 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 987F3164FF6; Fri, 19 Sep 2014 14:13:59 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 5D8A6164FE5 for ; Fri, 19 Sep 2014 14:13:59 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 19 Sep 2014 14:15:29 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 19 Sep 2014 14:13:58 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: wglc review of draft-ietf-weirds-bootstrap Thread-Index: AQHP1DV7LNE+xiGGvECV6eHscYt8lg== Date: Fri, 19 Sep 2014 18:13:58 +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.7.130812 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 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/xJohEqmlIeXpBWEy2s6Dcg1PG4Q Subject: [weirds] wglc review of draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:14:01 -0000 I have reviewed this document and have no further comments than those I made before WGLC. -andy From nobody Fri Sep 19 11:48:24 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669871A702F for ; Fri, 19 Sep 2014 11:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nbc5h_AA82aT for ; Fri, 19 Sep 2014 11:48: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 052471A0456 for ; Fri, 19 Sep 2014 11:48:21 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 57AAD213984; Fri, 19 Sep 2014 14:48:19 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id CF27B213974 for ; Fri, 19 Sep 2014 14:48:18 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 19 Sep 2014 14:49:48 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 19 Sep 2014 14:48:18 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: wglc review of draft-ietf-weirds-rdap-sec Thread-Index: AQHP1DpGHz28vweT1kepEctrXM6PuQ== Date: Fri, 19 Sep 2014 18:48:17 +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.7.130812 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3A8CD679598B6E47BF0FB237D3488925@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Hc1GgjqbCZRcEb1pErdA5_NnG38 Subject: [weirds] wglc review of draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:48:22 -0000 I have reviewed draft-ietf-weirds-rdap-sec and have a couple of comments. Overall, I think it looks great. 1. I assume the reference to RFC 2818 (which is Informational) is ok. We may want to see if there is a more modern reference that has come out of the HTTPbis working group. I don=B9t really care, but this seems like one o= f those nitpicky things the IESG will hit us with. 2. Section 3.1 talks about Basic and Digest authentication and says servers MUST implement both. While I agree clients MUST implement both, the servers part gives me a little heartburn. If we are trying to say server implementations should implement both but server operators are free to do as they please, I agree. Perhaps the following additional paragraph to section 3 to tie authentication, authorization, and policy altogether: This section describes security authentication mechanisms and their need for implementation by authorization policies. This section places requirements upon the implementations of clients and servers but does not dictate the policies of server operators. For example, a server operator with no policy regarding differentiated or tiered access to data will have no authorization mechanisms and will have no need for any type of authentication. But a server operator with policies on differentiated access will have to construct an authorization scheme and will need to follow the requirements of authentication as specified below. That might be to wordy, but you get the picture. 3. Section 3.2 has the sentence "Server operators SHOULD offer varying degrees of access=B2=8A I think that SHOULD really ought to be a MAY. Thanks to the author team for putting this document together. -andy From nobody Fri Sep 19 12:35:11 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423621A8785 for ; Fri, 19 Sep 2014 12:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL3U2mZaCBRi for ; Fri, 19 Sep 2014 12:35: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 127481A8789 for ; Fri, 19 Sep 2014 12:35:09 -0700 (PDT) Received: from h118.viagenie.ca (h118.viagenie.ca [206.123.31.118]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C7D0246907; Fri, 19 Sep 2014 15:35:07 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: Date: Fri, 19 Sep 2014 11:49:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2ql3Ada9lM9KzUp1tbJ2ha8QD4c Cc: "weirds@ietf.org" Subject: Re: [weirds] Interop and (no) meeting at IETF 91 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 19:35:10 -0000 Le 2014-09-19 =E0 09:40, Murray S. Kucherawy a = =E9crit : > Colleagues, >=20 > I have notified the IESG that WEIRDS will not be meeting as a working = group in Honolulu. >=20 > If, on the other hand, we want to hold another interop event, please = let me know so that I can make a request to the Secretariat for some = unofficial meeting space. I have that request already being done. We also already have that = conversation on the -interop mailing list that was setup for that = purpose. Marc. > Does anyone have a preference to when? What equipment is needed in = the room? How many people should we be able to accommodate? >=20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Sat Sep 20 19:52:59 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288B71A0314; Sat, 20 Sep 2014 19:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YflF2E0xS82q; Sat, 20 Sep 2014 19:52:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 527261A0322; Sat, 20 Sep 2014 19:52:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140921025224.18018.77732.idtracker@ietfa.amsl.com> Date: Sat, 20 Sep 2014 19:52:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/f70uRhPNEAI9OEelhjY19e61PBI Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-object-inventory-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 02:52:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Registration Data Access Protocol Object Inventory Analysis Authors : Linlin Zhou Ning Kong Sean Shen Arturo Servin Filename : draft-ietf-weirds-object-inventory-04.txt Pages : 30 Date : 2014-09-20 Abstract: WHOIS output objects from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) were collected and analyzed. This document describes the statistical analysis process and result of existing WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-object-inventory-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-object-inventory-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Sep 20 20:00:10 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F1A1A0315 for ; Sat, 20 Sep 2014 20:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejmkkIxVZM2E for ; Sat, 20 Sep 2014 20:00:02 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7F41A0314 for ; Sat, 20 Sep 2014 20:00:01 -0700 (PDT) Received: from [192.168.1.102] (unknown [114.242.249.220]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMJArPx5UOZAFAA--.11764S2; Sun, 21 Sep 2014 10:59:56 +0800 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E1E863FC-1465-4329-944C-AE5600231A41" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: Date: Sun, 21 Sep 2014 10:59:48 +0800 Message-Id: References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0ApMJArPx5UOZAFAA--.11764S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJw1rJFW7AF18uF18JrWDJwb_yoW5Jw4Upa y7KFnakan5tr97tws7G3W0vw4Iv398Zrs8AFy5JrW7ZFZ8Gwn8tr10yrs0vay5J3yfXF4Y vr4jgrn8Cwn5Ar7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyab7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21lYx0E2Ix0 cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8Jw ACjcxG0xvY0x0EwIxGrwCjr7xvwVCIw2I0I7xG6c02F41l42xK82IYc2Ij64vIr41l4I8I 3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxV WUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAF wI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcI k0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_ Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU5fCztUUUUU== X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/kUEemLYt2Bz8LNtfJ6cciXVwVAc Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call ending 9/19 for all documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 03:00:07 -0000 --Apple-Mail=_E1E863FC-1465-4329-944C-AE5600231A41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Murray, draft-ietf-weirds-object-inventory-04, which is modified according to = your and Edward=A1=AFs comments during the WG Last call, has been = submitted and posted to the IETF repository. Cheers, Ning =D4=DA 2014=C4=EA9=D4=C219=C8=D5=A3=AC=CF=C2=CE=E79:38=A3=ACMurray S. = Kucherawy =D0=B4=B5=C0=A3=BA > Hi all, >=20 > This massive WGLC ends today. Thank you to all of the participants = that did take the time to submit reviews. I'm a bit disappointed that = there were not more, but we'll take what we can get and hope it works. >=20 > Authors, I suggest you wait about another 12 hours and then start = posting your revisions. When you see a state change email from the data = tracker putting documents in "Waiting for WG Chair Go-Ahead", it means = WGLC has officially ended and we're waiting on you to do so. >=20 > To make our next milestone, we have a week from today to send them to = Pete and complete the AD Evaluation phase with him so he can initiate = the IETF-wide Last Calls. AD Evaluation can result in some = back-and-forth between him and the working group if he identifies = issues, so please get your revisions posted without delay, or reply to = this indicating your document is ready to go as-is. >=20 > Let's keep moving! >=20 > -MSK >=20 >=20 > On Thu, Sep 4, 2014 at 9:28 PM, Murray S. Kucherawy = wrote: > Colleagues, >=20 > Congratulations, we've met our first milestone as laid out at IETF 91! >=20 > This message begins a two-week Working Group Last Call for all = documents currently active in the WEIRDS WG. They are: >=20 > draft-ietf-weirds-bootstrap > draft-ietf-weirds-json-response > draft-ietf-weirds-object-inventory > draft-ietf-weirds-rdap-query > draft-ietf-weirds-rdap-sec > draft-ietf-weirds-redirects > draft-ietf-weirds-using-http >=20 > Please provide review comments either on this list or privately to the = author(s) on or before Friday, September 19, 2014. Please don't assume = everyone else in the group is doing reviews, so you don't need to; if we = all assume that, then the WGLCs are useless and consensus will be hard = to demonstrate. >=20 > Also, if any participant has knowledge of IPR that needs to be = declared on any of this work, please do so, as required by BCPs 78 and = 79. >=20 > I will fulfill the duties of document shepherd for all of them unless = I hear from others that there's interest in volunteering for a = particular document (I have one outstanding request so far). >=20 > -MSK, WEIRDS co-chair >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_E1E863FC-1465-4329-944C-AE5600231A41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312
Hi Murray,

draft-ietf-weirds-object-inventory-04, which is = modified according to your and Edward=A1=AFs comments during the WG Last = call, has been = submitted and posted to the IETF repository.

Cheers,
Ning



=D4=DA 2014=C4=EA9=D4=C219=C8=D5=A3=AC=CF=C2=CE=E79:38=A3=AC= Murray S. Kucherawy <superuser@gmail.com> = =D0=B4=B5=C0=A3=BA

Hi all,

This massive WGLC ends = today.  Thank you to all of the participants that did take the time = to submit reviews.  I'm a bit disappointed that there were not = more, but we'll take what we can get and hope it works.

Authors, = I suggest you wait about another 12 hours and then start posting your = revisions.  When you see a state change email from the data tracker = putting documents in "Waiting for WG Chair Go-Ahead", it means WGLC has = officially ended and we're waiting on you to do so.

To make = our next milestone, we have a week from today to send them to Pete and = complete the AD Evaluation phase with him so he can initiate the = IETF-wide Last Calls.  AD Evaluation can result in some = back-and-forth between him and the working group if he identifies = issues, so please get your revisions posted without delay, or reply to = this indicating your document is ready to go as-is.

Let's = keep moving!

-MSK


On Thu, Sep 4, 2014 at 9:28 PM, Murray S. = Kucherawy <superuser@gmail.com> = wrote:
Colleagues,

Congratulations, we've met our = first milestone as laid out at IETF 91!

This message begins a = two-week Working Group Last Call for all documents currently active in = the WEIRDS WG.  They = are:

draft-ietf-weirds-bootstrap
draft-ietf-weirds-json-re= sponse
draft-ietf-weirds-object-inventory
draft-ietf-weirds-rdap-que= ry
draft-ietf-weirds-rdap-sec
draft-ietf-weirds-redirects
draft-i= etf-weirds-using-http

Please provide review comments either = on this list or privately to the author(s) on or before Friday, = September 19, 2014.  Please don't assume everyone else in the group = is doing reviews, so you don't need to; if we all assume that, then the = WGLCs are useless and consensus will be hard to demonstrate.

Also, if any participant has knowledge of IPR that needs to be = declared on any of this work, please do so, as required by = BCPs 78 and 79.

I will fulfill the duties of document shepherd = for all of them unless I hear from others that there's interest in = volunteering for a particular document (I have one outstanding request = so far).

-MSK, WEIRDS co-chair

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

= --Apple-Mail=_E1E863FC-1465-4329-944C-AE5600231A41-- From nobody Sat Sep 20 23:19:29 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106901A035A for ; Sat, 20 Sep 2014 23:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67puho_tewG2 for ; Sat, 20 Sep 2014 23:19:25 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B061A0350 for ; Sat, 20 Sep 2014 23:19:24 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id c11so281590lbj.26 for ; Sat, 20 Sep 2014 23:19: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=vIutE+voWwZekX+Yw3cwVljcASABzjq3C0WgD3l+dP8=; b=0kfjvxUZGnP210Xf6DJkw5mWckolQROXWpvARrGCt/iFFWEtR4K1s43smCQ4Hc0z2f D5+xWq7k8jQWup5PkIjxMdDt4GvTabMDW2kpIoLbl7YoeM6EmM3Y6debTPq9lZMSAAJY 8f2RRsXxaqTmbles8BlHZJuk6K8C8O48bbVwD13eKvLJSpJgRulOQqjP3mAePuP/U26+ LmL2nl9CY5Zvs53L54UPWuCOy0ukKwVYa9AqJIQLk1r9DrnLJxQf1OWX+gwBey+00ZMj m+UMr05iyQxqkYHVNsPTHkDfI/pXyxh71/nBBOyo3b7QX9i1tpD3aptkF28Ig1SLnTHT wQJA== MIME-Version: 1.0 X-Received: by 10.112.78.38 with SMTP id y6mr544213lbw.94.1411280362755; Sat, 20 Sep 2014 23:19:22 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Sat, 20 Sep 2014 23:19:22 -0700 (PDT) In-Reply-To: References: Date: Sat, 20 Sep 2014 23:19:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ning Kong Content-Type: multipart/alternative; boundary=001a11c3db42b35cb905038d507d Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/l1v9Zs3K2TFxvxS3iRC6_BYMQ0I Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call ending 9/19 for all documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 06:19:27 -0000 --001a11c3db42b35cb905038d507d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Ning. I've entered my document shepherd writeup. Once I get email confirmations from each of the authors affirming no IPR complications, I'll send it off to Pete. You're almost first to the finish line! -MSK On Sat, Sep 20, 2014 at 7:59 PM, Ning Kong wrote: > > Hi Murray, > > draft-ietf-weirds-object-inventory-04, which is modified according to you= r > and Edward=E2=80=99s comments during the WG Last call, has been submitted= and > posted to the IETF repository. > > Cheers, > Ning > > > > =E5=9C=A8 2014=E5=B9=B49=E6=9C=8819=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=889:= 38=EF=BC=8CMurray S. Kucherawy =E5=86=99=E9=81=93=EF= =BC=9A > > Hi all, > > This massive WGLC ends today. Thank you to all of the participants that > did take the time to submit reviews. I'm a bit disappointed that there > were not more, but we'll take what we can get and hope it works. > > Authors, I suggest you wait about another 12 hours and then start posting > your revisions. When you see a state change email from the data tracker > putting documents in "Waiting for WG Chair Go-Ahead", it means WGLC has > officially ended and we're waiting on you to do so. > > To make our next milestone, we have a week from today to send them to Pet= e > and complete the AD Evaluation phase with him so he can initiate the > IETF-wide Last Calls. AD Evaluation can result in some back-and-forth > between him and the working group if he identifies issues, so please get > your revisions posted without delay, or reply to this indicating your > document is ready to go as-is. > > Let's keep moving! > > -MSK > > > On Thu, Sep 4, 2014 at 9:28 PM, Murray S. Kucherawy > wrote: > >> Colleagues, >> >> Congratulations, we've met our first milestone as laid out at IETF 91! >> >> This message begins a two-week Working Group Last Call for all documents >> currently active in the WEIRDS WG. They are: >> >> draft-ietf-weirds-bootstrap >> draft-ietf-weirds-json-response >> draft-ietf-weirds-object-inventory >> draft-ietf-weirds-rdap-query >> draft-ietf-weirds-rdap-sec >> draft-ietf-weirds-redirects >> draft-ietf-weirds-using-http >> >> Please provide review comments either on this list or privately to the >> author(s) on or before Friday, September 19, 2014. Please don't assume >> everyone else in the group is doing reviews, so you don't need to; if we >> all assume that, then the WGLCs are useless and consensus will be hard t= o >> demonstrate. >> >> Also, if any participant has knowledge of IPR that needs to be declared >> on any of this work, please do so, as required by BCPs 78 and 79. >> >> I will fulfill the duties of document shepherd for all of them unless I >> hear from others that there's interest in volunteering for a particular >> document (I have one outstanding request so far). >> >> -MSK, WEIRDS co-chair >> > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > > --001a11c3db42b35cb905038d507d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Ning.=C2=A0 I've entered my document= shepherd writeup.=C2=A0 Once I get email confirmations from each of the au= thors affirming no IPR complications, I'll send it off to Pete.

=
You're almost first to the finish line!

-MSK

=

On Sat, Sep= 20, 2014 at 7:59 PM, Ning Kong <nkong@cnnic.cn> wrote:

Hi Murray,

draft-ietf-weirds-object-inventory-04, wh= ich is modified according to your and Edward=E2=80=99s comments during the = WG Last call,=C2=A0has been submitted and posted to the=C2=A0I= ETF repository.

Cheers,
Ning



=E5=9C=A8 2014=E5=B9=B49=E6=9C=8819=E6=97=A5=EF=BC=8C=E4=B8= =8B=E5=8D=889:38=EF=BC=8CMurray S. Kucherawy <superuser@gmail.com> =E5=86=99=E9=81= =93=EF=BC=9A

Hi all,

This massive WGLC ends tod= ay.=C2=A0 Thank you to all of the participants that did take the time to su= bmit reviews.=C2=A0 I'm a bit disappointed that there were not more, bu= t we'll take what we can get and hope it works.

Authors, I sugge= st you wait about another 12 hours and then start posting your revisions.= =C2=A0 When you see a state change email from the data tracker putting docu= ments in "Waiting for WG Chair Go-Ahead", it means WGLC has offic= ially ended and we're waiting on you to do so.

To make our= next milestone, we have a week from today to send them to Pete and complet= e the AD Evaluation phase with him so he can initiate the IETF-wide Last Ca= lls.=C2=A0 AD Evaluation can result in some back-and-forth between him and = the working group if he identifies issues, so please get your revisions pos= ted without delay, or reply to this indicating your document is ready to go= as-is.

Let's keep moving!

-MSK


On Thu, Sep 4, 2014 at = 9:28 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:<= br>
Colleagues,
Congratulations, we've met our first milestone as laid out at IETF= 91!

This message begins a two-week Working Group Last Call for all = documents currently active in the WEIRDS WG.=C2=A0 They are:

d= raft-ietf-weirds-bootstrap
draft-ietf-weirds-json-response
draft-ietf= -weirds-object-inventory
draft-ietf-weirds-rdap-query
draft-ietf-weir= ds-rdap-sec
draft-ietf-weirds-redirects
draft-ietf-weirds-using-http<= br>
Please provide review comments either on this list or privatel= y to the author(s) on or before Friday, September 19, 2014.=C2=A0 Please do= n't assume everyone else in the group is doing reviews, so you don'= t need to; if we all assume that, then the WGLCs are useless and consensus = will be hard to demonstrate.

Also, if any participant has knowledge of IPR that needs to be declared= on any of this work, please do so, as required by BCPs 78 and= 79.

I will fulfill the duties of document shepherd for all of them = unless I hear from others that there's interest in volunteering for a p= articular document (I have one outstanding request so far).

-MSK, WEIRDS co-chair

_______________________________________________
weirds mailing list
<= a href=3D"mailto:weirds@ietf.org" target=3D"_blank">weirds@ietf.org
= = https://www.ietf.org/mailman/listinfo/weirds


--001a11c3db42b35cb905038d507d-- From nobody Sun Sep 21 12:01:36 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DBD1A0365 for ; Sun, 21 Sep 2014 12:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.617 X-Spam-Level: X-Spam-Status: No, score=-4.617 tagged_above=-999 required=5 tests=[HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Are9XSxMpZpJ for ; Sun, 21 Sep 2014 12:01:34 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C416E1A0364 for ; Sun, 21 Sep 2014 12:01:33 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Sun, 21 Sep 2014 21:01:30 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0195.001; Sun, 21 Sep 2014 21:01:27 +0200 From: Alexander Mayrhofer To: "Hollenbeck, Scott" , "weirds@ietf.org" Thread-Topic: Review of draft-ietf-weirds-rdap-query-13 Thread-Index: Ac/UDU+p9abcPxH9RBmYZDWJLrJ56gAGXnXQAGmherA= Date: Sun, 21 Sep 2014 19:01:26 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07526889114@NICS-EXCH2.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/SAlIiEMa0iAND5nBUm3T98FnylE Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 19:01:35 -0000 > I can add some text to both the Abstract and the introduction. Add to end= of > abstract and end of first paragraph in the intro: >=20 > "These uniform patterns define the query syntax for the Registration Data > Access Protocol (RDAP)." Very good, yep. =20 > > - OPEN ISSUE: I feel that it is *really important* to say that it's > > local server policy whether or not a server supports a certain query > > pattern, and which subset of it - especially for the "search" pattern. > > Do we have that somewhere in the documents? >=20 > I can make a change in Section 2 to address this. >=20 > OLD: >=20 > "It is envisioned that each registry will continue to maintain > NICNAME/WHOIS and/or RESTful web services specific to their needs and > those of their constituencies" >=20 > NEW >=20 > "Server implementations will likely implement a subset of these features > depending on local requirements. It is also envisioned that each registry= will > continue to maintain NICNAME/WHOIS and/or RESTful web services specific > to their needs and those of their constituencies" Can we make this even a bit stronger, like "Server implementations are free to support only a subset of these features= depending on local requirements..."? I'm concerned that implementations that eg. do not offer search capabilitie= s for whatever reason would otherwise be considered "not conforming to the = specification". > > - Hosts/Domains: Since we talk about "U-Labels" there, i do assume > > that > > UTF-8 strings that are not valid U-Labels would trigger an error in > > the required IDNA processing. For that error, i do assume server > > behaviour would then be covered by the HTTP draft, Section 5.4,so it > > would send back a 400 response code, correct? >=20 > I would expect any syntactically invalid query to be addressed as describ= ed in > Section 5 of using-http. Perfect > > ** 3.2 Search Path Segment > > > > - The text description doesn't seem to match the examples. while the > > text requires a slash concatenated to the plural form of the subject > > before the query string, the examples do not contain this slash. Are > > both Segments fine? Then we need to say an "OPTIONAL forward slash > > character"... >=20 > I think the "forward slash" text is incorrect and should be removed. Ther= e > should be no forward slash to make the text consistent with the examples. > > - I was writing a paragraph/rant here about the "pattern" being > > underspecified, until i got to Section 4. Section 4 made me happy, but > > maybe a forward reference to the search pattern descrition in section > > 4 would be good on first use of the "blah*" pattern.. >=20 > OK, that's reasonable, but the details of each search pattern are spelled= out > in more detail in 3.2.1 ("XXXX is a search pattern representing"...), 3.2= .2, and > 3.2.3. Section 4 describes query processing. Is this helpful? I'd be happy with both references. The NEW text below is fine. > OLD > "the equal sign character ('=3D', ASCII value 0x003D), and the search pat= tern." >=20 > NEW > "the equal sign character ('=3D', ASCII value 0x003D), and the search pat= tern. > Search pattern query processing is described more fully in Section 4." >=20 > > ** 4. Query Processing > > > > - This section could really use sub-sections, such as "4.1 Search > > Processing", "4.2 Character Folding", "4.3 Matching Rules" - it would > > make it easier to read (and would also require some thought on re- > > arranging paragraphs, admitted) >=20 > Yes, I think it would help. I'll see what I can do. Great, thanks=20 Alex From nobody Sun Sep 21 13:40:36 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F781A0218 for ; Sun, 21 Sep 2014 13:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4GHJxOpXm-B for ; Sun, 21 Sep 2014 13:40:33 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2260C1A01EA for ; Sun, 21 Sep 2014 13:40:27 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVB83u7yVX66dPBt/MSHjxzA9CgjlSQEb@postini.com; Sun, 21 Sep 2014 13:40:33 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 s8LKeQrc009635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 21 Sep 2014 16:40:26 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Sun, 21 Sep 2014 16:40:25 -0400 From: "Hollenbeck, Scott" To: Alexander Mayrhofer , "weirds@ietf.org" Thread-Topic: Review of draft-ietf-weirds-rdap-query-13 Thread-Index: Ac/UDU+p9abcPxH9RBmYZDWJLrJ56gAGXnXQAGmherAAA5/KcA== Date: Sun, 21 Sep 2014 20:40:25 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494C5F8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <19F54F2956911544A32543B8A9BDE07526889114@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE07526889114@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/RAzXuCln_wDM_6K1jwSDmvzWPJg Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 20:40:35 -0000 > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@nic.at] > Sent: Sunday, September 21, 2014 3:01 PM > To: Hollenbeck, Scott; weirds@ietf.org > Subject: AW: Review of draft-ietf-weirds-rdap-query-13 >=20 > > I can add some text to both the Abstract and the introduction. Add to > end of > > abstract and end of first paragraph in the intro: > > > > "These uniform patterns define the query syntax for the Registration > Data > > Access Protocol (RDAP)." >=20 > Very good, yep. >=20 > > > - OPEN ISSUE: I feel that it is *really important* to say that it's > > > local server policy whether or not a server supports a certain > query > > > pattern, and which subset of it - especially for the "search" > pattern. > > > Do we have that somewhere in the documents? > > > > I can make a change in Section 2 to address this. > > > > OLD: > > > > "It is envisioned that each registry will continue to maintain > > NICNAME/WHOIS and/or RESTful web services specific to their needs and > > those of their constituencies" > > > > NEW > > > > "Server implementations will likely implement a subset of these > features > > depending on local requirements. It is also envisioned that each > registry will > > continue to maintain NICNAME/WHOIS and/or RESTful web services > specific > > to their needs and those of their constituencies" >=20 > Can we make this even a bit stronger, like >=20 > "Server implementations are free to support only a subset of these > features depending on local requirements..."? >=20 > I'm concerned that implementations that eg. do not offer search > capabilities for whatever reason would otherwise be considered "not > conforming to the specification". That's not something I can agree to without a stronger sense of WG consensu= s. I can see DNRs not supporting ASN queries (that's the kind of use case I= was envisioning), but not supporting searches sounds like it could/should = be a conformance question. Scott From nobody Sun Sep 21 16:36:49 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40C51A0385 for ; Sun, 21 Sep 2014 16:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABRVE4i8flCM for ; Sun, 21 Sep 2014 16:36:46 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57C31A0382 for ; Sun, 21 Sep 2014 16:36:45 -0700 (PDT) Received: (qmail 19136 invoked from network); 21 Sep 2014 23:36:44 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 21 Sep 2014 23:36: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:mime-version:content-type:content-transfer-encoding; s=15d5d.541f610c.k1409; i=johnl@user.iecc.com; bh=6PwvpkHWSsY6/KuVBWl7PlTNhAoZw4qVzKYg3IglycE=; b=MaA0i/vrkKjKNa+bf92wHio55bBBIx1HNjv+WpTNLxNAGpb0IX40agJbj9rvj3ik1280wHwo4xkRUlqdEmAXvXMWzkaY48zo/x5DjU8rE2XuiZgzES0hR4jiGzN3CCATwCwGl9GPtfG0Mi/dNw+HEOSkIpZGSPi/T7JX5ZopAX4+4K3gv1QoGbVATyK7zq4waN0b9VUum9T8ZquI+YPa/g1rHMt2aXJxkyxAWqNBVdpLAgnWdU/clLK5CKYFqN32 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=15d5d.541f610c.k1409; olt=johnl@user.iecc.com; bh=6PwvpkHWSsY6/KuVBWl7PlTNhAoZw4qVzKYg3IglycE=; b=LkwaEPithxa39rgXW1wc593bVSWEghOympefFnAXsf+auvDuNqxUl4I29LgoPSuHVS9ayr5X/Ie93I615sN9uif7jsmJisdDi2uRqz+067GiPLSqyP2EC4mrfgWiKvkV1uspidkVd70Nnox5vLdjXgC2yEp7bbBED8XVoy6c4JdNv4HNNyaxgpiqfs+jw8qtqJ+Ma7TtkOH53ix0z+ZPQZMTD48UkmCGEKj3szcldGzeigyqXxAs/IdOfdXDEh9t Date: 21 Sep 2014 23:36:22 -0000 Message-ID: <20140921233622.89436.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494C5F8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/UQEM690n2jzaunbc98wCeHFx9_I Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 23:36:47 -0000 >> I'm concerned that implementations that eg. do not offer search >> capabilities for whatever reason would otherwise be considered "not >> conforming to the specification". This is a complete non-starter. The IETF is not the protocol police, and all we can do is tell people how to interoperate if that is what they want to do. Demanding that WEIRDS providers offer services they do not want to provide is totally, completely out of scope. (Defining a standard way to say "we don't do that" is within scope, and I believe we've done that adequately.) R's, John From nobody Sun Sep 21 22:39:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F4D1A1A24 for ; Sun, 21 Sep 2014 22:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8dLRjUQOPsN for ; Sun, 21 Sep 2014 22:39:13 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2041A1A1F for ; Sun, 21 Sep 2014 22:39:12 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id w61so1419702wes.21 for ; Sun, 21 Sep 2014 22:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h7sNzcdD9j/t+xLGiand7Mvh6qy4nq0ZIDEscClab8c=; b=PLUs8ShOVw+lVsnsXeQfp4mLb45q2DKwRupJk9J3gN6+cO7NfM9/SbgrUaAkcU/+9X /JPH0Bm2isL7pt9WRZu8LeRu+eQMHFrwyWm4e/Jalmv2nVS4ulpUf0pfODGL3zubmC9k A6yXdi7l39Akqa1J/5uI58nP4avK0e8akqyNxwFN3gPs4jA1w+7klAgbuUiLZSD4Z25h XHQsGeEQfYjUVsRIkAUoOA57oMhmMl53rKekbfNgFjJ/HMMsk1bKcKaBtoXBDdpvWqiP xqt3wxipNXlfgQYPZK0E0fuQFc1HWvF7P8xyuxiq+8F6LxeeHjUxdObEfnsLrJu8CfPT n5KA== MIME-Version: 1.0 X-Received: by 10.180.184.20 with SMTP id eq20mr12776515wic.61.1411364351655; Sun, 21 Sep 2014 22:39:11 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Sun, 21 Sep 2014 22:39:11 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494C5F8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <19F54F2956911544A32543B8A9BDE07526889114@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C5F8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Sun, 21 Sep 2014 22:39:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=001a11c3536ad445130503a0de6c Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/FQf643Az_zTlcBhqV4OnqrfQ5w0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 05:39:14 -0000 --001a11c3536ad445130503a0de6c Content-Type: text/plain; charset=UTF-8 On Sun, Sep 21, 2014 at 1:40 PM, Hollenbeck, Scott wrote: > > > "Server implementations will likely implement a subset of these > > features > > > depending on local requirements. It is also envisioned that each > > registry will > > > continue to maintain NICNAME/WHOIS and/or RESTful web services > > specific > > > to their needs and those of their constituencies" > > > > Can we make this even a bit stronger, like > > > > "Server implementations are free to support only a subset of these > > features depending on local requirements..."? > > > > I'm concerned that implementations that eg. do not offer search > > capabilities for whatever reason would otherwise be considered "not > > conforming to the specification". > > That's not something I can agree to without a stronger sense of WG > consensus. I can see DNRs not supporting ASN queries (that's the kind of > use case I was envisioning), but not supporting searches sounds like it > could/should be a conformance question. My impression of consensus is that, since not all WHOIS servers implement it today, it's optional in RDAP too. Does anyone remember something different? If that's the case, Alexander's suggestion aligns with consensus as far as I can tell. -MSK --001a11c3536ad445130503a0de6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Sep 21, 2014 at 1:40 PM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
> > "Server implementations will like= ly implement a subset of these
> features
> > depending on local requirements. It is also envisioned that each<= br> > registry will
> > continue to maintain NICNAME/WHOIS and/or RESTful web services > specific
> > to their needs and those of their constituencies"
>
> Can we make this even a bit stronger, like
>
> "Server implementations are free to support only a subset of thes= e
> features depending on local requirements..."?
>
> I'm concerned that implementations that eg. do not offer search > capabilities for whatever reason would otherwise be considered "n= ot
> conforming to the specification".

That's not something I can agree to without a stronger sens= e of WG consensus. I can see DNRs not supporting ASN queries (that's th= e kind of use case I was envisioning), but not supporting searches sounds l= ike it could/should be a conformance question.

<= div>My impression of consensus is that, since not all WHOIS servers impleme= nt it today, it's optional in RDAP too.=C2=A0 Does anyone remember some= thing different?

If that's the case, Alexander's = suggestion aligns with consensus as far as I can tell.

-M= SK
--001a11c3536ad445130503a0de6c-- From nobody Mon Sep 22 04:00:20 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BE01A1A48 for ; Mon, 22 Sep 2014 04:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_tnw_CEOHFv for ; Mon, 22 Sep 2014 04:00:17 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048831A1A45 for ; Mon, 22 Sep 2014 04:00:09 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKVCABOZom27U3ZgQVsaaXIRMNlSPBas+5@postini.com; Mon, 22 Sep 2014 04:00:16 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 s8MB08YW005803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 07:00:08 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 22 Sep 2014 07:00:08 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" Thread-Topic: [weirds] Review of draft-ietf-weirds-rdap-query-13 Thread-Index: Ac/UDU+p9abcPxH9RBmYZDWJLrJ56gAGXnXQAGmherAAA5/KcAAbUGqAAAKGaZA= Date: Mon, 22 Sep 2014 11:00:07 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494C73B8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <19F54F2956911544A32543B8A9BDE07526889114@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C5F8E@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_831693C2CDA2E849A7D7A712B24E257F494C73B8BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/cQ4AQoBT3xQWYTRNcCrenUni1ng Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 11:00:19 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F494C73B8BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTXVycmF5IFMuIEt1Y2hlcmF3eSBbbWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb21dDQpT ZW50OiBNb25kYXksIFNlcHRlbWJlciAyMiwgMjAxNCAxOjM5IEFNDQpUbzogSG9sbGVuYmVjaywg U2NvdHQNCkNjOiBBbGV4YW5kZXIgTWF5cmhvZmVyOyB3ZWlyZHNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbd2VpcmRzXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi13ZWlyZHMtcmRhcC1xdWVyeS0xMw0K DQpPbiBTdW4sIFNlcCAyMSwgMjAxNCBhdCAxOjQwIFBNLCBIb2xsZW5iZWNrLCBTY290dCA8c2hv bGxlbmJlY2tAdmVyaXNpZ24uY29tPG1haWx0bzpzaG9sbGVuYmVja0B2ZXJpc2lnbi5jb20+PiB3 cm90ZToNCj4gPiAiU2VydmVyIGltcGxlbWVudGF0aW9ucyB3aWxsIGxpa2VseSBpbXBsZW1lbnQg YSBzdWJzZXQgb2YgdGhlc2UNCj4gZmVhdHVyZXMNCj4gPiBkZXBlbmRpbmcgb24gbG9jYWwgcmVx dWlyZW1lbnRzLiBJdCBpcyBhbHNvIGVudmlzaW9uZWQgdGhhdCBlYWNoDQo+IHJlZ2lzdHJ5IHdp bGwNCj4gPiBjb250aW51ZSB0byBtYWludGFpbiBOSUNOQU1FL1dIT0lTIGFuZC9vciBSRVNUZnVs IHdlYiBzZXJ2aWNlcw0KPiBzcGVjaWZpYw0KPiA+IHRvIHRoZWlyIG5lZWRzIGFuZCB0aG9zZSBv ZiB0aGVpciBjb25zdGl0dWVuY2llcyINCj4NCj4gQ2FuIHdlIG1ha2UgdGhpcyBldmVuIGEgYml0 IHN0cm9uZ2VyLCBsaWtlDQo+DQo+ICJTZXJ2ZXIgaW1wbGVtZW50YXRpb25zIGFyZSBmcmVlIHRv IHN1cHBvcnQgb25seSBhIHN1YnNldCBvZiB0aGVzZQ0KPiBmZWF0dXJlcyBkZXBlbmRpbmcgb24g bG9jYWwgcmVxdWlyZW1lbnRzLi4uIj8NCj4NCj4gSSdtIGNvbmNlcm5lZCB0aGF0IGltcGxlbWVu dGF0aW9ucyB0aGF0IGVnLiBkbyBub3Qgb2ZmZXIgc2VhcmNoDQo+IGNhcGFiaWxpdGllcyBmb3Ig d2hhdGV2ZXIgcmVhc29uIHdvdWxkIG90aGVyd2lzZSBiZSBjb25zaWRlcmVkICJub3QNCj4gY29u Zm9ybWluZyB0byB0aGUgc3BlY2lmaWNhdGlvbiIuDQpUaGF0J3Mgbm90IHNvbWV0aGluZyBJIGNh biBhZ3JlZSB0byB3aXRob3V0IGEgc3Ryb25nZXIgc2Vuc2Ugb2YgV0cgY29uc2Vuc3VzLiBJIGNh biBzZWUgRE5ScyBub3Qgc3VwcG9ydGluZyBBU04gcXVlcmllcyAodGhhdCdzIHRoZSBraW5kIG9m IHVzZSBjYXNlIEkgd2FzIGVudmlzaW9uaW5nKSwgYnV0IG5vdCBzdXBwb3J0aW5nIHNlYXJjaGVz IHNvdW5kcyBsaWtlIGl0IGNvdWxkL3Nob3VsZCBiZSBhIGNvbmZvcm1hbmNlIHF1ZXN0aW9uLg0K DQpNeSBpbXByZXNzaW9uIG9mIGNvbnNlbnN1cyBpcyB0aGF0LCBzaW5jZSBub3QgYWxsIFdIT0lT IHNlcnZlcnMgaW1wbGVtZW50IGl0IHRvZGF5LCBpdCdzIG9wdGlvbmFsIGluIFJEQVAgdG9vLiAg RG9lcyBhbnlvbmUgcmVtZW1iZXIgc29tZXRoaW5nIGRpZmZlcmVudD8NCklmIHRoYXQncyB0aGUg Y2FzZSwgQWxleGFuZGVyJ3Mgc3VnZ2VzdGlvbiBhbGlnbnMgd2l0aCBjb25zZW5zdXMgYXMgZmFy IGFzIEkgY2FuIHRlbGwuDQoNCltTQUhdIFRoYXTigJlzIHNwZWNpZmljIHRvIHNlYXJjaCBiZWhh dmlvciwgYnV0IHRoZSB0ZXh0IEFsZXggaXMgc3VnZ2VzdGluZyBsZWF2ZXMgb3BlbiB0aGUgcG9z c2liaWxpdHkgb2YgbGVhdmluZyBvdXQgb3RoZXIgZmVhdHVyZXMsIHRvby4gU28gd2hlcmUgZG8g d2UgZHJhdyB0aGUgbGluZT8gRG9lcyBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IHByb3ZpZGVzIChm b3IgZXhhbXBsZSkgZG9tYWluIG5hbWUgbG9va3VwcyBhbmQgbm90aGluZyBlbHNlIOKAnGNvbmZv cm3igJ0/IEnigJltIG5vdCBjb21mb3J0YWJsZSB3aXRoIHJlZmVycmluZyB0byBleGlzdGluZyBX SE9JUyBiZWhhdmlvciBhcyBhIGd1aWRlIGJlY2F1c2UgZXhjZXB0aW9ucyBjYW4gYmUgZm91bmQg dG8gc3VwcG9ydCBwcmV0dHkgbXVjaCBhbnkgcG9zaXRpb24uDQoNClNjb3R0DQo= --_000_831693C2CDA2E849A7D7A712B24E257F494C73B8BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gTXVycmF5IFMuIEt1Y2hlcmF3eSBbbWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMTQgMTozOSBBTTxicj4N CjxiPlRvOjwvYj4gSG9sbGVuYmVjaywgU2NvdHQ8YnI+DQo8Yj5DYzo8L2I+IEFsZXhhbmRlciBN YXlyaG9mZXI7IHdlaXJkc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3dlaXJk c10gUmV2aWV3IG9mIGRyYWZ0LWlldGYtd2VpcmRzLXJkYXAtcXVlcnktMTM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBTZXAgMjEs IDIwMTQgYXQgMTo0MCBQTSwgSG9sbGVuYmVjaywgU2NvdHQgJmx0OzxhIGhyZWY9Im1haWx0bzpz aG9sbGVuYmVja0B2ZXJpc2lnbi5jb20iIHRhcmdldD0iX2JsYW5rIj5zaG9sbGVuYmVja0B2ZXJp c2lnbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij4mZ3Q7ICZndDsgJnF1b3Q7U2VydmVyIGltcGxlbWVudGF0aW9ucyB3 aWxsIGxpa2VseSBpbXBsZW1lbnQgYSBzdWJzZXQgb2YgdGhlc2U8YnI+DQomZ3Q7IGZlYXR1cmVz PGJyPg0KJmd0OyAmZ3Q7IGRlcGVuZGluZyBvbiBsb2NhbCByZXF1aXJlbWVudHMuIEl0IGlzIGFs c28gZW52aXNpb25lZCB0aGF0IGVhY2g8YnI+DQomZ3Q7IHJlZ2lzdHJ5IHdpbGw8YnI+DQomZ3Q7 ICZndDsgY29udGludWUgdG8gbWFpbnRhaW4gTklDTkFNRS9XSE9JUyBhbmQvb3IgUkVTVGZ1bCB3 ZWIgc2VydmljZXM8YnI+DQomZ3Q7IHNwZWNpZmljPGJyPg0KJmd0OyAmZ3Q7IHRvIHRoZWlyIG5l ZWRzIGFuZCB0aG9zZSBvZiB0aGVpciBjb25zdGl0dWVuY2llcyZxdW90Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IENhbiB3ZSBtYWtlIHRoaXMgZXZlbiBhIGJpdCBzdHJvbmdlciwgbGlrZTxicj4NCiZn dDs8YnI+DQomZ3Q7ICZxdW90O1NlcnZlciBpbXBsZW1lbnRhdGlvbnMgYXJlIGZyZWUgdG8gc3Vw cG9ydCBvbmx5IGEgc3Vic2V0IG9mIHRoZXNlPGJyPg0KJmd0OyBmZWF0dXJlcyBkZXBlbmRpbmcg b24gbG9jYWwgcmVxdWlyZW1lbnRzLi4uJnF1b3Q7Pzxicj4NCiZndDs8YnI+DQomZ3Q7IEknbSBj b25jZXJuZWQgdGhhdCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBlZy4gZG8gbm90IG9mZmVyIHNlYXJj aDxicj4NCiZndDsgY2FwYWJpbGl0aWVzIGZvciB3aGF0ZXZlciByZWFzb24gd291bGQgb3RoZXJ3 aXNlIGJlIGNvbnNpZGVyZWQgJnF1b3Q7bm90PGJyPg0KJmd0OyBjb25mb3JtaW5nIHRvIHRoZSBz cGVjaWZpY2F0aW9uJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYXQncyBub3Qgc29tZXRoaW5nIEkgY2FuIGFncmVlIHRvIHdpdGhv dXQgYSBzdHJvbmdlciBzZW5zZSBvZiBXRyBjb25zZW5zdXMuIEkgY2FuIHNlZSBETlJzIG5vdCBz dXBwb3J0aW5nIEFTTiBxdWVyaWVzICh0aGF0J3MgdGhlIGtpbmQgb2YgdXNlIGNhc2UgSSB3YXMg ZW52aXNpb25pbmcpLCBidXQgbm90IHN1cHBvcnRpbmcgc2VhcmNoZXMgc291bmRzIGxpa2UgaXQg Y291bGQvc2hvdWxkIGJlIGEgY29uZm9ybWFuY2UNCiBxdWVzdGlvbi48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+TXkgaW1wcmVzc2lvbiBvZiBjb25zZW5zdXMgaXMgdGhhdCwgc2lu Y2Ugbm90IGFsbCBXSE9JUyBzZXJ2ZXJzIGltcGxlbWVudCBpdCB0b2RheSwgaXQncyBvcHRpb25h bCBpbiBSREFQIHRvby4mbmJzcDsgRG9lcyBhbnlvbmUgcmVtZW1iZXIgc29tZXRoaW5nIGRpZmZl cmVudD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIHRoYXQncyB0aGUgY2FzZSwgQWxleGFuZGVyJ3Mgc3VnZ2VzdGlvbiBhbGlnbnMgd2l0aCBj b25zZW5zdXMgYXMgZmFyIGFzIEkgY2FuIHRlbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bU0FIXSBUaGF04oCZcyBzcGVjaWZpYyB0byBzZWFyY2ggYmVoYXZp b3IsIGJ1dCB0aGUgdGV4dCBBbGV4IGlzIHN1Z2dlc3RpbmcgbGVhdmVzIG9wZW4gdGhlIHBvc3Np YmlsaXR5IG9mIGxlYXZpbmcgb3V0IG90aGVyIGZlYXR1cmVzLCB0b28uIFNvIHdoZXJlIGRvIHdl IGRyYXcgdGhlIGxpbmU/IERvZXMNCiBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IHByb3ZpZGVzIChm b3IgZXhhbXBsZSkgZG9tYWluIG5hbWUgbG9va3VwcyBhbmQgbm90aGluZyBlbHNlIOKAnGNvbmZv cm3igJ0/IEnigJltIG5vdCBjb21mb3J0YWJsZSB3aXRoIHJlZmVycmluZyB0byBleGlzdGluZyBX SE9JUyBiZWhhdmlvciBhcyBhIGd1aWRlIGJlY2F1c2UgZXhjZXB0aW9ucyBjYW4gYmUgZm91bmQg dG8gc3VwcG9ydCBwcmV0dHkgbXVjaCBhbnkgcG9zaXRpb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlNjb3R0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_831693C2CDA2E849A7D7A712B24E257F494C73B8BRN1WNEXMBX01vc_-- From nobody Mon Sep 22 05:25:23 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508871A1ABB for ; Mon, 22 Sep 2014 05:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWMzc-ppUuDL for ; Mon, 22 Sep 2014 05:25:17 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9791A1AAC for ; Mon, 22 Sep 2014 05:25:17 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 22 Sep 2014 05:25:13 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Mon, 22 Sep 2014 05:25:14 -0700 From: Edward Lewis To: "Hollenbeck, Scott" , "Murray S. Kucherawy" Thread-Topic: Conformance - Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 Thread-Index: AQHP1mBCh6du8VQDu0aGckj9p8L21Q== Date: Mon, 22 Sep 2014 12:25:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.0.44.0] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3494219111_2405229" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/hNqRe0X_yRdYgwiI_fHRldnwh0c Cc: "weirds@ietf.org" Subject: [weirds] Conformance - Re: Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:25:20 -0000 --B_3494219111_2405229 Content-type: multipart/alternative; boundary="B_3494219111_2365949" --B_3494219111_2365949 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable (Soapbox:) =E2=80=9CConformance=E2=80=9D is a slippery slope issue. What John said is appropriate= - as long as an implementation can express =E2=80=9CI don=E2=80=99t do that=E2=80=9D and the other= side can cope one can consider the job of accomplishing interoperability complete. I=E2=80=99ve preferred that an implementation be able to claim =E2=80=9Cimplements RFC wxyz=E2=80=9D and leave the issue of conformance up to the buyer/seller of services that are composed from, among other items, the implementation. Through the years I=E2=80=99ve spent time trying to declare whether a service or module =E2=80=9Cconforms=E2=80=9D to an RFC and came away with the lesson that =E2=80=9Cconfo= rmance=E2=80=9D is a legal term and not a technical term. So - I would not fret too much about defining conformance to be too loose o= r too strict. Leave that to a test harness/tool. Permit the implementer to write code that =E2=80=9Cmake sense.=E2=80=9D I understand we don=E2=80=99t want to write a specification that is so weak that even the =E2=80=98ls=E2=80=99 command can claim compliance, but the way RFCs have been written historically, they assume that the developers have best intentions when it comes to providing functionality. From: , Scott Date: Monday, September 22, 2014 at 7:00 To: "Murray S. Kucherawy" Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 [SAH] That=E2=80=99s specific to search behavior, but the text Alex is suggesting leaves open the possibility of leaving out other features, too. So where do we draw the line? Does an implementation that provides (for example) domain name lookups and nothing else =E2=80=9Cconform=E2=80=9D? I=E2=80=99m not comfortable with ref= erring to existing WHOIS behavior as a guide because exceptions can be found to support pretty much any position. --B_3494219111_2365949 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
(Soapbox:)

“Conformance” is a slippery slope issue.  What John = said is appropriate - as long as an implementation can express “I don&= #8217;t do that” and the other side can cope one can consider the job = of accomplishing interoperability complete.  I’ve preferred that = an implementation be able to claim “implements RFC wxyz” and lea= ve the issue of conformance up to the buyer/seller of services that are comp= osed from, among other items, the implementation.

T= hrough the years I’ve spent time trying to declare whether a service o= r module “conforms” to an RFC and came away with the lesson that= “conformance” is a legal term and not a technical term.

So - I would not fret too much about defining conformance = to be too loose or too strict.  Leave that to a test harness/tool. &nbs= p;Permit the implementer to write code that “make sense.”  = I understand we don’t want to write a specification that is so weak th= at even the ‘ls’ command can claim compliance, but the way RFCs = have been written historically, they assume that the developers have best in= tentions when it comes to providing functionality.

From: <Hollenbeck>, Scott <shollenbeck@verisign.com>
Date: Monday, September 22, 2014 at 7:00
= To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: "weirds@ietf.or= g" <weirds@ietf.org>
Subject: Re: [weirds] Review of draft-ietf= -weirds-rdap-query-13

[SAH] That’= ;s specific to search behavior, but the text Alex is suggesting leaves open = the possibility of leaving out other features, too. So where do we draw the = line? Does an implementation that provides (for example) domain name lookups and noth= ing else “conform”? I’m not comfortable with referring to = existing WHOIS behavior as a guide because exceptions can be found to suppor= t pretty much any position.
 --B_3494219111_2365949-- --B_3494219111_2405229 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRiMN0bfrj/li1PUkWh RiVYUVicsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5 MjIxMjI1MTFaMA0GCSqGSIb3DQEBAQUABIIBABQB4I/t9if5ioAe8MSNGcZDiaBX7gafLVfz 5C+G/B0U14tF9b5cCEAgE74KKQVWoxSSYXTL1zQHEYEYM2DIL3QKl+fg4QMWREYEEs/roknv pPvaBKGU+bhU5gCFJjjsruNt2R2BFnrieFMP3np7C1IrjhBZ+7KWKsKPEBIGRLAVNABitr6s T/tdb5/0R/LOcE+cQC4qWsttuCyCnj2HtRSkDrbq1gKZsgfqxS2eo4BS6cEd95Dc/vPp4/3S 9WwOEtLUyapULedMs/VyIsFMKxssq4uS5wcnMcnCSq4J17stA83JCo9pMpIFCaecK4WurqGB 4jeyw+FLbeufCblGpeE= --B_3494219111_2405229-- From nobody Mon Sep 22 05:36:54 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777A51A1AB8 for ; Mon, 22 Sep 2014 05:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdjwLCnc3pCn for ; Mon, 22 Sep 2014 05:36:50 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E821A1ABA for ; Mon, 22 Sep 2014 05:36:48 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKVCAX4PyrPUMCLD9M0UJyUuaSZl1E5p35@postini.com; Mon, 22 Sep 2014 05:36:49 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 s8MCalUJ005322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 08:36:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 22 Sep 2014 08:36:47 -0400 From: "Hollenbeck, Scott" To: Andy Newton , "weirds@ietf.org" Thread-Topic: wglc review of draft-ietf-weirds-rdap-sec Thread-Index: AQHP1DpGHz28vweT1kepEctrXM6PuZwNGVBQ Date: Mon, 22 Sep 2014 12:36:47 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494C7593@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="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/3st9rHtcWxmyWU1QUhjzuOBekoo Subject: Re: [weirds] wglc review of draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:36:51 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andy Newton > Sent: Friday, September 19, 2014 2:48 PM > To: weirds@ietf.org > Subject: [weirds] wglc review of draft-ietf-weirds-rdap-sec >=20 > I have reviewed draft-ietf-weirds-rdap-sec and have a couple of > comments. > Overall, I think it looks great. >=20 > 1. I assume the reference to RFC 2818 (which is Informational) is ok. > We > may want to see if there is a more modern reference that has come out > of > the HTTPbis working group. I don=B9t really care, but this seems like one > of > those nitpicky things the IESG will hit us with. RFC 7230 is a possibility (it describes the https URI scheme), but it also = references 2818. I'd prefer to use 2818 because we're specifically talking = about TLS protection and not the URI scheme. > 2. Section 3.1 talks about Basic and Digest authentication and says > servers MUST implement both. While I agree clients MUST implement both, > the servers part gives me a little heartburn. If we are trying to say > server implementations should implement both but server operators are > free > to do as they please, I agree. Perhaps the following additional > paragraph > to section 3 to tie authentication, authorization, and policy > altogether: >=20 > This section describes security authentication mechanisms and their > need > for implementation by authorization policies. This section places > requirements upon the implementations of clients and servers but does > not > dictate the policies of server operators. For example, a server > operator > with no policy regarding differentiated or tiered access to data will > have > no authorization mechanisms and will have no need for any type of > authentication. But a server operator with policies on differentiated > access will have to construct an authorization scheme and will need to > follow the requirements of authentication as specified below. >=20 > That might be to wordy, but you get the picture. >=20 > 3. Section 3.2 has the sentence "Server operators SHOULD offer varying > degrees of access=B2=D0 I think that SHOULD really ought to be a MAY. >=20 > Thanks to the author team for putting this document together. I'll take care of these. Thanks for the feedback! Scott From nobody Mon Sep 22 05:45:52 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C588A1A1AC3; Mon, 22 Sep 2014 05:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1Z4OcWv8DSu; Mon, 22 Sep 2014 05:45:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 812651A00AE; Mon, 22 Sep 2014 05:45:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922124548.22121.74401.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 05:45:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/STrWYNfIQ_dQSWIqhxyY00vOytI Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-09.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:45:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Security Services for the Registration Data Access Protocol Authors : Scott Hollenbeck Ning Kong Filename : draft-ietf-weirds-rdap-sec-09.txt Pages : 11 Date : 2014-09-22 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-sec-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 22 05:47:18 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627611A1AC4 for ; Mon, 22 Sep 2014 05:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHn-moDjaFJW for ; Mon, 22 Sep 2014 05:47:14 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0081A1ABA for ; Mon, 22 Sep 2014 05:47:14 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKVCAaUqSdgw3CpmjMewsVqivYQ0nzrli5@postini.com; Mon, 22 Sep 2014 05:47:14 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 s8MClDtJ008731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Sep 2014 08:47:13 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 22 Sep 2014 08:47:13 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-09.txt Thread-Index: AQHP1mMm0FMx4LZTAU+YaPvZDy8t8ZwNGbgQ Date: Mon, 22 Sep 2014 12:47:12 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494C763C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140922124548.22121.74401.idtracker@ietfa.amsl.com> In-Reply-To: <20140922124548.22121.74401.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/hZYBYnkROQbpK1wdWA0gyrr8NvI Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-09.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:47:16 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, September 22, 2014 8:46 AM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-09.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 : Security Services for the Registration Data > Access Protocol > Authors : Scott Hollenbeck > Ning Kong > Filename : draft-ietf-weirds-rdap-sec-09.txt > Pages : 11 > Date : 2014-09-22 WG last call comments addressed... Scott From nobody Mon Sep 22 06:04:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8B1A1AB8 for ; Mon, 22 Sep 2014 06:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOpFuHmM_z7L for ; Mon, 22 Sep 2014 06:04:23 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA951A1AC6 for ; Mon, 22 Sep 2014 06:04:20 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id r10so4388382pdi.39 for ; Mon, 22 Sep 2014 06:04:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TvoLZpAIDmXRrlVnPxw7a3zwrkECkIghCeMP6U+SPoA=; b=j/FSjxVmbrXbaI4vy4dNMwqltjhAze4aq+Tb/u9FjXdkrw1qLPKRpGUNI8XILLhqZn CuUdVTQf/BSnH/nv4q3e6Djgi3ljNp9OeM4mH+YZeYaDWaP7RVDy5kMe6mVt7/qO7KXV pOIhkHUgeojqHTxeiGwpuznhCwcXkRrBlxqSFVbpvry6af0XYdRERQv18v/5zFzBTzw0 5mlBR+Rgt3UC5Ua38W9So+9lORMBGg9NwJC6yDenCf9TZ20DwTwcWk1hQ83piAYXqjZl M/vNIrig26n9UTTW+z9LYynU1sJJ+hPesBkH3i8VTJv6AwJZ8pd43m+mx+ggJ01NcXXw H6Sg== X-Gm-Message-State: ALoCoQkWCcGbR6A8ubAKDnIAOdS3WHgYRFQ0BPAx9V3fSODGloqGC6CLkCf8swqjJ3oRPxiR9i0S MIME-Version: 1.0 X-Received: by 10.68.235.105 with SMTP id ul9mr24260855pbc.3.1411391059895; Mon, 22 Sep 2014 06:04:19 -0700 (PDT) Received: by 10.66.168.12 with HTTP; Mon, 22 Sep 2014 06:04:19 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494C73B8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <19F54F2956911544A32543B8A9BDE07526889114@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C5F8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494C73B8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 22 Sep 2014 09:04:19 -0400 Message-ID: From: Andrew Newton To: "Hollenbeck, Scott" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/OVq43SkzQKRCZaRf4_9RLMdtCso Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:04:28 -0000 On Mon, Sep 22, 2014 at 7:00 AM, Hollenbeck, Scott wrote: > [SAH] That=E2=80=99s specific to search behavior, but the text Alex is su= ggesting > leaves open the possibility of leaving out other features, too. So where = do > we draw the line? Does an implementation that provides (for example) doma= in > name lookups and nothing else =E2=80=9Cconform=E2=80=9D? I=E2=80=99m not = comfortable with referring > to existing WHOIS behavior as a guide because exceptions can be found to > support pretty much any position. I think the answer is yes. We already know some registries will not support nameserver lookups and some will. Perhaps we should add text that says servers that do not support a certain query SHOULD respond with a 501 (not implemented) return code. Or put that in using-http and have rdap-query point to using-http. What do you think? -andy From nobody Mon Sep 22 07:35:31 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36A31A1AB9 for ; Mon, 22 Sep 2014 07:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKf7XJdgbZLC for ; Mon, 22 Sep 2014 07:35:28 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289CE1A1AD8 for ; Mon, 22 Sep 2014 07:35:25 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKVCAzrFaTmuJqc073RI3nbBB6NrMscoQn@postini.com; Mon, 22 Sep 2014 07:35:28 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 s8MEZOA3009456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 10:35:24 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 22 Sep 2014 10:35:23 -0400 From: "Hollenbeck, Scott" To: Andrew Newton Thread-Topic: [weirds] Review of draft-ietf-weirds-rdap-query-13 Thread-Index: Ac/UDU+p9abcPxH9RBmYZDWJLrJ56gAGXnXQAGmherAAA5/KcAAbUGqAAAKGaZAADQVkgAAFmD5w Date: Mon, 22 Sep 2014 14:35:24 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494C78DE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <19F54F2956911544A32543B8A9BDE07526889114@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C5F8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494C73B8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Axrs_zR9Vj3k1zoHvIiHDJE2GCc Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:35:29 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmRyZXcgTmV3dG9uIFttYWls dG86YW5keUBoeHIudXNdDQo+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDIyLCAyMDE0IDk6MDQg QU0NCj4gVG86IEhvbGxlbmJlY2ssIFNjb3R0DQo+IENjOiBNdXJyYXkgUy4gS3VjaGVyYXd5OyB3 ZWlyZHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt3ZWlyZHNdIFJldmlldyBvZiBkcmFmdC1p ZXRmLXdlaXJkcy1yZGFwLXF1ZXJ5LTEzDQo+IA0KPiBPbiBNb24sIFNlcCAyMiwgMjAxNCBhdCA3 OjAwIEFNLCBIb2xsZW5iZWNrLCBTY290dA0KPiA8c2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tPiB3 cm90ZToNCj4gPiBbU0FIXSBUaGF04oCZcyBzcGVjaWZpYyB0byBzZWFyY2ggYmVoYXZpb3IsIGJ1 dCB0aGUgdGV4dCBBbGV4IGlzDQo+IHN1Z2dlc3RpbmcNCj4gPiBsZWF2ZXMgb3BlbiB0aGUgcG9z c2liaWxpdHkgb2YgbGVhdmluZyBvdXQgb3RoZXIgZmVhdHVyZXMsIHRvby4gU28NCj4gd2hlcmUg ZG8NCj4gPiB3ZSBkcmF3IHRoZSBsaW5lPyBEb2VzIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgcHJv dmlkZXMgKGZvciBleGFtcGxlKQ0KPiBkb21haW4NCj4gPiBuYW1lIGxvb2t1cHMgYW5kIG5vdGhp bmcgZWxzZSDigJxjb25mb3Jt4oCdPyBJ4oCZbSBub3QgY29tZm9ydGFibGUgd2l0aA0KPiByZWZl cnJpbmcNCj4gPiB0byBleGlzdGluZyBXSE9JUyBiZWhhdmlvciBhcyBhIGd1aWRlIGJlY2F1c2Ug ZXhjZXB0aW9ucyBjYW4gYmUgZm91bmQNCj4gdG8NCj4gPiBzdXBwb3J0IHByZXR0eSBtdWNoIGFu eSBwb3NpdGlvbi4NCj4gDQo+IEkgdGhpbmsgdGhlIGFuc3dlciBpcyB5ZXMuIFdlIGFscmVhZHkg a25vdyBzb21lIHJlZ2lzdHJpZXMgd2lsbCBub3QNCj4gc3VwcG9ydCBuYW1lc2VydmVyIGxvb2t1 cHMgYW5kIHNvbWUgd2lsbC4NCj4gDQo+IFBlcmhhcHMgd2Ugc2hvdWxkIGFkZCB0ZXh0IHRoYXQg c2F5cyBzZXJ2ZXJzIHRoYXQgZG8gbm90IHN1cHBvcnQgYQ0KPiBjZXJ0YWluIHF1ZXJ5IFNIT1VM RCByZXNwb25kIHdpdGggYSA1MDEgKG5vdCBpbXBsZW1lbnRlZCkgcmV0dXJuIGNvZGUuDQo+IE9y IHB1dCB0aGF0IGluIHVzaW5nLWh0dHAgYW5kIGhhdmUgcmRhcC1xdWVyeSBwb2ludCB0byB1c2lu Zy1odHRwLg0KPiBXaGF0IGRvIHlvdSB0aGluaz8NCg0KSXQgY291bGQgd29yay4gV2UgYWxyZWFk eSBoYXZlIHRleHQgaW4gU2VjdGlvbiA0IHRoYXQgYWRkcmVzc2VzIGEgc2ltaWxhciBzaXR1YXRp b246DQoNCiJJZiBhIHNlcnZlciByZWNlaXZlcyBhIHNlYXJjaCByZXF1ZXN0IGJ1dCBjYW5ub3Qg cHJvY2VzcyB0aGUgcmVxdWVzdCBiZWNhdXNlIGl0IGRvZXMgbm90IHN1cHBvcnQgYSBwYXJ0aWN1 bGFyIHN0eWxlIG9mIHBhcnRpYWwgbWF0Y2ggc2VhcmNoaW5nLCBpdCBTSE9VTEQgcmV0dXJuIGFu IEhUVFAgNDIyIFtSRkM0OTE4XSBlcnJvci4iDQoNClNvIGhvdyBhYm91dCBhZGRpbmcgdGhpcyB0 byBTZWN0aW9uIDI/DQoNCiJTZXJ2ZXIgaW1wbGVtZW50YXRpb25zIGFyZSBmcmVlIHRvIHN1cHBv cnQgb25seSBhIHN1YnNldCBvZiB0aGVzZSBmZWF0dXJlcyBkZXBlbmRpbmcgb24gbG9jYWwgcmVx dWlyZW1lbnRzLiBJZiBhIHNlcnZlciByZWNlaXZlcyBhIHF1ZXJ5IHRoYXQgaXQgY2Fubm90IHBy b2Nlc3MgYmVjYXVzZSBpdCBpcyBub3QgaW1wbGVtZW50ZWQgaXQgU0hPVUxEIHJldHVybiBhbiBI VFRQIDUwMSBbUkZDNzIzMV0gZXJyb3IuIg0KDQpTY290dA0K From nobody Mon Sep 22 07:41:13 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5E11A1ABE for ; Mon, 22 Sep 2014 07:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8QoYSaPT4lZ for ; Mon, 22 Sep 2014 07:41:10 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263F01A1AD8 for ; Mon, 22 Sep 2014 07:41:10 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id r10so4523259pdi.12 for ; Mon, 22 Sep 2014 07:41:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LzefiRhkuaDDNlqjw1u8Ox/zDN8f6qlBeFCAfhYn1Cw=; b=gGTEV1FiW/+FD1PmveL5uhnE60YPZ82AeepjcK1yKSSWN7BPef6vGj6hOuqL1441el r4hZivbALw8ke2bue0g6jNNLbhVXdmz/ENEgCH4530zTo3LQvHq7Gn14iDEuOStZ4oeh 4JWN6mXbeqa7HWovEjNPIhpcnHSBf43gtflAfwQi4ubDHsKcQERH51G+glCsVkNxrsv0 IAUZDPg1pumPFF/DUYzME4NVG2QZMYwz2aGcIzMrTBJaVQUuvzVrpCWVF+ywOD3q3nuL nAbJB4oXKYmW5H+MjM/gAwd/s8/8FrjKPQnrnIy04n1L7iawf/gN8Uv782411WrHvssp fnxQ== X-Gm-Message-State: ALoCoQkuH4BeQPg/8k9g8T4yCDGejWj21UEQlewxg0Kwh5BdExpNj6TQLXxmH8nvtxB+vDM2HLMk MIME-Version: 1.0 X-Received: by 10.70.60.169 with SMTP id i9mr5381564pdr.166.1411396869619; Mon, 22 Sep 2014 07:41:09 -0700 (PDT) Received: by 10.66.168.12 with HTTP; Mon, 22 Sep 2014 07:41:09 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494C78DE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <19F54F2956911544A32543B8A9BDE07526889114@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C5F8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494C73B8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494C78DE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 22 Sep 2014 10:41:09 -0400 Message-ID: From: Andrew Newton To: "Hollenbeck, Scott" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Ro5haU37H2Db9toXdAI5eroOwgk Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:41:12 -0000 On Mon, Sep 22, 2014 at 10:35 AM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Monday, September 22, 2014 9:04 AM >> To: Hollenbeck, Scott >> Cc: Murray S. Kucherawy; weirds@ietf.org >> Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 >> >> On Mon, Sep 22, 2014 at 7:00 AM, Hollenbeck, Scott >> wrote: >> > [SAH] That=E2=80=99s specific to search behavior, but the text Alex is >> suggesting >> > leaves open the possibility of leaving out other features, too. So >> where do >> > we draw the line? Does an implementation that provides (for example) >> domain >> > name lookups and nothing else =E2=80=9Cconform=E2=80=9D? I=E2=80=99m n= ot comfortable with >> referring >> > to existing WHOIS behavior as a guide because exceptions can be found >> to >> > support pretty much any position. >> >> I think the answer is yes. We already know some registries will not >> support nameserver lookups and some will. >> >> Perhaps we should add text that says servers that do not support a >> certain query SHOULD respond with a 501 (not implemented) return code. >> Or put that in using-http and have rdap-query point to using-http. >> What do you think? > > It could work. We already have text in Section 4 that addresses a similar= situation: > > "If a server receives a search request but cannot process the request bec= ause it does not support a particular style of partial match searching, it = SHOULD return an HTTP 422 [RFC4918] error." > > So how about adding this to Section 2? > > "Server implementations are free to support only a subset of these featur= es depending on local requirements. If a server receives a query that it ca= nnot process because it is not implemented it SHOULD return an HTTP 501 [RF= C7231] error." > > Scott Works for me. Any objections? -andy From nobody Mon Sep 22 08:03:36 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C43A1A1AF3 for ; Mon, 22 Sep 2014 08:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSWugXaqJA_f for ; Mon, 22 Sep 2014 08:03:23 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298F11A0145 for ; Mon, 22 Sep 2014 08:03:22 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Mon, 22 Sep 2014 17:03:17 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 17:03:15 +0200 From: Alexander Mayrhofer To: Andrew Newton , "Hollenbeck, Scott" Thread-Topic: [weirds] Review of draft-ietf-weirds-rdap-query-13 Thread-Index: Ac/UDU+p9abcPxH9RBmYZDWJLrJ56gAGXnXQAGmherAAA5/KcAAOvcOAAAs1XoAABFZwgAADLlkAAAAzaYAABO/kwA== Date: Mon, 22 Sep 2014 15:03:15 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0752688B215@NICS-EXCH2.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <19F54F2956911544A32543B8A9BDE07526889114@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C5F8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494C73B8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494C78DE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/4nXjZvw4ZbJ_GJoqJMDCN8gc8IE Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 15:03:25 -0000 PiA+IFNvIGhvdyBhYm91dCBhZGRpbmcgdGhpcyB0byBTZWN0aW9uIDI/DQo+ID4NCj4gPiAiU2Vy dmVyIGltcGxlbWVudGF0aW9ucyBhcmUgZnJlZSB0byBzdXBwb3J0IG9ubHkgYSBzdWJzZXQgb2Yg dGhlc2UNCj4gZmVhdHVyZXMgZGVwZW5kaW5nIG9uIGxvY2FsIHJlcXVpcmVtZW50cy4gSWYgYSBz ZXJ2ZXIgcmVjZWl2ZXMgYSBxdWVyeSB0aGF0IGl0DQo+IGNhbm5vdCBwcm9jZXNzIGJlY2F1c2Ug aXQgaXMgbm90IGltcGxlbWVudGVkIGl0IFNIT1VMRCByZXR1cm4gYW4gSFRUUCA1MDENCj4gW1JG QzcyMzFdIGVycm9yLiINCj4gPg0KPiA+IFNjb3R0DQo+IA0KPiBXb3JrcyBmb3IgbWUuIEFueSBv YmplY3Rpb25zPw0KDQpbQWxleGFuZGVyIE1heXJob2Zlcl0gDQpTb3VuZHMgZ29vZCB0byBtZSB0 b28sIHRoYW5rcy4NCg0KQWxleA0KDQo= From nobody Mon Sep 22 08:33:49 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7261A1A64 for ; Mon, 22 Sep 2014 08:33:47 -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=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hItLTA6BQMpf for ; Mon, 22 Sep 2014 08:33:45 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::764]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1431A1AC1 for ; Mon, 22 Sep 2014 08:33:43 -0700 (PDT) Received: from DB4PR06MB128.eurprd06.prod.outlook.com (10.242.155.27) by DB4PR06MB128.eurprd06.prod.outlook.com (10.242.155.27) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Mon, 22 Sep 2014 15:33:19 +0000 Received: from DB4PR06MB128.eurprd06.prod.outlook.com ([169.254.16.110]) by DB4PR06MB128.eurprd06.prod.outlook.com ([169.254.16.110]) with mapi id 15.00.1034.003; Mon, 22 Sep 2014 15:33:19 +0000 From: Maarten Bosteels To: Alexander Mayrhofer , Andrew Newton , "Hollenbeck, Scott" Thread-Topic: [weirds] Review of draft-ietf-weirds-rdap-query-13 Thread-Index: Ac/UDU+p9abcPxH9RBmYZDWJLrJ56gAGXnXQAGmherAAA5/KcAAS7qWAAAs1X4AABFZvgAADLlkAAAAzaYAAAMWXgAAFPRqA Date: Mon, 22 Sep 2014 15:33:19 +0000 Message-ID: References: <19F54F2956911544A32543B8A9BDE07526888C96@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C4721@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <19F54F2956911544A32543B8A9BDE07526889114@NICS-EXCH2.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F494C5F8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494C73B8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494C78DE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <19F54F2956911544A32543B8A9BDE0752688B215@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE0752688B215@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [77.67.63.234] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB128; x-forefront-prvs: 034215E98F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(24454002)(189002)(479174003)(199003)(77982003)(21056001)(80022003)(107046002)(46102003)(2656002)(31966008)(83322001)(64706001)(93886004)(50986999)(19580405001)(20776003)(85306004)(15975445006)(76176999)(79102003)(19580395003)(4396001)(90102001)(230783001)(92726001)(120916001)(92566001)(76482002)(99396002)(77096002)(66066001)(36756003)(97736003)(74482002)(95666004)(74662003)(54356999)(86362001)(81342003)(74502003)(81542003)(83072002)(85852003)(87936001)(106356001)(105586002)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB128; H:DB4PR06MB128.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: dnsbelgium.be Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/a0vKNKmRDGX8MKC9Kh-QWx8Bba0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Review of draft-ietf-weirds-rdap-query-13 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 15:33:47 -0000 Looks good to me too. Maarten On 22/09/14 17:03, "Alexander Mayrhofer" wrote: >> > So how about adding this to Section 2? >> > >> > "Server implementations are free to support only a subset of these >> features depending on local requirements. If a server receives a query >>that it >> cannot process because it is not implemented it SHOULD return an HTTP >>501 >> [RFC7231] error." >> > >> > Scott >>=20 >> Works for me. Any objections? > >[Alexander Mayrhofer] >Sounds good to me too, thanks. > >Alex > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From nobody Mon Sep 22 10:06:16 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512541A1B93; Mon, 22 Sep 2014 10:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_WoV8DdltcI; Mon, 22 Sep 2014 10:06:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B840F1A1B9A; Mon, 22 Sep 2014 10:06:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922170609.32251.96052.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 10:06:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/mfCZ1jgTUK07-iyYM0ivO7BOe5Q Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-14.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:06:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Registration Data Access Protocol Query Format Authors : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-14.txt Pages : 19 Date : 2014-09-22 Abstract: This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-query-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 22 10:10:28 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAC01A1BD9 for ; Mon, 22 Sep 2014 10:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUEL9p0BnXbr for ; Mon, 22 Sep 2014 10:10:20 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986111A1BA6 for ; Mon, 22 Sep 2014 10:10:03 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKVCBX686PS0dfWSGE9Hu5r6t/iMx/H/Ua@postini.com; Mon, 22 Sep 2014 10:10:03 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 s8MHA1VU017083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Sep 2014 13:10:02 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 22 Sep 2014 13:10:00 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: I-D Action: draft-ietf-weirds-rdap-query-14.txt Thread-Index: AQHP1oeQgSF1Ed0PSE2e4b23G+wFXZwNYiIA Date: Mon, 22 Sep 2014 17:10:01 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494C7E30@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140922170609.32251.96052.idtracker@ietfa.amsl.com> In-Reply-To: <20140922170609.32251.96052.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/HkJ-krsyGZh_ss-Hx0YvuKZcypM Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-14.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:10:26 -0000 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, September 22, 2014 1:06 PM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: I-D Action: draft-ietf-weirds-rdap-query-14.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Extensible Internet Registration > Data Service Working Group of the IETF. >=20 > Title : Registration Data Access Protocol Query > Format > Authors : Andrew Lee Newton > Scott Hollenbeck > Filename : draft-ietf-weirds-rdap-query-14.txt > Pages : 19 > Date : 2014-09-22 >=20 > Abstract: > This document describes uniform patterns to construct HTTP URLs that > may be used to retrieve registration information from registries > (including both Regional Internet Registries (RIRs) and Domain Name > Registries (DNRs)) using "RESTful" web access patterns. These > uniform patterns define the query syntax for the Registration Data > Access Protocol (RDAP). This version addresses WG last call comments, incorporating discussion resu= lts as appropriate. Please let me and Andy know if we missed anything. A di= ff is the best way to see the changes. http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-weirds-rdap-query-13&url2=3Dd= raft-ietf-weirds-rdap-query-14 Scott From nobody Mon Sep 22 10:29:36 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5391A1BB2 for ; Mon, 22 Sep 2014 10:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCRXK9D3_q7I for ; Mon, 22 Sep 2014 10:29:33 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14D21A1A60 for ; Mon, 22 Sep 2014 10:29:33 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id m15so3002883wgh.34 for ; Mon, 22 Sep 2014 10:29:32 -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=uJRZkUHZCKA+sT31nHWP3gGoozZGe3/DeSkMOxSRZkA=; b=ER1eDpVRrxNgpPlWhC0eJNNtsE0haibBP44gurPeBscbvymQDrqUHuI0sDiHv3X1XK YAGFylhcZpRPLFHisDUrOQq6IGxmTYuIwqzI+Qph17++PTweWrqYWmnh+0LDH8UWDjFC OnL2N+qdonKW8f55gZ75on2RVGBMe+GfrPLFaTxAAKz2RZfSKdVS8mFQc+nqA/hHAeLB tgalPCZknsOW9ij5Fo4723nLR1xm0XxwfKwaQJrp6+tw7+378+JJEVQdFO53rU07zj0o p77KJR3LQPH3hw50eSnDEOf91z6Lf9QXi7dSkumcpDVVoxB0wQ3DgTWVCOBuMQU49oXh gSMA== MIME-Version: 1.0 X-Received: by 10.180.10.38 with SMTP id f6mr16675918wib.30.1411406972244; Mon, 22 Sep 2014 10:29:32 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 22 Sep 2014 10:29:32 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494C7E30@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140922170609.32251.96052.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F494C7E30@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 22 Sep 2014 10:29:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=001a11c25d0836d8e20503aacbe2 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/4HGw_HyKStMb5bfpC8-rWV8h3EA Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-14.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:29:35 -0000 --001a11c25d0836d8e20503aacbe2 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 22, 2014 at 10:10 AM, Hollenbeck, Scott < shollenbeck@verisign.com> wrote: > This version addresses WG last call comments, incorporating discussion > results as appropriate. Please let me and Andy know if we missed anything. > A diff is the best way to see the changes. > Hi Scott, thanks for driving this forward. The only outstanding issue for me is the fact that REST is mentioned, but there's no reference describing or defining it. Anticipating someone bringing this up during IETF Last Call or IESG Evaluation (in the "please expand this acronym on first use" kind of way), I brought this question up on apps-discuss and created quite a stir as to what the right solution might be. There are several suggestions on a thread over there if you care to look and see if you want to make any changes based on those proposals. This isn't major enough to wait for, but if you spot something that looks palatable, please go ahead and make the change. I'll probably not get to the PROTO writeup until this afternoon or evening. -MSK --001a11c25d0836d8e20503aacbe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 22, 2014 at 10:10 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
This version addresses WG last call comments,= incorporating discussion results as appropriate. Please let me and Andy kn= ow if we missed anything. A diff is the best way to see the changes.

Hi Scott, thanks for driving this= forward.

The only outstanding issue for me is the fact t= hat REST is mentioned, but there's no reference describing or defining = it.=C2=A0 Anticipating someone bringing this up during IETF Last Call or IE= SG Evaluation (in the "please expand this acronym on first use" k= ind of way), I brought this question up on apps-discuss and created quite a= stir as to what the right solution might be.=C2=A0 There are several sugge= stions on a thread over there if you care to look and see if you want to ma= ke any changes based on those proposals.

This isn't m= ajor enough to wait for, but if you spot something that looks palatable, pl= ease go ahead and make the change.=C2=A0 I'll probably not get to the P= ROTO writeup until this afternoon or evening.

-MSK
--001a11c25d0836d8e20503aacbe2-- From nobody Mon Sep 22 10:37:41 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672741A1B91 for ; Mon, 22 Sep 2014 10:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hSD5TmiLGtb for ; Mon, 22 Sep 2014 10:37:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 297261A1B57 for ; Mon, 22 Sep 2014 10:37:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922173737.16990.56968.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 10:37:37 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/e9RXcSH6rTWKC4ikZPuRDjZauYI Subject: [weirds] Milestones changed for weirds WG X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:37:39 -0000 Changed milestone "draft-ietf-weirds-object-inventory to the IESG", resolved as "Done". URL: http://datatracker.ietf.org/wg/weirds/charter/ From nobody Mon Sep 22 11:05:00 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7831A1AA3 for ; Mon, 22 Sep 2014 11:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYMjylkCqHwd for ; Mon, 22 Sep 2014 11:04:57 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16AA1A1B57 for ; Mon, 22 Sep 2014 11:04:55 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVCBkx31UiClhQhc0ZMjg+7iZJ5dsZ9SU@postini.com; Mon, 22 Sep 2014 11:04:56 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 s8MI4sso016380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 14:04:54 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 22 Sep 2014 14:04:53 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-14.txt Thread-Index: AQHP1oeQgSF1Ed0PSE2e4b23G+wFXZwNYiIAgABJZwD//8ZLMA== Date: Mon, 22 Sep 2014 18:04:53 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494C7F41@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140922170609.32251.96052.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F494C7E30@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_831693C2CDA2E849A7D7A712B24E257F494C7F41BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/42EVp93AO5rLPkIXfCgGjylDL_A Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-14.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 18:04:59 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F494C7F41BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRvY3VtZW50IGFscmVhZHkgaW5jbHVkZXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRv IFJveSBGaWVsZGluZ+KAmXMgZGlzc2VydGF0aW9uIChsb29rIGZvciDigJxbUkVTVF3igJ0gaW4g dGhlIHRleHQpLiBEbyB3ZSBuZWVkIHRvIGRvIG1vcmUgdGhhbiB0aGF0PyBJIGRpZG7igJl0IHRo aW5rIHNvIGJhc2VkIG9uIHRoaXM6DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9hcHBzLWRpc2N1c3MvY3VycmVudC9tc2cxMjk3Ni5odG1sDQoNClNjb3R0DQoNCkZyb206 IE11cnJheSBTLiBLdWNoZXJhd3kgW21haWx0bzpzdXBlcnVzZXJAZ21haWwuY29tXQ0KU2VudDog TW9uZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMTQgMTozMCBQTQ0KVG86IEhvbGxlbmJlY2ssIFNjb3R0 DQpDYzogd2VpcmRzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3dlaXJkc10gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi13ZWlyZHMtcmRhcC1xdWVyeS0xNC50eHQNCg0KT24gTW9uLCBTZXAgMjIsIDIw MTQgYXQgMTA6MTAgQU0sIEhvbGxlbmJlY2ssIFNjb3R0IDxzaG9sbGVuYmVja0B2ZXJpc2lnbi5j b208bWFpbHRvOnNob2xsZW5iZWNrQHZlcmlzaWduLmNvbT4+IHdyb3RlOg0KVGhpcyB2ZXJzaW9u IGFkZHJlc3NlcyBXRyBsYXN0IGNhbGwgY29tbWVudHMsIGluY29ycG9yYXRpbmcgZGlzY3Vzc2lv biByZXN1bHRzIGFzIGFwcHJvcHJpYXRlLiBQbGVhc2UgbGV0IG1lIGFuZCBBbmR5IGtub3cgaWYg d2UgbWlzc2VkIGFueXRoaW5nLiBBIGRpZmYgaXMgdGhlIGJlc3Qgd2F5IHRvIHNlZSB0aGUgY2hh bmdlcy4NCg0KSGkgU2NvdHQsIHRoYW5rcyBmb3IgZHJpdmluZyB0aGlzIGZvcndhcmQuDQpUaGUg b25seSBvdXRzdGFuZGluZyBpc3N1ZSBmb3IgbWUgaXMgdGhlIGZhY3QgdGhhdCBSRVNUIGlzIG1l bnRpb25lZCwgYnV0IHRoZXJlJ3Mgbm8gcmVmZXJlbmNlIGRlc2NyaWJpbmcgb3IgZGVmaW5pbmcg aXQuICBBbnRpY2lwYXRpbmcgc29tZW9uZSBicmluZ2luZyB0aGlzIHVwIGR1cmluZyBJRVRGIExh c3QgQ2FsbCBvciBJRVNHIEV2YWx1YXRpb24gKGluIHRoZSAicGxlYXNlIGV4cGFuZCB0aGlzIGFj cm9ueW0gb24gZmlyc3QgdXNlIiBraW5kIG9mIHdheSksIEkgYnJvdWdodCB0aGlzIHF1ZXN0aW9u IHVwIG9uIGFwcHMtZGlzY3VzcyBhbmQgY3JlYXRlZCBxdWl0ZSBhIHN0aXIgYXMgdG8gd2hhdCB0 aGUgcmlnaHQgc29sdXRpb24gbWlnaHQgYmUuICBUaGVyZSBhcmUgc2V2ZXJhbCBzdWdnZXN0aW9u cyBvbiBhIHRocmVhZCBvdmVyIHRoZXJlIGlmIHlvdSBjYXJlIHRvIGxvb2sgYW5kIHNlZSBpZiB5 b3Ugd2FudCB0byBtYWtlIGFueSBjaGFuZ2VzIGJhc2VkIG9uIHRob3NlIHByb3Bvc2Fscy4NClRo aXMgaXNuJ3QgbWFqb3IgZW5vdWdoIHRvIHdhaXQgZm9yLCBidXQgaWYgeW91IHNwb3Qgc29tZXRo aW5nIHRoYXQgbG9va3MgcGFsYXRhYmxlLCBwbGVhc2UgZ28gYWhlYWQgYW5kIG1ha2UgdGhlIGNo YW5nZS4gIEknbGwgcHJvYmFibHkgbm90IGdldCB0byB0aGUgUFJPVE8gd3JpdGV1cCB1bnRpbCB0 aGlzIGFmdGVybm9vbiBvciBldmVuaW5nLg0KLU1TSw0K --_000_831693C2CDA2E849A7D7A712B24E257F494C7F41BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGUgZG9jdW1lbnQgYWxyZWFkeSBpbmNsdWRlcyBhbiBpbmZvcm1hdGl2ZSBy ZWZlcmVuY2UgdG8gUm95IEZpZWxkaW5n4oCZcyBkaXNzZXJ0YXRpb24gKGxvb2sgZm9yIOKAnFtS RVNUXeKAnSBpbiB0aGUgdGV4dCkuIERvIHdlIG5lZWQgdG8gZG8gbW9yZSB0aGFuIHRoYXQ/IEkg ZGlkbuKAmXQgdGhpbmsgc28gYmFzZWQNCiBvbiB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYXBwcy1kaXNj dXNzL2N1cnJlbnQvbXNnMTI5NzYuaHRtbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlNjb3R0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNdXJyYXkgUy4gS3VjaGVyYXd5IFttYWlsdG86 c3VwZXJ1c2VyQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIFNlcHRlbWJl ciAyMiwgMjAxNCAxOjMwIFBNPGJyPg0KPGI+VG86PC9iPiBIb2xsZW5iZWNrLCBTY290dDxicj4N CjxiPkNjOjwvYj4gd2VpcmRzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbd2Vp cmRzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXdlaXJkcy1yZGFwLXF1ZXJ5LTE0LnR4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24s IFNlcCAyMiwgMjAxNCBhdCAxMDoxMCBBTSwgSG9sbGVuYmVjaywgU2NvdHQgJmx0OzxhIGhyZWY9 Im1haWx0bzpzaG9sbGVuYmVja0B2ZXJpc2lnbi5jb20iIHRhcmdldD0iX2JsYW5rIj5zaG9sbGVu YmVja0B2ZXJpc2lnbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp cyB2ZXJzaW9uIGFkZHJlc3NlcyBXRyBsYXN0IGNhbGwgY29tbWVudHMsIGluY29ycG9yYXRpbmcg ZGlzY3Vzc2lvbiByZXN1bHRzIGFzIGFwcHJvcHJpYXRlLiBQbGVhc2UgbGV0IG1lIGFuZCBBbmR5 IGtub3cgaWYgd2UgbWlzc2VkIGFueXRoaW5nLiBBIGRpZmYgaXMgdGhlIGJlc3Qgd2F5IHRvIHNl ZSB0aGUgY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPkhpIFNjb3R0LCB0aGFua3MgZm9yIGRyaXZpbmcgdGhpcyBmb3J3YXJkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5UaGUgb25seSBvdXRzdGFuZGluZyBpc3N1ZSBmb3IgbWUgaXMgdGhl IGZhY3QgdGhhdCBSRVNUIGlzIG1lbnRpb25lZCwgYnV0IHRoZXJlJ3Mgbm8gcmVmZXJlbmNlIGRl c2NyaWJpbmcgb3IgZGVmaW5pbmcgaXQuJm5ic3A7IEFudGljaXBhdGluZyBzb21lb25lIGJyaW5n aW5nIHRoaXMgdXAgZHVyaW5nIElFVEYgTGFzdCBDYWxsIG9yIElFU0cgRXZhbHVhdGlvbiAoaW4g dGhlDQogJnF1b3Q7cGxlYXNlIGV4cGFuZCB0aGlzIGFjcm9ueW0gb24gZmlyc3QgdXNlJnF1b3Q7 IGtpbmQgb2Ygd2F5KSwgSSBicm91Z2h0IHRoaXMgcXVlc3Rpb24gdXAgb24gYXBwcy1kaXNjdXNz IGFuZCBjcmVhdGVkIHF1aXRlIGEgc3RpciBhcyB0byB3aGF0IHRoZSByaWdodCBzb2x1dGlvbiBt aWdodCBiZS4mbmJzcDsgVGhlcmUgYXJlIHNldmVyYWwgc3VnZ2VzdGlvbnMgb24gYSB0aHJlYWQg b3ZlciB0aGVyZSBpZiB5b3UgY2FyZSB0byBsb29rIGFuZCBzZWUgaWYgeW91IHdhbnQNCiB0byBt YWtlIGFueSBjaGFuZ2VzIGJhc2VkIG9uIHRob3NlIHByb3Bvc2Fscy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+VGhpcyBpc24ndCBtYWpvciBlbm91Z2ggdG8gd2FpdCBmb3IsIGJ1dCBpZiB5b3Ug c3BvdCBzb21ldGhpbmcgdGhhdCBsb29rcyBwYWxhdGFibGUsIHBsZWFzZSBnbyBhaGVhZCBhbmQg bWFrZSB0aGUgY2hhbmdlLiZuYnNwOyBJJ2xsIHByb2JhYmx5IG5vdCBnZXQgdG8gdGhlIFBST1RP IHdyaXRldXAgdW50aWwgdGhpcyBhZnRlcm5vb24gb3IgZXZlbmluZy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1NU0s8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_831693C2CDA2E849A7D7A712B24E257F494C7F41BRN1WNEXMBX01vc_-- From nobody Mon Sep 22 11:13:09 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC201A1B9F for ; Mon, 22 Sep 2014 11:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.859 X-Spam-Level: * X-Spam-Status: No, score=1.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_PROFIT1=3.858, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIuKlEf8k_eW for ; Mon, 22 Sep 2014 11:13:07 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52061A1B19 for ; Mon, 22 Sep 2014 11:13:06 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id w61so1472114wes.26 for ; Mon, 22 Sep 2014 11:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fWdB0FAxiK03VS/66ctCz8WhsmjQClcLCPepDfG0TPM=; b=SrBkwyAgelryAVfH1TlfxvyAVFMcxqX2aK5iMincG1DHN70MrS2P/mQY0VIr4Jc+D1 o8uDyNiL2UMSdd8OYUkLUQ9B2zeW/nWpj8M9K2B+fWiMgqwjszwNoCC8sp8SKY+zoI0S PTeTzJKZEbsr42LgOFmuYKRjriLVgMWdgkwbZgvaj/Tksy6DGoqByJXz/zUIVB9o0MNS iyfWBPWy6JE7wFiwzwcXAl7gv58IcV2D8mCeY0/ZIQRrzuQ44WpZq4Y3JtarK6iJ2hy/ omKsSS7cm6aqm/RwvjQOOqLyzFMGzwB0qV9b18WEksCbdXNZhtxbR73eC5rs0RGIDLX0 SZ6g== MIME-Version: 1.0 X-Received: by 10.194.79.35 with SMTP id g3mr4561174wjx.110.1411409585164; Mon, 22 Sep 2014 11:13:05 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 22 Sep 2014 11:13:05 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494C7F41@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140922170609.32251.96052.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F494C7E30@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494C7F41@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 22 Sep 2014 11:13:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=047d7bf0c59af4efe20503ab6654 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/oLouY-12pPKKHzuy9qTZJjFSM0k Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-14.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 18:13:08 -0000 --047d7bf0c59af4efe20503ab6654 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 22, 2014 at 11:04 AM, Hollenbeck, Scott < shollenbeck@verisign.com> wrote: > The document already includes an informative reference to Roy Fielding= =E2=80=99s > dissertation (look for =E2=80=9C[REST]=E2=80=9D in the text). Do we need = to do more than > that? I didn=E2=80=99t think so based on this: > > > > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12976.html > > I thought it was done there too but the thread continued for quite a while, with more people making suggestions or expressing concern that the dissertation reference shouldn't be used. I don't feel like we need to spend a lot more time on it. My purpose in mentioning it once more is to point out the suggestions made on that thread in case any of them improve our document at all and/or complaint-proof it. If you think we're good to go as we have it, then that's fine with me. -MSK --047d7bf0c59af4efe20503ab6654 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 22, 2014 at 11:04 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

The document already includes an informati= ve reference to Roy Fielding=E2=80=99s dissertation (look for =E2=80=9C[RES= T]=E2=80=9D in the text). Do we need to do more than that? I didn=E2=80=99t= think so based on this:

=C2=A0

http://www.ietf= .org/mail-archive/web/apps-discuss/current/msg12976.html<= /span>

<= br>
I thought it was done there too but the thread continued for = quite a while, with more people making suggestions or expressing concern th= at the dissertation reference shouldn't be used.

I don't fee= l like we need to spend a lot more time on it.=C2=A0 My purpose in mentioni= ng it once more is to point out the suggestions made on that thread in case= any of them improve our document at all and/or complaint-proof it.=C2=A0 I= f you think we're good to go as we have it, then that's fine with m= e.

-MSK
--047d7bf0c59af4efe20503ab6654-- From nobody Mon Sep 22 11:22:29 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4EF1A1BBF for ; Mon, 22 Sep 2014 11:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.342 X-Spam-Level: X-Spam-Status: No, score=-0.342 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PROFIT1=3.858, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fwrrrdFxx7X for ; Mon, 22 Sep 2014 11:22:25 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8C11A1B9F for ; Mon, 22 Sep 2014 11:22:23 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKVCBo3w7Ddxv1B21B2If3DMHyjarebQDi@postini.com; Mon, 22 Sep 2014 11:22:24 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 s8MIMMrm017015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 14:22:22 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 22 Sep 2014 14:22:22 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-14.txt Thread-Index: AQHP1oeQgSF1Ed0PSE2e4b23G+wFXZwNYiIAgABJZwD//8ZLMIAAReCA//++saA= Date: Mon, 22 Sep 2014 18:22:22 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494C8037@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140922170609.32251.96052.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F494C7E30@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F494C7F41@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_831693C2CDA2E849A7D7A712B24E257F494C8037BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/MRAeLksUFQ7JkGCyggK5_XuSD-g Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-14.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 18:22:26 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F494C8037BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTXVycmF5IFMuIEt1Y2hlcmF3eSBbbWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb21dDQpT ZW50OiBNb25kYXksIFNlcHRlbWJlciAyMiwgMjAxNCAyOjEzIFBNDQpUbzogSG9sbGVuYmVjaywg U2NvdHQNCkNjOiB3ZWlyZHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbd2VpcmRzXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXdlaXJkcy1yZGFwLXF1ZXJ5LTE0LnR4dA0KDQpPbiBNb24sIFNlcCAy MiwgMjAxNCBhdCAxMTowNCBBTSwgSG9sbGVuYmVjaywgU2NvdHQgPHNob2xsZW5iZWNrQHZlcmlz aWduLmNvbTxtYWlsdG86c2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tPj4gd3JvdGU6DQpUaGUgZG9j dW1lbnQgYWxyZWFkeSBpbmNsdWRlcyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUm95IEZp ZWxkaW5n4oCZcyBkaXNzZXJ0YXRpb24gKGxvb2sgZm9yIOKAnFtSRVNUXeKAnSBpbiB0aGUgdGV4 dCkuIERvIHdlIG5lZWQgdG8gZG8gbW9yZSB0aGFuIHRoYXQ/IEkgZGlkbuKAmXQgdGhpbmsgc28g YmFzZWQgb24gdGhpczoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Fw cHMtZGlzY3Vzcy9jdXJyZW50L21zZzEyOTc2Lmh0bWwNCg0KSSB0aG91Z2h0IGl0IHdhcyBkb25l IHRoZXJlIHRvbyBidXQgdGhlIHRocmVhZCBjb250aW51ZWQgZm9yIHF1aXRlIGEgd2hpbGUsIHdp dGggbW9yZSBwZW9wbGUgbWFraW5nIHN1Z2dlc3Rpb25zIG9yIGV4cHJlc3NpbmcgY29uY2VybiB0 aGF0IHRoZSBkaXNzZXJ0YXRpb24gcmVmZXJlbmNlIHNob3VsZG4ndCBiZSB1c2VkLg0KDQpJIGRv bid0IGZlZWwgbGlrZSB3ZSBuZWVkIHRvIHNwZW5kIGEgbG90IG1vcmUgdGltZSBvbiBpdC4gIE15 IHB1cnBvc2UgaW4gbWVudGlvbmluZyBpdCBvbmNlIG1vcmUgaXMgdG8gcG9pbnQgb3V0IHRoZSBz dWdnZXN0aW9ucyBtYWRlIG9uIHRoYXQgdGhyZWFkIGluIGNhc2UgYW55IG9mIHRoZW0gaW1wcm92 ZSBvdXIgZG9jdW1lbnQgYXQgYWxsIGFuZC9vciBjb21wbGFpbnQtcHJvb2YgaXQuICBJZiB5b3Ug dGhpbmsgd2UncmUgZ29vZCB0byBnbyBhcyB3ZSBoYXZlIGl0LCB0aGVuIHRoYXQncyBmaW5lIHdp dGggbWUuDQpbU0FIXSBMZXTigJlzIGxlYXZlIHRoZSBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgYXMt aXMgYW5kIGxldCB0aGUgY2hpcHMgZmFsbCB3aGVyZSB0aGV5IG1heS4NCg0KU2NvdHQNCg== --_000_831693C2CDA2E849A7D7A712B24E257F494C8037BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gTXVycmF5IFMuIEt1Y2hlcmF3eSBbbWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMTQgMjoxMyBQTTxicj4N CjxiPlRvOjwvYj4gSG9sbGVuYmVjaywgU2NvdHQ8YnI+DQo8Yj5DYzo8L2I+IHdlaXJkc0BpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3dlaXJkc10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi13ZWlyZHMtcmRhcC1xdWVyeS0xNC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBTZXAgMjIsIDIwMTQgYXQgMTE6MDQg QU0sIEhvbGxlbmJlY2ssIFNjb3R0ICZsdDs8YSBocmVmPSJtYWlsdG86c2hvbGxlbmJlY2tAdmVy aXNpZ24uY29tIiB0YXJnZXQ9Il9ibGFuayI+c2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGUgZG9jdW1lbnQgYWxyZWFkeSBpbmNsdWRlcyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2Ug dG8gUm95IEZpZWxkaW5n4oCZcyBkaXNzZXJ0YXRpb24gKGxvb2sgZm9yIOKAnFtSRVNUXeKAnSBp biB0aGUgdGV4dCkuDQogRG8gd2UgbmVlZCB0byBkbyBtb3JlIHRoYW4gdGhhdD8gSSBkaWRu4oCZ dCB0aGluayBzbyBiYXNlZCBvbiB0aGlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMt ZGlzY3Vzcy9jdXJyZW50L21zZzEyOTc2Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYXBwcy1kaXNjdXNzL2N1cnJlbnQvbXNnMTI5NzYu aHRtbDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5JIHRob3VnaHQgaXQgd2FzIGRvbmUgdGhlcmUgdG9vIGJ1dCB0aGUgdGhyZWFkIGNv bnRpbnVlZCBmb3IgcXVpdGUgYSB3aGlsZSwgd2l0aCBtb3JlIHBlb3BsZSBtYWtpbmcgc3VnZ2Vz dGlvbnMgb3IgZXhwcmVzc2luZyBjb25jZXJuIHRoYXQgdGhlIGRpc3NlcnRhdGlvbiByZWZlcmVu Y2Ugc2hvdWxkbid0IGJlIHVzZWQuPGJyPg0KPGJyPg0KSSBkb24ndCBmZWVsIGxpa2Ugd2UgbmVl ZCB0byBzcGVuZCBhIGxvdCBtb3JlIHRpbWUgb24gaXQuJm5ic3A7IE15IHB1cnBvc2UgaW4gbWVu dGlvbmluZyBpdCBvbmNlIG1vcmUgaXMgdG8gcG9pbnQgb3V0IHRoZSBzdWdnZXN0aW9ucyBtYWRl IG9uIHRoYXQgdGhyZWFkIGluIGNhc2UgYW55IG9mIHRoZW0gaW1wcm92ZSBvdXIgZG9jdW1lbnQg YXQgYWxsIGFuZC9vciBjb21wbGFpbnQtcHJvb2YgaXQuJm5ic3A7IElmIHlvdSB0aGluayB3ZSdy ZSBnb29kIHRvIGdvIGFzDQogd2UgaGF2ZSBpdCwgdGhlbiB0aGF0J3MgZmluZSB3aXRoIG1lLjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltT QUhdIExldOKAmXMgbGVhdmUgdGhlIGluZm9ybWF0aXZlIHJlZmVyZW5jZSBhcy1pcyBhbmQgbGV0 IHRoZSBjaGlwcyBmYWxsIHdoZXJlIHRoZXkgbWF5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5TY290dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_831693C2CDA2E849A7D7A712B24E257F494C8037BRN1WNEXMBX01vc_-- From nobody Mon Sep 22 11:56:17 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DD31A1AF4 for ; Mon, 22 Sep 2014 11:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lInXl42t5WzK for ; Mon, 22 Sep 2014 11:56:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B331A1B57 for ; Mon, 22 Sep 2014 11:55:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922185554.17493.58067.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 11:55:54 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/E95Ijj_5ALdr0o4FBUxllCtiv5A Subject: [weirds] Milestones changed for weirds WG X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 18:56:09 -0000 Changed milestone "draft-ietf-weirds-rdap-query to the IESG", resolved as "Done". URL: http://datatracker.ietf.org/wg/weirds/charter/ From nobody Mon Sep 22 13:11:34 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AB41A1B51 for ; Mon, 22 Sep 2014 13:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgoFV-jTPvt0 for ; Mon, 22 Sep 2014 13:11:32 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA3C1A1B0E for ; Mon, 22 Sep 2014 13:11:10 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id p10so3095380wes.31 for ; Mon, 22 Sep 2014 13:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uF1g0xcy/oTkZ63EN9WoADPymToYeGNBLZ/wq3EV6Ks=; b=RY3UQQMnqepNurm2rOn0IjLrmCPFFXQ5/twmvubpnPatbHU314G7Xuy9MoijvAXY1+ qhZdQp7QpXIn+GnOQDZ0hm80U51w+90HxcWA3TtjgAw3wDQ6wBHGH3K7UIf/jSQXVUbV +cD70bkmPBt3dvnESdtEz5scBxrYCUmhC+1tOCZ/nKR5jxK7TvA14W/VMc3/gI1rwb+5 H0fj0xOZSPs3Iy0tkbXLEvlVSS9jq88nYAxLyzcLDzytuUwkx80Mr39dT0u3lUbk8FBB 41MPAoEiA7J7eIuDZjHjYbISWqc2LIUxWRASPWqVzV5DuMAB7ZUPksPZp8qJLjCOdwSM GwIA== MIME-Version: 1.0 X-Received: by 10.194.184.101 with SMTP id et5mr23395650wjc.14.1411416669634; Mon, 22 Sep 2014 13:11:09 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 22 Sep 2014 13:11:09 -0700 (PDT) Date: Mon, 22 Sep 2014 13:11:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7ba9792e39483b0503ad0d3f Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ayz05mb5FeH5U0SGSu3AYUbZJ2s Subject: [weirds] Three down, four to go! X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:11:33 -0000 --047d7ba9792e39483b0503ad0d3f Content-Type: text/plain; charset=UTF-8 Colleagues, The rdap-sec, rdap-query and object-inventory drafts have been submitted to the IESG. Congrats to all of us, and especially the authors! For the other four: When you submit your documents, please also send me an email directly that affirms you have no knowledge of any IPR that hasn't been declared in conformance with BCP 78 and 79. I need that from all authors before I can hit the "Submit" button. Thanks! -MSK --047d7ba9792e39483b0503ad0d3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The rdap-sec,= rdap-query and object-inventory drafts have been submitted to the IESG.=C2= =A0 Congrats to all of us, and especially the authors!

For the= other four: When you submit your documents, please also send me an email d= irectly that affirms you have no knowledge of any IPR that hasn't been = declared in conformance with BCP 78 and 79.=C2=A0 I need that from all auth= ors before I can hit the "Submit" button.

Thanks!
-MSK
--047d7ba9792e39483b0503ad0d3f-- From nobody Tue Sep 23 07:20:25 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B191A86F0; Tue, 23 Sep 2014 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YW27ldhgr3h; Tue, 23 Sep 2014 07:20:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A87E71A86EE; Tue, 23 Sep 2014 07:20:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140923142013.3841.66279.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 07:20:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/lIFHksBBz8FmC_QOksce3e1Esfk Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-09.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 14:20:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : JSON Responses for the Registration Data Access Protocol (RDAP) Authors : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-json-response-09.txt Pages : 90 Date : 2014-09-23 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-json-response-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 23 09:47:02 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97891A8756 for ; Tue, 23 Sep 2014 09:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPZ6iBAiiG_b for ; Tue, 23 Sep 2014 09:46:57 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA86D1A8755 for ; Tue, 23 Sep 2014 09:46:52 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x13so4184818wgg.28 for ; Tue, 23 Sep 2014 09:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bFYX1nlI1OYpOvCc95tekvSBnyTobzXbiu7udplmGQI=; b=SxzzuXcsvIrQ/YrMh/i5NyoCqVBOL+e5EZZd8MUThjBJRu5sgVSSFO6tHjv3PULZvf 0eTWd4xEii9WzmruVzFrmqckhlZ6XX/eexd0ytLRFr924s5SC45Edjs0Eh9l3uVAVL+a a3u78QlebFlfh8wgu3tlUGJeEBDrWLzzPJ+jqawFr5bzyNWC6Q9GaLpMxSOCnhNb037R bh3i6oh+EjqOCS+aUpW7MFnuk++gu58cSTSmXVIraVUR0VX8gYlP8VAl5QMSgCvd5II2 vF0Ck5a/q4Bvf8dD6SCqDpzqnK9rDI4u0FEw5yQT5D0ZFvTG+ZAcT0I5yHfm4w0HV0+n Ew0Q== MIME-Version: 1.0 X-Received: by 10.194.219.193 with SMTP id pq1mr1002312wjc.5.1411490811432; Tue, 23 Sep 2014 09:46:51 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 23 Sep 2014 09:46:51 -0700 (PDT) Date: Tue, 23 Sep 2014 09:46:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c286206b55220503be50bf Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/R2iMgWqOZTEFvMHSffee7RSwMSA Subject: [weirds] On redirects X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 16:47:00 -0000 --001a11c286206b55220503be50bf Content-Type: text/plain; charset=UTF-8 Colleagues, Four drafts submitted. We're getting down to the wire here! I reviewed all the documents last week and posted review comments, as you've seen. With respect to the redirects document, I'm wondering if it might be simpler to roll those contents into the using-http document. Here's my reasoning: 0) We've only got a day or two left to meet our deadline. 1) The redirects document is not as close to being ready as the using-http document is (I'm worried by the "TBC" and "TBD" notations especially). 2) Rudimentary support for redirects is already covered in Section 5.2 of using-http. 3) Beyond definitions, references, and the usual boilerplate, the meat of the redirects draft is about a page and a half long. 4) Author responsiveness is becoming a factor. 5) Less work for Pete. I understand that there's at least one implementation of what's described in this document, so I do want to preserve the work. I'm just not certain that it needs its own document given the constraints under which we're presently operating. Any opinions on this, especially from the authors of both documents? -MSK --001a11c286206b55220503be50bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,
Four drafts submitted.=C2=A0 We're getting down to the wire= here!

I reviewed all the documents last week and posted revie= w comments, as you've seen.=C2=A0 With respect to the redirects documen= t, I'm wondering if it might be simpler to roll those contents into the= using-http document.=C2=A0 Here's my reasoning:

0) W= e've only got a day or two left to meet our deadline.

1) T= he redirects document is not as close to being ready as the using-http docu= ment is (I'm worried by the "TBC" and "TBD" notatio= ns especially).

2) Rudimentary support for redirects is alread= y covered in Section 5.2 of using-http.

3) Beyond definit= ions, references, and the usual boilerplate, the meat of the redirects draf= t is about a page and a half long.

4) Author responsiveness is= becoming a factor.

5) Less work for Pete.

I unde= rstand that there's at least one implementation of what's described= in this document, so I do want to preserve the work.=C2=A0 I'm just no= t certain that it needs its own document given the constraints under which = we're presently operating.

Any opinions on this, especiall= y from the authors of both documents?

-MSK
--001a11c286206b55220503be50bf-- From nobody Tue Sep 23 10:02:33 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BA11A8777 for ; Tue, 23 Sep 2014 10:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eORpHy2pDjGx for ; Tue, 23 Sep 2014 10:02:30 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 39EA51A8767 for ; Tue, 23 Sep 2014 10:01:48 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id E42CF164FD7; Tue, 23 Sep 2014 13:01:47 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 4B6DB165005; Tue, 23 Sep 2014 13:01:47 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 23 Sep 2014 13:03:10 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Tue, 23 Sep 2014 13:01:46 -0400 From: Andy Newton To: "Murray S. Kucherawy" Thread-Topic: [weirds] On redirects Thread-Index: AQHP104BLhHW68bZyka539/862IV+JwPNI8A Date: Tue, 23 Sep 2014 17:01:46 +0000 Message-ID: <92E21A89-B348-4FDB-8309-0A4D8BD100D2@arin.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.34.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D9E740FDB8CC4489B11BA7985FC1415@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/JKFPBBI8bYn9e-LAmsDnCK0HJYI Cc: "weirds@ietf.org" Subject: Re: [weirds] On redirects X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 17:02:31 -0000 On Sep 23, 2014, at 12:46 PM, Murray S. Kucherawy wro= te: > Any opinions on this, especially from the authors of both documents? I can quickly turn around some text in using-http that is ripped and conver= ted from the redirects draft if that is what people want. -andy= From nobody Tue Sep 23 15:02:53 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1981A1BD2 for ; Tue, 23 Sep 2014 15:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRPtw3qTttsu for ; Tue, 23 Sep 2014 15:02:49 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8A81A1B67 for ; Tue, 23 Sep 2014 15:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:date:from:to:subject:message-id:mail-followup-to: references:mime-version:content-type:content-disposition:in-reply-to: user-agent:return-path; bh=ynCq5kFTzlYPN8DWACOmHy1XCkk/jk+y0AEMVh/F8OA=; b=xdLxDMvXKC1ufwv+S3NFxoKnTxMKeO7aIoI2MmVpVgHN3Q93oJyomQZnnUImdrtZhQH4CuwUN92Ib icBKleI1wVz7MRkOCV4UpDKq34B4M0OqeqviP2OLhOqM+xGJiMrz0GJdHWsmnyjZwuybT2wPjZdK+k Rgl1LZ2IXhudda+A= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Wed, 24 Sep 2014 08:05:04 +1000 (EST) Received: from main (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 24 Sep 2014 08:02:43 +1000 Received: from tomh by main with local (Exim 4.84) (envelope-from ) id 1XWYAV-000AzL-Ky for weirds@ietf.org; Wed, 24 Sep 2014 08:02:43 +1000 Date: Wed, 24 Sep 2014 08:02:43 +1000 From: Tom Harrison To: Message-ID: <20140923220243.GG33822@main> Mail-Followup-To: weirds@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/UNzo2h-ZJ6ZuJ5Si_LLwZVITyrY Subject: Re: [weirds] On redirects X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 22:02:50 -0000 On Tue, Sep 23, 2014 at 09:46:51AM -0700, Murray S. Kucherawy wrote: > I reviewed all the documents last week and posted review comments, as > you've seen. With respect to the redirects document, I'm wondering if it > might be simpler to roll those contents into the using-http document. I think this is a good idea. -Tom From nobody Tue Sep 23 18:14:52 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6971A899B for ; Tue, 23 Sep 2014 18:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj-b6FLW8fQ2 for ; Tue, 23 Sep 2014 18:14:48 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2AA51A89A1 for ; Tue, 23 Sep 2014 18:14:47 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id im17so6054264vcb.36 for ; Tue, 23 Sep 2014 18:14:47 -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=kpaczW8R0JYmIfwgBTXjQXPwDHV2Z47MeppcKUdZyRk=; b=IoTAtRUr/ZhK01kzSeoKchaiJgKlzw/OzgjN4DMvNLT3IJAJVc8l8IZ8y0qXMjPKio Ed7i+1n5fCwcTvUWKbNP0iSjuCsrfFtjLMHfevFh8BhK4WSB2LbnBgnlfFHBHWFDQGHp mIoL2ILDXXlzAcvqqVk252+Zrtrd7h18sweaYpcgEA1dLq3PFUC1+fb1JNYpd9A0HIwJ 6yK5WUISyN0li5Q1mDhl2BnYRJPyUSa8SdT4DPHu74ZHCFZQ7j6slga2gO6MhoyGGsxf PnU0zXPvmnJtaqp+vmO3AbmWIM17xS8BzZmaxwvCpPn/w5UQlS1kfsD5PWoJk2/FtNSg 1OGA== X-Received: by 10.52.145.199 with SMTP id sw7mr1856772vdb.33.1411521286829; Tue, 23 Sep 2014 18:14:46 -0700 (PDT) Received: from [192.168.1.230] (r186-48-158-2.dialup.adsl.anteldata.net.uy. [186.48.158.2]) by mx.google.com with ESMTPSA id tz3sm2746791vdb.24.2014.09.23.18.14.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Sep 2014 18:14:45 -0700 (PDT) Message-ID: <54221B2C.4030403@gmail.com> Date: Tue, 23 Sep 2014 22:15:24 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Andy Newton , "Murray S. Kucherawy" References: <92E21A89-B348-4FDB-8309-0A4D8BD100D2@arin.net> In-Reply-To: <92E21A89-B348-4FDB-8309-0A4D8BD100D2@arin.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/0dHIl24XZf0ImCe2dS3MVjEHtms Cc: "weirds@ietf.org" Subject: Re: [weirds] On redirects X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 01:14:49 -0000 I do agree. On 9/23/2014 2:01 PM, Andy Newton wrote: > > On Sep 23, 2014, at 12:46 PM, Murray S. Kucherawy wrote: > >> Any opinions on this, especially from the authors of both documents? > > I can quickly turn around some text in using-http that is ripped and converted from the redirects draft if that is what people want. > > -andy > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From nobody Tue Sep 23 19:40:55 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA691A8A45 for ; Tue, 23 Sep 2014 19:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfeN3HxHfUI2 for ; Tue, 23 Sep 2014 19:40:52 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2CAB1A8A4C for ; Tue, 23 Sep 2014 19:40:52 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id em10so6039676wid.11 for ; Tue, 23 Sep 2014 19:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t6NLUHwdGOPtOd0IoApo9ap0BjBUWQDvnOVhBvnp2K8=; b=r4OXrxygQvKleke7KtqazwTaT6dHYxupTWqyJGvWkI54mZ3iuvgKNLHkSXuSx05rTV YiXker0ubymI0Er0dETZd2wzqc+vmZEmCGDgmgt6qxpKTtZea8/ylab4uip0bbTP9/r1 HTK+Rjc0QmtqNuOqCENnIjw1li6U1HDc+CscdiHjoJgjHVmnXLH3f5nvv05WH54bL5gA YczJNm/s3YQPvq/faEk6X+CO+53c/BgRsKWBlBXhATHsBEasXaRWjkK42dgLBXBok9y4 CWgd8GRpi2misEQi5J0+cc6Fu17Q0hMkQAUYFYpKNgr22lV+N7ThimN/I6WCY8LRa75Z ipEg== MIME-Version: 1.0 X-Received: by 10.180.184.20 with SMTP id eq20mr27311445wic.61.1411526451194; Tue, 23 Sep 2014 19:40:51 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 23 Sep 2014 19:40:51 -0700 (PDT) In-Reply-To: <54221B2C.4030403@gmail.com> References: <92E21A89-B348-4FDB-8309-0A4D8BD100D2@arin.net> <54221B2C.4030403@gmail.com> Date: Tue, 23 Sep 2014 19:40:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: Carlos Martinez Content-Type: multipart/alternative; boundary=001a11c3536ab6f3d30503c69c48 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/h7oNwlReFzk_W9x8hCUgBTNiGWY Cc: "weirds@ietf.org" Subject: Re: [weirds] On redirects X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 02:40:54 -0000 --001a11c3536ab6f3d30503c69c48 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 23, 2014 at 6:15 PM, Carlos M. Martinez wrote: > I do agree. > Andy, please proceed. Try to keep new text (i.e., wording or concepts not in the redirects draft already) to a minimum so that we can still reasonably claim that your changes have consensus. I'll merge the two documents in the datatracker when we submit it to Pete. -MSK --001a11c3536ab6f3d30503c69c48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 23, 2014 at 6:15 PM, Carlos M. Martinez <= carlosm3011@gmail.com> wrote:
<= div class=3D"gmail_quote">
I do agree.

Andy, please proceed.=C2=A0 Try to keep new t= ext (i.e., wording or concepts not in the redirects draft already) to a min= imum so that we can still reasonably claim that your changes have consensus= .

I'll merge the two documents in the datatracker whe= n we submit it to Pete.

-MSK
--001a11c3536ab6f3d30503c69c48-- From nobody Wed Sep 24 11:10:38 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00441A0312 for ; Wed, 24 Sep 2014 11:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE__djj7BhN9 for ; Wed, 24 Sep 2014 11:10: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 C53C71A0311 for ; Wed, 24 Sep 2014 11:10:25 -0700 (PDT) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 533B34037D; Wed, 24 Sep 2014 14:10:24 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: <20140916225142.GA21306@main> Date: Wed, 24 Sep 2014 13:30:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66598ACC-674B-4ED7-A297-CE7053600608@viagenie.ca> References: <20140916225142.GA21306@main> To: Tom Harrison , "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/YZ0kt8_zpg9A-Zv2X6kIHaN351Q Cc: "" Subject: Re: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 18:10:31 -0000 Le 2014-09-16 =E0 18:51, Tom Harrison a =E9crit : > On Mon, Sep 15, 2014 at 10:57:49AM -0700, Murray S. Kucherawy wrote: >> 4) Also in Section 3, rather than requiring that all base URLs end in = "/", >> couldn't the client just add one if it's missing in the bootstrap = object? >> I'm wondering why that MUST is needed. >=20 > Speaking for myself, the previous text here was: >=20 > Base RDAP URLs are likely to have a trailing "/" character because > they are aggregated to the various segments defined in > [I-D.ietf-weirds-rdap-query]. >=20 > Without any other instruction, the obvious thing for a client to do in > the absence of the trailing "/" is append that "/", given the way in > which the segments are defined in rdap-query. However, there is > nothing prohibiting a server operator from having a bootstrap base URL > like "https://registry.example.com/myrdap-", and resource paths like > "https://registry.example.com/myrdap-domain/example.com". I was > interested to avoid any confusion on this point, hence the suggestion > for MUST. If this were replaced with text that required the appending > of the "/" for bootstrap URLs that do not have it, that would work as > well. So unless someone else speak, the text for this will remain as it is. >=20 >> 10) In Section 5, I'm a little puzzled by the use of "longest match". = I >> think it's right, but we might want to add parenthetically that we're >> actually looking to match the largest number of network bits. longest match is a very very well known concept within people using IP = addresses. It is a basic concept of routing. Moreover, there is some = text about this in the draft already. So I'm not sure what you would = like to see. >> Otherwise, >> I'm a little fuzzy on what "longest" might mean because IP addresses = are >> all the same size (within the same family). that is not the point at all. The prefix always come with a mask, which = is the delimitation. Again, there is text explaining what that means. = Can you suggest alternative text? >=20 > Additionally, I think it would be worth clarifying what to do when > looking up a network range that is larger than any single range in the > registry, let me make sure I understand your point with an example based on my = understanding of your text: a query is for 1.0.0.0/3 and that there is = no 1.0.0.0/3 in the registry, but there is 2.0.0.0/3 and 1.0.0.0/4. Is = this the use case you are trying to describe? Marc. > or that is split equally between multiple ranges in the > registry. Treating these cases in the same way as "non-existent > entries" as per section 7 is probably the simplest approach. >=20 > -Tom >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Wed Sep 24 11:50:12 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E74B1A0347 for ; Wed, 24 Sep 2014 11:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy-4JlhqoGIh for ; Wed, 24 Sep 2014 11:50:08 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94481A00EF for ; Wed, 24 Sep 2014 11:50:07 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id t60so6611173wes.8 for ; Wed, 24 Sep 2014 11:50:06 -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=qMOae5M57YuyrXXsVKAQDDM9NCNZNh8dlOAf5E0W6VI=; b=rSNptPT74Svr5j03iSUjTeyrXiXlf3Fdx/w+iz0VjKb1JE4O9837A11rk3cMvIJ9fB 9SaWvkI9XMYrAzh9QFj/AlWtXEF4dJ+MPXkj7KGg6FSky4QqQLbs/UIK0PL7fTMADKd9 tA1e11SgOvV6sdfcEq3FYhxy+mlIAFhQepN+LxI1cCgu0pWbP8we+7hFXZYPzABp+u24 tdlOubk61cdI/IISQdm+8D+r189bB/U3p3uUcqZ8Kv1EHEfeu6H8v4X3JJtexK8pfFpt Qdbo+MEZqkdByrAA9UhUvbNNrkJ4RpWI2GKSNkIrSrhmWTw7CEBnXsUe13yCdQsj58Nz 2MAA== MIME-Version: 1.0 X-Received: by 10.194.237.2 with SMTP id uy2mr10011528wjc.89.1411584606302; Wed, 24 Sep 2014 11:50:06 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Wed, 24 Sep 2014 11:50:06 -0700 (PDT) In-Reply-To: <66598ACC-674B-4ED7-A297-CE7053600608@viagenie.ca> References: <20140916225142.GA21306@main> <66598ACC-674B-4ED7-A297-CE7053600608@viagenie.ca> Date: Wed, 24 Sep 2014 11:50:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: Marc Blanchet Content-Type: multipart/alternative; boundary=089e01493f680779f60503d4277e Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/4H8IdIsF5BPkPXCV7Zl7-zxSd0U Cc: "" Subject: Re: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 18:50:10 -0000 --089e01493f680779f60503d4277e Content-Type: text/plain; charset=UTF-8 On Wed, Sep 24, 2014 at 10:30 AM, Marc Blanchet wrote: > > Without any other instruction, the obvious thing for a client to do in > > the absence of the trailing "/" is append that "/", given the way in > > which the segments are defined in rdap-query. However, there is > > nothing prohibiting a server operator from having a bootstrap base URL > > like "https://registry.example.com/myrdap-", and resource paths like > > "https://registry.example.com/myrdap-domain/example.com". I was > > interested to avoid any confusion on this point, hence the suggestion > > for MUST. If this were replaced with text that required the appending > > of the "/" for bootstrap URLs that do not have it, that would work as > > well. > > So unless someone else speak, the text for this will remain as it is. > Tom makes a good point, so I'm satisfied. >> 10) In Section 5, I'm a little puzzled by the use of "longest match". I > >> think it's right, but we might want to add parenthetically that we're > >> actually looking to match the largest number of network bits. > > longest match is a very very well known concept within people using IP > addresses. It is a basic concept of routing. Moreover, there is some text > about this in the draft already. So I'm not sure what you would like to see. > Someone who knows about domain names but not IP addresses might not know what "longest match" means in that context. I get that it's a term of art, but that sometimes means it will leave some readers in the dark. If I'm the only one worried about this, then just leave it. > Additionally, I think it would be worth clarifying what to do when > > looking up a network range that is larger than any single range in the > > registry, > > let me make sure I understand your point with an example based on my > understanding of your text: a query is for 1.0.0.0/3 and that there is > no 1.0.0.0/3 in the registry, but there is 2.0.0.0/3 and 1.0.0.0/4. Is > this the use case you are trying to describe? > Assuming I understand Tom's point: If I ask for 128.0.0.0/1, do I get back all v4 records where the most significant bit is set? -MSK --089e01493f680779f60503d4277e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 24, 2014 at 10:30 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
> Without any other instruction, the obvious thing for a client to= do in
> the absence of the trailing "/" is append that "/"= , given the way in
> which the segments are defined in rdap-query.=C2=A0 However, there is<= br> > nothing prohibiting a server operator from having a bootstrap base URL=
> like "https://registry.example.com/myrdap-", and resource paths = like
> "https://registry.example.com/myrdap-domain/example.com= ".=C2=A0 I was
> interested to avoid any confusion on this point, hence the suggestion<= br> > for MUST.=C2=A0 If this were replaced with text that required the appe= nding
> of the "/" for bootstrap URLs that do not have it, that woul= d work as
> well.

So unless someone else speak, the text for this will remain as it is= .

Tom makes a good point, so I'm sa= tisfied.

>> 10) In Section 5, I'm a little puzzled by the= use of "longest match".=C2=A0 I
>> think it's right, but we might want to add parenthetically tha= t we're
>> actually looking to match the largest number of network bits.

longest match is a very very well known concept within people using = IP addresses. It is a basic concept of routing.=C2=A0 Moreover, there is so= me text about this in the draft already. So I'm not sure what you would= like to see.

Someone who knows about d= omain names but not IP addresses might not know what "longest match&qu= ot; means in that context.=C2=A0 I get that it's a term of art, but tha= t sometimes means it will leave some readers in the dark.

If I'm the only one worried about this, then just leave it.

> Additionally, I think it would be worth clarifying wh= at to do when
> looking up a network range that is larger than any single range in the=
> registry,

let me make sure I understand your point with an example based on my= understanding of your text: a query is for 1.0.0.0/3=C2=A0 and that there is no 1.0.0.0/3 in the registry, but there is 2.0.0.0/3 and 1.0.0.0/4. Is this the use case you = are trying to describe?

Assuming I u= nderstand Tom's point: If I ask for 128.= 0.0.0/1, do I get back all v4 records where the most significant bit is= set?

-MSK
--089e01493f680779f60503d4277e-- From nobody Wed Sep 24 13:57:33 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E871A02F6; Wed, 24 Sep 2014 13:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsjqTroHtQFe; Wed, 24 Sep 2014 13:57:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 868331A036D; Wed, 24 Sep 2014 13:57:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140924205728.23691.62312.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 13:57:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/gWnm4xKKApu4CGuXzMjYJpC0hps Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-12.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 20:57:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : HTTP usage in the Registration Data Access Protocol (RDAP) Authors : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-12.txt Pages : 19 Date : 2014-09-24 Abstract: This document is one of a collection that together describe the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-using-http-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-using-http-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 24 14:10:21 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8C11A1A42 for ; Wed, 24 Sep 2014 14:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jka_7N2Iue5V for ; Wed, 24 Sep 2014 14:10:16 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9EA1A1A3A for ; Wed, 24 Sep 2014 14:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:from:to:subject:thread-topic:thread-index:date:message-id: references:in-reply-to:accept-language:content-language:x-ms-has-attach: x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding: mime-version; bh=WGCChHmAcPcOidY80fsbLNiF74s2lnZlZ0PO18iu/js=; b=CnQWGA7SFj8ifLz1ZAM1T2INptgjoMabNsh2ckVg9YLDIbGkmjJuzkoSKEfB7803rwqddb3PGY94x YW9sHR5qDOqvAn882gA7xczI+EPVE9TX3qQOJGwEJvwfsmauR0coFhpGsRdLnbDFN7X9fd6Eqm4+we MC4jO6wbLzEbwTSk= Received: from iamda3.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Thu, 25 Sep 2014 07:10:05 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by iamda3.org.apnic.net ([fe80::e195:c0e8:e814:db75%15]) with mapi id 14.01.0218.012; Thu, 25 Sep 2014 07:10:11 +1000 From: Tom Harrison To: "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-bootstrap Thread-Index: AQHP0RM/nx5Np5nuMEWi3KYc3HyPOZwDt8YAgAw5AwCAAORcVQ== Date: Wed, 24 Sep 2014 21:09:08 +0000 Message-ID: <0005C18AC37F0B428D143F90B6069C6788CF08A2@NXMDA1.org.apnic.net> References: <20140916225142.GA21306@main>, <66598ACC-674B-4ED7-A297-CE7053600608@viagenie.ca> In-Reply-To: <66598ACC-674B-4ED7-A297-CE7053600608@viagenie.ca> Accept-Language: en-US, en-AU 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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/LJoIF9cV9Gp2ybKqqOyUFlegbZk Subject: Re: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 21:10:19 -0000 >> Additionally, I think it would be worth clarifying what to do when >> looking up a network range that is larger than any single range in >> the registry, > > let me make sure I understand your point with an example based on > my understanding of your text: a query is for 1.0.0.0/3 and that > there is no 1.0.0.0/3 in the registry, but there is 2.0.0.0/3 and > 1.0.0.0/4. Is this the use case you are trying to describe? Yes, that's right. It's not to do with the networks that a potential RDAP server might return in response to a query, but merely with the=20 selection of the RDAP server based on the bootstrap. -Tom= From nobody Wed Sep 24 16:07:17 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917601A1AE5 for ; Wed, 24 Sep 2014 16:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWjSEIsVCr2R for ; Wed, 24 Sep 2014 16:07:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 175B21A1AF5 for ; Wed, 24 Sep 2014 16:06:56 -0700 (PDT) Received: from [192.168.1.164] (modemcable060.86-160-184.mc.videotron.ca [184.160.86.60]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C1B73403D0; Wed, 24 Sep 2014 19:06:54 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: <0005C18AC37F0B428D143F90B6069C6788CF08A2@NXMDA1.org.apnic.net> Date: Wed, 24 Sep 2014 19:06:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140916225142.GA21306@main>, <66598ACC-674B-4ED7-A297-CE7053600608@viagenie.ca> <0005C18AC37F0B428D143F90B6069C6788CF08A2@NXMDA1.org.apnic.net> To: Tom Harrison X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/VS3Y-QO1Bk5cg_a68ivB1jtZo-A Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 23:07:15 -0000 Le 2014-09-24 =E0 17:09, Tom Harrison a =E9crit : >>> Additionally, I think it would be worth clarifying what to do when >>> looking up a network range that is larger than any single range in >>> the registry, >>=20 >> let me make sure I understand your point with an example based on >> my understanding of your text: a query is for 1.0.0.0/3 and that >> there is no 1.0.0.0/3 in the registry, but there is 2.0.0.0/3 and >> 1.0.0.0/4. Is this the use case you are trying to describe? >=20 > Yes, that's right. It's not to do with the networks that a potential > RDAP server might return in response to a query, but merely with the=20= > selection of the RDAP server based on the bootstrap. of course. So in the example above, it is obvious (to me at least) that the client = would parse the registry and find no match, therefore the registry does = not have any rdap server for the prefix. Do you agree? If yes, then I'm = not sure what needs to be said in the draft. Marc. >=20 > -Tom > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Wed Sep 24 16:58:25 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2241A1B5A for ; Wed, 24 Sep 2014 16:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmWdmAg_BebY for ; Wed, 24 Sep 2014 16:58:22 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119DD1A1B59 for ; Wed, 24 Sep 2014 16:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:from:to:subject:thread-topic:thread-index:date:message-id: references:in-reply-to:accept-language:content-language:x-ms-has-attach: x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding: mime-version; bh=cI7RtixqvK4B10tQnh/CtB4qs2c7qazAku3ETjrLFa4=; b=EmVbdCxs3b2ZOZwKGi5Re0v+UWJG6yJotM8r4oQAeZtgjPybwAmheYNgVONXlGH13IBLOhTSuPR0n LlXY53MezIFBVjVpcNWlTt/DKW5O0xWNxbgWwPhFHZibb18F2W4+J55D49GhSeHC+nxJdmGXrCctok N7PNqQvAHFabtgrI= Received: from iamda3.org.apnic.net (unknown [203.119.101.249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Thu, 25 Sep 2014 10:00:44 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by iamda3.org.apnic.net ([fe80::e195:c0e8:e814:db75%15]) with mapi id 14.01.0218.012; Thu, 25 Sep 2014 09:58:17 +1000 From: Tom Harrison To: "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-bootstrap Thread-Index: AQHP0RM/nx5Np5nuMEWi3KYc3HyPOZwDt8YAgAw5AwCAAORcVf//eYcAgACz2I4= Date: Wed, 24 Sep 2014 23:58:16 +0000 Message-ID: <0005C18AC37F0B428D143F90B6069C6788CF0932@NXMDA1.org.apnic.net> References: <20140916225142.GA21306@main>, <66598ACC-674B-4ED7-A297-CE7053600608@viagenie.ca> <0005C18AC37F0B428D143F90B6069C6788CF08A2@NXMDA1.org.apnic.net>, In-Reply-To: Accept-Language: en-US, en-AU 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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/7eRjU47354aOEkt6-hJ7lPfuVfU Subject: Re: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 23:58:24 -0000 >> Yes, that's right. It's not to do with the networks that a=20 >> potential RDAP server might return in response to a query, but >> merely with the selection of the RDAP server based on the >> bootstrap. >=20 > of course. >=20 > So in the example above, it is obvious (to me at least) that the=20 > client would parse the registry and find no match, therefore the=20 > registry does not have any rdap server for the prefix. Do you agree? > If yes, then I'm not sure what needs to be said in the draft. I agree, but I still think it's worth clarifying, given the explicit routing analogy. Finding references to "longest match" in the context of routing is easy, but those are all about finding the longest match for a single address, rather than a network, as far as I can tell. =20 Additionally, section 5 has "the authoritative registration data service is found by doing a longest match of the target *address*", and "[t]he longest match is done the same way as for routing". I=20 think a reasonable implementor might, in the absence of a covering=20 prefix, think it open e.g. to resolve to a server based on the first address in the target network, or by using some other address or=20 subnet from the target network. In that sort of situation, they really should be returning an error to the client. -Tom= From nobody Wed Sep 24 17:01:55 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08C41A1B7D for ; Wed, 24 Sep 2014 17:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKNZqoHrm8fM for ; Wed, 24 Sep 2014 17:01: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 6ED451A1B7B for ; Wed, 24 Sep 2014 17:01:52 -0700 (PDT) Received: from [192.168.1.164] (modemcable060.86-160-184.mc.videotron.ca [184.160.86.60]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 353AE403D0; Wed, 24 Sep 2014 20:01:51 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: <0005C18AC37F0B428D143F90B6069C6788CF0932@NXMDA1.org.apnic.net> Date: Wed, 24 Sep 2014 20:01:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140916225142.GA21306@main>, <66598ACC-674B-4ED7-A297-CE7053600608@viagenie.ca> <0005C18AC37F0B428D143F90B6069C6788CF08A2@NXMDA1.org.apnic.net>, <0005C18AC37F0B428D143F90B6069C6788CF0932@NXMDA1.org.apnic.net> To: Tom Harrison X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/xb6_1hwhkCXwTgRyRnQaQS9OfyQ Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 00:01:54 -0000 Le 2014-09-24 =E0 19:58, Tom Harrison a =E9crit : >>> Yes, that's right. It's not to do with the networks that a=20 >>> potential RDAP server might return in response to a query, but >>> merely with the selection of the RDAP server based on the >>> bootstrap. >>=20 >> of course. >>=20 >> So in the example above, it is obvious (to me at least) that the=20 >> client would parse the registry and find no match, therefore the=20 >> registry does not have any rdap server for the prefix. Do you agree? >> If yes, then I'm not sure what needs to be said in the draft. >=20 > I agree, but I still think it's worth clarifying, given the explicit > routing analogy. Finding references to "longest match" in the context > of routing is easy, but those are all about finding the longest match > for a single address, rather than a network, as far as I can tell. =20 > Additionally, section 5 has "the authoritative registration data > service is found by doing a longest match of the target *address*", > and "[t]he longest match is done the same way as for routing". I=20 > think a reasonable implementor might, in the absence of a covering=20 > prefix, think it open e.g. to resolve to a server based on the first > address in the target network, or by using some other address or=20 > subnet from the target network. In that sort of situation, they > really should be returning an error to the client. ok. I guess I'm too involved in routing and network operations. Would = you mind providing some text suggestions? Marc. >=20 > -Tom > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Wed Sep 24 18:32:38 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0C61A6EFE for ; Wed, 24 Sep 2014 18:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xk-ePv6kDCg for ; Wed, 24 Sep 2014 18:32:35 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942B31A1BFC for ; Wed, 24 Sep 2014 18:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:from:to:subject:thread-topic:thread-index:date:message-id: references:in-reply-to:accept-language:content-language:x-ms-has-attach: x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding: mime-version; bh=zr9ZaM1fXj+rJbGJO3aMFH6qVx8xYat3FEn5/UwP+Lw=; b=FbmOh0H1r+uBKHpVzsUp4IQkFBtIcMqhgU3mifZfWh9wMHNk5GJsMulzaGKM8aPazR+yaIjAAlXf0 BvkDhy92HyGXxnZN891RJnCBUCC2xZVwqJFBscXN2KO9HP3HYR/6W+lR5F3vxz1QBd2tFsn7Vd9eAL EmTot95PXXE2B8po= Received: from iamda3.org.apnic.net (unknown [203.119.101.249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Thu, 25 Sep 2014 11:34:58 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by iamda3.org.apnic.net ([fe80::e195:c0e8:e814:db75%15]) with mapi id 14.01.0218.012; Thu, 25 Sep 2014 11:32:30 +1000 From: Tom Harrison To: "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-bootstrap Thread-Index: AQHP0RM/nx5Np5nuMEWi3KYc3HyPOZwDt8YAgAw5AwCAAORcVf//eYcAgACz2I7//1t/AIAAwBy2 Date: Thu, 25 Sep 2014 01:32:29 +0000 Message-ID: <0005C18AC37F0B428D143F90B6069C6788CF09CF@NXMDA1.org.apnic.net> References: <20140916225142.GA21306@main>, <66598ACC-674B-4ED7-A297-CE7053600608@viagenie.ca> <0005C18AC37F0B428D143F90B6069C6788CF08A2@NXMDA1.org.apnic.net>, <0005C18AC37F0B428D143F90B6069C6788CF0932@NXMDA1.org.apnic.net>, In-Reply-To: Accept-Language: en-US, en-AU 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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/yZ-vAMhUv8NS8rVC6ipvrypU4RM Subject: Re: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 01:32:37 -0000 > ok. I guess I'm too involved in routing and network operations.=20 > Would you mind providing some text suggestions? After the first paragraph in section 5 (the first and second=20 paragraphs below are straight from the original text): For IP address space, the authoritative registration data service is found by doing a longest match of the target address with the values of the arrays in the corresponding Address Space RDAP Bootstrap registry. The longest match is done the same way as for routing: the addresses are converted in binary form and then the binary strings are compared to find the longest match. =20 If the target is a network, rather than a single address, then the longest match is based on the network prefix components only. If there is no single entry in the registry that covers the whole target network, clients SHOULD NOT default to resolving the query=20 by using a single address from, or a subnet of, the target network. The values contained in the second element of the array are the=20 base RDAP URLs as described in [I-D.ietf-weirds-rdap-query]. The longest match method enables covering prefixes of a larger address space pointing to one base RDAP URL while more specific prefixes within the covering prefix being served by another base RDAP URL. -Tom= From nobody Wed Sep 24 19:06:31 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75141A6F0E for ; Wed, 24 Sep 2014 19:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8f4FWFdEZLu9 for ; Wed, 24 Sep 2014 19:06:25 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E405E1A6F17 for ; Wed, 24 Sep 2014 19:06:24 -0700 (PDT) Received: (qmail 3257 invoked from network); 25 Sep 2014 02:06:23 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 25 Sep 2014 02:06:23 -0000 Date: 25 Sep 2014 02:06:01 -0000 Message-ID: <20140925020601.51728.qmail@ary.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/yjH-So091sal8UpUZ8m5Cv1JmAg Subject: Re: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:06:29 -0000 >> I agree, but I still think it's worth clarifying, given the explicit >> routing analogy. Finding references to "longest match" in the context >> of routing is easy, ... It's also a standard idea in text processing, regular expressions, and the various automata that process them. In this context, I'm having trouble imagining the mindset of someone who would interpret "longest match" as anything other than, you know, the longest match. R's, John From nobody Thu Sep 25 06:42:46 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D6C1A00D5 for ; Thu, 25 Sep 2014 06:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgpxWp3q7iNN for ; Thu, 25 Sep 2014 06:42:39 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC561A6FE3 for ; Thu, 25 Sep 2014 06:42:39 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so1158530pab.18 for ; Thu, 25 Sep 2014 06:42:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xkxZgvD6ag4JwQm5e+GwdILSyhK6mTQv5iiUGjtnd8k=; b=i7Zcxb/ZRI2/qad6X1oEtMNF65uMws4qThaDTLGRMnH8hPH8TRF4Rgq3ACiPa5nUwu w+k7a6nTD7rdUGSDyy2432OCelQST6ivWsdHn/HGeKV1fp7lvcBBHZi4sTPglUXcTLrt 8MyT+2tPDWuyR4qdOTpts/z9GOCUqBibvYOGovgGvRFCg1px+GrYwJFsgPvIFLX6h4hE fuh1+NT7/JCYz4BqrmTb+Mvs2XDyjpYkNJv6QgwiP5ZraMkKCDzvO5lf4nzOlwhwJInq MLyBTnwcJ1DqCqNbjJzGS4TsVyBR+tAujb3Laf1mA7Gb77SVSY1DKliLMnvK4fAoC/+d vrng== X-Gm-Message-State: ALoCoQnlqyyWHUeYzDFnXMytB7/oKJWN0zg7IXnTEOcyZPB5f25jmrCRqyMTiQfZS0X8loqxn3gR MIME-Version: 1.0 X-Received: by 10.69.25.35 with SMTP id in3mr19652657pbd.63.1411652559266; Thu, 25 Sep 2014 06:42:39 -0700 (PDT) Received: by 10.66.168.12 with HTTP; Thu, 25 Sep 2014 06:42:39 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: <0005C18AC37F0B428D143F90B6069C6788CF09CF@NXMDA1.org.apnic.net> References: <20140916225142.GA21306@main> <66598ACC-674B-4ED7-A297-CE7053600608@viagenie.ca> <0005C18AC37F0B428D143F90B6069C6788CF08A2@NXMDA1.org.apnic.net> <0005C18AC37F0B428D143F90B6069C6788CF0932@NXMDA1.org.apnic.net> <0005C18AC37F0B428D143F90B6069C6788CF09CF@NXMDA1.org.apnic.net> Date: Thu, 25 Sep 2014 09:42:39 -0400 Message-ID: From: Andrew Newton To: Tom Harrison Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/e4Fu35YzLG5cfG-GDuj4F3ZJhNY Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-bootstrap X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 13:42:44 -0000 On Wed, Sep 24, 2014 at 9:32 PM, Tom Harrison wrote: > After the first paragraph in section 5 (the first and second > paragraphs below are straight from the original text): > > For IP address space, the authoritative registration data service is > found by doing a longest match of the target address with the values > of the arrays in the corresponding Address Space RDAP Bootstrap > registry. The longest match is done the same way as for routing: the > addresses are converted in binary form and then the binary strings > are compared to find the longest match. > > If the target is a network, rather than a single address, then the > longest match is based on the network prefix components only. If > there is no single entry in the registry that covers the whole > target network, clients SHOULD NOT default to resolving the query > by using a single address from, or a subnet of, the target network. > > The values contained in the second element of the array are the > base RDAP URLs as described in [I-D.ietf-weirds-rdap-query]. The > longest match method enables covering prefixes of a larger address > space pointing to one base RDAP URL while more specific prefixes > within the covering prefix being served by another base RDAP URL. > Or in other words, where a NO MATCH in the other registries is not easily subverted by adding bits because nothing there would be reasonably meaningful, guessing at an IP address in a range to find a match when there is no clear longest match is simply not acceptable. I agree with this, though as an implementer it never once crossed my mind to do something like that. This text doesn't change anything, it just guards against a corner case. So I think it should be added. -andy From nobody Mon Sep 29 19:17:07 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6CF1A00C9; Mon, 29 Sep 2014 19:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSVBHL8ZJ7Na; Mon, 29 Sep 2014 19:16:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6831A00C0; Mon, 29 Sep 2014 19:16:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930021659.28400.10875.idtracker@ietfa.amsl.com> Date: Mon, 29 Sep 2014 19:16:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/bk716yCLb0Kf6ZctPD9RCc8-FGk Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-bootstrap-07.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 02:17:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Finding the Authoritative Registration Data (RDAP) Service Authors : Marc Blanchet Guillaume Leclanche Filename : draft-ietf-weirds-bootstrap-07.txt Pages : 16 Date : 2014-09-29 Abstract: This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-bootstrap-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 29 19:24:28 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AE31A00EA for ; Mon, 29 Sep 2014 19:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx4k5AsO8Q-G for ; Mon, 29 Sep 2014 19:24: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 DA0AC1A00DD for ; Mon, 29 Sep 2014 19:24:23 -0700 (PDT) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9FC4340411 for ; Mon, 29 Sep 2014 22:24:22 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Marc Blanchet In-Reply-To: <20140930021659.28400.10875.idtracker@ietfa.amsl.com> Date: Mon, 29 Sep 2014 22:24:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8BCF6479-FD02-4184-8640-0EC146C3BE9A@viagenie.ca> References: <20140930021659.28400.10875.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/-3HSD9bIPhYd7KXal7es_TlbBHg Subject: Re: [weirds] I-D Action: draft-ietf-weirds-bootstrap-07.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 02:24:25 -0000 Hello, bootstrap draft received many comments, all good! most of them were in = sync, while a few were opposite. Please note that, as requested, there = is now an ABNF which becomes the formal syntax specification of the = registry. I hope we implemented all WGLC comments. Tracker bugs have = been updated. Regards, Marc. Le 2014-09-29 =E0 22:16, internet-drafts@ietf.org a =E9crit : >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Extensible Internet Registration = Data Service Working Group of the IETF. >=20 > Title : Finding the Authoritative Registration Data = (RDAP) Service > Authors : Marc Blanchet > Guillaume Leclanche > Filename : draft-ietf-weirds-bootstrap-07.txt > Pages : 16 > Date : 2014-09-29 >=20 > Abstract: > This document specifies a method to find which Registration Data > Access Protocol (RDAP) server is authoritative to answer queries for > a requested scope, such as domain names, IP addresses or Autonomous > System numbers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-bootstrap-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds