From nobody Mon Dec 1 16:07: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 44E291ACD63 for ; Mon, 1 Dec 2014 16:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt4qqWKBUH9t for ; Mon, 1 Dec 2014 16:06:46 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD131AC42F for ; Mon, 1 Dec 2014 16:06:46 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 30A9620C4C for ; Mon, 1 Dec 2014 19:06:46 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 01 Dec 2014 19:06:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=mesmtp; bh=KjQ5cfk0nkvxeJJ2 62PPMfU56c0=; b=F+QtzP7aBgsolGwmZPD9uSNAAA6n52HGGlsPuH+DpggyrxkF g7qvEZ4KEkzFWdysUmafOTHIuA/YMlxROJgfTiLTzlkjtNCgAixF4nF+AuLmEavE ElPnFxy7RuU3kZpqCuE7EFtPtOCFA9ZOeRu0x9Ntg2bwm8uCOaAesFWmNuA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:message-id:references:to; s= smtpout; bh=KjQ5cfk0nkvxeJJ262PPMfU56c0=; b=BT+sLlBSDFyXdcZdRCfW PB1nv1mAmq7RARKiedeQXWzQQJnGhSGjvHbWU5Cfj950F80Fa6kvUDeHXKRcc5eE RKcPvlo5u3H2uh8DRjCxuancV3k39evYcIrB2U9ElGQv0V5elMWvsCzAagnpFzG4 W4/KLDFUwFDDGFloFYNyoLA= X-Sasl-enc: mpGc/m+6slTgCK1bXWX5GVOIvDOVKRXzkPUxN8XHOg++ 1417478805 Received: from [10.35.132.83] (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 6A5BA6800C9; Mon, 1 Dec 2014 19:06:45 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C75EDB4-B7A8-4964-A532-968AACB29AB4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <81AA7EAA-76C9-49CE-9B9C-B717E00A08CB@cooperw.in> Date: Mon, 1 Dec 2014 16:06:59 -0800 Message-Id: <5F7DA9CB-C39D-43ED-BD74-66BD0E365FD9@cooperw.in> References: <20141028231454.16979.8007.idtracker@ietfa.amsl.com> <23FB3A98-8047-4505-B91F-FB9ABCAC8407@arin.net> <81AA7EAA-76C9-49CE-9B9C-B717E00A08CB@cooperw.in> To: Andy Newton X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/RI9Zl-VWYqLB9flyoLuJRzCLcXU Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" , "weirds@ietf.org" , IESG Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 00:06:49 -0000 --Apple-Mail=_0C75EDB4-B7A8-4964-A532-968AACB29AB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I reviewed the -12 of this document and it mostly looks good, but there = are a couple of outstanding points: * The first paragraph in Section 13 is redundant now, I think. * I=92m a little confused about the normative recommendation made in = Section 13. It almost sounds as if you=92re recommending a particular = interpretation of =93private,=94 =93redacted,=94 and =93obscured,=94 = while being open to other interpretations. That doesn=92t seem = advisable, though =97 shouldn=92t the interpretations of those values = apply the same everywhere? It seems more like what you want to RECOMMEND = is that if the data elements fit the interpretations of the status = values, then those status values SHOULD be used. * The example given for =93obscured=94 is not quite what I was = expecting, and seems like it could be confused for =93redacted.=94 I = would have thought =93obscured=94 meant something more like you take an = identifier that directly identifies an entity and replace it with a = randomized identifier for that entity, or some such. Thanks, Alissa On Oct 30, 2014, at 7:24 AM, Alissa Cooper wrote: > On Oct 30, 2014, at 4:09 AM, Andy Newton wrote: >=20 >>=20 >> On Oct 28, 2014, at 7:14 PM, Alissa Cooper wrote: >>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> I think this document is missing a discussion of the fact that while >>> jCard was selected as the format for entity representation because = it can >>> flexibly accommodate the spectrum of the kinds of entities that = require >>> representation in RDAP, the full jCard specification includes many = fields >>> that are unrelated to the uses of the RDAP protocol and therefore = not >>> expected to be stored or made available by servers. This is a = different >>> point than the point made in Appendix A.1 (which should really be in >>> Section 14 IMO) about the use of status values, which implies that = the >>> fields exist in the server-side database but are not shared in = certain >>> circumstances. >>=20 >> This is a good point. Does inserting the following paragraph after = the first paragraph in Section 5.1 address this? >>=20 >> The entity object class uses jCard [RFC7095] to represent contact = information, >> such as postal addresses, email addresses, phone numbers and names of=20= >> organizations and individuals. Many of the types of information that = can be >> represented with jCard are unlikely to be used in RDAP, such as = birthdays, >> anniversaries, and gender. >=20 > s/are unlikely to be used/have no use/ >=20 > Otherwise looks good. >=20 >>=20 >>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> =3D Section 3.2 =3D >>> I love an idiom as much as the next person, but it would be better = to use >>> names in examples that are not culturally specific. >>>=20 >>> =3D Section 4 =3D >>> The reference to I-D.ietf-jcardcal-jcard should be replaced with RFC >>> 7095, I think. >>>=20 >>> =3D Section 6.1 =3D >>> Following on from my DISCUSS, I know the example in this section is = just >>> an example, but it includes all kinds of information about Joe User = that >>> no registry should be asking for and no registrant should willingly >>> provide (gender? anniversary? really?!). It would be nice for the = example >>> to reflect what reality might/should actually be like. >>=20 >> Agreed (though your section numbers are off). >=20 > Sorry about that, too many document reviews going on at once =85 >=20 > Thanks, > Alissa >=20 >>=20 >> Thanks. >>=20 >> -andy >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_0C75EDB4-B7A8-4964-A532-968AACB29AB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I = reviewed the -12 of this document and it mostly looks good, but there = are a couple of outstanding points:

* The first = paragraph in Section 13 is redundant now, I = think.

* I=92m a little confused about the = normative recommendation made in Section 13. It almost sounds as if = you=92re recommending a particular interpretation of =93private,=94 = =93redacted,=94 and =93obscured,=94 while being open to other = interpretations. That doesn=92t seem advisable, though =97 shouldn=92t = the interpretations of those values apply the same everywhere? It seems = more like what you want to RECOMMEND is that if the data elements fit = the interpretations of the status values, then those status values = SHOULD be used.

* The example given for = =93obscured=94 is not quite what I was expecting, and seems like it = could be confused for =93redacted.=94 I would have thought =93obscured=94 = meant something more like you take an identifier that directly = identifies an entity and replace it with a randomized identifier for = that entity, or some = such.

Thanks,
Alissa

On Oct 30, 2014, at 7:24 AM, Alissa Cooper <alissa@cooperw.in> = wrote:

On Oct 30, 2014, at 4:09 AM, Andy = Newton <andy@arin.net> = wrote:


On Oct 28, 2014, at 7:14 PM, = Alissa Cooper <alissa@cooperw.in> = wrote:

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

I think this document is missing a = discussion of the fact that while
jCard was selected as the format = for entity representation because it can
flexibly accommodate the = spectrum of the kinds of entities that require
representation in = RDAP, the full jCard specification includes many fields
that are = unrelated to the uses of the RDAP protocol and therefore not
expected = to be stored or made available by servers. This is a different
point = than the point made in Appendix A.1 (which should really be = in
Section 14 IMO) about the use of status values, which implies that = the
fields exist in the server-side database but are not shared in = certain
circumstances.

This is a good point. =  Does inserting the following paragraph after the first paragraph = in Section 5.1 address this?

The entity object class uses jCard = [RFC7095] to represent contact information,
such as postal addresses, = email addresses, phone numbers and names of 
organizations and = individuals. Many of the types of information that can be
represented = with jCard are unlikely to be used in RDAP, such as = birthdays,
anniversaries, and gender.

s/are = unlikely to be used/have no use/

Otherwise looks = good.



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

=3D Section 3.2 =3D
I love an idiom as = much as the next person, but it would be better to use
names in = examples that are not culturally specific.

=3D Section 4 =3D
The= reference to I-D.ietf-jcardcal-jcard should be replaced with = RFC
7095, I think.

=3D Section 6.1 =3D
Following on from my = DISCUSS, I know the example in this section is just
an example, but = it includes all kinds of information about Joe User that
no registry = should be asking for and no registrant should willingly
provide = (gender? anniversary? really?!). It would be nice for the example
to = reflect what reality might/should actually be = like.

Agreed (though your section numbers are = off).

Sorry about that, too many document reviews = going on at once =85

Thanks,
Alissa


Thanks.

-andy

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

= --Apple-Mail=_0C75EDB4-B7A8-4964-A532-968AACB29AB4-- From nobody Mon Dec 1 16:11:56 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD521A1BE1; Mon, 1 Dec 2014 16:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHxLI46PF312; Mon, 1 Dec 2014 16:11:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 492CC1A912F; Mon, 1 Dec 2014 16:11:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202001153.11251.9959.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 16:11:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/bBX1EnGLF3bku9XaRupxL90-5MU Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-using-http@tools.ietf.org Subject: [weirds] Alissa Cooper's No Objection on draft-ietf-weirds-using-http-15: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 00:11:54 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-weirds-using-http-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. I am curious if someone went through this doc to make sure everything it says is consistent with the change to MUST use TLS in rdap-sec. From nobody Tue Dec 2 02:54: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 823721A1A8C; Tue, 2 Dec 2014 02:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU5oJFH4-35W; Tue, 2 Dec 2014 02:54:52 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id F39B11A1A88; Tue, 2 Dec 2014 02:54:51 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id A81B9164EB0; Tue, 2 Dec 2014 05:54:51 -0500 (EST) 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 E1D09164E6C; Tue, 2 Dec 2014 05:54:50 -0500 (EST) 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.210.2; Tue, 2 Dec 2014 05:57:15 -0500 Received: from CHAMBX01.corp.arin.net ([fe80::1cef:1d7:cca9:5953]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0210.002; Tue, 2 Dec 2014 05:54:50 -0500 From: Andy Newton To: Alissa Cooper Thread-Topic: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) Thread-Index: AQHP8wT+VvAo7jjE6k+C7Xa31Tup25xIwNgAgAA2l4CAMv4ggIAAYSwA Date: Tue, 2 Dec 2014 10:54:49 +0000 Message-ID: In-Reply-To: <5F7DA9CB-C39D-43ED-BD74-66BD0E365FD9@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/auijzo_PjSG07AG2edxrUONZAI4 Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" , "weirds@ietf.org" , IESG Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 10:54:53 -0000 From: Alissa Cooper >I reviewed the -12 of this document and it mostly looks good, but there >are a couple of outstanding points: > >* The first paragraph in Section 13 is redundant now, I think. Oops. Editing mistake. > >* I=B9m a little confused about the normative recommendation made in >Section 13. It almost sounds as if you=B9re recommending a particular >interpretation of =B3private,=B2 =B3redacted,=B2 and =B3obscured,=B2 while= being open >to other interpretations. That doesn=B9t seem > advisable, though =8B shouldn=B9t the interpretations of those values app= ly >the same everywhere? It seems more like what you want to RECOMMEND is >that if the data elements fit the interpretations of the status values, >then those status values SHOULD be used. Most of the new text in this section was given to us by Kathleen, which I viewed as a recommended list of status values to use when appropriate and a quick comparison of the privacy related status values (in case the reader gets lost in the sea of status values listed in 10.2.2). Maybe the last sentence in the first paragraph should be changed. OLD For the following status codes, the RECOMMENDED actions include: NEW The following status codes SHOULD be used to describe data elements of a response when appropriate: > >* The example given for =B3obscured=B2 is not quite what I was expecting, = and >seems like it could be confused for =B3redacted.=B2 I would have thought >=B3obscured=B2 meant something more like you take an identifier that direc= tly >identifies an entity and replace it > with a randomized identifier for that entity, or some such. The difference between redact and obscured in this context is the former is removal of certain data. Checking my dictionary, I see that redact can actually mean removal or obscuring of data. I=B9d be willing to change the status value to =B3removed" or some other word for better clarity. Your suggestion for obscured is different enough that it is probably worthy of a separate status value to be used with =B3private=B2 or =B3redac= ted=B2. Perhaps =B3anonymized=B2? -andy From nobody Tue Dec 2 09:38: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 9350A1A6EF2 for ; Tue, 2 Dec 2014 09:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dkz1aEXJWhr for ; Tue, 2 Dec 2014 09:37:53 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FE51A1C05 for ; Tue, 2 Dec 2014 09:37:53 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 06FEF22D37 for ; Tue, 2 Dec 2014 12:37:52 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 02 Dec 2014 12:37:53 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=XRmouc697HhVXD3gkqPjcHnY5Ks=; b=2Xp5ryYzdTXPcMY2vUgtA 70lNKbcsZ7XoFnbpfOiwO+9TdzYcb9lIeIxvZVsc3YOzY/pE05CuVeGBIbDxDrpa mIgRAKjKuIvLEFq8i4ynUnzTA6WgCm5WhhEDgP/ilaP2ylJs2u8MNCgzQvoaXzOF ZINJ6pcDuQ/esgdsOKgfa8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=XRmouc697HhVXD3gkqPjcHn Y5Ks=; b=cR+ZJDZrBgMLy1VkYQsKSphlArsESlPxjfqCtBA0t/W8FljQ16YswTe mQEA2fxRntbhL2EXPY33pm/0XDoyGwGrV+iX1asYXPX8Eqo+JReaRDDmoUAzwHRf hw8Fb92Eei1fJr1tfNegarCR2bRSOZN7t8JE7D+zuGxmylKSDZx8= X-Sasl-enc: 02YfgL2g/6OswfOD/BV8mDWGsSERKiiUPeeOxRFpsTAO 1417541872 Received: from [10.35.132.83] (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id 503F5C0027E; Tue, 2 Dec 2014 12:37:52 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Tue, 2 Dec 2014 09:38:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8B068127-0C91-4DC2-A25E-F64A07444E1A@cooperw.in> References: To: Andy Newton X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/cwiV0wuGR9eRDzAgR19o5DYuSps Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" , "weirds@ietf.org" , IESG Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 17:37:57 -0000 On Dec 2, 2014, at 2:54 AM, Andy Newton wrote: > From: Alissa Cooper >=20 >> I reviewed the -12 of this document and it mostly looks good, but = there >> are a couple of outstanding points: >>=20 >> * The first paragraph in Section 13 is redundant now, I think. >=20 > Oops. Editing mistake. >=20 >>=20 >> * I=B9m a little confused about the normative recommendation made in >> Section 13. It almost sounds as if you=B9re recommending a particular >> interpretation of =B3private,=B2 =B3redacted,=B2 and =B3obscured,=B2 = while being open >> to other interpretations. That doesn=B9t seem >> advisable, though =8B shouldn=B9t the interpretations of those values = apply >> the same everywhere? It seems more like what you want to RECOMMEND is >> that if the data elements fit the interpretations of the status = values, >> then those status values SHOULD be used. >=20 > Most of the new text in this section was given to us by Kathleen, = which I > viewed as a recommended list of status values to use when appropriate = and > a quick comparison of the privacy related status values (in case the > reader gets lost in the sea of status values listed in 10.2.2). >=20 > Maybe the last sentence in the first paragraph should be changed. >=20 > OLD > For the following status codes, the RECOMMENDED actions include: >=20 > NEW > The following status codes SHOULD be used to describe data elements > of a response when appropriate: Works for me. >=20 >>=20 >> * The example given for =B3obscured=B2 is not quite what I was = expecting, and >> seems like it could be confused for =B3redacted.=B2 I would have = thought >> =B3obscured=B2 meant something more like you take an identifier that = directly >> identifies an entity and replace it >> with a randomized identifier for that entity, or some such. >=20 > The difference between redact and obscured in this context is the = former > is removal of certain data. Checking my dictionary, I see that redact = can > actually mean removal or obscuring of data. I=B9d be willing to change = the > status value to =B3removed" or some other word for better clarity. >=20 > Your suggestion for obscured is different enough that it is probably > worthy of a separate status value to be used with =B3private=B2 or = =B3redacted=B2. > Perhaps =B3anonymized=B2? I think if you have private, removed, and obscured, you will have = covered all the bases. Anonymity is difficult to achieve in practice, so = I would stay away from "anonymized.=94 Alissa >=20 > -andy >=20 From nobody Tue Dec 2 09:53: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 AB01C1A6FC0 for ; Tue, 2 Dec 2014 09:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cpCRrWRMpFQ for ; Tue, 2 Dec 2014 09:53:45 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCB21A6FBB for ; Tue, 2 Dec 2014 09:53:44 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6959B22702 for ; Tue, 2 Dec 2014 12:53:44 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 02 Dec 2014 12:53:44 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=HiavXHdF//kShapOlTaANN+GKXY=; b=JhUO1ooi1spDz+Pbxv6A9 zLsdkkrUwHKkwDkoa2v7CmJsFZkJvS2rRVdfwHN+cPQEN0CEjUmLgvE83gS1Y6sF 6onMj6HKXpQX/DO+6tZIKlRkm2cdaOhguLTWnSJNGCO/FWghcw0yW+3DP00ZhvIu rObYcd4IPV7viLQmpZBYNU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=HiavXHdF//kShapOlTaANN+ GKXY=; b=hzzcAgVLCG5bOAUj6Dp/cXOlCRpdFNuiVsbPGcYzwsg4YMbhn/Ysm99 3HHULJdVZXxjhfhLRPab3kfaJvE7E9IgtfJs3g1hbVHuiRXeLuVv3ZKIRlex8Uxm IezuOUiGIorgDeVwEKj1MnFxsia4JtsPV0GElwIVv13AUNlYJS2A= X-Sasl-enc: fZQJ5qKuJT2yUNq/RCUH9miUaZ0QlTXwuHTLfLeguNvM 1417542823 Received: from [10.35.132.83] (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id 9DDD9C0027E; Tue, 2 Dec 2014 12:53:43 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> Date: Tue, 2 Dec 2014 09:54:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> To: IESG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/pZH_ok9kDNYFPZQBxrlZk6FiS3U Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 17:53:47 -0000 Thanks for addressing my DISCUSS points. I just have a couple of = follow-ups. I=92m glad to see this new text in 3.5: HTTP Over TLS MUST be used to protect all client-server exchanges unless operational constraints make it impossible to meet this requirement. Is it implied that this applies to rdap-bootstrap as well? Couple of comments on this text in section 5: In addition to privacy risks to registrants, there are also potential privacy risks for those who query registration data. For example, the fact that a law enforcement officer performs a particular query may reveal information about the officer's activities that he or she would have preferred to keep private. RDAP supports the use of HTTP over TLS to provide privacy protection for those querying registrant data as well as registrants. Someone in Honolulu suggested to me that the law enforcement officer = example might not be the best one, and that=92s probably right. I would = suggest substituting another term instead =97 maybe =93registry = employee=94? I would also suggest editing the last sentence to match the above text = from 3.5: =93RDAP requires the use of HTTP over TLS to provide privacy = protection for those querying registrant data as well as registrants, = unless operational constraints make it impossible to meet this = requirement.=94 Also given the new text in 3.5, it seems like the recommendations in = section 6 regarding the TLS null cipher suite should be updated as well. = I would suggest "This option MUST NOT be used=94 =97 assuming the same = operational constraints caveat does not apply here. Thanks, Alissa On Oct 28, 2014, at 4:15 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-weirds-rdap-sec-10: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > =3D General comment =3D > I'm not exactly sure which document this remark is directed at, but = I'm > putting it in a DISCUSS here and we can figure that out later. >=20 > I feel like the RDAP document suite is missing an overall explanation = of > the privacy threat model associated with registration data, the policy > choices that are left up to registry providers, and the mechanisms > included in RDAP to help protect registrant and client/user privacy = and > facilitate those policy choices. There are mentions of some of this = here > and there, but even those are not necessarily consistent with each = other > (see my DISCUSS on draft-ietf-weirds-using-http). So I think it would = be > beneficial to capture this in one place and articulate it explicitly, > rather than implicitly across the documents. Some of the salient = points > for starters: >=20 > * WHOIS data has historically included personal information about > registrants, has been made public, and has not had the benefit of > authentication or access control mechanisms to gate access to it. In = part > as a result of this, proxy and privacy services have arisen to shield = the > identities of registrants. >=20 > * The standardization of RDAP does not change or impact the data that > registries may require to be collected from registrants. However, RDAP > data structures allow servers to indicate when data returned to = clients > has been made private, redacted, obscured, or shielded by a proxy. >=20 > * RDAP uses the jCard standard format for entity representation, but = many > of the jCard fields are irrelevant for registry operation purposes and > their use should be minimized. >=20 > * RDAP includes mechanisms that can be used to authenticate clients, > allowing servers to support tiered access based on local policy. This > means that all registration data need no longer be public, and = personal > data or data that may be considered more sensitive can have its access > restricted to specifically privileged clients. >=20 > * [Something about confidentiality of requests and responses ... see = my > other DISCUSS point below.] >=20 > * etc. >=20 > =3D Section 3.4 =3D > "If the policy of the server operator > requires encryption to protect client-server data exchanges (such as > to protect non-public data that can not be accessed without client > identification and authentication), HTTP Over TLS MUST be used to > protect those exchanges." >=20 > It is unclear to me that a server policy that allows unencrypted = access > should be allowed, particularly in the cases of entity-related = requests, > but perhaps also in the case of other requests. The fact that the > registry data may be public is orthogonal to the question of whether a > particular query for that data should have confidentiality protection. > I'd like to understand why RDAP does not require HTTP over TLS to be = used > in all cases and instead allows unsuspecting client users to send = their > queries in the clear in cases where server policy does not mandate use = of > TLS. I'm especially curious about this since clients are required to > support HTTPS anyway. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =3D Section 3.1 =3D > "RDAP's authentication framework needs to accommodate anonymous access > as well as verification of identities" >=20 > I would suggest s/anonymous access/unauthenticated access/ since > generally it can be pretty difficult to remain anonymous when = accessing > anything over IP. >=20 > Similar comment for 3.2, I would delete "or anonymous." >=20 >=20 From nobody Tue Dec 2 10:00: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 4958A1A1BFB; Tue, 2 Dec 2014 10:00:13 -0800 (PST) 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 9ovQWN9LNxzC; Tue, 2 Dec 2014 10:00:11 -0800 (PST) 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 A7D001A1BBD; Tue, 2 Dec 2014 10:00:05 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKVH3+JI+H4F9wjo/rRkA9u4Gl9V/dRxtT@postini.com; Tue, 02 Dec 2014 10:00:11 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id sB2I01v6031951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 13:00:02 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 13:00:01 -0500 From: "Hollenbeck, Scott" To: Alissa Cooper , IESG Thread-Topic: Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) Thread-Index: AQHQDljueW9VDFy+VkqDhH8RMvacQJx8lcFw Date: Tue, 2 Dec 2014 18:00:00 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49536C35@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ON-FNT72r_M2TBvzYBzegFpze1I Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:00:13 -0000 > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Tuesday, December 02, 2014 12:54 PM > To: IESG > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > chairs@tools.ietf.org; weirds@ietf.org > Subject: Re: Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: > (with DISCUSS and COMMENT) >=20 > Thanks for addressing my DISCUSS points. I just have a couple of > follow-ups. >=20 > I'm glad to see this new text in 3.5: >=20 > HTTP Over TLS MUST be used to > protect all client-server exchanges unless operational constraints > make it impossible to meet this requirement. >=20 > Is it implied that this applies to rdap-bootstrap as well? Yes. The bootstrap document currently says this: "The transport used to access the registries could be more secure by using = TLS [RFC5246] if IANA supports it." So if IANA supports it TLS MUST be used. > Couple of comments on this text in section 5: >=20 > In addition to privacy risks to registrants, there are also > potential > privacy risks for those who query registration data. For example, > the fact that a law enforcement officer performs a particular query > may reveal information about the officer's activities that he or she > would have preferred to keep private. RDAP supports the use of HTTP > over TLS to provide privacy protection for those querying registrant > data as well as registrants. >=20 > Someone in Honolulu suggested to me that the law enforcement officer > example might not be the best one, and that's probably right. I would > suggest substituting another term instead - maybe "registry employee"? >=20 > I would also suggest editing the last sentence to match the above text > from 3.5: "RDAP requires the use of HTTP over TLS to provide privacy > protection for those querying registrant data as well as registrants, > unless operational constraints make it impossible to meet this > requirement." >=20 > Also given the new text in 3.5, it seems like the recommendations in > section 6 regarding the TLS null cipher suite should be updated as > well. I would suggest "This option MUST NOT be used" - assuming the > same operational constraints caveat does not apply here. These are all reasonable suggestions. I'll do another edit. I can't think of an operational reason to use the TLS null cipher... Scott From nobody Tue Dec 2 11:20:36 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9841A6FE2; Tue, 2 Dec 2014 11:20:19 -0800 (PST) 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 MZDfK5V55-C9; Tue, 2 Dec 2014 11:20:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E3B1A1B37; Tue, 2 Dec 2014 11:20:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202192005.24727.14545.idtracker@ietfa.amsl.com> Date: Tue, 02 Dec 2014 11:20:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/69umCViDngjPVfVSAhVDH6nX-qk Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-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: Tue, 02 Dec 2014 19:20:19 -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-12.txt Pages : 13 Date : 2014-12-02 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 access control, 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-sec-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 Tue Dec 2 11:20: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 61CE21A6FE5 for ; Tue, 2 Dec 2014 11:20:20 -0800 (PST) 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 iBkZY2izcj2w; Tue, 2 Dec 2014 11:20:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF221A6EDA; Tue, 2 Dec 2014 11:20:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202192006.24727.41126.idtracker@ietfa.amsl.com> Date: Tue, 02 Dec 2014 11:20:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/oAuQMgiVFBFbEdkI6WhGz029aRs Subject: [weirds] New Version Notification - draft-ietf-weirds-rdap-sec-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: Tue, 02 Dec 2014 19:20:20 -0000 A new version (-12) has been submitted for draft-ietf-weirds-rdap-sec: http://www.ietf.org/internet-drafts/draft-ietf-weirds-rdap-sec-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-sec-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. IETF Secretariat. From nobody Wed Dec 3 06:13:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51E81A1B27; Wed, 3 Dec 2014 06:13:37 -0800 (PST) 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 QG3kVS5y-Tvr; Wed, 3 Dec 2014 06:13:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9124F1A1B29; Wed, 3 Dec 2014 06:13:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141203141334.11635.12701.idtracker@ietfa.amsl.com> Date: Wed, 03 Dec 2014 06:13:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/x89D4zffO4trzC4i_addTiy6jwg Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-13.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 14:13:38 -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-13.txt Pages : 91 Date : 2014-12-03 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-json-response-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 3 06:13: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 5CDA81A1B29 for ; Wed, 3 Dec 2014 06:13:39 -0800 (PST) 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 1Mvvh2lzgyvj; Wed, 3 Dec 2014 06:13:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B27951A1B34; Wed, 3 Dec 2014 06:13:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141203141334.11635.9622.idtracker@ietfa.amsl.com> Date: Wed, 03 Dec 2014 06:13:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NKDU0335m3X3vLxi3FUC7rzwdkg Subject: [weirds] New Version Notification - draft-ietf-weirds-json-response-13.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 14:13:39 -0000 A new version (-13) has been submitted for draft-ietf-weirds-json-response: http://www.ietf.org/internet-drafts/draft-ietf-weirds-json-response-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-json-response-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Dec 15 05:11: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 69C941A1BBD; Mon, 15 Dec 2014 05:11:47 -0800 (PST) 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 6I3dfGh7YoFD; Mon, 15 Dec 2014 05:11:45 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECC91A1AC3; Mon, 15 Dec 2014 05:11:39 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKVI7eCoe++jlXfBcD9RzIdpxLcUhdc1DA@postini.com; Mon, 15 Dec 2014 05:11:44 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id sBFDBb4x026053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 08:11:37 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 15 Dec 2014 08:11:37 -0500 From: "Hollenbeck, Scott" To: Alissa Cooper , IESG Thread-Topic: Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) Thread-Index: AQHQDljueW9VDFy+VkqDhH8RMvacQJx8lcFwgBQeSwA= Date: Mon, 15 Dec 2014 13:11:36 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49543B83@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F49536C35@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49536C35@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.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/zzEAKlc6oXZ3F8Jvx3OoSGC8KxE Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 13:11:47 -0000 Top posting... Alissa, draft-ietf-weirds-rdap-sec was updated on 2 December to address the= comments described below. Could you please take another look and update yo= ur discuss position if the new version addresses your feedback appropriatel= y? Scott > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Hollenbeck, > Scott > Sent: Tuesday, December 02, 2014 1:00 PM > To: Alissa Cooper; IESG > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > chairs@tools.ietf.org; weirds@ietf.org > Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds- > rdap-sec-10: (with DISCUSS and COMMENT) >=20 > > -----Original Message----- > > From: Alissa Cooper [mailto:alissa@cooperw.in] > > Sent: Tuesday, December 02, 2014 12:54 PM > > To: IESG > > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > > chairs@tools.ietf.org; weirds@ietf.org > > Subject: Re: Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec- > 10: > > (with DISCUSS and COMMENT) > > > > Thanks for addressing my DISCUSS points. I just have a couple of > > follow-ups. > > > > I'm glad to see this new text in 3.5: > > > > HTTP Over TLS MUST be used to > > protect all client-server exchanges unless operational constraints > > make it impossible to meet this requirement. > > > > Is it implied that this applies to rdap-bootstrap as well? >=20 > Yes. The bootstrap document currently says this: >=20 > "The transport used to access the registries could be more secure by > using TLS [RFC5246] if IANA supports it." >=20 > So if IANA supports it TLS MUST be used. >=20 > > Couple of comments on this text in section 5: > > > > In addition to privacy risks to registrants, there are also > > potential > > privacy risks for those who query registration data. For example, > > the fact that a law enforcement officer performs a particular > query > > may reveal information about the officer's activities that he or > she > > would have preferred to keep private. RDAP supports the use of > HTTP > > over TLS to provide privacy protection for those querying > registrant > > data as well as registrants. > > > > Someone in Honolulu suggested to me that the law enforcement officer > > example might not be the best one, and that's probably right. I would > > suggest substituting another term instead - maybe "registry > employee"? > > > > I would also suggest editing the last sentence to match the above > text > > from 3.5: "RDAP requires the use of HTTP over TLS to provide privacy > > protection for those querying registrant data as well as registrants, > > unless operational constraints make it impossible to meet this > > requirement." > > > > Also given the new text in 3.5, it seems like the recommendations in > > section 6 regarding the TLS null cipher suite should be updated as > > well. I would suggest "This option MUST NOT be used" - assuming the > > same operational constraints caveat does not apply here. >=20 > These are all reasonable suggestions. I'll do another edit. >=20 > I can't think of an operational reason to use the TLS null cipher... >=20 > Scott >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Thu Dec 18 11:32: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 02C071AC3A6; Thu, 18 Dec 2014 11:32:50 -0800 (PST) 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 ZTYuxtXmlN9V; Thu, 18 Dec 2014 11:32:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B761AC39B; Thu, 18 Dec 2014 11:32:48 -0800 (PST) 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.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 11:32:48 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/39IPVUH4NCFwKrWaKQbspV6aiQI Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-bootstrap-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, 18 Dec 2014 19:32: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 : Finding the Authoritative Registration Data (RDAP) Service Author : Marc Blanchet Filename : draft-ietf-weirds-bootstrap-11.txt Pages : 17 Date : 2014-12-18 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-bootstrap-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 Dec 18 11:32:56 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1661AC3A9 for ; Thu, 18 Dec 2014 11:32:53 -0800 (PST) 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 mSL_N1Gs_dyR; Thu, 18 Dec 2014 11:32:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 626601AC3A0; Thu, 18 Dec 2014 11:32:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, mszucs@afilias.info, weirds@ietf.org, presnick@qti.qualcomm.com, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218193248.30639.29632.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 11:32:48 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/vlIQFeQ7goxgXTpu4gG4rFRjhnc Subject: [weirds] New Version Notification - draft-ietf-weirds-bootstrap-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, 18 Dec 2014 19:32:53 -0000 A new version (-11) has been submitted for draft-ietf-weirds-bootstrap: http://www.ietf.org/internet-drafts/draft-ietf-weirds-bootstrap-11.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-bootstrap-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. IETF Secretariat. From nobody Thu Dec 18 11:39:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C261A3BA9 for ; Thu, 18 Dec 2014 11:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tlApI_mWkt5 for ; Thu, 18 Dec 2014 11:39:27 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id AA08C1AC3AC for ; Thu, 18 Dec 2014 11:39:27 -0800 (PST) Received: from h100.viagenie.ca (h100.viagenie.ca [206.123.31.100]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DCA0740371; Thu, 18 Dec 2014 14:39:27 -0500 (EST) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_0F6B7607-292E-466A-8E30-4D25D4F19103" Message-Id: <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Date: Thu, 18 Dec 2014 14:39:26 -0500 References: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> To: Barry Leiba , Pete Resnick , "Murray S. Kucherawy" , Michael Szucs X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ymeSiG6vzrWmg8D7xKNAXBCRWsI Cc: draft-ietf-weirds-bootstrap.all@tools.ietf.org, "" Subject: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-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, 18 Dec 2014 19:39:30 -0000 --Apple-Mail=_0F6B7607-292E-466A-8E30-4D25D4F19103 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, this new version shall address all comments received from IESG review. = IMHO, it should clear the DISCUSS and move ahead. Regards, Marc. > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >=20 > De: internet-drafts@ietf.org > =C3=80: i-d-announce@ietf.org > Objet: I-D Action: draft-ietf-weirds-bootstrap-11.txt > Date: 18 d=C3=A9cembre 2014 14:32:48 UTC=E2=88=925 > 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 > Author : Marc Blanchet > Filename : draft-ietf-weirds-bootstrap-11.txt > Pages : 17 > Date : 2014-12-18 >=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-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-bootstrap-11 >=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=_0F6B7607-292E-466A-8E30-4D25D4F19103 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,
 this new version shall address = all comments received from IESG review. IMHO, it should clear the = DISCUSS and move ahead.

Regards, Marc.

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

De: = internet-drafts@ietf.org
=C3=80: = i-d-announce@ietf.org
Objet: = I-D Action: = draft-ietf-weirds-bootstrap-11.txt
Date: = 18 d=C3=A9cembre 2014 14:32:48 = UTC=E2=88=925
Cc: = weirds@ietf.org
R=C3=A9pon= dre =C3=A0: internet-drafts@ietf.org


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

=        Title =           : Finding = the Authoritative Registration Data (RDAP) Service
=        Author =          : Marc Blanchet
= Filename        : = draft-ietf-weirds-bootstrap-11.txt
Pages =           : 17
= Date =            : = 2014-12-18

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-11

A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-bootstrap-= 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/

_______________________________________________
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=_0F6B7607-292E-466A-8E30-4D25D4F19103-- From nobody Thu Dec 18 11:48: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 2F0CA1A6F6F; Thu, 18 Dec 2014 11:47:57 -0800 (PST) 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 Qnj3VrO2hjWu; Thu, 18 Dec 2014 11:47:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A4C1A3BA9; Thu, 18 Dec 2014 11:47:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218194755.14988.65765.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 11:47:55 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/6Qtz0KbA_x_go7A8RTNxoIn1y1s Cc: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, weirds@ietf.org Subject: [weirds] Barry Leiba's No Objection on draft-ietf-weirds-bootstrap-11: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:47:57 -0000 Barry Leiba has entered the following ballot position for draft-ietf-weirds-bootstrap-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Version -11 addresses all my comments; many thanks for working that stuff out with me. From nobody Thu Dec 18 12:59: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 763E31A1B39 for ; Thu, 18 Dec 2014 12:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylLL7EQskoW9 for ; Thu, 18 Dec 2014 12:59:07 -0800 (PST) Received: from office.denic.de (office.denic.de [81.91.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569E11A047A for ; Thu, 18 Dec 2014 12:59:06 -0800 (PST) Received: from office.denic.de (mailout1.denic.de [10.122.34.3]) by office.denic.de (Postfix) with ESMTPS id CC7E3240021; Thu, 18 Dec 2014 21:58:53 +0100 (CET) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtps (TLSv1:AES256-SHA:256) id 1Y1i9t-0000FL-KL; Thu, 18 Dec 2014 21:58:53 +0100 Received: from localhost by x27.adm.denic.de with local id 1Y1i9q-0002jL-Dv; Thu, 18 Dec 2014 21:58:50 +0100 Date: Thu, 18 Dec 2014 21:58:50 +0100 From: Peter Koch To: Marc Blanchet Message-ID: <20141218205850.GH28899@x28.adm.denic.de> Mail-Followup-To: Marc Blanchet , Barry Leiba , Pete Resnick , "Murray S. Kucherawy" , Michael Szucs , draft-ietf-weirds-bootstrap.all@tools.ietf.org, "" References: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/9JjQjqWNClrlio9i9GCycuNgAMI Cc: Pete Resnick , "" , draft-ietf-weirds-bootstrap.all@tools.ietf.org, Barry Leiba Subject: Re: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-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, 18 Dec 2014 20:59:09 -0000 On Thu, Dec 18, 2014 at 02:39:26PM -0500, Marc Blanchet wrote: > Hello, > this new version shall address all comments received from IESG review. IMHO, it should clear the DISCUSS and move ahead. I've re-read the updated IANA considerations section. This new version still does not focus on the IETF side of things and in fact tries to make ICANN's work with IETF tools. In fact, what is about to be established here is not even a registry, it is operational data (fed from existing registries coming from different, non-IETF IANA pillars). more like the DNS root zone than an IETF protocol parameters registry. Therefore what the IETF should do is specify the format only and let "the other entity" (aka ICANN) describe (in an RFC, independent submission stream) the operational details of the initial "hook". The end result for users would be the same with the benefit of untangling the policy space. Let us please use this opportunity not to further contribute to overlaps between different IANA functions where in neighboring venues we try to more precisely specify the separation of duties. -Peter From nobody Thu Dec 18 13:09: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 AB19D1A1B94 for ; Thu, 18 Dec 2014 13:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZa190vGZOzP for ; Thu, 18 Dec 2014 13:09:27 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD571A1B71 for ; Thu, 18 Dec 2014 13:09:26 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so1763938lab.9 for ; Thu, 18 Dec 2014 13:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=MTvpQLBRRXZIsfqaWZ2g9gJwDFke8L6ehEkpcUasudo=; b=0V5ELBz84QXDNbABM5vJUkkndfsNjixhby4juD0slAcbBDAJu2egpYIoU3I3KBaNjc Wn7Z0sfBVrd6jsfvJdbdrSgsQ1zmYP7hnzRRJFmlw2TnDOVxUI4COWESLDP5L7xktsSW TIHvuICuEpvLQyGpgZ48jJTiHHGG79lEnelVZb1RFjndU8HWQmh4Hm1KEyqzm1GyoYrR KxHmgKv5OpIglnmEK1t6PZjA9FYtUF0WzJ+O72x9UpJOixmqRIea88nFLjPCvNb6WPrk UUgldvX7F8p6/Sj6Luiv4kQVbxrcxdUWWM25b+ggYWExtgfbRqKn+XjxyKu+MhHUCq85 VONA== MIME-Version: 1.0 X-Received: by 10.112.41.168 with SMTP id g8mr4260758lbl.59.1418936965053; Thu, 18 Dec 2014 13:09:25 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Thu, 18 Dec 2014 13:09:24 -0800 (PST) In-Reply-To: <20141218205850.GH28899@x28.adm.denic.de> References: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> <20141218205850.GH28899@x28.adm.denic.de> Date: Thu, 18 Dec 2014 16:09:25 -0500 X-Google-Sender-Auth: kF9mZcfM-3tXX5KfcAFlzOMkjCw Message-ID: From: Barry Leiba To: Marc Blanchet , Barry Leiba , Pete Resnick , "Murray S. Kucherawy" , Michael Szucs , "draft-ietf-weirds-bootstrap.all@tools.ietf.org" , "" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/TUoxU6lvfmDwgolt1j1DHth1Aak Subject: Re: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-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, 18 Dec 2014 21:09:27 -0000 > to be established here is not even a registry, it is operational data > (fed from existing registries coming from different, non-IETF IANA pillars). > more like the DNS root zone than an IETF protocol parameters registry. > > Therefore what the IETF should do is specify the format only and let > "the other entity" (aka ICANN) describe (in an RFC, independent submission stream) > the operational details of the initial "hook". I would be happy with that alternative, as long as it's a normative reference, which this document would then have to wait for. I think it's important for this document (along with its normative references) to provide the complete information necessary to create implementations. I'm not sure we want to delay things for that, but you're welcome to argue it. Barry From nobody Thu Dec 18 13:35: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 9E03E1A8730 for ; Thu, 18 Dec 2014 13:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCf-OehwqObI for ; Thu, 18 Dec 2014 13:35:26 -0800 (PST) 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 5B36F1A702E for ; Thu, 18 Dec 2014 13:35:26 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id gd6so1794415lab.3 for ; Thu, 18 Dec 2014 13:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vLzCWAZSo0qdcvRiarMDGBJnD1ozwIYtWAodW5Hdu5M=; b=o7An4+abMofnE9jKfaDKnislmc0EHIKuZBKUESn8/6+5VD261f97AhxjANBDVEOKQC bqJ5RcLDcnNlN00hrtRlVRW88zKJJ2ufEtRNA1gFG2fNZMhY8jZlHY2iPu2GQmYvgQE9 1GMGvAIuc754qz9PfFT0R+zmaSIIVpEocPt+PMwxt+0bh7H1sPYuyjJHvpo1eluOgOfg N7HB4gb/mUOq19Q2DGm5DL2QZKZ2ToNd7fzby1COIYiyzONvtFfyDV8HYsX0ch3eKKQU hXFGf5PNi6fHKVuTUrhpvETsNsTbSk6P/gCS3Uquwhf9sGhAr8+y8xOh+JCEmnhh24+w GFVA== MIME-Version: 1.0 X-Received: by 10.112.185.99 with SMTP id fb3mr4353595lbc.21.1418938524826; Thu, 18 Dec 2014 13:35:24 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Thu, 18 Dec 2014 13:35:24 -0800 (PST) In-Reply-To: References: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> <20141218205850.GH28899@x28.adm.denic.de> Date: Thu, 18 Dec 2014 16:35:24 -0500 X-Google-Sender-Auth: z7meX_K7Vq7e1r3Q8ftVDSm0MVE Message-ID: From: Barry Leiba To: Peter Koch Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/BQeN7TEPG_0gZszxFdzDvBcDSiA Cc: Pete Resnick , "" , "draft-ietf-weirds-bootstrap.all@tools.ietf.org" Subject: Re: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-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, 18 Dec 2014 21:35:27 -0000 Further following up... On Thu, Dec 18, 2014 at 4:09 PM, Barry Leiba wrote: >> to be established here is not even a registry, it is operational data >> (fed from existing registries coming from different, non-IETF IANA pillars). >> more like the DNS root zone than an IETF protocol parameters registry. >> >> Therefore what the IETF should do is specify the format only and let >> "the other entity" (aka ICANN) describe (in an RFC, independent submission stream) >> the operational details of the initial "hook". > > I would be happy with that alternative, as long as it's a normative > reference, which this document would then have to wait for. I think > it's important for this document (along with its normative references) > to provide the complete information necessary to create > implementations. > > I'm not sure we want to delay things for that, but you're welcome to argue it. I'll add that we have already run this version by IANA (and, so, ICANN), and they're fine with it. Are you sure that they'd rather publish a separate document of their own for this? Barry From nobody Thu Dec 18 13:36: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 8FD9A1A879B for ; Thu, 18 Dec 2014 13:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JhMvUnvwC2Q for ; Thu, 18 Dec 2014 13:36:43 -0800 (PST) Received: from office.denic.de (office.denic.de [81.91.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4921A879D for ; Thu, 18 Dec 2014 13:36:43 -0800 (PST) Received: from office.denic.de (mailout1.denic.de [10.122.34.3]) by office.denic.de (Postfix) with ESMTPS id AB3A4240021; Thu, 18 Dec 2014 22:36:30 +0100 (CET) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtps (TLSv1:AES256-SHA:256) id 1Y1ikI-0000Tm-GB; Thu, 18 Dec 2014 22:36:30 +0100 Received: from localhost by x27.adm.denic.de with local id 1Y1ikF-0003PC-AH; Thu, 18 Dec 2014 22:36:27 +0100 Date: Thu, 18 Dec 2014 22:36:27 +0100 From: Peter Koch To: Barry Leiba Message-ID: <20141218213627.GI28899@x28.adm.denic.de> Mail-Followup-To: Barry Leiba , Marc Blanchet , Pete Resnick , "Murray S. Kucherawy" , Michael Szucs , "draft-ietf-weirds-bootstrap.all@tools.ietf.org" , "" References: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> <20141218205850.GH28899@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/_ra6JXf_O9S6-gaAnI-RztJj5vk Cc: Pete Resnick , "" , "draft-ietf-weirds-bootstrap.all@tools.ietf.org" Subject: Re: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-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, 18 Dec 2014 21:36:49 -0000 On Thu, Dec 18, 2014 at 04:09:25PM -0500, Barry Leiba wrote: > > "the other entity" (aka ICANN) describe (in an RFC, independent submission stream) > > the operational details of the initial "hook". > > I would be happy with that alternative, as long as it's a normative > reference, which this document would then have to wait for. I think while processing them in prallel at the RFC Editor is a good idea, I think not only should there be no normative reference (downref to Informational, not necessary to understand the protocol spec, not even to implement it because what's provided in the "companion" RFC is config data) but probably none at all, simply because the IETF might not need to take a position here _and_ the protocol work is done by specifying the format. But I could understand the desire to provide some guidance in an appendix _with_ a pointer to the 2nd RFC. > I'm not sure we want to delay things for that, but you're welcome to argue it. I'd not argue in favor of delay, but definitely for said separation. I can't write the second document because "I'm not ICANN" ... -Peter From nobody Thu Dec 18 13:44: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 5E2D11A9046 for ; Thu, 18 Dec 2014 13:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3ViWsFa0zbm for ; Thu, 18 Dec 2014 13:44:41 -0800 (PST) Received: from office.denic.de (office.denic.de [81.91.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624191A8A6D for ; Thu, 18 Dec 2014 13:44:41 -0800 (PST) Received: from office.denic.de (mailout1.denic.de [10.122.34.3]) by office.denic.de (Postfix) with ESMTPS id DB30A240021; Thu, 18 Dec 2014 22:44:34 +0100 (CET) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtps (TLSv1:AES256-SHA:256) id 1Y1is6-0000Ul-ON; Thu, 18 Dec 2014 22:44:34 +0100 Received: from localhost by x27.adm.denic.de with local id 1Y1is6-0003ZJ-IK; Thu, 18 Dec 2014 22:44:34 +0100 Date: Thu, 18 Dec 2014 22:44:34 +0100 From: Peter Koch To: Barry Leiba Message-ID: <20141218214434.GJ28899@x28.adm.denic.de> Mail-Followup-To: Barry Leiba , Marc Blanchet , Pete Resnick , "Murray S. Kucherawy" , Michael Szucs , "draft-ietf-weirds-bootstrap.all@tools.ietf.org" , "" References: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> <20141218205850.GH28899@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/hJ7b9RNxTNekbP5Mv7WkkXD1tm4 Cc: Pete Resnick , "" , "draft-ietf-weirds-bootstrap.all@tools.ietf.org" Subject: Re: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-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, 18 Dec 2014 21:44:43 -0000 On Thu, Dec 18, 2014 at 04:35:24PM -0500, Barry Leiba wrote: > I'll add that we have already run this version by IANA (and, so, > ICANN), and they're fine with it. Are you sure that they'd rather > publish a separate document of their own for this? it's probably worth distinguishing the IANA and the ICANN roles here. When IANA staff says they are fine with it, I'd read that as 'the instructions are clear' and 'we can implement this as desired' rather than 'we take a position regarding the IETF politics'. I.e., it is the usual check of 'IANA considerations'. My point is that the IETF needs to be prepared. Also, I'd not expect "IANA" to appear in the editor's section of the second documrnt. -Peter From nobody Mon Dec 22 17:01:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BE11A8978; Mon, 22 Dec 2014 17:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5U0Xc6LQekC5; Mon, 22 Dec 2014 17:01:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD0C1A8970; Mon, 22 Dec 2014 17:01:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223010133.27706.56894.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 17:01:33 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/8SZ9-67TT5T9r8DtESkI8lT1bdc Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds-chairs@tools.ietf.org, weirds@ietf.org Subject: [weirds] Alissa Cooper's No Objection on draft-ietf-weirds-rdap-sec-12: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 01:01:34 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-weirds-rdap-sec-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my discuss and comment points. From nobody Tue Dec 23 10:00: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 8AB031A1A8C; Tue, 23 Dec 2014 10:00:43 -0800 (PST) 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 v_VLxCg4lZ3e; Tue, 23 Dec 2014 10:00:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A1F1A1AA6; Tue, 23 Dec 2014 10:00:40 -0800 (PST) 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.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223180040.2571.76227.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 10:00:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ZDc4GRltxKdYNZ9LL21oJauY3ac Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-17.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 Dec 2014 18:00:43 -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-17.txt Pages : 20 Date : 2014-12-23 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-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-query-17 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 Dec 23 10:00: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 A64061A1ABF for ; Tue, 23 Dec 2014 10:00:47 -0800 (PST) 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 QVpUs6jqN7EZ; Tue, 23 Dec 2014 10:00:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F151A1AB3; Tue, 23 Dec 2014 10:00:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com, barryleiba@computer.org, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223180040.2571.52423.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 10:00:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/TZAM4WpuTqFPG2ieX3fTr1YycX4 Subject: [weirds] New Version Notification - draft-ietf-weirds-rdap-query-17.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 Dec 2014 18:00:47 -0000 A new version (-17) has been submitted for draft-ietf-weirds-rdap-query: http://www.ietf.org/internet-drafts/draft-ietf-weirds-rdap-query-17.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-query-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Dec 23 10:12: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 1A3B31A1A98; Tue, 23 Dec 2014 10:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVPd6F7KOkBK; Tue, 23 Dec 2014 10:12:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BE51A1A9D; Tue, 23 Dec 2014 10:12:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223181214.6444.4976.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 10:12:14 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/0FQV4QN8tdHz2m_W20jOyIKbYdM Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org Subject: [weirds] Alissa Cooper's No Objection on draft-ietf-weirds-rdap-query-17: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 18:12:18 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-weirds-rdap-query-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my comments. From nobody Tue Dec 23 10:17:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDD51A1AA9; Tue, 23 Dec 2014 10:17:15 -0800 (PST) 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 8u_1yP-23Qee; Tue, 23 Dec 2014 10:17:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 234331A1AA5; Tue, 23 Dec 2014 10:17:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223181714.17613.64457.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 10:17:14 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/FvyuiaugSsS08PAwGV7zK7mMxNI Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org Subject: [weirds] Barry Leiba's No Objection on draft-ietf-weirds-rdap-query-17: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 18:17:16 -0000 Barry Leiba has entered the following ballot position for draft-ietf-weirds-rdap-query-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Version -17 addresses my comments; thanks very much. From nobody Tue Dec 23 13:25:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9731ABD38; Tue, 23 Dec 2014 13:25:11 -0800 (PST) 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 ApAO9V-Fg7wI; Tue, 23 Dec 2014 13:25:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 508A91ABD3F; Tue, 23 Dec 2014 13:25:09 -0800 (PST) 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.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223212509.28610.79463.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 13:25:09 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/l1FuYrt9gE-_-NsKfdmcSW7Ye1Q Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-18.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 Dec 2014 21:25: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-18.txt Pages : 20 Date : 2014-12-23 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-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-query-18 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 Dec 23 13:25: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 D4D2E1ABD38 for ; Tue, 23 Dec 2014 13:25:13 -0800 (PST) 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 Tz-YscRq7XHB; Tue, 23 Dec 2014 13:25:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 730511AC398; Tue, 23 Dec 2014 13:25:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223212509.28610.99198.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 13:25:09 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/30tHh1dmEzFwAUhqb9n919CY574 Subject: [weirds] New Version Notification - draft-ietf-weirds-rdap-query-18.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 Dec 2014 21:25:14 -0000 A new version (-18) has been submitted for draft-ietf-weirds-rdap-query: http://www.ietf.org/internet-drafts/draft-ietf-weirds-rdap-query-18.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-query-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Dec 24 08:04: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 B11F81A8A7F; Wed, 24 Dec 2014 08:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BPTyxCsFkqX; Wed, 24 Dec 2014 08:04:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B05241A8A85; Wed, 24 Dec 2014 08:04:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141224160410.23488.33387.idtracker@ietfa.amsl.com> Date: Wed, 24 Dec 2014 08:04:10 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/c1IxgenTTG7jS7hGNnR0-PE7_Z8 Cc: weirds-chairs@tools.ietf.org, weirds@ietf.org, draft-ietf-weirds-json-response@tools.ietf.org Subject: [weirds] Alissa Cooper's No Objection on draft-ietf-weirds-json-response-13: (with COMMENT) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 16:04:12 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-weirds-json-response-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss and comment points. From nobody Mon Dec 29 13:57: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 AFF751A9128 for ; Mon, 29 Dec 2014 13:57:20 -0800 (PST) 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 6R7oBh38aEFe; Mon, 29 Dec 2014 13:57:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 704671A924E; Mon, 29 Dec 2014 13:57:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-object-inventory@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229215719.29308.5201.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 13:57:19 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ygq5vp4NJ7y9NdzLkrt33GGOEAU Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 21:57:20 -0000 IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory/ From nobody Mon Dec 29 13:58: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 6CAF41ACDEA for ; Mon, 29 Dec 2014 13:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgDaiB5eUhCf; Mon, 29 Dec 2014 13:57:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F0C1ACDF5; Mon, 29 Dec 2014 13:57:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-using-http@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229215757.22648.74137.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 13:57:57 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/C_8zn_ZU8mGkoC-r7cUkVrYykbE Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 21:58:00 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ From nobody Mon Dec 29 13:58: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 7136E1A9128 for ; Mon, 29 Dec 2014 13:58:55 -0800 (PST) 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 Vzrw1xcmyLRv; Mon, 29 Dec 2014 13:58:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 484531A9131; Mon, 29 Dec 2014 13:58:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229215854.25322.88922.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 13:58:54 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/lRbSGXy7KaLLsrc6eEsdImxunQQ Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 21:58:55 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ From nobody Mon Dec 29 13:59: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 D654E1ACDF3 for ; Mon, 29 Dec 2014 13:59:57 -0800 (PST) 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 RTtqEAVP9__w; Mon, 29 Dec 2014 13:59:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDAD1A9007; Mon, 29 Dec 2014 13:59:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, mszucs@afilias.info, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229215955.23423.29700.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 13:59:55 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Lzz7Ln9dLPsU7SrSXJjkNZsl25c Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 21:59:58 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ From nobody Mon Dec 29 14:00: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 BE5A71A9113 for ; Mon, 29 Dec 2014 14:00:40 -0800 (PST) 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 suCJAW96lgyS; Mon, 29 Dec 2014 14:00:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8743A1ACDEA; Mon, 29 Dec 2014 14:00:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229220038.24665.83575.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 14:00:38 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/O2NBanTc7tiFkV-ZM1fRVY0ohs0 Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 22:00:40 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ From nobody Mon Dec 29 14:00: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 5E0A11ACDFE for ; Mon, 29 Dec 2014 14:00:52 -0800 (PST) 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 lSnr_AWzuawp; Mon, 29 Dec 2014 14:00:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6AE1ACDF9; Mon, 29 Dec 2014 14:00:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229220050.9082.87377.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 14:00:50 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/_m4kq3cSg3PmSRAOfETlx4lMKQM Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 22:00:52 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ From nobody Mon Dec 29 14:02: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 BA8781ACE1C for ; Mon, 29 Dec 2014 14:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1UluqUHZXFU for ; Mon, 29 Dec 2014 14:02:03 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2691ACE15 for ; Mon, 29 Dec 2014 14:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1419890522; x=1451426522; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QKw6CdFIePv7r0Yom6vtZVY79rxxf7zVs2kr9JwT+uY=; b=ZPnsVgwp4WmzLqqbDOvfeJkJZoBXC56lDAhqNsWh2T/8hunQ3tqdheuS +zSOB8sbP2kUoiB1GkLBM/nlGVvyyYbr38biGUR0AhgCzE3S4nq3ImcZO yZUuo24EVAwRkNqnJJLo7+oNskGTItkMmdA4jM211jnyn3vuF9+lJb3xe 0=; X-IronPort-AV: E=McAfee;i="5600,1067,7666"; a="95829231" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 29 Dec 2014 14:02:02 -0800 X-IronPort-AV: E=Sophos;i="5.07,661,1413270000"; d="scan'208";a="31382157" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Dec 2014 14:02:01 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 29 Dec 2014 14:02:00 -0800 Message-ID: <54A1CF56.7080707@qti.qualcomm.com> Date: Mon, 29 Dec 2014 16:01:58 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> In-Reply-To: <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/lcJQv05s4ixVH1az-cCGV2cfuhY Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" , draft-ietf-weirds-json-response@tools.ietf.org Subject: [weirds] About to push the approve button, but... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 Dec 2014 22:02:06 -0000 Doing my final review of the docs, it looks like using-http, rdap-sec, and object-inventory are ready to go, and I want to do one final check on bootstrap in light of Peter's comments, but that looks good too. However, as I was about to approve the lot, I noticed a few issues in rdap-query and json-response that seem to have been dropped during IESG Eval. On some of them, perhaps the intention was to say, "Thanks, but we're leaving that as-is", but all I see is silence. On rdap-query, from Ted's comments: On 10/29/14 5:45 PM, Andy Newton wrote: > On Oct 29, 2014, at 2:47 PM, Ted Lemon wrote: > >> Point A: >> >> In 3.1.2: >> ... >> > The point is: don’t do ASDOT… which is an issue for 4-byte as numbers. We should probably actually say that, and split apart the first paragraph to put the examples closer to it. > >> Point B: >> >> Section 6 appears to be confusing presentation and representation. A >> client might well present a UI that shows U-labels, but use A-labels on >> the back end. The text as written here really doesn't make sense. >> What are you trying to say? I think that you shouldn't confuse what's >> presented to the user with what's sent on the wire. Possibly this is >> related to the confusion over A-labels and U-labels that I called out in >> Point 2 of the discuss. > > [No response] > And later: On 10/29/14 6:49 PM, Ted Lemon wrote: > My concern is that it will be used for data mining by people other than owners of nameservers. I don't think there's much that can be done to mitigate this, though, so I'll take it out of the DISCUSS. It wouldn't hurt to mention it specifically in the security considerations section, but I'll leave that up to you. > Sounds like Point A was supposed to get some additional text, but nothing changed, and that Point B and the requested addition to Security Consideration were ignored. On json-response, Stephen's last two points: On 10/30/14 8:47 AM, Stephen Farrell wrote: > - p21, the list following the example contains items that were > not in the example - this is unclear writing. Are you saying > that the list is normative or not? If so, you need to say so. > If not, why go beyond the example? The same point applies to > the lots of other examples that follow. > > - 10.2.X: there's a lot of stuff here that wasn't described. I > wouldn't be surprised if that causes interop problems. > and both of Ted's points: On 10/29/14 2:40 PM, Ted Lemon wrote: > Point 1: > > In 4.3: > It is the job of the clients to determine line breaks, spacing and > display issues for sentences within the character strings of the > "description" array. Each string in the "description" array contains > a single complete division of human readable text indicating to > clients where there are semantic breaks. > > What do you mean by "semantic breaks"? Paragraph breaks? Sentence > breaks? Dependent clause breaks? This doesn't make sense. I'm not > going to raise a discuss on it because I don't think it affects > interoperability, but I have no idea how to implement a client to display > this in a way that will make sense to the user. > > Point 2: > > A general question that occurred to me in reading 5.5, which also applies > to 5.4: should you have some text talking about how the link member of a > network or autnum object is generated? Both networks and autnum objects, > as I understand it, can be gotten by querying any number in the range > they enclose. But of course the link member isn't going to enumerate > all the possible queries that could return the particular object > containing that link member. So how is the value that's returned > chosen? Is it the lowest number in the range? The number that was used > in the query that returned the object? Some other number? > > I don't think you need to change anything, but it might be worth > discussing this in sections 5.4 and 5.5. > These all look completely dropped. Can the authors give me a status on the above comments? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Dec 30 09:47: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 A5EAC1A03A1 for ; Tue, 30 Dec 2014 09:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYYQ4_Ht09_q for ; Tue, 30 Dec 2014 09:47:18 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7789B1A1A0C for ; Tue, 30 Dec 2014 09:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1419961638; x=1451497638; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ivWFo3D2GMyF/U/nlASlUVXYKhET2squFOMViM68ThY=; b=lwknGQv9qUGcy9rq6ZkPmzUKyoQ4FpmvOD1vMt3STLeLjH3idMB6cxFD 7s05A+GKqlMqp+sE4RfUAWJYW53RBYY0FWE0/d5U2QM8Jj9U/KEWdhYlX XlHJBHvNG9QhW0WCIVAZ8206NUuXgBnOOPST+AHS8m+1vLQ5VwFKVS5Fa I=; X-IronPort-AV: E=McAfee;i="5600,1067,7667"; a="80806961" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Dec 2014 09:47:17 -0800 X-IronPort-AV: E=Sophos;i="5.07,666,1413270000"; d="scan'208";a="820903512" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Dec 2014 09:47:18 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 30 Dec 2014 09:47:16 -0800 Message-ID: <54A2E521.9090602@qti.qualcomm.com> Date: Tue, 30 Dec 2014 11:47:13 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Marc Blanchet , Barry Leiba , "Murray S. Kucherawy" , Michael Szucs , , "" References: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> <20141218205850.GH28899@x28.adm.denic.de> In-Reply-To: <20141218205850.GH28899@x28.adm.denic.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/018u-cr0dOGCOM6cseWJCF3twp8 Subject: Re: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-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: Tue, 30 Dec 2014 17:47:20 -0000 Peter, I don't disagree in principle with any of the below, but (a) I think the conclusion of the WG and the IESG was that the separation was sufficient enough to keep things separate and, more importantly, (b) I repeatedly brought this document to the attention of the IAB IANA Evolution Program and no concerns were expressed. I don't feel like I'm in a position at this point (both in terms of my understanding of the issue and what I see as the consensus) to tell the WG to go in a different direction. If you feel this is a blunder, I will take absolutely no offense (and I don't think the WG should either) if you appeal this, as I do think this is an important issue. Appealing will not only put the single issue on the IESG's agenda to review, but it also means that if we stick by our decision it can be reviewed by the IAB as a whole. Given the political implications of this issue, I don't think that would be such a bad outcome. I am even happy to help you walk through the appeal process so that it happens quickly and properly. The appeal can probably be decided before the document is likely to get to the top of RFC Editor queue anyway, so I don't think it will introduce any significant delay. Let me know if you want to do that. Either way, once my questions from yesterday about json-response and rdap-query get answered, I'll mark the entire set as approved. pr On 12/18/14 2:58 PM, Peter Koch wrote: > On Thu, Dec 18, 2014 at 02:39:26PM -0500, Marc Blanchet wrote: > >> Hello, >> this new version shall address all comments received from IESG review. IMHO, it should clear the DISCUSS and move ahead. >> > I've re-read the updated IANA considerations section. This new > version still does not focus on the IETF side of things and in fact > tries to make ICANN's work with IETF tools. In fact, what is about > to be established here is not even a registry, it is operational data > (fed from existing registries coming from different, non-IETF IANA pillars). > more like the DNS root zone than an IETF protocol parameters registry. > > Therefore what the IETF should do is specify the format only and let > "the other entity" (aka ICANN) describe (in an RFC, independent submission stream) > the operational details of the initial "hook". > The end result for users would be the same with the benefit of untangling the > policy space. Let us please use this opportunity not to further contribute to > overlaps between different IANA functions where in neighboring venues we > try to more precisely specify the separation of duties. > > -Peter > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Dec 30 10:06: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 D63351A1A15 for ; Tue, 30 Dec 2014 10:06:27 -0800 (PST) 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 MOzlsu-eTGgb for ; Tue, 30 Dec 2014 10:06:26 -0800 (PST) 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 1D0F41A1A14 for ; Tue, 30 Dec 2014 10:06:26 -0800 (PST) Received: from crankycanuck.ca (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B40D58A031; Tue, 30 Dec 2014 18:06:23 +0000 (UTC) Date: Tue, 30 Dec 2014 13:06:23 -0500 From: Andrew Sullivan To: Pete Resnick Message-ID: <20141230180622.GE55744@crankycanuck.ca> References: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> <20141218205850.GH28899@x28.adm.denic.de> <54A2E521.9090602@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54A2E521.9090602@qti.qualcomm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/pFO6wkoZAtTBuEPJZa1kwkDnKSE Cc: "" , draft-ietf-weirds-bootstrap.all@tools.ietf.org, Barry Leiba Subject: Re: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-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: Tue, 30 Dec 2014 18:06:28 -0000 On Tue, Dec 30, 2014 at 11:47:13AM -0600, Pete Resnick wrote: > enough to keep things separate and, more importantly, (b) I repeatedly > brought this document to the attention of the IAB IANA Evolution Program and > no concerns were expressed. I read the document more than once, both with my WG participant hat on and as a member of the IANA evolution program, and I guess I don't see what the problem is, given the WG's decision to go this way. That is, I _always_ thought using an IANA registry for bootstrapping was silly, and I always thought that we have a perfectly good mechanism in the DNS to deliver this sort of answer. But given how far in the rough I was, I couldn't see what else to do. Moreover, staff from the current IANA operator was in the room and not objecting when this issue was raised (and is presumably still on the list). But it seems to me that what the document is outlining is an admittedly-unusual update mechanism for the registry. It surprises me somewhat that IANA in its review did not ask, "How are we supposed to do this?" But if they know, then I can't see what the problem is. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Dec 30 16:30: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 56F0D1A899B for ; Tue, 30 Dec 2014 16:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 6LxSlrcBlpyU for ; Tue, 30 Dec 2014 16:30:20 -0800 (PST) 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 6A17A1A8997 for ; Tue, 30 Dec 2014 16:30:19 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVKNDlw4gx7PaQTmNfVU0D5FDk/5G+7CJ@postini.com; Tue, 30 Dec 2014 16:30:19 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id sBV0UERk031502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Dec 2014 19:30:14 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 30 Dec 2014 19:30:13 -0500 From: "Hollenbeck, Scott" To: Pete Resnick , "weirds@ietf.org" Thread-Topic: [weirds] About to push the approve button, but... Thread-Index: AQHQI7MYkAB24mPOD0ukG7pveYSASJyo135w Date: Wed, 31 Dec 2014 00:30:13 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F0F1FA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> <54A1CF56.7080707@qti.qualcomm.com> In-Reply-To: <54A1CF56.7080707@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/5u5sMNO3VlOtR8wgb9Jak4dOwQA Cc: "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] About to push the approve button, but... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Dec 2014 00:30:22 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Pete Resnick > Sent: Monday, December 29, 2014 5:02 PM > To: weirds@ietf.org > Cc: weirds-chairs@tools.ietf.org; draft-ietf-weirds-rdap- > query@tools.ietf.org; draft-ietf-weirds-json-response@tools.ietf.org > Subject: [weirds] About to push the approve button, but... >=20 > Doing my final review of the docs, it looks like using-http, rdap-sec, > and object-inventory are ready to go, and I want to do one final check > on bootstrap in light of Peter's comments, but that looks good too. > However, as I was about to approve the lot, I noticed a few issues in > rdap-query and json-response that seem to have been dropped during IESG > Eval. On some of them, perhaps the intention was to say, "Thanks, but > we're leaving that as-is", but all I see is silence. >=20 > On rdap-query, from Ted's comments: >=20 > On 10/29/14 5:45 PM, Andy Newton wrote: > > On Oct 29, 2014, at 2:47 PM, Ted Lemon wrote: > > > >> Point A: > >> > >> In 3.1.2: > >> ... > >> > > The point is: don't do ASDOT... which is an issue for 4-byte as > numbers. We should probably actually say that, and split apart the > first paragraph to put the examples closer to it. I'll leave this one to Andy. > >> Point B: > >> > >> Section 6 appears to be confusing presentation and representation. > A > >> client might well present a UI that shows U-labels, but use A-labels > on > >> the back end. The text as written here really doesn't make sense. > >> What are you trying to say? I think that you shouldn't confuse > what's > >> presented to the user with what's sent on the wire. Possibly this > is > >> related to the confusion over A-labels and U-labels that I called > out in > >> Point 2 of the discuss. > > > > [No response] There was no response because this was part of our "we don't know what to s= ay about Ted's IDN issues" off-list discussion. If I were to respond now I = would say "what we have there came from our best IDN experts and I'm inclin= ed to leave it alone unless they say otherwise". > And later: >=20 > On 10/29/14 6:49 PM, Ted Lemon wrote: > > My concern is that it will be used for data mining by people other > than owners of nameservers. I don't think there's much that can be > done to mitigate this, though, so I'll take it out of the DISCUSS. It > wouldn't hurt to mention it specifically in the security considerations > section, but I'll leave that up to you. > > >=20 > Sounds like Point A was supposed to get some additional text, but > nothing changed, and that Point B and the requested addition to > Security > Consideration were ignored. I have to disagree with the suggestion to add text about data mining. This = isn't WHOIS, and we wrote a security document that describes client identif= ication, authorization, and access control features in RDAP to address that= issue with WHOIS. There was no direct response simply because the point go= t lost in the flurry of higher priority discuss topics. > On json-response, Stephen's last two points: >=20 > On 10/30/14 8:47 AM, Stephen Farrell wrote: > > - p21, the list following the example contains items that were > > not in the example - this is unclear writing. Are you saying > > that the list is normative or not? If so, you need to say so. > > If not, why go beyond the example? The same point applies to > > the lots of other examples that follow. > > > > - 10.2.X: there's a lot of stuff here that wasn't described. I > > wouldn't be surprised if that causes interop problems. > > >=20 > and both of Ted's points: >=20 > On 10/29/14 2:40 PM, Ted Lemon wrote: > > Point 1: > > > > In 4.3: > > It is the job of the clients to determine line breaks, spacing > and > > display issues for sentences within the character strings of the > > "description" array. Each string in the "description" array > contains > > a single complete division of human readable text indicating to > > clients where there are semantic breaks. > > > > What do you mean by "semantic breaks"? Paragraph breaks? Sentence > > breaks? Dependent clause breaks? This doesn't make sense. I'm > not > > going to raise a discuss on it because I don't think it affects > > interoperability, but I have no idea how to implement a client to > display > > this in a way that will make sense to the user. > > > > Point 2: > > > > A general question that occurred to me in reading 5.5, which also > applies > > to 5.4: should you have some text talking about how the link member > of a > > network or autnum object is generated? Both networks and autnum > objects, > > as I understand it, can be gotten by querying any number in the range > > they enclose. But of course the link member isn't going to > enumerate > > all the possible queries that could return the particular object > > containing that link member. So how is the value that's returned > > chosen? Is it the lowest number in the range? The number that was > used > > in the query that returned the object? Some other number? > > > > I don't think you need to change anything, but it might be worth > > discussing this in sections 5.4 and 5.5. > > >=20 > These all look completely dropped. >=20 > Can the authors give me a status on the above comments? Status for rdap-query provided above. I'll need to talk to Andy about json-= response. Scott From nobody Wed Dec 31 08: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 010A61A9252 for ; Wed, 31 Dec 2014 08:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGia-Dpx1cAq for ; Wed, 31 Dec 2014 08:48:56 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9B81A916B for ; Wed, 31 Dec 2014 08:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1420044534; x=1451580534; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=55yjoDLaalZt2tnr5LpkiymfBlGKFr3zaMadjo7vYqg=; b=TWxa5NGMWax8TSqM5uUVsSRYyV/KDGFZzkf3dfvNoIrU1Qdaehdn2y5L uNS9uBw21upKbg2xHQ9yi8/PRN4Qji1Lq1N1PwbjTpWYqUFhUBe1Dha0A quf+umXzvGWffROE3CdlHePLZK/I9aZPG10F/JxQUY6aJR/ZX9W7DN6fd M=; X-IronPort-AV: E=McAfee;i="5600,1067,7667"; a="96150472" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Dec 2014 08:48:54 -0800 X-IronPort-AV: E=Sophos;i="5.07,673,1413270000"; d="scan'208";a="808373075" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Dec 2014 08:48:52 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 31 Dec 2014 08:48:51 -0800 Message-ID: <54A428F2.8010102@qti.qualcomm.com> Date: Wed, 31 Dec 2014 10:48:50 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> <54A1CF56.7080707@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F49F0F1FA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F0F1FA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01H.na.qualcomm.com (10.85.0.34) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/S53eT3_UzewiezLdObEvInXGVxI Cc: "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] About to push the approve button, but... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Dec 2014 16:48:59 -0000 On 12/30/14 6:30 PM, Hollenbeck, Scott wrote: >> Doing my final review of the docs, it looks like using-http, rdap-sec, >> and object-inventory are ready to go, and I want to do one final check >> on bootstrap in light of Peter's comments, but that looks good too. >> However, as I was about to approve the lot, I noticed a few issues in >> rdap-query and json-response that seem to have been dropped during IESG >> Eval. On some of them, perhaps the intention was to say, "Thanks, but >> we're leaving that as-is", but all I see is silence. >> >> On rdap-query, from Ted's comments: >> >> On 10/29/14 5:45 PM, Andy Newton wrote: >> >>> On Oct 29, 2014, at 2:47 PM, Ted Lemon wrote: >>> >>> >>>> Point A: >>>> >>>> In 3.1.2: >>>> ... >>>> >>>> >>> The point is: don't do ASDOT... which is an issue for 4-byte as >>> numbers. We should probably actually say that, and split apart the >>> first paragraph to put the examples closer to it. > I'll leave this one to Andy. > Ack. He promised to get back to me when he was not hopped-up on cough medicine. >>>> Point B: >>>> >>>> Section 6 appears to be confusing presentation and representation. >>>> A client might well present a UI that shows U-labels, but use >>>> A-labels on the back end. The text as written here really doesn't >>>> make sense. What are you trying to say? I think that you shouldn't >>>> confuse what's presented to the user with what's sent on the wire. >>>> Possibly this is related to the confusion over A-labels and >>>> U-labels that I called out in Point 2 of the discuss. >>> [No response] >>> > There was no response because this was part of our "we don't know what to say about Ted's IDN issues" off-list discussion. If I were to respond now I would say "what we have there came from our best IDN experts and I'm inclined to leave it alone unless they say otherwise". > Good. That's my gut too. He doesn't like this sentence: Clients capable of processing non-ASCII characters may prefer a U-label since this is more visually recognizable and familiar than A-label strings, but clients using programmatic interfaces might find it easier to submit and display A-labels if they are unable to input U-labels with their keyboard configuration. And he's right, that sentence is mixing apples and oranges: You can display a U-label or an A-label as a decoded string, and which encoding you use internally doesn't effect that. But I know what was meant, and I don't think it is likely to confuse implementers, so I don't see a big need to change it. >> And later: >> >> On 10/29/14 6:49 PM, Ted Lemon wrote: >> >>> My concern is that it will be used for data mining by people other >>> than owners of nameservers. I don't think there's much that can be >>> done to mitigate this, though, so I'll take it out of the DISCUSS. It >>> wouldn't hurt to mention it specifically in the security considerations >>> section, but I'll leave that up to you. >>> >> Sounds like Point A was supposed to get some additional text, but >> nothing changed, and that Point B and the requested addition to >> Security Consideration were ignored. >> > I have to disagree with the suggestion to add text about data mining. This isn't WHOIS, and we wrote a security document that describes client identification, authorization, and access control features in RDAP to address that issue with WHOIS. Seems like a fair response to me. > There was no direct response simply because the point got lost in the flurry of higher priority discuss topics. > Yep. Just making sure we have a record on the list that we saw the issue and there was a disposition. >> On json-response, Stephen's last two points: >> >> On 10/30/14 8:47 AM, Stephen Farrell wrote: >> >>> - p21, the list following the example contains items that were >>> not in the example - this is unclear writing. Are you saying >>> that the list is normative or not? If so, you need to say so. >>> If not, why go beyond the example? The same point applies to >>> the lots of other examples that follow. >>> >>> - 10.2.X: there's a lot of stuff here that wasn't described. I >>> wouldn't be surprised if that causes interop problems. >>> >>> >> and both of Ted's points: >> >> On 10/29/14 2:40 PM, Ted Lemon wrote: >> >>> Point 1: >>> >>> In 4.3: >>> It is the job of the clients to determine line breaks, spacing and >>> display issues for sentences within the character strings of the >>> "description" array. Each string in the "description" array contains >>> a single complete division of human readable text indicating to >>> clients where there are semantic breaks. >>> >>> What do you mean by "semantic breaks"? Paragraph breaks? Sentence >>> breaks? Dependent clause breaks? This doesn't make sense. I'm >>> not going to raise a discuss on it because I don't think it affects >>> interoperability, but I have no idea how to implement a client to >>> display this in a way that will make sense to the user. >>> >>> Point 2: >>> >>> A general question that occurred to me in reading 5.5, which also >>> applies to 5.4: should you have some text talking about how the >>> link member of a network or autnum object is generated? Both >>> networks and autnum objects, as I understand it, can be gotten by >>> querying any number in the range they enclose. But of course the >>> link member isn't going to enumerate all the possible queries that >>> could return the particular object containing that link member. >>> So how is the value that's returned chosen? Is it the lowest >>> number in the range? The number that was used in the query that >>> returned the object? Some other number? >>> >>> I don't think you need to change anything, but it might be worth >>> discussing this in sections 5.4 and 5.5. >>> >> These all look completely dropped. >> >> Can the authors give me a status on the above comments? >> > Status for rdap-query provided above. I'll need to talk to Andy about json-response. > Thanks. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Dec 31 11:46: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 178F61A1A58 for ; Wed, 31 Dec 2014 11:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeWPkJNz2Vy7 for ; Wed, 31 Dec 2014 11:46:49 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 7B38B1A1A55 for ; Wed, 31 Dec 2014 11:46:49 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 344EB21370A; Wed, 31 Dec 2014 14:46:49 -0500 (EST) 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 5AA34213704; Wed, 31 Dec 2014 14:46:48 -0500 (EST) 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.210.2; Wed, 31 Dec 2014 14:50:17 -0500 Received: from CHAMBX01.corp.arin.net ([fe80::1cef:1d7:cca9:5953]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0210.002; Wed, 31 Dec 2014 14:46:42 -0500 From: Andy Newton To: Pete Resnick Thread-Topic: [weirds] About to push the approve button, but... Thread-Index: AQHQI7MYAIX2rzjec0qnKB1GMiEBXpyqcWqA Date: Wed, 31 Dec 2014 19:46:41 +0000 Message-ID: References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> <54A1CF56.7080707@qti.qualcomm.com> In-Reply-To: <54A1CF56.7080707@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.57] Content-Type: text/plain; charset="Windows-1252" Content-ID: <49384F31D4BC5F4FA94E382D33DD1950@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/M_djKCBbVyJ5Pqh50rDqJTjpLTE Cc: "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] About to push the approve button, but... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Dec 2014 19:46:51 -0000 > On json-response, Stephen's last two points: >=20 > On 10/30/14 8:47 AM, Stephen Farrell wrote: >> - p21, the list following the example contains items that were >> not in the example - this is unclear writing. Are you saying >> that the list is normative or not? If so, you need to say so. >> If not, why go beyond the example? The same point applies to >> the lots of other examples that follow. >>=20 Well, this is a general problem with describing JSON without a schema langu= age: clarity relies on the copious use of examples. This section lays out a= n example of entity as it might be rendered by an RIR, then lays out the no= rmative structure, then gives an elided example, then gives an example as i= t might be rendered by a DNR. I fail to see how rearranging things helps or= giving an example with ALL valid fields would be clearer. And the words "T= his object has the following members=94 precedes the list. How can that be = made clearer? >> - 10.2.X: there's a lot of stuff here that wasn't described. I >> wouldn't be surprised if that causes interop problems. >> =20 >=20 Every value in that section as a description field. And to my knowledge, no= ne of it has shown up as an issue in our interop sessions. > and both of Ted's points: >=20 > On 10/29/14 2:40 PM, Ted Lemon wrote: >> Point 1: >>=20 >> In 4.3: >> It is the job of the clients to determine line breaks, spacing and >> display issues for sentences within the character strings of the >> "description" array. Each string in the "description" array contains >> a single complete division of human readable text indicating to >> clients where there are semantic breaks. >>=20 >> What do you mean by "semantic breaks"? Paragraph breaks? Sentence >> breaks? Dependent clause breaks? This doesn't make sense. I'm not >> going to raise a discuss on it because I don't think it affects >> interoperability, but I have no idea how to implement a client to displa= y >> this in a way that will make sense to the user. >>=20 This was discussed on the list and, as I recall, there was an issue over th= ese being considered paragraph breaks. The current words raised no objectio= ns. We can change it, but it is just gonna make somebody else unhappy for l= ittle benefit. >> Point 2: >>=20 >> A general question that occurred to me in reading 5.5, which also applie= s >> to 5.4: should you have some text talking about how the link member of a >> network or autnum object is generated? Both networks and autnum objects= , >> as I understand it, can be gotten by querying any number in the range >> they enclose. But of course the link member isn't going to enumerate >> all the possible queries that could return the particular object >> containing that link member. So how is the value that's returned >> chosen? Is it the lowest number in the range? The number that was use= d >> in the query that returned the object? Some other number? >>=20 >> I don't think you need to change anything, but it might be worth >> discussing this in sections 5.4 and 5.5. >> =20 I don=92t think text discussing how to generate links will be helpful becau= se the solution is just to pick a number (perhaps the lowest or highest) in= the range and go for it. Or use object handles (synthetic keys). It=92s an= implementation issue that could have many solutions. -andy From nobody Wed Dec 31 11:55: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 76BEE1A1A6A for ; Wed, 31 Dec 2014 11:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPj7nRAO7qJE for ; Wed, 31 Dec 2014 11:55:00 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 469061A1A6B for ; Wed, 31 Dec 2014 11:55:00 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id C6F06164EB2; Wed, 31 Dec 2014 14:54:59 -0500 (EST) 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 394E5164E5D; Wed, 31 Dec 2014 14:54:59 -0500 (EST) 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.210.2; Wed, 31 Dec 2014 14:58:28 -0500 Received: from CHAMBX01.corp.arin.net ([fe80::1cef:1d7:cca9:5953]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0210.002; Wed, 31 Dec 2014 14:54:52 -0500 From: Andy Newton To: Pete Resnick Thread-Topic: [weirds] About to push the approve button, but... Thread-Index: AQHQI7MYAIX2rzjec0qnKB1GMiEBXpypLk2AgAERbACAADP6AA== Date: Wed, 31 Dec 2014 19:54:52 +0000 Message-ID: <700325D7-01EB-43B6-A42E-0DDC331BA67C@arin.net> References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> <54A1CF56.7080707@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F49F0F1FA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <54A428F2.8010102@qti.qualcomm.com> In-Reply-To: <54A428F2.8010102@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.57] Content-Type: multipart/alternative; boundary="_000_700325D701EB43B6A42E0DDC331BA67Carinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/w285_SdRyZyRM5b4kZyrBKu3em4 Cc: "draft-ietf-weirds-json-response@tools.ietf.org" , "weirds-chairs@tools.ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] About to push the approve button, but... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Dec 2014 19:55:02 -0000 --_000_700325D701EB43B6A42E0DDC331BA67Carinnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBPY3QgMjksIDIwMTQsIGF0IDI6NDcgUE0sIFRlZCBMZW1vbjxUZWQuTGVtb25Abm9taW51 bS5jb208bWFpbHRvOlRlZC5MZW1vbkBub21pbnVtLmNvbT4+ICAgd3JvdGU6DQoNCg0KUG9pbnQg QToNCg0KSW4gMy4xLjI6DQouLi4NCg0KDQpUaGUgcG9pbnQgaXM6IGRvbid0IGRvIEFTRE9ULi4u IHdoaWNoIGlzIGFuIGlzc3VlIGZvciA0LWJ5dGUgYXMNCm51bWJlcnMuIFdlIHNob3VsZCBwcm9i YWJseSBhY3R1YWxseSBzYXkgdGhhdCwgYW5kIHNwbGl0IGFwYXJ0IHRoZQ0KZmlyc3QgcGFyYWdy YXBoIHRvIHB1dCB0aGUgZXhhbXBsZXMgY2xvc2VyIHRvIGl0Lg0KSSdsbCBsZWF2ZSB0aGlzIG9u ZSB0byBBbmR5Lg0KDQoNCkFjay4gSGUgcHJvbWlzZWQgdG8gZ2V0IGJhY2sgdG8gbWUgd2hlbiBo ZSB3YXMgbm90IGhvcHBlZC11cCBvbiBjb3VnaCBtZWRpY2luZS4NCg0KVGhlIGN1cnJlbnQgZHJh ZnQgc2F5cyDigJxBUyBQbGFpbuKAnSBhbmQgcmVmZXJlbmNlcyA1Mzk2LiBJIHRoaW5rIHRoYXQg aXMgY2xlYXIgZW5vdWdoLiBXZSBzaG91bGRu4oCZdCBoYXZlIHRvIHNwZWNpZnkgZXZlcnl0aGlu ZyBhIGNsaWVudCBzaG91bGRu4oCZdCBkbyBiZWNhdXNlIHRoYXQgaXMgYSBiaWcgdW5pdmVyc2Uu DQoNCi1hbmR5DQo= --_000_700325D701EB43B6A42E0DDC331BA67Carinnet_ Content-Type: text/html; charset="utf-8" Content-ID: <4936DA2692558C42AF464AE146471933@corp.arin.net> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPk9uIE9jdCAyOSwgMjAxNCwgYXQgMjo0NyBQTSwgVGVkIExlbW9uJmx0 OzxhIGhyZWY9Im1haWx0bzpUZWQuTGVtb25Abm9taW51bS5jb20iIGNsYXNzPSIiPlRlZC5MZW1v bkBub21pbnVtLmNvbTwvYT4mZ3Q7ICZuYnNwOyZuYnNwO3dyb3RlOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPlBvaW50IEE6PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSW4gMy4xLjI6PGJyIGNsYXNzPSIiPg0KLi4uPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KVGhlIHBvaW50IGlzOiBk b24ndCBkbyBBU0RPVC4uLiB3aGljaCBpcyBhbiBpc3N1ZSBmb3IgNC1ieXRlIGFzPGJyIGNsYXNz PSIiPg0KbnVtYmVycy4gV2Ugc2hvdWxkIHByb2JhYmx5IGFjdHVhbGx5IHNheSB0aGF0LCBhbmQg c3BsaXQgYXBhcnQgdGhlPGJyIGNsYXNzPSIiPg0KZmlyc3QgcGFyYWdyYXBoIHRvIHB1dCB0aGUg ZXhhbXBsZXMgY2xvc2VyIHRvIGl0LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCkknbGwgbGVhdmUgdGhpcyBvbmUgdG8gQW5keS48YnIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDs8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i Ij5BY2suDQogSGUgcHJvbWlzZWQgdG8gZ2V0IGJhY2sgdG8gbWUgd2hlbiBoZSB3YXMgbm90IGhv cHBlZC11cCBvbiBjb3VnaCBtZWRpY2luZS48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5UaGUgY3VycmVudCBkcmFmdCBzYXlzIOKAnEFTIFBs YWlu4oCdIGFuZCByZWZlcmVuY2VzIDUzOTYuIEkgdGhpbmsgdGhhdCBpcyBjbGVhciBlbm91Z2gu IFdlIHNob3VsZG7igJl0IGhhdmUgdG8gc3BlY2lmeSBldmVyeXRoaW5nIGEgY2xpZW50IHNob3Vs ZG7igJl0IGRvIGJlY2F1c2UgdGhhdCBpcyBhIGJpZyB1bml2ZXJzZS48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1hbmR5PC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_700325D701EB43B6A42E0DDC331BA67Carinnet_-- From nobody Wed Dec 31 12:19: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 4169B1A1AB4 for ; Wed, 31 Dec 2014 12:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHSkEjSqfm51 for ; Wed, 31 Dec 2014 12:19:43 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1CD1A1AAD for ; Wed, 31 Dec 2014 12:19:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1420057183; x=1451593183; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=sRAM2nw5V3v2y2c9Ak6Zto1e5ZjfJXIEM2s0j8r5btY=; b=W0c7x4Wxzl+Ijh55ZfFu3VeqyJFsNc8xjS+cBF84KV9vUxufgclySs5v 2IWBNOjrDppfYOLN4Cus1tpnzBVZOJ2UXGHsO0r7UAZcJ8IwcxcpuTxj0 q25p1S8/DpjZVaqrZOveHcmfAJHcRZbI7lHJ9NUN/LMUtF0w5nOzm6AsO k=; X-IronPort-AV: E=McAfee;i="5600,1067,7668"; a="96158559" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Dec 2014 12:19:42 -0800 X-IronPort-AV: E=Sophos;i="5.07,674,1413270000"; d="scan'208,217";a="808441021" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Dec 2014 12:19:42 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 31 Dec 2014 12:19:40 -0800 Message-ID: <54A45A5A.6030804@qti.qualcomm.com> Date: Wed, 31 Dec 2014 14:19:38 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Andy Newton References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> <54A1CF56.7080707@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F49F0F1FA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <54A428F2.8010102@qti.qualcomm.com> <700325D7-01EB-43B6-A42E-0DDC331BA67C@arin.net> In-Reply-To: <700325D7-01EB-43B6-A42E-0DDC331BA67C@arin.net> Content-Type: multipart/alternative; boundary="------------000707020509090803030109" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/01o0NRhPcqZxQR-nuyjk8Gk2Cco Cc: "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] About to push the approve button, but... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Dec 2014 20:19:45 -0000 --------------000707020509090803030109 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 12/31/14 1:54 PM, Andy Newton wrote: >>>>> On Oct 29, 2014, at 2:47 PM, Ted Lemon>>>> > wrote: >>>>> >>>>> >>>>>> Point A: >>>>>> >>>>>> In 3.1.2: >>>>>> ... >>>>>> >>>>>> >>>>> The point is: don't do ASDOT... which is an issue for 4-byte as >>>>> numbers. We should probably actually say that, and split apart the >>>>> first paragraph to put the examples closer to it. >>> I'll leave this one to Andy. >>> >> >> Ack. He promised to get back to me when he was not hopped-up on cough >> medicine. > > The current draft says "AS Plain" and references 5396. I think that is > clear enough. We shouldn't have to specify everything a client > shouldn't do because that is a big universe. Sounds OK. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------000707020509090803030109 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 12/31/14 1:54 PM, Andy Newton wrote:

On Oct 29, 2014, at 2:47 PM, Ted Lemon<Ted.Lemon@nominum.com>   wrote:

      
Point A:

In 3.1.2:
...

        
The point is: don't do ASDOT... which is an issue for 4-byte as
numbers. We should probably actually say that, and split apart the
first paragraph to put the examples closer to it.
I'll leave this one to Andy.
  

Ack. He promised to get back to me when he was not hopped-up on cough medicine.

The current draft says “AS Plain” and references 5396. I think that is clear enough. We shouldn’t have to specify everything a client shouldn’t do because that is a big universe.

Sounds OK.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------000707020509090803030109-- From nobody Wed Dec 31 12:21: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 8210F1A1AB9 for ; Wed, 31 Dec 2014 12:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydGUXdcD1BLo for ; Wed, 31 Dec 2014 12:21:21 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB76F1A1A50 for ; Wed, 31 Dec 2014 12:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1420057281; x=1451593281; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QV6cRUMb6JoS14Udzc56vlJAwIYnIinjJEEoryfsRvE=; b=apRv2KBpgBroMhSYz65gLSAazAqzXtOyOxiGTHb2urTU1CTarPISR+K3 aNkxv4q3R/SsbrXAl4311SUj3UQCMf8FseOCt8Sk9wZ0NYonsCNFm4Ssw cEJk1pp3upmLlyHQnGob4NWAqLeZts3lMw3ymUxn0UINCqpAR8ItGjJth g=; X-IronPort-AV: E=McAfee;i="5600,1067,7668"; a="96158651" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Dec 2014 12:21:21 -0800 X-IronPort-AV: E=Sophos;i="5.07,675,1413270000"; d="scan'208";a="875559146" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Dec 2014 12:21:21 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 31 Dec 2014 12:21:20 -0800 Message-ID: <54A45ABE.4050307@qti.qualcomm.com> Date: Wed, 31 Dec 2014 14:21:18 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Andy Newton References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> <54A1CF56.7080707@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/iVvDn9ttEtz3rKhRqX3ufUQtTAI Cc: "weirds-chairs@tools.ietf.org" , "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" , "draft-ietf-weirds-json-response@tools.ietf.org" Subject: Re: [weirds] About to push the approve button, but... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Dec 2014 20:21:23 -0000 On 12/31/14 1:46 PM, Andy Newton wrote: >> On json-response, Stephen's last two points: >> >> On 10/30/14 8:47 AM, Stephen Farrell wrote: >> >>> - p21, the list following the example contains items that were >>> not in the example - this is unclear writing. Are you saying >>> that the list is normative or not? If so, you need to say so. >>> If not, why go beyond the example? The same point applies to >>> the lots of other examples that follow. >>> > Well, this is a general problem with describing JSON without a schema language: clarity relies on the copious use of examples. This section lays out an example of entity as it might be rendered by an RIR, then lays out the normative structure, then gives an elided example, then gives an example as it might be rendered by a DNR. I fail to see how rearranging things helps or giving an example with ALL valid fields would be clearer. And the words "This object has the following members” precedes the list. How can that be made clearer? > I think it's the "This" that's the problem: It's not that the object in the above example has the following members; it's that an object of the particular type *can* contain the following members. Saying that is probably a good idea. So for 5.1: The entity object class can contain the following members: For 5.2, simply s/has/can contain, and so on for the other sections. That would certainly clarify. >>> - 10.2.X: there's a lot of stuff here that wasn't described. I >>> wouldn't be surprised if that causes interop problems. >>> > Every value in that section as a description field. And to my knowledge, none of it has shown up as an issue in our interop sessions. > Seems like a satisfactory response to me. >> and both of Ted's points: >> >> On 10/29/14 2:40 PM, Ted Lemon wrote: >> >>> Point 1: >>> >>> In 4.3: >>> It is the job of the clients to determine line breaks, spacing and >>> display issues for sentences within the character strings of the >>> "description" array. Each string in the "description" array contains >>> a single complete division of human readable text indicating to >>> clients where there are semantic breaks. >>> >>> What do you mean by "semantic breaks"? Paragraph breaks? Sentence >>> breaks? Dependent clause breaks? This doesn't make sense. I'm not >>> going to raise a discuss on it because I don't think it affects >>> interoperability, but I have no idea how to implement a client to display >>> this in a way that will make sense to the user. >>> > This was discussed on the list and, as I recall, there was an issue over these being considered paragraph breaks. The current words raised no objections. We can change it, but it is just gonna make somebody else unhappy for little benefit. > I'm OK with leaving it. It's basically saying that the creator of the array decided on where to put breaks, and the interpreter of the array can do what it will with that information. >>> Point 2: >>> >>> A general question that occurred to me in reading 5.5, which also applies >>> to 5.4: should you have some text talking about how the link member of a >>> network or autnum object is generated? Both networks and autnum objects, >>> as I understand it, can be gotten by querying any number in the range >>> they enclose. But of course the link member isn't going to enumerate >>> all the possible queries that could return the particular object >>> containing that link member. So how is the value that's returned >>> chosen? Is it the lowest number in the range? The number that was used >>> in the query that returned the object? Some other number? >>> >>> I don't think you need to change anything, but it might be worth >>> discussing this in sections 5.4 and 5.5. >>> >>> > I don’t think text discussing how to generate links will be helpful because the solution is just to pick a number (perhaps the lowest or highest) in the range and go for it. Or use object handles (synthetic keys). It’s an implementation issue that could have many solutions. > Ack. So, I wouldn't mind a quick edit of those lines in json-response, and I'll consider the rdap-query issues addressed. Thanks. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Dec 31 12:22: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 B19171A1AC6 for ; Wed, 31 Dec 2014 12:22:05 -0800 (PST) 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 wZ7X6iwkz-5u; Wed, 31 Dec 2014 12:22:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E451A1A50; Wed, 31 Dec 2014 12:22:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-rdap-query@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231202204.1215.50948.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 12:22:04 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/-PJn9kdqzL00345Yb9-lJWCpcpo Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 20:22:05 -0000 IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ From nobody Wed Dec 31 13:04: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 0F0481A006B; Wed, 31 Dec 2014 13:04:02 -0800 (PST) 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 CRysyEnDFLFL; Wed, 31 Dec 2014 13:04:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4933A1A1AF0; Wed, 31 Dec 2014 13:04:00 -0800 (PST) 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.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231210400.20253.49821.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 13:04:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2Ijd53b3AFFl5qE5TLkqnnFAUqY Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-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: Wed, 31 Dec 2014 21:04: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 : JSON Responses for the Registration Data Access Protocol (RDAP) Authors : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-json-response-14.txt Pages : 91 Date : 2014-12-31 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-json-response-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 Wed Dec 31 13:04: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 080F61A006B for ; Wed, 31 Dec 2014 13:04:03 -0800 (PST) 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 O8n26mMCdieg; Wed, 31 Dec 2014 13:04:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3BC1A1AF2; Wed, 31 Dec 2014 13:04:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231210400.20253.99619.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 13:04:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/G8hHuNO6kFbvKfUlCelBp2PMAQ0 Subject: [weirds] New Version Notification - draft-ietf-weirds-json-response-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: Wed, 31 Dec 2014 21:04:03 -0000 A new version (-14) has been submitted for draft-ietf-weirds-json-response: http://www.ietf.org/internet-drafts/draft-ietf-weirds-json-response-14.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-json-response-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. IETF Secretariat. From nobody Wed Dec 31 13:06:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B271A1AF9 for ; Wed, 31 Dec 2014 13:06:20 -0800 (PST) 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 IMzKMKT0HhEP; Wed, 31 Dec 2014 13:06:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBC51A1AFA; Wed, 31 Dec 2014 13:06:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-json-response@tools.ietf.org, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231210619.17176.32259.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 13:06:19 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/zCHVIYk7yLsFmu_gC0TAfxCGxyg Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 21:06:21 -0000 IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/ From nobody Wed Dec 31 13:37: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 A22DE1A1AFC for ; Wed, 31 Dec 2014 13:37:09 -0800 (PST) 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 4xzVdVGW8j2X; Wed, 31 Dec 2014 13:37:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A41941A038E; Wed, 31 Dec 2014 13:37:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds-chairs@tools.ietf.org, draft-ietf-weirds-bootstrap@tools.ietf.org, mszucs@afilias.info, weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231213708.23178.36101.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 13:37:08 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/pEKegQY4dVLJe2odwncXKa6sRRg Subject: [weirds] ID Tracker State Update Notice: X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 21:37:09 -0000 IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/ From nobody Wed Dec 31 22:45: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 2565A1A0074 for ; Wed, 31 Dec 2014 22:42:41 -0800 (PST) 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_40=-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 N9WJ3Hl2WH12 for ; Wed, 31 Dec 2014 22:42:39 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777341A006F for ; Wed, 31 Dec 2014 22:42:39 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so3155726wes.1 for ; Wed, 31 Dec 2014 22:42:38 -0800 (PST) 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=furs73kt3M0VDzE6k0uTbj889IlIE8OO/+JlfgbKQr0=; b=sZEFWubc243YE7TF+gpMrI8DhqFmTwrPDBTOLGZjvWiWFdyPawIRYFEp1OMF/G2k2N 5ko+qfB/FSNp/cUDgKp5+6bx+NGfFKMLdxfjlml9lrKzaIA2hgVK+qZ95kPNIkl5fDva LGy/F5VkCFF3xhvAnMzvU6cN6SZvWVx91dg+Nqce32TEKI1B24psgJRHWMJzRxAwJdaZ cQ4C16OsRUDOd2yL0uPcfhV5TMRy1lC8k4LPcRZ2qb8CZHvFKd93kfR6AX0gn/SVGEKC IF+1XInR1RFoF4f04z/SisqkBcblyK+w8UzAx2ZvrHB+E+4HeZJfR+K58A55+IKTXdR4 MuKw== MIME-Version: 1.0 X-Received: by 10.180.94.37 with SMTP id cz5mr119386093wib.61.1420094558284; Wed, 31 Dec 2014 22:42:38 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 31 Dec 2014 22:42:38 -0800 (PST) Date: Wed, 31 Dec 2014 22:42:38 -0800 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d04426c2cb1b2a7050b918768 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/vSXQ1AVjGH3W3XACmN8pB3tGpZQ Subject: [weirds] Congratulations X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jan 2015 06:42:41 -0000 --f46d04426c2cb1b2a7050b918768 Content-Type: text/plain; charset=UTF-8 With less than 12 hours to go (in my time zone) in the new year, all documents are now in "Approved-announcement to be sent" state. This means what I said at ICANN in Los Angeles wasn't false. Happy new year, everyone. Good work! -MSK, for the co-chairs --f46d04426c2cb1b2a7050b918768 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With less than 12 hours to go (in my time zone) in th= e new year, all documents are now in "Approved-announcement to be sent= " state.=C2=A0 This means what I said at ICANN in Los Angeles wasn'= ;t false.

Happy new year, everyone.=C2=A0 Good work!

-M= SK, for the co-chairs

--f46d04426c2cb1b2a7050b918768--