From steve.sheng@icann.org Fri Aug 5 11:56:03 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2AA21F8B34 for ; Fri, 5 Aug 2011 11:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMSHpWXpJInz for ; Fri, 5 Aug 2011 11:56:02 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4221F8B33 for ; Fri, 5 Aug 2011 11:56:02 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Fri, 5 Aug 2011 11:56:20 -0700 From: Steve Sheng To: Andy Newton , =JeffH Date: Fri, 5 Aug 2011 11:56:15 -0700 Thread-Topic: My notes from bar BOF Thread-Index: AQHMTYH5KDToq6VaV0S+9rIGFGAmDZUD0RuAgArWlK0= Message-ID: In-Reply-To: <32001899-44CE-4F4A-A018-E4A80A1F9E39@arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: [weirds] My notes from bar BOF X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 18:56:03 -0000 Hi all, for those of you that are not in the bar BOF, here are some informa= l notes from my recollection. If you were in that session, please feel free t= o correct/add. =20 Kind regards,=20 Steve ************************************************************************* Rough Number of Attendees: 40 Pete R. asked that this has been done in the past (IRIS), and there is little adoption, why would this time be different? - Andy mentioned that technically speaking IRIS is heavy weight. One of the reasons that hindered IRIS's adoption is that it uses NAPTR. IRIS also uses BEEP for transport as they were not allowed to use HTTP at the time. This made it difficult to write clients and servers for IRIS. Compared with IRIS= , the RESTful approach reuses the HTTP component, and it does not use NAPTR. - Steve S mentioned that ICANN's is looking to improve WHOIS including support for internationalized registration data. They looked at several alternatives (extending WHOIS, IRIS, RWS), and thought that the RESTful approach by ARIN is most promising. So they did a pilot (documented in the internet draft) to understand RWS better. Participants discussed what are the problems to solve, and listed four: - standardized/machine parsable output. - support internationalized registration data - Be able to support different users - Better referral features Pete R. asked if we developed this, would there be people willing to write clients? Who are the consumers? Are there any evidence that _client_ people want this?=20 - Jeff H. mentioned that they rely on this data heavily, and they would write clients to use it. - Peter K. disagreed, "it only benefits secondary domain industries, and that the end user is ok with the current status quo." =20 - the area directors would like to move this conversation onto the mailing list to make sure that there will actually be people willing to write clients for it, and people actually willing to use it. Someone raised whether it make sense to do IRIS over HTTP? - Andy mentioned that IRIS is tied to XML, and if alternative formats are desired (JSON), then IRIS over HTTP might not work. Andrew S. asked if people have any comments for the drafts? - One comment, there is no schema for ARIN's draft. Harald A. asked Andy to take an action item to add schema to ARIN's draft. - Peter K. mentioned that there is a need to separate policy from technical= . In particular, the draft requirement document seems to be mixing policy requirements with technical ones. Andrew S. asked if people are willing to work on it and review drafts? - About 10 people raised their hands. ************************************************************************* On 7/29/11 1:25 PM, "Andy Newton" wrote: >=20 > On Jul 28, 2011, at 7:55 PM, =3DJeffH wrote: >=20 >> I spose we oughta ask "what /did/ happen with IRIS deployment and what w= ould >> you do differently if you did it over again?".... >>=20 >> IRIS - An Overview for the ICANN Whois Task Force >> Andrew Newton, VeriSign Labs >> Leslie Daigle, VeriSign Labs >> April 29, 2004 >> http://gnso.icann.org/mailing-lists/archives/dow1tf/pdfXH57SShw9O.pdf >=20 > Perhaps people didn't like the font weight and accent color of the slide > presentation? :) >=20 > VeriSign did have a pilot IRIS server refreshed daily with data from thei= r > registry up and running, in addition to their previous Whois-LDAP server = pilot > up and running. Neither saw much traffic. >=20 > As an exercise as to why, I suggest you spend one hour attempting to cons= truct > a simple IRIS client to query for information about a domain name. For > comparison, also spend one hour attempting to construct a simple Whois-RW= S > client to query an IP address from ARIN's Whois restful web service. >=20 > -andy > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From peter@denic.de Mon Aug 8 00:15:05 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D4E21F85DE for ; Mon, 8 Aug 2011 00:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA6S3gGcfntF for ; Mon, 8 Aug 2011 00:15:04 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 4666821F85F2 for ; Mon, 8 Aug 2011 00:14:58 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QqK3W-00054F-Gi; Mon, 08 Aug 2011 09:15:22 +0200 Received: from localhost by x27.adm.denic.de with local id 1QqK3W-0007k4-7i; Mon, 08 Aug 2011 09:15:22 +0200 Date: Mon, 8 Aug 2011 09:15:22 +0200 From: Peter Koch To: weirds@ietf.org Message-ID: <20110808071522.GE30809@x27.adm.denic.de> References: <32001899-44CE-4F4A-A018-E4A80A1F9E39@arin.net> 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 Subject: Re: [weirds] My notes from bar BOF X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 07:15:05 -0000 minuted Bar BOFs sound scary, but thanks! On Fri, Aug 05, 2011 at 11:56:15AM -0700, Steve Sheng wrote: > - Peter K. disagreed, "it only benefits secondary domain industries, and > that the end user is ok with the current status quo." i believe i said this in the context of DCHK or more general in the context of "domain availability checks" of any flavour. Primary user appears to be the secondary domain market and this group apparently has learned to live with a variety of protocols, some of them more or less proprietary. -Peter From dave.piscitello@icann.org Mon Aug 8 05:20:31 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C48421F8A35 for ; Mon, 8 Aug 2011 05:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7eik0h-SoJ3 for ; Mon, 8 Aug 2011 05:20:27 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0D21F85C0 for ; Mon, 8 Aug 2011 05:20:27 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 8 Aug 2011 05:20:53 -0700 From: Dave Piscitello To: Peter Koch Date: Mon, 8 Aug 2011 05:20:52 -0700 Thread-Topic: [weirds] My notes from bar BOF Thread-Index: AcxVxZ2qePZYPOutTo23mCg8tdnLeg== Message-ID: <66C0A7BD-6C48-4182-879E-5E9239CC1751@icann.org> References: <32001899-44CE-4F4A-A018-E4A80A1F9E39@arin.net> <20110808071522.GE30809@x27.adm.denic.de> In-Reply-To: <20110808071522.GE30809@x27.adm.denic.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] My notes from bar BOF X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 12:20:31 -0000 I suppose you want a copy of the covert recording, mistrustful muggle that = you are... It's already been sent to The Ministry of Magic :-O On Aug 8, 2011, at 3:15 AM, Peter Koch wrote: > minuted Bar BOFs sound scary, but thanks! >=20 >=20 > On Fri, Aug 05, 2011 at 11:56:15AM -0700, Steve Sheng wrote: >=20 >> - Peter K. disagreed, "it only benefits secondary domain industries, and >> that the end user is ok with the current status quo." >=20 > i believe i said this in the context of DCHK or more general in the conte= xt > of "domain availability checks" of any flavour. Primary user appears to > be the secondary domain market and this group apparently has learned to l= ive > with a variety of protocols, some of them more or less proprietary. >=20 > -Peter > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From msk@cloudmark.com Tue Aug 9 11:55:03 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01321F8C13 for ; Tue, 9 Aug 2011 11:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.602 X-Spam-Level: X-Spam-Status: No, score=-103.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zma-5rLyu5b2 for ; Tue, 9 Aug 2011 11:55:02 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id AE44A21F8BAE for ; Tue, 9 Aug 2011 11:55:02 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 9 Aug 2011 11:55:32 -0700 From: "Murray S. Kucherawy" To: "weirds@ietf.org" Date: Tue, 9 Aug 2011 11:55:30 -0700 Thread-Topic: New Version Notification for draft-kucherawy-weirds-requirements-01.txt Thread-Index: AcxWxWdMPwxz0lOZQgeoZiSQqpqrogAAHwrw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 18:55:03 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBBdWd1 c3QgMDksIDIwMTEgMTE6NTEgQU0NClRvOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpDYzogTXVycmF5 IFMuIEt1Y2hlcmF3eQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1rdWNoZXJhd3ktd2VpcmRzLXJlcXVpcmVtZW50cy0wMS50eHQNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWt1Y2hlcmF3eS13ZWlyZHMtcmVxdWlyZW1lbnRzLTAxLnR4dCBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE11cnJheSBLdWNoZXJhd3kgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWt1Y2hlcmF3eS13ZWly ZHMtcmVxdWlyZW1lbnRzDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBSZXF1aXJlbWVudHMgRm9y IEludGVybmV0IFJlZ2lzdHJ5IFNlcnZpY2VzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0wOC0wOQ0K V0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDcNCg0KQWJz dHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGVudW1lcmF0ZXMgYSBiYXNlIHNldCBvZiByZXF1aXJl bWVudHMgdGhhdCBzaG91bGQgYmUNCiAgIGluY2x1ZGVkIGluIGFueSBzeXN0ZW0gdGhhdCBwcm92 aWRlcyByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24gZm9yDQogICBJbnRlcm5ldCBlbnRpdGllcywg YmUgdGhleSBuZXR3b3JrIGFzc2lnbm1lbnRzIG9yIGRvbWFpbiBuYW1lDQogICBhc3NpZ25tZW50 cy4gIFNvbWUgb2YgdGhlc2UsIGluIHR1cm4sIHdpbGwgZGVmaW5lIHJlcXVpcmVtZW50cyBmb3IN CiAgIHJlZ2lzdHJhcnM7IHRoaXMsIGhvd2V2ZXIsIGlzIGFuIGlzc3VlIG91dHNpZGUgb2YgdGhl IHNjb3BlIG9mIHRoaXMNCiAgIGRvY3VtZW50Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From peter@denic.de Sat Aug 13 15:03:24 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2C321F85F2 for ; Sat, 13 Aug 2011 15:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmEA74cK0F91 for ; Sat, 13 Aug 2011 15:03:23 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 14AC521F86C2 for ; Sat, 13 Aug 2011 15:03:22 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QsMJE-0001K7-Ba; Sun, 14 Aug 2011 00:04:00 +0200 Received: from localhost by x27.adm.denic.de with local id 1QsMJE-0002QB-5k; Sun, 14 Aug 2011 00:04:00 +0200 Date: Sun, 14 Aug 2011 00:04:00 +0200 From: Peter Koch To: weirds@ietf.org Message-ID: <20110813220400.GJ11178@x27.adm.denic.de> References: 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 Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 22:03:24 -0000 On Tue, Aug 09, 2011 at 11:55:30AM -0700, Murray S. Kucherawy wrote: > Filename: draft-kucherawy-weirds-requirements > Revision: 01 > Title: Requirements For Internet Registry Services > Creation date: 2011-08-09 i have reviewed this updated version with the discussion in mind. The clarification in section 4.3 is a step forward, but still i think these operational and policy requirements, while representing a real constituency, need to be rephrased. > 2. Document Series > This memo represents the introduction to a series of others that > define the overall problem and some available solutions. The series > is as follows: > 1. RFCxxxx: Requirements for Internet Registry Services (this memo) > 2. RFCxxxx+1: The ICANN Internet Registry Service API > 3. RFCxxxx+2: The RIPE Internet Registry Service API > 4. RFCxxxx+3: The ARIN Internet Registry Service API > 5. RFCxxxx+4: RESTful WHOIS > The intent is to publish one of the API specifications as a standards > track document, and the remainder (including this memo) as > informational documents. Not sure the collection of API descriptions is sufficient to meet requirements either as layed out in this current version or any subsequent result of a potential working group, mostly because they appear kind of ready already. However, the headlines (related to the other drafts circulated before the bar bof meeting) implicitly state one requirement: if REST is the religion du jour, that's something to state. > 3.2. Incorporated Requirements > Many of the requirements distilled from the input provided by various > communities in [CRISP] will apply to this effort as well. It is > certainly the case that the research presented there should be > considered prerequisite reading for this new work. As discussed in Quebec, we'd probably need to have a walk-through of all the requirements and explicitly accept, modify and not the least abandon those listed in RFC 3707. > 4.1. Clients > The client-side requirements are as follows: > 1. To support internationalized values, a client SHOULD be able to > handle replies that contain data that are not exclusively 7-bit > clean. Agree. But it might be better to make this a requirement of the overall protocol rather than one side of the interaction, i.e., "the protocol MUST support i18n", or something along the lines of RFC 3707's section 3.2.9. > 2. A client SHOULD support caching of replies. It MAY apply its own > default and MAY use a time-to-live provided as part of the reply. Same here. If the client is expected to cache, the protocol MUST or SHOULD provide methods of cache-control. > 4.2. Servers > The server-side requirements are as follows: > 1. A server MUST be able to return internationalized data. see above. > 3. A server SHOULD be able to provide class-of-service facilities > for different types of users. At least the following cases need > to be considered: > anonymous: Users with no prior arrangement for access to the > data; typically all available data will be provided in > response to a query, but the query rate may be severely > limited. No authentication is typically required. > security: Users that have an interest in a specific subset of a > registration's data for the purpose of analysis and > correlation while evaluating the trustworthiness of the > source. Examples include email client evaluation, email > content evaluation, web site security, etc. The subset will > typically include creation/registration dates, assigned > nameserver names and IP addresses, registrar ID and registrant > ID. Users in this class would be required to authenticate in > some way, but such clients would not typically be subjected to > rate limiting given the prior arrangement. > law enforcement: Users with a bona fide interest in as much > registration data, including change history, as is available. > Typically, queries would be rare but have extremely high > priority. These clients would definitely require > authentication and probably also require encryption. This would mean the protocol has to support client authentication, integrity and transport confidentiality and in the end also data origin authentication. The protocol should support combinations thereof, but i'd rather not encode different classes of access a priori. > 6. A server MUST provide a minimum set of data about a given query. > It is expected that this minimum set will be different for a > network allocation registry than a domain name registry, however > the following MUST be provided: > * The creation date of the record > * The date on which the record most recently changed owners/ > registrants > * For domain name registration records, the identifier of the > registrar that created the record > * For domain name registration records, the identifier of the > registrant that created the record > * For network registration records, the size of the assigned > subnet in terms of a number of bits The way it is written makes it an operational or policy requirement that the IETF will have a hard time getting a say in. RFC 3707 chose a different approach that would require protocol features rather than service models. This is a crucial issue. I understand where you're coming from but the IETF is the wrong body (not implying a single such body exists) to mandate certain fields in a whois or "registration information service" output. -Peter From msk@cloudmark.com Sun Aug 14 20:25:18 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0501311E80A1 for ; Sun, 14 Aug 2011 20:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.066 X-Spam-Level: X-Spam-Status: No, score=-103.066 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmhYNT-529Ve for ; Sun, 14 Aug 2011 20:25:17 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 64DD811E8083 for ; Sun, 14 Aug 2011 20:25:17 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 14 Aug 2011 20:21:33 -0700 From: "Murray S. Kucherawy" To: "weirds@ietf.org" Date: Sun, 14 Aug 2011 20:21:33 -0700 Thread-Topic: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt Thread-Index: AcxaBO+jLIeRQAt0RjWoIFN6JRXphgA9HOGw Message-ID: References: <20110813220400.GJ11178@x27.adm.denic.de> In-Reply-To: <20110813220400.GJ11178@x27.adm.denic.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 03:25:18 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf = Of Peter Koch > Sent: Saturday, August 13, 2011 3:04 PM > To: weirds@ietf.org > Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy- > weirds-requirements-01.txt >=20 > Not sure the collection of API descriptions is sufficient to meet > requirements either as layed out in this current version or any > subsequent result of a potential working group, mostly because they > appear kind of ready already. > However, the headlines (related to the other drafts circulated before > the bar bof meeting) implicitly state one requirement: if REST is the > religion du jour, that's something to state. That certainly is the case, but that seemed to me to be inappropriate to sa= y in a requirements document. > As discussed in Quebec, we'd probably need to have a walk-through of all > the requirements and explicitly accept, modify and not the least abandon > those listed in RFC 3707. Fair enough. Who among us is sufficiently familiar with the output of CRIS= P to lead that effort? > Agree. But it might be better to make this a requirement of the overall > protocol rather than one side of the interaction, i.e., "the protocol > MUST support i18n", or something along the lines of RFC 3707's section > 3.2.9. Makes sense to me. (Same for your other "see above"s.) > > 3. A server SHOULD be able to provide class-of-service facilities > > for different types of users. At least the following cases need > > to be considered: >=20 > > anonymous: Users with no prior arrangement for access to the > > data; typically all available data will be provided in > > response to a query, but the query rate may be severely > > limited. No authentication is typically required. >=20 > > security: Users that have an interest in a specific subset of a > > registration's data for the purpose of analysis and > > correlation while evaluating the trustworthiness of the > > source. Examples include email client evaluation, email > > content evaluation, web site security, etc. The subset will > > typically include creation/registration dates, assigned > > nameserver names and IP addresses, registrar ID and registran= t > > ID. Users in this class would be required to authenticate in > > some way, but such clients would not typically be subjected t= o > > rate limiting given the prior arrangement. >=20 > > law enforcement: Users with a bona fide interest in as much > > registration data, including change history, as is available. > > Typically, queries would be rare but have extremely high > > priority. These clients would definitely require > > authentication and probably also require encryption. >=20 > This would mean the protocol has to support client authentication, integr= ity > and transport confidentiality and in the end also data origin authenticat= ion. > The protocol should support combinations thereof, but i'd rather not > encode different classes of access a priori. Also fair enough, though I think it might be beneficial to include these as= use cases rather than specific class-of-service requirements. > The way it is written makes it an operational or policy requirement > that the IETF will have a hard time getting a say in. RFC 3707 chose > a different approach that would require protocol features rather than > service models. This is a crucial issue. I understand where you're > coming from but the IETF is the wrong body (not implying a single such > body exists) to mandate certain fields in a whois or "registration > information service" output. I'm frankly a little worried that if the RFCs don't say something like this= , we can just say "Hi, WHOIS is now HTTP and XML," and we're finished. I s= uppose it's the "If it's not said here, where will it be said?" concern, si= nce I haven't heard for sure that ICANN plans to insist on a minimum field = set for specific classes of service from registrars or anything like that. It seems to me we're defining a service here, and defining some minima for = compliance isn't outside of the IETF's realm. But I'd be happy to hear of = a better solution that ensures this gets covered somewhere if not here. From sm@resistor.net Mon Aug 15 00:10:44 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC01611E808A for ; Mon, 15 Aug 2011 00:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfu-pNvlNCxw for ; Mon, 15 Aug 2011 00:10:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 727B411E8082 for ; Mon, 15 Aug 2011 00:10:41 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p7F7BHDh020297; Mon, 15 Aug 2011 00:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1313392282; bh=8pZk3uqvxi0hQWJJlK6/LrqZ8yoO+OKi3fd/qjXBjjA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=cklKcku7rTX5OMErbUT9h4rSuixVREyLIHou9KTeyM/RTs6uNzCovOMaG7+K6cqP0 xttFhQs44V2iYlHQVbGfHWZ8Pv6IpdKvk9Y97mOiPk8/s9fY+gV5/4xToMHz5jWyRW nsIo1mpY5HrLicgL7VytTVD3CiZQNu7cbT0bEkfA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1313392282; bh=8pZk3uqvxi0hQWJJlK6/LrqZ8yoO+OKi3fd/qjXBjjA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=KG8bRlQz3mBP9VZ9cRwmBbcumPJjUtZRcTRpQ1HcuWfiSB3NXFgxt3JP3o4V17e6g KXTQaigzePNMKZG/x1g/CsT2fum6LValzxFPDKl6ojQomlKHZCREfnAKnQvtqu4Pth oFuEGRh1pWn75KWSsEKDo9MB3LRKKHH0Heaq13ig= Message-Id: <6.2.5.6.2.20110814203227.0688db40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 15 Aug 2011 00:06:06 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <20110813220400.GJ11178@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 07:10:44 -0000 Hi Murray, At 20:21 14-08-2011, Murray S. Kucherawy wrote: >I'm frankly a little worried that if the RFCs don't say something >like this, we can just say "Hi, WHOIS is now HTTP and XML," and >we're finished. I suppose it's the "If it's not said here, where >will it be said?" concern, since I haven't heard for sure that ICANN >plans to insist on a minimum field set for specific classes of >service from registrars or anything like that. If the RFC includes operational requirements, it is "telling" operators what to do or it may be interpreted like that by some people. Determining the policy for domains is not an IETF decision. I suggest asking the policy makers about whether there are policies covering the data being provided through Whois. If that question cannot be resolved, you might as well settle for HTTP and XML. Regards, -sm From peter@denic.de Mon Aug 15 03:14:46 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BAD21F8B27 for ; Mon, 15 Aug 2011 03:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnRNX1iQ1dDh for ; Mon, 15 Aug 2011 03:14:46 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 332FB21F8B20 for ; Mon, 15 Aug 2011 03:14:46 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QsuCh-0005O5-0L; Mon, 15 Aug 2011 12:15:31 +0200 Received: from localhost by x27.adm.denic.de with local id 1QsuCg-000533-Ou; Mon, 15 Aug 2011 12:15:30 +0200 Date: Mon, 15 Aug 2011 12:15:30 +0200 From: Peter Koch To: weirds@ietf.org Message-ID: <20110815101530.GP11178@x27.adm.denic.de> References: <20110813220400.GJ11178@x27.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 Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 10:14:47 -0000 On Sun, Aug 14, 2011 at 08:21:33PM -0700, Murray S. Kucherawy wrote: > > However, the headlines (related to the other drafts circulated before > > the bar bof meeting) implicitly state one requirement: if REST is the > > religion du jour, that's something to state. > > That certainly is the case, but that seemed to me to be inappropriate to say in a requirements document. well, it should be possible to find some wording that doesn't predetermine the solution more than acceptable - maybe by listing difficulties that people experienced with (or didn't even bother to experience because they shied away from) IRIS. > > This would mean the protocol has to support client authentication, integrity > > and transport confidentiality and in the end also data origin authentication. > > The protocol should support combinations thereof, but i'd rather not > > encode different classes of access a priori. > > Also fair enough, though I think it might be beneficial to include these as use cases rather than specific class-of-service requirements. That would mean giving a rationale for the list of requirements? Sounds reasonable to me. > I'm frankly a little worried that if the RFCs don't say something like this, we can just say "Hi, WHOIS is now HTTP and XML," and we're finished. Besides the "transport" and the representation paradigm, the data model is very important as are the security properties of the protocol, both for transport and the objects. So, it's a bit more than http+xml, but i'd not expect the content of the data objects to be subject to mandatory protocol requirements. > I suppose it's the "If it's not said here, where will it be said?" concern, since I haven't heard for sure that ICANN plans to insist on a minimum field set for specific classes of service from registrars or anything like that. ICANN, for one, will have to do its policy work no matter what. The topic of whois has been on ICANN's agenda since its inception and it won't be solved by throwing it over the fence into the IETF's garden and then re-importing policy declared as technical requirements. Also, ICANN is only responsible for part of the spectrum, still bound by different legislations. The RIRs and ccTLDs and potentially a fair number of "new" TLDs will have to adhere to their own policy development processes and local legislation. And here we are back to square one: did IRIS really "fail" and why? -Peter From steve.sheng@icann.org Mon Aug 15 13:27:11 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15B21F8C4E for ; Mon, 15 Aug 2011 13:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPvgsqA5E95T for ; Mon, 15 Aug 2011 13:27:11 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0B09B21F8C07 for ; Mon, 15 Aug 2011 13:27:11 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 15 Aug 2011 13:27:57 -0700 From: Steve Sheng To: Peter Koch , "weirds@ietf.org" Date: Mon, 15 Aug 2011 13:27:55 -0700 Thread-Topic: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt Thread-Index: AcxbNFGluxfNPo5mRhGSO1erzOXSjgAVX6nV Message-ID: In-Reply-To: <20110815101530.GP11178@x27.adm.denic.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 20:27:11 -0000 On 8/15/11 3:15 AM, "Peter Koch" wrote: >> I'm frankly a little worried that if the RFCs don't say something like t= his, >> we can just say "Hi, WHOIS is now HTTP and XML," and we're finished. >=20 > Besides the "transport" and the representation paradigm, the data model > is very important as are the security properties of the protocol, both fo= r > transport and the objects. So, it's a bit more than http+xml, but i'd no= t > expect the content of the data objects to be subject to mandatory protoco= l > requirements. >=20 I agree with Peter that content of the data is an ICANN issue not an IETF issue. There are a lot of issues with WHOIS, but it is important to separat= e the policy issues / protocol issues. In WHOIS, there are three elements: registration data, protocol and services.=20 Regarding the registration data. Today, there is no overarching policy on what they include / their purposes are. Currently the RAA (registrar Accreditation agreement between ICANN and registrars identify what they are= ) and ccTLD operators define their own policies. Whether to require a minimum set is a very good question, however it is a policy question, and I conside= r it out of scope here. What is perhaps within the scope is to make sure that the schema / data model is structured and extensible. Regarding the policies that operators set for the WHOIS service (rate limit= , availability), I sense the frustration is that there is much variability in terms of the service offered. However, these are again primarily policy questions, not technical ones. >From a protocol perspective, instead of dictating policy, perhaps we should think about enabling policy. For example the rate limit debate highlights that there are different classes of users that have different query needs, perhaps it is useful to have features in the protocol to distinguish them and allow operators to apply different limits to different types of users and (could even charge some of them, here again a policy and market question).=20 Thoughts?=20 Steve >> I suppose it's the "If it's not said here, where will it be said?" conc= ern, >> since I haven't heard for sure that ICANN plans to insist on a minimum f= ield >> set for specific classes of service from registrars or anything like tha= t. >=20 > ICANN, for one, will have to do its policy work no matter what. The topi= c of > whois has been on ICANN's agenda since its inception and it won't be solv= ed > by throwing it over the fence into the IETF's garden and then re-importin= g > policy declared as technical requirements. Also, ICANN is only responsib= le > for part of the spectrum, still bound by different legislations. The RIR= s and > ccTLDs and potentially a fair number of "new" TLDs will have to adhere to > their > own policy development processes and local legislation. >=20 > And here we are back to square one: did IRIS really "fail" and why? >=20 > -Peter From peter@denic.de Mon Aug 15 21:49:08 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0454821F87F9 for ; Mon, 15 Aug 2011 21:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LFdDrv9P2oi for ; Mon, 15 Aug 2011 21:49:07 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 76B7521F8B61 for ; Mon, 15 Aug 2011 21:49:07 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QtBb6-00047Q-Uw; Tue, 16 Aug 2011 06:49:53 +0200 Received: from localhost by x27.adm.denic.de with local id 1QtBb6-0004es-No; Tue, 16 Aug 2011 06:49:52 +0200 Date: Tue, 16 Aug 2011 06:49:52 +0200 From: Peter Koch To: weirds@ietf.org Message-ID: <20110816044952.GT11178@x27.adm.denic.de> References: <20110815101530.GP11178@x27.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 Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 04:49:08 -0000 On Mon, Aug 15, 2011 at 01:27:55PM -0700, Steve Sheng wrote: > I agree with Peter that content of the data is an ICANN issue not an IETF small clarification: the emphasis is on "not IETF"; whether or not it's ICANN's game depends on a number of factors. The fact of the matter ist there is not a single body "to rule them all". > What is perhaps within the scope is to make sure that the schema / data > model is structured and extensible. Absolutely. Attributes/fields or objcts need to be recognized as optional. Otherwise people might follow the syntax but will have to provide N/A or something similar. > perhaps it is useful to have features in the protocol to distinguish them > and allow operators to apply different limits to different types of users > and (could even charge some of them, here again a policy and market > question). Sure, that would be covered by Murray's use cases. Again, IRIS had provisions in that direction and the reason it was not (or not widely?) implemented is not obviously technical. -Peter From dave.piscitello@icann.org Tue Aug 16 14:13:42 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B5511E808E for ; Tue, 16 Aug 2011 14:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db3E1KNKLSMr for ; Tue, 16 Aug 2011 14:13:41 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id A177121F8B5A for ; Tue, 16 Aug 2011 14:13:41 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 16 Aug 2011 14:14:31 -0700 From: Dave Piscitello To: Steve Sheng Date: Tue, 16 Aug 2011 14:14:30 -0700 Thread-Topic: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt Thread-Index: AcxcWX0eSSZ5BVx7R66Sh9XvtV3wEg== Message-ID: <7EC97FB8-8A7E-4ABE-AA24-5AA07971387D@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Peter Koch , "weirds@ietf.org" Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:13:42 -0000 On Aug 15, 2011, at 4:27 PM, Steve Sheng wrote: > On 8/15/11 3:15 AM, "Peter Koch" wrote: >=20 >>> I'm frankly a little worried that if the RFCs don't say something like = this, >>> we can just say "Hi, WHOIS is now HTTP and XML," and we're finished. >>=20 >> Besides the "transport" and the representation paradigm, the data model >> is very important as are the security properties of the protocol, both f= or >> transport and the objects. So, it's a bit more than http+xml, but i'd n= ot >> expect the content of the data objects to be subject to mandatory protoc= ol >> requirements. >>=20 >=20 > I agree with Peter that content of the data is an ICANN issue not an IETF > issue. There are a lot of issues with WHOIS, but it is important to separ= ate > the policy issues / protocol issues. Actually, isn't the content a matter that is administrative domain specific= ? In the case of domain name registries, the ICANN community makes policy r= egarding domain registration data. In the case of Internet addressing regis= tries, the ASO/RIRs do. But while these are the most popularly known WHOIS = deployments, neither the framework nor the protocol ought to impose restric= tions on the data elements that comprise a given instance of "directory ser= vice data". (So IMO it would be perfectly appropriate to have several data models/defin= itions). From dave.piscitello@icann.org Tue Aug 16 14:16:57 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A3F11E808F for ; Tue, 16 Aug 2011 14:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8ct0rEPpirg for ; Tue, 16 Aug 2011 14:16:56 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id DD7B321F8B5A for ; Tue, 16 Aug 2011 14:16:56 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 16 Aug 2011 14:17:45 -0700 From: Dave Piscitello To: Peter Koch Date: Tue, 16 Aug 2011 14:17:44 -0700 Thread-Topic: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt Thread-Index: AcxcWfD2MFvoDqT2SAi8Og19PXpS2A== Message-ID: <66E4DDE3-4F48-44AE-8410-A52F5493A718@icann.org> References: <20110813220400.GJ11178@x27.adm.denic.de> In-Reply-To: <20110813220400.GJ11178@x27.adm.denic.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_66E4DDE34F4844AE8410A52F5493A718icannorg_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:16:57 -0000 --_000_66E4DDE34F4844AE8410A52F5493A718icannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 13, 2011, at 6:04 PM, Peter Koch wrote: . A server SHOULD be able to provide class-of-service facilities for different types of users. At least the following cases need to be considered: anonymous: Users with no prior arrangement for access to the data; typically all available data will be provided in response to a query, but the query rate may be severely limited. No authentication is typically required. security: Users that have an interest in a specific subset of a registration's data for the purpose of analysis and correlation while evaluating the trustworthiness of the source. Examples include email client evaluation, email content evaluation, web site security, etc. The subset will typically include creation/registration dates, assigned nameserver names and IP addresses, registrar ID and registrant ID. Users in this class would be required to authenticate in some way, but such clients would not typically be subjected to rate limiting given the prior arrangement. law enforcement: Users with a bona fide interest in as much registration data, including change history, as is available. Typically, queries would be rare but have extremely high priority. These clients would definitely require authentication and probably also require encryption. This would mean the protocol has to support client authentication, integrit= y and transport confidentiality and in the end also data origin authenticatio= n. The protocol should support combinations thereof, but i'd rather not encode different classes of access a priori. A question here. Is it the protocol or the framework that has to support th= ese facilities/services? For example, I could envision "XML over HTTPS" cou= ld satisfy encryption and server authentication, and where different servic= e providers could employ subauthentication methods common to SSL as they c= hoose (much as people use SSL today to support "extranets" and "intranets")= . Am I thinking outside the parameters here? --_000_66E4DDE34F4844AE8410A52F5493A718icannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Aug 13, 2= 011, at 6:04 PM, Peter Koch wrote:

. &= nbsp;A server SHOULD be able to provide class-of-service facilities
      for = different types of users.  At least the following cases need
      to be = considered:

   = ;   anonymous:  Users with no prior arrangement for acc= ess to the
   &nbs= p;     data; typically all available data will be = provided in
   &nb= sp;     response to a query, but the query rate ma= y be severely
   &= nbsp;     limited.  No authentication is typi= cally required.

  &= nbsp;   security:  Users that have an interest in a spe= cific subset of a
  &nb= sp;      registration's data for the purpose = of analysis and
   = ;      correlation while evaluating the trust= worthiness of the
  &nb= sp;      source.  Examples include email= client evaluation, email
 &= nbsp;       content evaluation, web site= security, etc.  The subset will
         typically includ= e creation/registration dates, assigned
         nameserver nam= es and IP addresses, registrar ID and registrant
         ID. &= nbsp;Users in this class would be required to authenticate in
       &nbs= p; some way, but such clients would not typically be subjected to
<= /blockquote>
      &= nbsp;  rate limiting given the prior arrangement.

      law enfo= rcement:  Users with a bona fide interest in as much
<= blockquote type=3D"cite">        &n= bsp;registration data, including change history, as is available.
       =   Typically, queries would be rare but have extremely high
      &nb= sp;  priority.  These clients would definitely require
      &n= bsp;  authentication and probably also require encryption.

This would mean the protocol has to support client authentica= tion, integrity
and transport confidentiality and in the end also data o= rigin authentication.
The protocol should support combinations thereof, = but i'd rather not
encode different classes of access a priori.

A question here. Is it the protocol or = the framework that has to support these facilities/services? For example, I= could envision "XML over HTTPS" could satisfy encryption and server authen= tication, and where different service providers could employ  subauthe= ntication methods common to SSL as they choose (much as people use SSL toda= y to support "extranets" and "intranets"). Am I thinking outside the parame= ters here?

= --_000_66E4DDE34F4844AE8410A52F5493A718icannorg_-- From bill.smith@paypal-inc.com Tue Aug 16 14:42:49 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D8611E80FF for ; Tue, 16 Aug 2011 14:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.224 X-Spam-Level: X-Spam-Status: No, score=-8.224 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J332m2HXGsbM for ; Tue, 16 Aug 2011 14:42:49 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2B88711E80F9 for ; Tue, 16 Aug 2011 14:42:49 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:Received: From:To:CC:Date:43:Subject:Thread-Topic:Thread-Index: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: acceptlanguage:Content-Type:Content-Transfer-Encoding: MIME-Version:Return-Path:X-EMS-Proccessed:X-EMS-STAMP: X-CFilter; b=v6nk3aEWOi8wk+qOOkA1izykD0TJ4P+qovMOub1r3zg4NTZP8vnm616F q6IX9o2d8tJCfOcbtnXkGIm6tzDO4vV5Ra+kZcYej2HWL+elDCV0jfvvI yPzMRt/a1BiRNws; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bill.smith@paypal-inc.com; q=dns/txt; s=ppinc; t=1313531019; x=1345067019; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CM66atpPjw9uxhARmsBZMx0cCFpUIKBbKrIqk0pcQJs=; b=a1FyxuDvFjNDgPyQXOc1dVWlssh3mpzyB8+YlPsd/QXsbzG32MTKBkAs mWC5wbEjj8gsiMZxIGArwzPhwIfsXsXrMq22fl2Y3NlJ3U+jGFxfk4OLs VQbyK1nMbBvY8ms; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.68,236,1312182000"; d="scan'208";a="3078092" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 16 Aug 2011 14:43:39 -0700 Received: from DEN-MEXHT-004.corp.ebay.com (10.241.17.60) by DEN-MEXHT-003.corp.ebay.com (10.241.17.54) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 16 Aug 2011 15:43:13 -0600 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-004.corp.ebay.com ([10.241.17.60]) with mapi; Tue, 16 Aug 2011 15:43:13 -0600 From: "Smith, Bill" To: Dave Piscitello Date: Tue, 16 Aug 2011 15:43:11 -0600 Thread-Topic: [weirds] New Version Notification for draft-kucherawy-weirds-requirements-01.txt Thread-Index: AcxcXX+ouVJo3TJkQDeqvNRd+h+OVw== Message-ID: <4EC5464C-D5D6-4B22-86FC-E9A6B5954F0E@paypal.com> References: <20110813220400.GJ11178@x27.adm.denic.de> <66E4DDE3-4F48-44AE-8410-A52F5493A718@icann.org> In-Reply-To: <66E4DDE3-4F48-44AE-8410-A52F5493A718@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMS-Proccessed: 10SqDH0iR7ekR7SRpKqm5A== X-EMS-STAMP: 1DDRkP8dK7oudKX84+lf0A== X-CFilter: Scanned Cc: Peter Koch , "weirds@ietf.org" Subject: Re: [weirds] New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:42:50 -0000 On Aug 16, 2011, at 2:17 PM, Dave Piscitello wrote: >=20 > A question here. Is it the protocol or the framework that has to support = these facilities/services? For example, I could envision "XML over HTTPS" c= ould satisfy encryption and server authentication, and where different serv= ice providers could employ subauthentication methods common to SSL as they= choose (much as people use SSL today to support "extranets" and "intranets= "). Am I thinking outside the parameters here? >=20 I think you're well within the parameters of a reasonable discussion on the= future of WHOIS. IMO, what will be important is picking/establishing a data model, either ex= tensible or a set of models for the "common" uses. From a user's perspectiv= e, it would be nice if there was significant overlap in these models. It'd = be equally useful to have the presentation be as similar as possible, again= from the perspective of the user. I'm not suggesting a *requirement* that = all presentations be identical, but rather suggesting that we consider the = uninformed user of WHOIS as we move forward and recognize that what me obvi= ous to the well-informed, is positively opaque to others. (User experience is too often overlooked (rough) Uniformity in the model and presentation of WHOIS data would be a r= efreshing change from a number of perspectives. As for transport, I'd suggest that any forward-looking "protocol" be transp= ort independent. HTTPS is a fin protocol. So is SMTP. When it comes to authentication, I'm less sanguine about our ability to com= e up with a mechanism that will prove operationally feasible at Internet sc= ale. (So it's probably best to leave that to someone else.)= From dave.piscitello@icann.org Tue Aug 16 15:10:02 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA5821F86AC for ; Tue, 16 Aug 2011 15:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.666 X-Spam-Level: X-Spam-Status: No, score=-5.666 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVmXj44wJzsV for ; Tue, 16 Aug 2011 15:09:49 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 8E82221F85EC for ; Tue, 16 Aug 2011 15:09:49 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 16 Aug 2011 15:10:38 -0700 From: Dave Piscitello To: "Smith, Bill" Date: Tue, 16 Aug 2011 15:10:38 -0700 Thread-Topic: [weirds] New Version Notification for draft-kucherawy-weirds-requirements-01.txt Thread-Index: AcxcYVSriPjCQE/YSe6niCFCOyH4Ow== Message-ID: References: <20110813220400.GJ11178@x27.adm.denic.de> <66E4DDE3-4F48-44AE-8410-A52F5493A718@icann.org> <4EC5464C-D5D6-4B22-86FC-E9A6B5954F0E@paypal.com> In-Reply-To: <4EC5464C-D5D6-4B22-86FC-E9A6B5954F0E@paypal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Peter Koch , "weirds@ietf.org" Subject: Re: [weirds] New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:10:02 -0000 X-List-Received-Date: Tue, 16 Aug 2011 22:10:02 -0000 On Aug 16, 2011, at 5:43 PM, Smith, Bill wrote: >=20 > On Aug 16, 2011, at 2:17 PM, Dave Piscitello wrote: >=20 >>=20 >> A question here. Is it the protocol or the framework that has to support= these facilities/services? For example, I could envision "XML over HTTPS" = could satisfy encryption and server authentication, and where different ser= vice providers could employ subauthentication methods common to SSL as the= y choose (much as people use SSL today to support "extranets" and "intranet= s"). Am I thinking outside the parameters here? >>=20 >=20 > I think you're well within the parameters of a reasonable discussion on t= he future of WHOIS. Thanks for this. >=20 > IMO, what will be important is picking/establishing a data model, either = extensible or a set of models for the "common" uses. From a user's perspect= ive, it would be nice if there was significant overlap in these models. It'= d be equally useful to have the presentation be as similar as possible, aga= in from the perspective of the user. I'm not suggesting a *requirement* tha= t all presentations be identical, but rather suggesting that we consider th= e uninformed user of WHOIS as we move forward and recognize that what me ob= vious to the well-informed, is positively opaque to others. >=20 > (User experience is too often overlooked >=20 > (rough) Uniformity in the model and presentation of WHOIS data would be a= refreshing change from a number of perspectives. Share the user perspective frequently:-) >From your comment I am speculating that a common set of data elements for "= contact data" used uniformly across registries might be desirable. Sub-elem= ents of these data might, for example, follow conventions prescribed by pos= tal, telephony, and internet protocol (e.g., email) standards. Similarly, c= onventions for internationalized domain names (A-label and U-label) would a= lso be desirable. >=20 > As for transport, I'd suggest that any forward-looking "protocol" be tran= sport independent. HTTPS is a fin protocol. So is SMTP. Here, I think you mean that the framework should separate data from transpo= rt, and that the framework should accommodate any protocol that satisfies t= he transport service requirements (Sorry to sound so "OSI" about this). >=20 > When it comes to authentication, I'm less sanguine about our ability to c= ome up with a mechanism that will prove operationally feasible at Internet = scale. (So it's probably best to leave that to someone else.) Defining authentication methods that prove operationally feasible at Intern= et scale represents one end of the design spectrum and yes, we don't know h= ow to do that today. Defining a framework that accommodates the selected us= e of authentication, even if it is for specific access controlled circumsta= nces of a much smaller scale, seems to be useful (and not merely an exercis= e). From Jeff.Hodges@KingsMountain.com Tue Aug 16 16:45:25 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3E811E80FC for ; Tue, 16 Aug 2011 16:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.271 X-Spam-Level: X-Spam-Status: No, score=-101.271 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU191QWXi3vY for ; Tue, 16 Aug 2011 16:45:24 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id C4D5011E80F8 for ; Tue, 16 Aug 2011 16:45:24 -0700 (PDT) Received: (qmail 29241 invoked by uid 0); 16 Aug 2011 23:46:14 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 16 Aug 2011 23:46:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=rZ+kOARpI3VhgaF8ZSUHwEuCX5HiICjJ8O+pK4FNJJA=; b=C4aa9Vw/cVTOyOtifUengxSOrtFIwqGu5WY/YzMl1ImVa00K4ay3vle5ZxAU9XwDUIJze5lkmwkiMaVEEJhTgvGgEjHe2+DzE2IscXXNXGLzgqWxCQLqy7H6HbY++HSr; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.156]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1QtTKo-0004MQ-1K; Tue, 16 Aug 2011 17:46:14 -0600 Message-ID: <4E4B0145.5050503@KingsMountain.com> Date: Tue, 16 Aug 2011 16:46:13 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: weirds@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [weirds] My notes from WEIRDS bar BOF @ IETF-81 Quebec (updated) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 23:45:25 -0000 some modest updates from my notes. HTH, =JeffH > ************************************************************************* > > Rough Number of Attendees: 40 Requirements document (Murray K.): http://tools.ietf.org/html/draft-kucherawy-weirds-requirements > > Pete R. asked that this has been done in the past (IRIS), and there is > little adoption, why would this time be different? > > - Andy mentioned that technically speaking IRIS is heavy weight. One of the > reasons that hindered IRIS's adoption is that it uses NAPTR. IRIS also uses > BEEP for transport as they were not allowed to use HTTP at the time. This > made it difficult to write clients and servers for IRIS. Compared with > IRIS, the RESTful approach reuses the HTTP component, and it does not use > NAPTR. Andy also noted that ARIN's perspective is that when they impl'd their restful service and deployed it, they realized it could change, and so "..as long as things don't go completely off the rails [with something even newer], we're good." See message attached below wrt IRIS experience, and also this I-D.. ARIN's RESTful Web Service for Whois Data http://tools.ietf.org/html/draft-newton-weirds-arin-whoisrws > - Steve S mentioned that ICANN's is looking to improve WHOIS including > support for internationalized registration data. They looked at several > alternatives (extending WHOIS, IRIS, RWS), and thought that the RESTful > approach by ARIN is most promising. So they did a pilot (documented in the > internet draft) to understand RWS better. Also, their approach is somewhat different than ARIN's. [ RWS == "Restful Web Service" ? ] See.. A RESTful Web Service for Domain Name Registration Data (RWS-DNRD) http://tools.ietf.org/html/draft-newton-weirds-arin-whoisrws-00 > Participants discussed what are the problems to solve, and listed four: > > - standardized/machine parsable output. > > - support internationalized registration data > > - Be able to support different users aka differentiation of service based on requestors > - Better referral features Koster: navigation (eg referrals) [ these four issues were allegedly addressed in the crisp / iris work > Pete R. asked if we developed this, would there be people willing to write > clients? Who are the consumers? Are there any evidence that _client_ people > want this? > > - Jeff H. mentioned that they rely on this data heavily, and they would > write clients to use it. - Murray K. concurred. > - Peter K. disagreed, "it only benefits secondary domain industries, and > that the end user is ok with the current status quo." > > - the area directors would like to move this conversation onto the mailing > list to make sure that there will actually be people willing to write > clients for it, and people actually willing to use it. > > > Someone raised whether it make sense to do IRIS over HTTP? > > - Andy mentioned that IRIS is tied to XML, and if alternative formats are > desired (JSON), then IRIS over HTTP might not work. > > > Andrew S. asked if people have any comments for the drafts? > > - One comment, there is no schema for ARIN's draft. Harald A. asked Andy to > take an action item to add schema to ARIN's draft. > > - Peter K. mentioned that there is a need to separate policy from > technical. In particular, the draft requirement document seems to be mixing > policy requirements with technical ones. We need to answer (Peter K's) question: "why would a registry deploy this?" The requirements > > Andrew S. asked if people are willing to work on it and review drafts? > > - About 10 people raised their hands. > > ************************************************************************* > > > On 7/29/11 1:25 PM, "Andy Newton" wrote: > >> >> On Jul 28, 2011, at 7:55 PM, =JeffH wrote: >> >>> I spose we oughta ask "what /did/ happen with IRIS deployment and what >>> would you do differently if you did it over again?".... >>> >>> IRIS - An Overview for the ICANN Whois Task Force Andrew Newton, >>> VeriSign Labs Leslie Daigle, VeriSign Labs April 29, 2004 >>> http://gnso.icann.org/mailing-lists/archives/dow1tf/pdfXH57SShw9O.pdf >> >> Perhaps people didn't like the font weight and accent color of the slide >> presentation? :) >> >> VeriSign did have a pilot IRIS server refreshed daily with data from >> their registry up and running, in addition to their previous Whois-LDAP >> server pilot up and running. Neither saw much traffic. >> >> As an exercise as to why, I suggest you spend one hour attempting to >> construct a simple IRIS client to query for information about a domain >> name. For comparison, also spend one hour attempting to construct a simple >> Whois-RWS client to query an IP address from ARIN's Whois restful web >> service. >> >> -andy > > From peter@denic.de Wed Aug 17 01:30:55 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC321F8B38 for ; Wed, 17 Aug 2011 01:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwnsXq8p6nHS for ; Wed, 17 Aug 2011 01:30:55 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id D46A721F8B2F for ; Wed, 17 Aug 2011 01:30:54 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QtbXN-0005yq-4D; Wed, 17 Aug 2011 10:31:45 +0200 Received: from localhost by x27.adm.denic.de with local id 1QtbXN-0004oE-0M; Wed, 17 Aug 2011 10:31:45 +0200 Date: Wed, 17 Aug 2011 10:31:44 +0200 From: Peter Koch To: weirds@ietf.org Message-ID: <20110817083144.GF11178@x27.adm.denic.de> References: <20110813220400.GJ11178@x27.adm.denic.de> <66E4DDE3-4F48-44AE-8410-A52F5493A718@icann.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66E4DDE3-4F48-44AE-8410-A52F5493A718@icann.org> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 08:30:55 -0000 {hand edited the slightly broken quotation levels} On Tue, Aug 16, 2011 at 02:17:44PM -0700, Dave Piscitello wrote: > On Aug 13, 2011, at 6:04 PM, Peter Koch wrote: > > This would mean the protocol has to support client authentication, integrity > > and transport confidentiality and in the end also data origin authentication. > > The protocol should support combinations thereof, but i'd rather not > > encode different classes of access a priori. > A question here. Is it the protocol or the framework that has to support these facilities/services? For example, I could envision "XML over HTTPS" could satisfy encryption and server authentication, and where different service providers could employ subauthentication methods common to SSL as they choose (much as people use SSL today to support "extranets" and "intranets"). Am I thinking outside the parameters here? you may just have read "protocol" more strict than i had intended. I hadn't implied that that happen at the transport level, but no matter where, the WHOISng (if any) would have to define the bindings and semantics. This is probably already to far in the detail for the first round of requirements. -Peter From aservin@lacnic.net Wed Aug 17 06:25:36 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF4521F8B71 for ; Wed, 17 Aug 2011 06:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.215 X-Spam-Level: X-Spam-Status: No, score=-0.215 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci1dZ-mJ94fi for ; Wed, 17 Aug 2011 06:25:35 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8D19521F8B62 for ; Wed, 17 Aug 2011 06:25:35 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.78]) by mail.lacnic.net.uy (Postfix) with ESMTP id E817330845F; Wed, 17 Aug 2011 10:26:00 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <4EC5464C-D5D6-4B22-86FC-E9A6B5954F0E@paypal.com> Date: Wed, 17 Aug 2011 10:25:52 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110813220400.GJ11178@x27.adm.denic.de> <66E4DDE3-4F48-44AE-8410-A52F5493A718@icann.org> <4EC5464C-D5D6-4B22-86FC-E9A6B5954F0E@paypal.com> To: "Smith, Bill" X-Mailer: Apple Mail (2.1084) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: Peter Koch , "weirds@ietf.org" Subject: Re: [weirds] New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 13:25:36 -0000 On 16 Aug 2011, at 18:43, Smith, Bill wrote: >=20 > On Aug 16, 2011, at 2:17 PM, Dave Piscitello wrote: >=20 >>=20 >> A question here. Is it the protocol or the framework that has to = support these facilities/services? For example, I could envision "XML = over HTTPS" could satisfy encryption and server authentication, and = where different service providers could employ subauthentication = methods common to SSL as they choose (much as people use SSL today to = support "extranets" and "intranets"). Am I thinking outside the = parameters here? >>=20 >=20 > I think you're well within the parameters of a reasonable discussion = on the future of WHOIS. >=20 > IMO, what will be important is picking/establishing a data model, = either extensible or a set of models for the "common" uses. Or both. I was thinking in: a set of common and extensible objects =09 extensible objects to accomodate any data that don't fit in the = defined common (and extensible) objects. May be I am naive, but as user (not data producer) is what I = would like to have.=20 > =46rom a user's perspective, it would be nice if there was significant = overlap in these models. It'd be equally useful to have the presentation = be as similar as possible, again from the perspective of the user. I'm = not suggesting a *requirement* that all presentations be identical, but = rather suggesting that we consider the uninformed user of WHOIS as we = move forward and recognize that what me obvious to the well-informed, is = positively opaque to others. >=20 > (User experience is too often overlooked >=20 > (rough) Uniformity in the model and presentation of WHOIS data would = be a refreshing change from a number of perspectives. >=20 > As for transport, I'd suggest that any forward-looking "protocol" be = transport independent. HTTPS is a fin protocol. So is SMTP. >=20 > When it comes to authentication, I'm less sanguine about our ability = to come up with a mechanism that will prove operationally feasible at = Internet scale. (So it's probably best to leave that to someone else.) Regards, .as From andy@arin.net Wed Aug 17 12:54:39 2011 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EFE1F0C4B for ; Wed, 17 Aug 2011 12:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCFgcbSkDm-w for ; Wed, 17 Aug 2011 12:54:38 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBA61F0C47 for ; Wed, 17 Aug 2011 12:54:38 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 2808F164F88; Wed, 17 Aug 2011 15:55:23 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 05A8C164F5D; Wed, 17 Aug 2011 15:55:23 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 17 Aug 2011 15:54:57 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.118]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.01.0270.001; Wed, 17 Aug 2011 15:55:09 -0400 From: Andy Newton To: Peter Koch Thread-Topic: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt Thread-Index: AQHMW9AMKlMLIefLpUCeCChDJ5alQ5Uhuo8A Date: Wed, 17 Aug 2011 19:55:09 +0000 Message-ID: <704AC1A9-B70C-4852-B04F-3839B7DFE47C@arin.net> References: <20110815101530.GP11178@x27.adm.denic.de> <20110816044952.GT11178@x27.adm.denic.de> In-Reply-To: <20110816044952.GT11178@x27.adm.denic.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.203] Content-Type: text/plain; charset="us-ascii" Content-ID: <28CD1C24786BB945BF60A3E3F5A98947@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 19:54:39 -0000 On Aug 16, 2011, at 12:49 AM, Peter Koch wrote: >> perhaps it is useful to have features in the protocol to distinguish the= m >> and allow operators to apply different limits to different types of user= s >> and (could even charge some of them, here again a policy and market >> question).=20 >=20 > Sure, that would be covered by Murray's use cases. Again, IRIS had provi= sions > in that direction and the reason it was not (or not widely?) implemented > is not obviously technical. We could probably short circuit the need to make these types of requirement= s by stating that this will be a REST system using HTTP, and the base of su= ch features are already found in HTTP. In my experience with ARIN's Whois-R= WS, there is only one such feature not present in HTTP that needed to be pl= aced at another layer, which was specifying that a result set had been limi= ted in size. If you look at the IRIS stack, you'll find that many of the fe= atures in the "IRIS" layer already exist in HTTP. This is one of the reason= s why re-use of HTTP is so compelling and implementing IRIS is a bit more o= f a hill to climb. -andy=